Practice-vendor alliance should be put in writing

How do you protect yourself and your practice to ensure that technology meets your needs, remains current and can be fixed if it breaks even if the vendor you hire goes out of business?

The answer is to prepare for these challenges at the beginning of the relationship -- through your contract.

When engaging a technology vendor, it is imperative to define what the vendor is agreeing to provide. The contract should spell out the details, such as the software to be provided or the functions the software will have. The contract should include the goals for the technology being purchased, including milestones that must be reached for payment.

If the vendor is providing hardware (servers, computers, etc.), descriptions of those should be spelled out, together with a recognition of who owns the equipment. Is the practice buying the equipment, or is it for the practice to use for the life of the contract only? The contract also should spell out who needs to maintain the hardware and what happens to it when the contract ends.

If customized software is being developed, the contract should set forth who owns the software and any related copyrights. Is the practice merely licensing the software, or is the vendor providing a "work for hire," in which case the practice owns the software and the related intellectual property? If the software is licensed, what are the limitations on the practice's ability to use, copy or modify the software if necessary?

Once the software and other items the vendor will provide are described in the contract, you should set a time frame for those items to be developed (if necessary), provided, installed and proven to work. Though some payment can be paid up front, payment should be withheld until promised items are received, installed and proved to be operable. Making payment earlier, or a larger payment up front, can leave the practice with little leverage over the vendor to correct any problems other than expensive litigation.

The contract should set forth clear dates for delivery, proof of operability (including defined minimums for the technology to be considered operable) and time periods for the vendor to fix any problems. It should provide for the consequences in the event the vendor fails to meet these deadlines. You should consider setting deadlines and milestones -- tied to further payments -- for appropriate progress in integration, migration of information to the new technology and other relevant goals, milestones and metrics.

The agreement with the vendor should include training, ongoing maintenance and updates to the software as required. With respect to training, similar considerations with respect to the delivery, installation and proof of operability of the software apply. Timelines and goals should be set, and payments should be conditioned on meeting those timelines and goals.

With respect to maintenance and upgrades, the contract should include the price of such services, the maintenance to be provided, how maintenance requests will be made, contact information to make such requests, and how often upgrades will become available.

How these issues should be resolved in each practice setting is specific to the technology and its importance to your practice. Does the vendor need to have 24-hour maintenance available seven days a week? Is there a separate price for emergency service? How is it determined that an upgrade is necessary? These and other issues, if not considered at the outset, can create problems that can significantly damage your practice.

What happens if the vendor goes out of business and the technology breaks down? How will the practice be protected? Though many technology companies can perform simple fixes in basic software or hardware, fixing highly customized platforms becomes more difficult for a company that did not develop the software.

Usually, such circumstances will require a new technology vendor to have access to the actual source code of the software and other development documentation of the platform. But if the vendor is out of business and did not provide the information to the practice, how is your practice supposed to obtain such information?

The solution is for the parties to enter into a software escrow agreement at the outset of the relationship. These agreements involve a third party (an escrow agent) who holds the source code and other development documentation and releases it only upon the occurrence of specified events or agreement of the parties.

An escrow agreement can provide varying levels of related services. These services can involve the escrow agent verifying that the "deposit" includes actual code, that the code provided can be translated to object code (which can be read by computers), and confirmation that the object code operates properly or as expected.

The escrow agent can inventory the items provided and verify that all necessary items have been deposited. Each software escrow service has its own rates and contracts.

If a software escrow agreement is used, the contract should address issues related to the escrow, including who will pay for the service, how long the escrow will be in place, in what form the deposit will be made, whether the deposited items will be updated based on future development work or upgrades, and the terms and conditions under which the escrow agent will be allowed to release the deposited material.

It is important that the relationship between your practice and the vendor be put in writing so that you are protected from problems down the road and that your relationship with the vendor proceeds as smoothly and predictably as possible.