Contract negotiations key to the right data system
13 tips for making sure a vendor works for you
It’s your money. You are entitled to get what you want when negotiating a contract, especially one for a new data system for your home health organization.
Despite what you may hear from a software vendor, you don’t have to do business their way. If your home health agency is willing to commit the time and a substantial chunk of financial resources to improving information systems, then as a director, you must make certain you get what you pay for.
"Contract negotiations are not to be taken lightly," cautions Bobbie Nehez, director of information systems for CCF Health Care Ventures in Cleveland. "Put it down in writing."
As managed care stakes a bigger claim in the home health industry, the burden will be on agencies and their directors to reduce costs, improve quality, and facilitate access to information. Technology is a logical way to achieve that. It can replace the paper trail with "paperless" systems, letting home care agencies reduce data duplication and improve care through data sharing. Elements such as clinical documentation, payroll and billing, disease state management, and care paths can be brought on line, yet reaching such a technological nirvana is never as easy as vendors make it sound.
Nehez has been in charge of CCF Health Care Ventures’ information systems for just over a year. CCF Health Care Ventures is one of the top 25 home care agencies in the country, and is a wholly owned subsidiary of The Cleveland Clinic Foundation. "[Home care systems automation] is in its embryonic state, and there are a lot of vendors who are capitalizing on that."
The computer industry has been quick to develop home care information systems in response to managed care demands to control costs. There is much to choose from, and Nehez urges caution, whether you want custom-designed computer programs or are ready to buy an application off the shelf.
She warns home care providers to remember that while the agency commits itself to technology for the long run, vendors don’t always look at it that way. A software program is only as good as the support your vendor provides. "Do business with ones that will service you ongoing, the way you want to be serviced," she says. "Ongoing support must be scrutinized."
A few years ago, Nehez says, developers of automated systems pretty much dictated to the purchaser what the support agreement would be. Yet now, with the proliferation of vendors in the marketplace, shoppers can demand more. "Competition makes them provide more services," she observes.
In addition to implementation costs, there are support costs as well. Nehez recommends determining the bottom-line cost of a system first. That means the cost of the hardware, software, and personnel.
Ask questions, Nehez advises. How many users do you have? Where will they reside in the same building, or at different locations throughout the country? What do the users need at the workstation level, what kind of file server is needed, and what features and functionalities do you require?
Time is money
Don’t overlook personnel costs. "How many full-time [information systems] people do you need for ongoing support? That’s another bottom-line cost," says Nehez, explaining that a salary may add $50,000 in annual cost to the project. And there are always licensing costs. "Suppose you pay $1,500 per user license," says Nehez. "Well, if you have 10 people using it, that’s 10 times $1,500."
Time is money. In automating information systems, the agency hopes to realize savings by using fewer people to do the job faster, says Nehez. That is the benchmark. And the contract is crucial to helping an agency achieve its automation aims.
Negotiate, preferably through your own attorney, for what you want. Don’t be rushed. Although most contract talks take only a few weeks, it is not unusual for some negotiations to last as long as four months, Nehez says. After all, the whole idea behind information automation is to make you more competitive. The last thing you need is to sign an agreement that favors the vendor more than your own agency.
To help avoid this, Nehez has developed the following proposal checklist for dealing with vendors, a set of dos and don’ts that also can be used to form the foundation of the contract:
1. Define what the user wants.
"A standard vendor contract is kind of one-sided," says Nehez. "Vendors expect you to pay quickly, adding late fees and all that, but their attitude is, We’ll do our best to fix it.’ I say, OK, I’ll do my best to pay you.’"
2. Avoid a time-and-materials contract.
"Go for fixed bids," Nehez advises. "There’s no reason to do business any other way. Otherwise, you won’t have a prayer of staying within your budget."
3. Shop around.
Get three or four bids. "See who you are comfortable doing business with," Nehez says. Sometimes that might mean the vendor you like is more expensive than others, but still is worth it. And you can always use that as a negotiating tool. Tell the costlier vendor you can get it cheaper somewhere else. The vendor may lower the price.
4. Negotiate not only how much you will pay, but when.
Once you and the vendor have agreed on the product you want and have defined this in writing, Nehez suggests paying the vendor 40% of the contract price when implementation begins. After that, the system must be tested. It should pass a unit test as well as an integrated test, explains Nehez. "Each module should function alone and as part of a computer network."
After testing, "you can sign off on it and pay another 10%," she says. Then pay 10% more once staff training and roll-out are completed.
"There should be a stabilization period for any issues that arise," Nehez says, noting that issues will always come up with new technology. A vendor should address these problems quickly and fix them at no charge. Keep the vendor "at your beck and call" for a least a month, Nehez advises. "After the stabilization period has ended, you can pay the remaining amount if you wish."
5. Demand timely support.
It is important to specify in the contract that the vendor should fix any problem with the system expeditiously. "They should incur a mild penalty if they can’t fix something in a time frame that doesn’t affect your cash flow," Nehez says. "This will determine your whole success."
If they don’t agree to a mild penalty, get something in writing spelling out what their support response will be and demand a firm date. "Having them say best effort’ is not just good enough," says Nehez, adding that most vendor contracts promise only best efforts. "Get a specific time."
6. Control travel expenses.
Vendors routinely charge customers for any travel expense related to the project. These fall outside the project costs, Nehez says. "They need to abide by your rules." If, for example, your agency provides meal reimbursement at a rate of $25 a day, then the vendor should receive no more.
7. Include a termination clause.
You should be able to terminate an agreement at any time for dissatisfaction, Nehez says. "Pay only for services you asked for."
8. Own the copyright to software.
If the IS is custom-designed for your agency, the software copyright belongs to you, not the vendor, Nehez points out. "You had them write it [the program] for you. The source code is yours."
9. Build in security.
Make sure only certain users have access to certain data.
10. Ensure data archiving and restoration capability.
A system should have capability to archive and restore data, Nehez says. If it doesn’t, your response time and throughput could be affected. A system must be able to do this, but a lot of vendors don’t automatically include it, Nehez says.
11. Define the system response time.
"What is the vendor going to guarantee for response time?" Response time, explains Nehez, is how long it takes "to get the information up on the screen after you press Enter.’ Will it take five to 10 seconds, or will the vendor guarantee split-second response?" In come cases, users may require split-second response, says Nehez. She recalls a system taking as long as 15 minutes to display much-needed data on screen. "That means it’s a poorly written application, nine out of 10 times."
12. Require confidentiality.
The vendor should sign a confidentiality agreement, Nehez says, because "they are going into all the intricacies of your business. It’s proprietary. You don’t want them going out and writing their own system and selling it."
13. Make sure the product is year-2000 compliant.
That might seem elementary, but Nehez says it’s a serious issue if overlooked. Because computers typically recognize the year by the last two digits, e.g., 97 for 1997, software should be written so that it doesn’t confuse the year 2000 with 1900.
"Applications need to be able to handle that," Nehez notes. "You need to have down in writing from the vendor how they will handle year 2000."