As hospital pharmacies become increasingly automated, pharmacy managers are becoming more involved in contract negotiations with software and hardware vendors. Despite the fact that there is a push in contract writing toward using less legal jargon, legal technical terms (also known as legal terms of art) will typically appear even in user-friendly agreements. While pharmacy managers are certainly not expected to be experts in contract writing, having a grasp of some of the common terms inherent to technology contracts can help streamline the negotiation process and ensure that a binding contract is not executed without all conditions being fully understood and mutually agreed upon. A well thought-out contract can prevent implementation delays; unanticipated expenses such as additional out-of-scope hardware, software, or infrastructure necessary to make the product functional; and even protracted and costly litigation.
Establishing the Contractual Relationship
The purpose of a contract is to allow all parties involved to come to a mutual understanding of expectations and the consequences should one party breach the conditions set forth in the contract or not perform as agreed. At minimum, a contract specifies who the involved parties are, identifies the contractual relationship (ie, buyer and seller), the subject of the contractual transaction, consideration (ie, price to be paid and terms of payment), and terms of performance (ie, what each party is to provide and/or do, and when). Sophisticated technology contracts have additional elements that should be carefully considered.
A contract’s business case statement should set forth an organization’s goals for implementing the vendor’s solution with a specific timeline to go-live and post-go-live stabilization. The contract should then stipulate what the vendor’s responsibilities will be in meeting these goals. This ensures better understanding between the organization and the vendor and helps clarify the intent of the agreement.
Pay attention to product specifications (vendor statements regarding the functionality, interoperability, and physical characteristics of the product) and documentation (material provided by the vendor describing configuration, operation, and maintenance of the product), as they are commonly referenced in contracts. When the vendor warrants performance to the product’s documentation, enforcement becomes a challenge if a dispute arises over functionality, because the vendor publishes the documentation and can update it (and any software) long after your contract has been signed.
Uniform Commercial Code
Ambiguities are the bane of contracting; terms of contracts must be clear and avoid the need for a court or arbitrator to fill in the gaps when a non-breaching party attempts to enforce the terms of the agreement. A body of law called the Uniform Commercial Code (UCC) sets forth default provisions in many situations so that contracts need not spell out these situations. Most states have codified some or all of the UCC into their statutes. However, technology and software transactions may fall outside the UCC as it addresses transactions involving goods. While off-the-shelf software is generally considered goods under the UCC, custom programming and support contracts are generally seen as services. The typical transaction for pharmacy-related technology involves both goods (ie, hardware and software) and services (eg, implementation, software updates, and technical support). Since services generally do not fall under the UCC, resolution of disputes varies depending on whether the predominate purpose of the contract was a transaction of sale of goods with labor incidentally involved (where the UCC applies), or rendition of services with goods incidentally involved (where the UCC does not apply). Technology contracts should thus be crafted to minimize ambiguities that could trigger default UCC gap filling provisions that are unfavorable to your organization, or fall outside UCC if the transaction is determined to be predominately for services.
Choice of Law
Contracts frequently involve parties from different states. The choice of which state’s law governs a contract, should a dispute arise, generally favors the party from the state named in the contract. With this in mind, it is not unusual for the vendor to specify its home state in the initial boilerplate. In addition, some contracts will include a forum of law provision so that any litigation or arbitration must take place in the named state’s jurisdiction. In contracts where both forum and choice of law terms tie to one party’s home state, that party will have a substantial advantage over the other in the event of dispute, especially if the parties are geographically distant. The additional costs of retaining counsel in another state and travel to distant proceedings can be enough to discourage some parties from asserting their rights. Therefore it is recommended that both the choice and forum of law reflect your state, not the vendor’s.
It is advisable to have indemnification clauses involving health care providers and technology vendors reviewed by legal counsel to ensure that your organization does not incur liability due to failure of the technology vendor’s product or service. A typical indemnification clause might state that you agree to defend, indemnify, and hold the vendor harmless from any claim by or on behalf of any patient of yours if a claim arises out of the operation of the hardware, program, or services. Unless an exception is explicitly made for situations where the vendor’s program or technology malfunction caused patient harm, your organization will not only be defending itself, but also will have to defend the vendor if the vendor is named in the litigation. Keep in mind, even with such protection spelled out, the vendor may assert that the failure was attributed to your organization’s implementation, operation, or maintenance of the technology. Make sure indemnification granted to the vendor by your organization only applies to valid claims (ie, a claim that actually wins in court or arbitration). By specifying indemnification only for valid claims, the indemnifying party can collect any costs for defending the indemnified party from meritless claims.
It also is important to pay attention to limitations of liability provisions. Carefully evaluate provisions for direct, consequential, and punitive damages, and ensure any provisions that put a cap on parties’ liabilities are reasonable in view of any potential scope and risk of using the product. Make sure there is a provision to exclude any breaches of confidentiality, willful or intentional misconduct, or claims paid by insurers from the limits of liability.
Force majeure, also known as Act-of-God provisions, release one or both parties from liability for breach of contractual obligations if a natural disaster, fire, terrorism, war, labor dispute, or similar events beyond the control of the parties makes performance impossible or impractical. The party that writes the first draft of a contract will often provide for relieving their obligation if such events occur. Make sure that your organization is similarly excused in such situations by including an analogous provision.
It goes without saying that any contract between a technology vendor and health care provider will have provisions that protect the intellectual property of the vendor. Organizations also should be protected in this manner, and ownership rights for an organization’s business processes, workflows, and data should be spelled out in the contract as well. Doing so will minimize any risk that workflows or policies and procedures are used by the vendor without an organization’s consent.
The typical technology contract will provide for a license for software rather than the purchaser receiving outright ownership. License fees are usually payable as a lump sum as part of the overall packaged solution. Make note of how licensing fees are calculated: Is it per user? Does that mean that you pay for a license when the user is not actually online? Is it per concurrent connection? It is important to anticipate the high-water level usage so that users are not locked out pending the vendor adding more licenses.
If the vendor’s product consists of hardware and supporting software, the hardware will typically be purchased or leased, but as previously mentioned, the software will just be licensed for use with that hardware. Many vendors’ products contain at least some software code that the vendor has licensed from the original source. This includes operating systems, database management systems, and software utilities. In the contract with the vendor, there will likely be a provision related to this sub-licensed software. Be sure to understand who is responsible for the cost of updates and support of sublicensed software, and that any open-source software the vendor has incorporated into the product is included under sublicensed software. Finally, check to see if the vendor will indemnify your organization from any claims made by the sublicensed software’s owner related to your use of the product.
Of course an organization needs protection of its investment in the unlikely event that the vendor goes out of business. But, what if a product is discontinued or sunsetted by the vendor, in spite of the fact it continues to meet an organization’s needs as-is? Prepare for this by placing all programming code into a neutral third party escrow in the event the vendor cannot or will not provide help for a sunsetted product. Having the source code escrowed will provide an organization’s IT department with an opportunity to use this code to keep the product functioning. Keep in mind that sublicensed software may pose an issue even if you have access to the source code.
In a typical health care technology contract, there will be assignment clauses that allow a party to “farm out” certain aspects of its responsibilities, such as support and accounts payable services, to a third party. If you are concerned that a third party might not provide the same service level as the vendor, this can be a provision to negotiate. Remember that assignment clauses work both ways—if an organization is sold or merges with another organization, an assignment clause should be included so that any successor to that organization can continue to operate the product under the contract.
Support Fee Negotiation
Support fees are another area to focus on during the contracting process. Typical annual support fees will run between 15% to 20% of the license fee for the software component of the technology, and about 10% for the hardware components. Make sure support fees are locked in for at least three years, and that any subsequent increases are tied to the Consumer Price Index.
In addition, incorporate specific time-to-repair metrics (not merely time-to-response), since it is the return to functionality that is the real concern. This will help mitigate the chances that the product will be out of service for long periods of time. Build meaningful remedies (ie, refund of support fees or penalty payments proportional to the time the technology was down beyond the agreed response time) into the agreement in case the vendor is unable to provide timely repairs. It may be beneficial to both parties to define different levels of response depending on the severity of the malfunction so that the vendor does not expend Herculean efforts for low-impact problems.
There are a few aspects of warranties that deserve mention. For any product that is involved in patient care, it is critical that the vendor warrants that no disabling code is incorporated into the product such that the vendor could unilaterally stop the product from operating normally, and that their product is virus-free. Be sure to understand what actions, if any, your organization must take to maintain the product as virus free: Does the vendor update the anti-virus software on its product, or will your organization be responsible for doing so? Will the vendor warrant a certain level of performance (eg, screens will respond to input in x seconds)? Response times should be spelled out, especially for any technology that impacts patient care.
Incorporating objective measures of performance into the agreement can be beneficial. Sometimes the vendor will predict the results the product will bring to an organization. These representations are generally not enforceable unless the representations were fraudulent, so a prudent approach is to specify a risk-sharing arrangement where the vendor will absorb costs if the prediction does not come to pass. Such provisions are enforceable if they are objectively measurable and clearly spell out each party’s responsibilities to obtain the predicted result.
HIPAA and State Privacy Laws
If the vendor will have any access to protected health information (PHI), provisions must be made so that access is limited solely to supporting the application. Because the cost of violating HIPAA and state privacy laws is substantial and potentially catastrophic, the vendor should indemnify an organization for all breaches of privacy that occur from actions of the vendor, its employees, or assignees. The indemnification should cover unauthorized access and intentional or inadvertent release of PHI because most privacy laws have taken a strict liability approach to PHI breaches—meaning the mere unauthorized access or release of PHI triggers substantial civil penalties as well as liability. Lack of knowledge or intent is irrelevant with such breaches.
Gag provisions—which may be called Publicity on a vendor’s contract—are a controversial development in health care information technology. These provisions create a publicity blanket over an organization’s relationship with the vendor, including even that such a relationship exists. What is most concerning, however, is that these clauses prohibit the discussion of issues and workarounds with other health care providers. If every organization relented to such provisions, open exchange of information between health care providers about products’ strengths and weaknesses could be severely limited. This type of provision potentially could preclude the disclosure of defects that cause, or could cause, patient harm. An organization should strongly consider removal of any language that prevents them from openly discussing a technology solution with colleagues in any forum; however, restrictions on disclosure of any of the vendor’s proprietary information (eg, pricing, screen shots, etc) are reasonable. After all, honest and open discussion about technology products is mutually beneficial if the vendor uses this information to improve its products.
While not an exhaustive list, familiarizing yourself with these prevailing aspects of technology contracts can help ease the negotiation process. Generally, in situations where significant costs and implementation resources or impact to patient care are affected by the technology product, it is advisable to enlist the help of legal counsel when negotiating and finalizing the contract. Remember, contract negotiations are not competitive events—consider them an opportunity to create an agreement that is mutually beneficial with respect to each party’s responsibilities and expectations. n
Robert L. Stein, PharmD, JD, a consultant with Dearborn Advisors, assists health care organizations to adopt and optimize electronic health records by engaging physicians and other clinicians in the design and use of these systems. He practiced clinical pharmacy for 14 years in adult and neonatal critical care settings, and held progressive leadership roles in hospital pharmacies before specializing in technology and computer applications. Bob was an independent consultant, assisting hospitals with selection, design, implementation and optimization of EHRs, departmental pharmacy systems, automated dispensing systems, and various PC applications. Bob also teaches pharmacy law at Western University of Health Sciences College of Pharmacy in Pomona, California, and his legal interests include developments in pharmacy law, health care technology vendor contracts, e-discovery of health records, and ARRA HITECH incentives for hospitals and health care providers.
This article provides an overview of some of the elements of technology contracts but is not intended to be legal advice. Always consult your own legal counsel for specific legal guidance regarding contracts.
Did You Know?
A contract does not have to be explicitly titled Contract and could be called a Letter of Agreement or Letter of Understanding or something similar. However, in some cases a Letter of Intent or Letter of Understanding may merely be an enforceable agreement to negotiate a contract. In such cases, after good faith negotiations occur, one or both parties can walk away with no further liability to the other party.