Craig B. Monsen, Elizabeth G. Olson and John D. Manning
Healthcare organizations (HCOs) need a negotiating team with the expertise and knowledge to properly assess and negotiate software license agreements with vendors. This team will need to represent different interests, including user, technical, finance, and legal interests of the HCO. The agreements provided by software vendors tend to be one-sided and do not adequately protect HCOs or address all HCO needs. “Legalese,” the legal terms and language of contracts, is not harmless and in many respects affects technical, business, and financial issues, including business continuity, data protection, return on investment, and other value propositions. HCOs should not underestimate their leverage to negotiate for better terms in their software license agreement with vendors. This chapter describes a process for health information technology (IT), contract negotiation, and provides a description of contract terms, related issues, and negotiation compromises.
derivative works 289
limitations and exclusions of liability 301
open-source software 290
service level agreement (SLA) 295
software as a service (SaaS) 290
software escrow 294
software license agreements 288
software warranty 295
Never underestimate the leverage that a healthcare organization has to contractually protect itself.
Healthcare organizations (HCOs) depend on computer software for the delivery of healthcare services to patients and for most, if not all, of their business operations. It is unimaginable today that an HCO could function without the use of software for a wide variety of applications and purposes, including clinical care, billing, security, compliance, research, and operations. Software vendors who provide the software are diverse in size, expertise, resources, ability, and the solutions they offer, but one practice they have in common is their insistence on software license agreements (also referred to as contracts) as a prerequisite to using their software. The term “vendor” refers to the licensor, service provider, or other company that licenses or provides the software to the HCO. The term HCO is used generically in this chapter to mean not only the HCO itself but also, when the context allows, the HCO’s leadership or the designated representatives on a team doing the contract negotiations.
A negotiating team for a software agreement may be at the executive level or composed of other designated team members who first work with the vendor on the terms and conditions of the agreement. Then, the agreement is signed by an authorized signatory such as the chief executive officer (CEO), chief financial officer (CFO), or the chief information officer (CIO) who is authorized to sign purchases or contracts and make financial commitments. A negotiating team’s typical composition is listed in Box 19.1.
Although this chapter does not address Stark, anti-kickback, Health Information Portability and Accountability Act (HIPAA), and other regulatory issues, those issues must always be carefully considered and accounted for by the HCO. Details about legal issues may be found in Chapter 27. HIPAA is discussed in Chapter 28, and regulatory issues such as Health Information Technology for Economic Clinical Health (HITECH) and Meaningful Use are in Chapter 29.
This chapter focuses on commercial software license agreements rather than open-source software licenses. It is written primarily to address traditional “on-premises” software licenses, but much of what is said about “on-premises” licenses also applies to cloud-based services. The chapter includes a discussion of cloud-based services (e.g., software as a service [SaaS] licenses) and is written from the perspective of informing healthcare professionals and informaticians who are expected to take a leadership role in understanding the implications of these types of agreements. It is not written for attorneys but rather for others responsible for understanding and approving software license agreements and ensuring that the HCO complies with those agreements. By necessity, the chapter is not completely comprehensive (i.e., any given software license agreement is likely to include additional provisions not mentioned here and may not include some provisions that are mentioned). However, the chapter provides a description of the topics and contractual provisions deemed the most relevant to the intended reader.
When purchasing a license for software that is mission critical or highly important, the HCO should be sure to understand what it is agreeing to and should make sure that the agreement makes sense in the context of which the HCO will use the software. Software license agreements can be relatively simple, but more often they are lengthy and complex and even confusing. They include provisions that address significant business and technical issues often in legalese or “boilerplate.” These provisions should never be dismissed or overlooked as routine or harmless, as they may lead to surprises with business, technical, financial, and/or patient care consequences.
There are three key points to always remember when dealing with these types of agreements (Box 19.2).
Software is a “work of authorship” under the copyright laws. There is always a copyright to any software that is original (i.e., not copied from someone else). Copyrights only protect “expression” and not ideas, methods, facts, concepts, inventions, or systems. Writing computer software is analogous to writing a book. Both are expressions protected by copyright, but the concepts and ideas in them are not. Therefore, copyrights can protect software against copying and even against other derivative works.
A copyright is different from a patent. Whereas copyright is a form of protection provided to the authors of original works, a patent protects the invention of an inventor (Section 2016). Sometimes, software includes or represents a patentable invention, or the use of the software may be or involve a patentable method. Software that is involved in a patentable invention creates additional considerations and potential liabilities for HCOs. A software vendor might have one or more patents applicable to its software, some of which may be owned by a competing company. In this case, the HCO licensing the software may be unintentionally infringing on a patent and be liable for damages payable to the owner of the patent.
Trade secrets are a third form of intellectual property applicable to software. A trade secret is information that is not generally known to others and not readily ascertainable by others (Uniform Trade Secrets Act Definition, 2016). Trade secrets are protected against misappropriation (e.g., taking by improper means). Software can include trade secrets. The source code to commercial software is often held by the owner of the software as a trade secret. Open-source software is not a trade secret, as the software and its source code are typically made available to the public and therefore are generally known to the public. Typically, when commercial software is distributed, it is the object code or executable code version of the software that is distributed, and the source code is withheld from distribution. In such cases, the source code may be a trade secret.
In general, a contract represents an agreement between parties that creates legally enforceable obligations. A contract may represent an exchange of value, such as a service where one party pays the other. Alternatively, there may be no charge at all, such as a nondisclosure agreement for software sustained by selling advertisements.
Software vendors will insist on using a binding contract, such as a software license agreement, when licensing commercial software to an HCO. License agreements provide the vendor with contractual protection of its software in addition to intellectual property protection. They create payment obligations and restrictions on use and limitations of liability and disclaimers that protect the vendor. However, a license agreement can also protect HCOs by including obligations and warranties binding on the vendor that give the HCO assurance as to the software and its functionality, performance, and compatibility, as well as other protections (e.g., indemnification against claims that the software infringes another person’s intellectual property).
It may not always be obvious that a license agreement has been agreed upon. Many licensing agreements will be called “Software Licensing Agreement” or “Master Agreement”; however, sometimes they take different names. It is not uncommon for vendors to create a “Purchase Order” or “Sales Order” that references a separate software licensing agreement. End User License Agreements requiring users to acknowledge “I Accept” are commonly agreed upon as “click through” agreements that create obligations for the user and may also create uncomfortable obligations for their employer. Finally, depending on the maturity and approach of a vendor, “Letter of Agreements,” “Term Sheets,” “Memorandum of Understanding,” “Amendment,” and “Letter of Intent” may all represent contracts with software licensing terms.
Software is typically not sold when distributed to customers. Instead, vendors will often sell licenses to use the software rather than the software itself. If the software were sold, this generally would give ownership in the form of copyright or other intellectual property (IP) protection to the customer, which is often unacceptable to a vendor wanting to license the software to others. A license is, in effect, permission to use the software.
The media (e.g., DVDs) on which the software resides and is distributed to an HCO (1) may be owned by the HCO as a purchaser, or (2) may be leased or loaned to the HCO (i.e., the vendor owns the media). Ownership of the media is not an issue when software is downloaded by the HCO via the internet from the vendor or is remotely accessed and used by the HCO via the internet as in a software as a service (SaaS) agreement. SaaS is a software distribution model where applications are hosted by a vendor and made available to customers over a network, typically the internet.
Traditionally, software licenses have been “on-premises” licenses, meaning that the software (usually the executable code but not the source code) is installed and runs on a computer or network located at the facility of the licensee (e.g., the HCO). (See Table 19.1 for definitions of the terms source code, executable code, and interpretive code.) Cloud licensing takes a different approach. The software resides and runs on the vendor’s server(s), and the licensee (e.g., the HCO) remotely accesses and uses the software through the internet (e.g., via a web browser).
Table 19.1
An example of cloud licensing is SaaS licensing. SaaS can be characterized by a single instance of the software running on the vendor’s server that is accessed and used by multiple licensees (i.e., “multitenant”). This maximizes some of the benefits of a SaaS solution (e.g., the cost of hosting, running, maintaining, and supporting a single instance of the same version of the software reduces costs when those costs can be shared by multiple licensees). The term SaaS can also apply to solutions that are not single instance or are multitenant.
Other cloud services include hosting, managed services, on-demand services, and application service provider (ASP) services. Some agreements are structured as a hybrid of an on-premises license and a cloud license. For example, some vendors will license the software through an on-premises license but then offer hosting services through a services agreement (e.g., a hosting or managed services agreement). In such cases, the HCO is licensed to use the software under the license but engages the vendor through a services agreement to host and run the software for the HCO on the vendor’s servers. If the services agreement were to terminate, it remains possible for the HCO to run and use the software on its own computers or network under the terms of the on-premises license agreement.
Typically, the vendor has a standard template for a license agreement. However, it is often possible to negotiate the terms of any software license. The vendor’s version should be viewed by the HCO as only a starting point. The vendor’s form of agreement is mostly designed to protect the vendor and not the HCO. The agreement usually includes legalese that can mislead or surprise an HCO. It often fails to include many protections and assurances important to the HCO that must be sought through negotiation. Health providers and informaticians involved in contract negotiations should not be distracted by the “friendliness” of a vendor or with the developing informatics-vendor relationship, but rather they should focus on gaining a clear and objective understanding of what is in the agreement. HCOs should not hesitate to negotiate aggressively for the needs of the healthcare institution. Vendors can be persuaded to change their agreements, but they will not do so without a request from the HCO. HCOs should not underestimate their leverage. While HCOs should negotiate firmly and aggressively for the needs of the institution, a collegial, professional manner is always the most effective way to reach an acceptable agreement. The HCO and its representatives should maintain an amicable and a professional relationship with the vendor at all times, and contract negotiations are no exception.
Although situations will vary, the progression of a negotiated agreement is likely to include a process similar to the one outlined in Box 19.3. As is illustrated, the process involves numerous cycles.
The reason for having the vendor prepare a second draft is that this allows the agreement to move closer to what the HCO needs and wants in an agreement before the HCO starts to change the agreement. Assuming that the vendor accommodates some of the changes requested by the HCO in the first teleconference or meeting, there will be fewer changes that the HCO needs to make in its final draft. In the process, there should be shared control of the agreement document, by taking turns in preparing response drafts that are redlined to show changes to the prior draft. Two major tips for version control are listed in Box 19.4.
Even the best agreement is not a substitute for due diligence (see also Chapter 18 on system selection processes). The HCO should check formally and informally with other users and obtain references from existing customers via conversations and site visits for larger purchases. The HCO can ask who has recently discontinued use of the vendor’s software and why. References provided by the vendor are not likely to include customers with bad experiences or complaints that the HCO might need to know. Sometimes vendors are asked to provide financial statements so that the financial stability of the vendor can be assessed. Suddenly losing support and maintenance services from a vendor in bankruptcy or buyouts can place HCOs in a difficult position.
Key to the due diligence process is to perform it on several alternative vendors. This can provide a greater perspective on desired functionality, and it strengthens negotiating leverage with several backup options should negotiations with the preferred vendor stall. The HCO needs to know its requirements and must clearly communicate those requirements to the vendor. Document the responses from the vendor to these requirements, including those presented during demonstrations of the software. Outside consultants/experts engaged by the HCO may be useful to it in the due diligence and negotiating process.
Request for proposal (RFP) or request for information (RFI) processes are worth the effort, time, and expense for larger software purchases. The RFP process, outlined in Chapter 18, sets forth the HCO’s requirements and expectations for the software, including its functionality, performance, compatibility, and maintenance. The RFP should also be used to ask relevant questions of prospective vendors, including costs. The more comprehensive the RFP, the more comprehensive the response should be from the vendor. This will reduce the likelihood of misunderstandings and surprises later. Traditionally, an RFP is used with multiple vendors and is the basis for a bidding, comparison, and selection process, but can be a great tool to learn even from a single vendor.
The vendor’s response to the RFP should be made a part of the license agreement. For example, the license agreement can reference the vendor’s response and state that the vendor stands behind its response (i.e., that the response is accurate and that any promise or assurance in the response will be met by the vendor). Because of the nature of “Entire Agreement” clauses (see the next section), the response will be of no effect if not incorporated into the license agreement.
If the vendor objects to the inclusion of its response to the RFP in the license agreement, then the HCO should insist that the HCO relied on the vendor’s response in the selection of the vendor. If the vendor still objects, the HCO should offer to allow the vendor to correct or clarify its response, and then the corrected or clarified response should be added to the agreement. If the corrections reveal some unpleasant surprises, it is better for the HCO to know before rather than after signing the agreement.
Although it is not common to do so, the RFP should be used to address the tough contract issues (including legal issues) that inevitably arise in contract negotiations (e.g., limitations of liability, termination, and scope of use). Negotiating these is much more difficult after the vendor knows that it has been selected, so early in the selection process is a good time to solidify these terms. This approach can reduce the amount of time spent negotiating the agreement and can lead to a better result for the HCO.
An “Entire Agreement” clause, also known to attorneys as an integration clause, might read as follows:
Entire Agreement. This Agreement is the entire agreement between the parties with regard to the subject matter of this Agreement and supersedes and incorporates all prior or contemporaneous representations, understandings or agreements, and may not be modified or amended except by an agreement in writing signed by the parties hereto.
This means the HCO must put everything it is relying on in the agreement. Exhibits, addendums, appendices, and documents that are incorporated by reference into the agreement can be used for this purpose. Statements made by salespersons, demonstrations, marketing materials, and other peripheral statements and documents do not count unless they are incorporated into the agreement. The agreement should identify what the HCO is paying for (Box 19.5).
Definitions of terms is often one of the first major components of a licensing agreement listed in Box 19.6. The agreement should include definitions of all vendor-specific terms and concepts, as mentioned in Chapter 18. The system selection team, negotiating team, or designated representatives should review these to ensure they are consistent with the HCOs use of the terms and for clarity. Though it may be tempting to consider definitions boilerplate or mutually understood, this section often includes important content such as the definition of a Licensed User that impacts the pricing model.
Although there is significant variation, a mission-critical license agreement might include the steps and stages listed in Box 19.7. Expectations for progressing through these stages in a timely fashion is often reflected on a time schedule to keep the vendor on track. The contract should contain a good estimate of the initial project from start to go-live, including purchasing hardware, installation, customization, interfaces, training, testing, and user acceptance testing. For example, a community hospital may project an 18-month timeline that is broken into discrete events representing a project plan. (For more information about project management, see Chapter 17.) Generally, vendors resist contractual time commitments, but usually, an HCO can get some meaningful time commitments or at least good faith estimates. Even if the estimates are nonbinding, they create expectations and increase the probability that the project will be completed within an expected time frame. Furthermore, payments or monetary incentives can be tied to milestones, even if the dates associated with the milestones are nonbinding estimates. For example, the vendor would not be in breach of the agreement for failing to meet an estimated date for a given milestone, but if that milestone is also a payment, then payment may be delayed until the milestone is met.
Assuming that the vendor is committed to a time schedule, the agreement should indicate the consequences of a failure to meet the schedule. Such consequences may include liquidated damages, credits, discounts, or delay in payments. For example, if a go-live date is missed by more than a week, the contract may specify that the license fee will be reduced by a specified amount. In response, some vendors may seek financial incentives for early or timely performance of the schedule. Assuming the vendor accepts the concept of a binding time schedule, the HCO should expect the vendor to insist on exceptions for delay or non-performance caused by the HCO, another supplier, or a force majeure (disruptions caused by causes beyond the control of the vendor such as natural disasters or other unforeseeable circumstances beyond the control of a group). The vendor may also insist on building a margin for error into the time schedule.
Fundamentally, the license is permission from the vendor for the HCO to use the software. The license agreement needs to define who may access and use the software. Obviously, this includes the HCO and its employees, but a broader scope may be needed. Contractors acting on behalf of the HCO or other affiliated organizations may need to use the software as well. Examples of users may also include (1) independent physicians having admitting privileges at the HCO’s hospitals; (2) independent healthcare providers and clinics (e.g., to share medical records or perform billing); (3) patients or their family members who will see screen displays or output generated by the software; (4) consultants, other independent contractors (e.g., programmers), and volunteers; and (5) in some cases affiliated foundations or staff and students from affiliated institutions of higher learning. For example, the emergency department may contract with an outside billing agency. This outside agency needs to be mentioned as a user. Otherwise, billing and reimbursements will be negatively affected. The HCO needs to anticipate who the users will be and then make sure that the license agreement allows for those users.
The scope of the license will often be subject to “internal use” or “permitted use” restrictions. The language may vary, but the HCO should be comfortable that these types of restrictions do not prohibit the intended use of the software. For example, a simple restriction that the software may only be used for internal purposes might prohibit use of the software that benefits or involves others outside of the HCO. The scope of a software license is often defined or limited by various license metrics, such as those listed in Box 19.8.
HCOs should anticipate that applicable license metrics (e.g., licensed users) might be exceeded at some time in the future and to provide for the same discounted pricing originally negotiated to cover the excess. This is often covered through an annual reconciliation or “true up” of the license. In other words, the agreement should allow for a review of the license volume annually and for the payment of additional license fees if needed to cover the excess. With this approach, the HCO will not be in breach of the agreement for exceeding a license metric provided.
The license might include limits on the number of copies of the software. An extreme example might be the following clause: Vendor grants to HCO a license to use one copy of the software and to have and maintain one backup copy of the software. This is a problem because multiple copies of the software can be found in the areas listed in Box 19.9.
An HCO will certainly exceed a one-copy limit because the software held in the computer’s memory (e.g., random access memory, or RAM) is legally considered under the copyright laws as a copy of the software, and there will be a copy of the software on the hard drive. Any limitation on the number of copies should reflect the reality of the technology and use.
Sometimes, a license is limited to certain numbers and types of environments and instances. The HCO will need to be licensed to use the software in a “production environment” at a minimum. The HCO’s technical advisors should review this wording carefully to be sure that it is adequate in the context of expected use. Often, the HCO will want the right to use the software in more than one production environment or in other environments, such as testing, training, development, and recovery environments. The same is true if this concept is expressed in terms of “instances” or some other technical terminology.
Normally, a software license will prohibit the HCO from modifying the software or creating derivative works based on the software. If the HCO needs to maintain, customize, or enhance the software, then the HCO will need to expand the license to include permission to modify and create derivative works. In such a case and at a minimum, the agreement needs to require the vendor to provide the materials listed in Box 19.10 to the HCO. The HCO will also need programmers, employees, or contractors with the necessary abilities to use the source code to maintain, customize, and enhance the software.
For mission-critical or highly important software, an escrow may be included with the license agreement for business continuity purposes. For instance, if the vendor goes out of business or otherwise ceases to provide maintenance of the software (e.g., to fix programming errors or to update the software), the HCO may be left in an untenable position. A software escrow is a means to provide protection of the HCO if such an event arises. For a software escrow, a neutral third-party escrow company holds the source code, programming documentation, and other items needed for maintenance and modification of the software. The escrow agreement includes release conditions, release procedures, and terms addressing intellectual property and bankruptcy law issues. A release condition is typically the bankruptcy or insolvency of the vendor, the vendor’s breach of maintenance or other obligations, the discontinuation of support by the vendor, the vendor going out of business, or the vendor disrupting use of the software in any other manner. The occurrence of a release condition entitles the HCO to receive the escrowed materials from the escrow company.
A SaaS escrow is an escrow for a SaaS or other cloud-based software solutions. It is similar to the typical software escrow described previously, but also includes having the escrow company maintain a mirror or similar solution on its own server. The SaaS escrow must be in a condition that can be brought live and online for the HCO’s use if a release condition occurs or the HCO’s access to the software is terminated by the vendor. The frequency of data updates to the escrow’s server is just one of many details to be addressed in the escrow agreement. How “hot,” “warm,” or “cold” the escrowed materials may affect cost and how quickly the escrowed solution can be brought live for the HCO.
The HCO should seek detailed specifications, as these define the software that the HCO expects to receive. Specifications may apply to warranties, acceptance, payment milestones, and maintenance obligations of the vendor. The initial draft of the license agreement from the vendor will likely include few or no specifications. The HCO should negotiate for meaningful specifications and preferably create and negotiate them prior to the signing of the agreement. Sometimes, the specifications need to be created after signing. If so, then stage 1 of the agreement can focus on the creation of the specifications. If parties agree on the specifications (which is almost always the case), then they proceed to subsequent stages of the agreement. If they do not agree, then the agreement is terminated.
Many types of specifications can be included in the agreement, such as those in Box 19.11. If the agreement includes custom development or if the development is “agile,” then few if any specifications may exist. Agile software development (What is Agile Software Development, 2021) has its advantages that may outweigh the protections that an HCO may otherwise seek in an agreement.
Sometimes, the vendor offers no warranty (i.e., software is provided “as is” without any guarantee). The HCO should refuse to accept such an agreement. A good software warranty addresses most or all components in Box 19.12. The vendor is likely to have in its draft of the license agreement disclaimers or protections listed in Box 19.13. There may be other disclaimers or limitations. For example, a clause may state that the software is not intended or licensed for high-risk uses or applications. The HCO should seek clarification that those high-risk uses or applications do not apply to healthcare or the specific purposes the HCO intends for its use of the software.
When the license agreement is a SaaS agreement, a service level agreement (SLA) is often included as part of, or in addition to, the SaaS agreement. The SLA is intended to define certain service levels and the consequences of failure to meet those levels. Typically, the service levels are not commitments of the vendor. Therefore, the vendor is not in breach of contract for failure to meet those levels, but rather is only obligated to provide the specified remedy (e.g., service credits). The most common service levels address uptime versus downtime (i.e., availability of the software to the HCO), performance, resolution time, and remedies.
There can be disagreement about what “uptime” means. Does it simply mean that the HCO is able to access the software? What if some critical functionality of the software is producing errors or is not functioning but 90% of the functionality is available? Health professionals and informaticians need to understand that 100% uptime is typically not feasible. For each increment toward 100% uptime, expenses can increase dramatically and be unaffordable.
In the end, the agreement should be clear. A very favorable clause for the HCO would define “uptime” as the time during which the software, including all functionality and without material error, is available for access and use by the HCO.
What is considered downtime typically has several carve-outs. Scheduled downtime for maintenance and updates is commonly not considered downtime. Downtime caused by the HCO is often not included in a calculation of downtime (e.g., connectivity issues or failure to meet the vendor’s requirements). Force majeure events (i.e., disruptions beyond the control of the vendor such as natural disasters such as floods, war, or lightning strikes) are also often excluded from uptime calculations. The HCO should ensure that the vendor is obligated to maintain disaster recovery solutions sufficient to overcome many force majeure events (see Chapter 21 on downtime and disaster recovery). Because of these adjustments to uptime calculations, an uptime service level of 99.999% is not likely to reflect true uptime and availability of the software.
The appropriate uptime percentage should be based on several factors, including the criticality of the software and impact that downtime would have on the HCO. An uptime of 99.999% is generally considered the gold standard, but lesser uptimes may be appropriate for certain contexts. For example, software needed for monitoring in an ICU may need the gold standard, whereas business software used during business hours can have lower uptime, thus reducing costs. Even if an uptime percentage of near 100% is achieved, there can still be other issues, such as network bottlenecks, poor latency, and other performance problems.
In the context of a SaaS agreement, users will not tolerate a solution that performs slowly, and the SLA should be drafted to address this. Sometimes this type of performance is described as response time (i.e., the time for the computer running the software to respond to the user’s input of a command). These performance issues can be very complex and difficult to precisely define in an SLA, and slow performance is not necessarily the fault of the vendor or the software. A simpler solution, but often unacceptable to the vendor, is to use general wording to define a service level in terms of reasonableness (e.g., response time will not be unreasonable).
Another type of response time is the time it takes for the vendor to respond to a notice of a problem. It is easy to draft this type of response time in an SLA. Resolution time is much more difficult. Vendors vary on their contractual commitments to fix a problem. The range of commitments include those listed in Box 19.14. Without knowing what the problem is, the vendor will be hesitant to commit to a resolution time or even to guarantee that the problem will be resolved. Nonetheless, the HCO should attempt to build these concepts into the SLA or into warranties elsewhere in the agreement. The HCO should note that a “response” is not a solution. A response time of 30 minutes may only mean that the vendor’s support personnel will acknowledge receipt of a support ticket. One compromise is to have good response times coupled with an assurance by the HCO that diagnosis or troubleshooting of the problem will begin within the response period and that efforts to resolve the problem will be diligently pursued to completion as soon as reasonably possible. This should also include a promise to provide a workaround solution, if practicable, while the permanent resolution is being worked on. This compromise may be better expressed as a warranty or contractual promise outside of the SLA.
An SLA commonly defines different categories of problem severity. Simplistically, categories will range from critical to nothing more than a minor fix or a change request. The agreement may spell out response times and severity levels in simple terms or in complex detail. The HCO should carefully review the actual wording used by the vendor to define severity categories, because a lesser category may result in a long and unacceptable resolution time. For example, the resolution time for a low-severity category might be nothing more than a promise by the vendor to include a fix in the next release of the software without any assurance as to if and when the next release will take place. The HCO should insist that a patient safety issue is critical and should be addressed within a few hours.
The usual remedy for a failure to meet an SLA level is a credit to be applied against future payments to the vendor. For uptime, the credit may be defined as a percentage of a monthly fee for the level of uptime achieved during that month. As the level of uptime decreases, the credit increases. Remedies other than credits can be used in an SLA, but vendors are typically reluctant to use anything other than credits. The HCO should make sure that the SLA allows for use of the credit to pay for any obligation to the vendor, not just as a credit against future payments of a specific service. For example, the HCO should be allowed to apply credits toward training, consulting, custom development, data migration, and additional software products. It should also allow for the HCO to collect cash for the credit if the credit still exists at the time the agreement terminates.
Vendors often include a clause in SLAs to the effect that the credit or other remedy is the sole and exclusive remedy for a failure to meet an SLA level. The HCO should be leery about this. For example, this should never apply to a breach by the vendor of an obligation to provide maintenance of the software. As a more extreme example, if the credit for uptime is capped at 25% of the SaaS fee, then literally, the SLA would still require the HCO to pay the remaining 75% of the SaaS fee even if uptime were 0%. Of course, that would be outrageous, but the literal wording of many SLAs means this. As ultimate protection, the HCO should insist on the right to terminate the SaaS agreement if the SLA levels are significantly or continuously not met. This termination right is typically considered separate from other remedies.
After implementation, the HCO should have the right to test and then accept (or reject) the software. Acceptance should be based on conformance of the software to the acceptance criteria. Acceptance criteria can include those listed in Box 19.15.
If a problem (i.e., nonconformance with any acceptance criterion) is discovered through testing, then the HCO should reject the software and the vendor should be required to fix the problem and redeliver the software for retesting. When no problem is discovered, then the HCO should accept the software. The process may be repeated as necessary.
In many situations, HCOs will do pre-production testing of the software before it is used and tested live in a production environment. With this approach, the HCO does not risk using the software on live data and at the risk of patients’ well-being until after it is accepted through pre-production testing. Testing in a live environment is still important because live testing can reveal problems not discovered in a pre-live environment. In effect, the testing and acceptance (or rejection) process is repeated for the live environment.
Sometimes vendors want separate acceptance testing of software components, applications, and interfaces. This is often called unit testing. If done separately, this might not reveal problems that arise when the whole system (all components, applications, and interfaces) is used together. This is called integrated testing. An HCO should not accept unit testing alone for acceptance. A possible compromise is to have preliminary acceptance of each unit followed later by final acceptance testing of the integrated system.
For a multisite solution, testing of the software at one site may not reveal all problems when the software goes live for all sites, especially if there is transmission or sharing of data between sites or other interactions between sites. Final testing and acceptance for all sites is advisable.
Software acceptance ideally may be incorporated as a payment milestone on which a portion of the license fee is conditioned.
The HCO’s right to reject the software if acceptance criteria are not met should be expressly stated in agreement. The vendor should be obligated to fix problems and redeliver for a repeat of acceptance testing. The entire software should be retested, not just the corrected portion of the software because correcting one problem may lead to a new one.
Often a difficult issue to negotiate with the vendor is the concept of an absolute obligation to fix versus an effort to use “best efforts” or “commercially reasonable efforts” to try to fix. There may be pre-specified limits on the time allotted to complete a fix or to provide a workaround solution. Such obligations may specify what happens if acceptance testing still fails after repeated attempts to correct the problem, or if the vendor exceeds the defined time limit.
In case of failure, vendors may say that the HCO will get a refund of the license fee, but only for the software components or applications that fail. There is no refund for other software components and applications that pass and are accepted and no refund for services (e.g., installation, implementation, training). This should be unacceptable to the HCO. For example, if some of the accepted software components require an unaccepted component, then the HCO should be able to reject everything. (As a reminder, for more detail on downtime and disaster recovery, see Chapter 21.) The HCO should have the option to elect one of the following remedies in Box 19.16 if the software ultimately fails to pass acceptance testing.
Maintenance and support by the vendor of the software are essential in most license agreements to ensure HCOs have a reliable system in place for continuous use. Maintenance and support include some or all of the components listed in Box 19.17. HCOs may employ various tactics to reduce maintenance and support costs. The HCO may create its own help desk to discount or reduce fees payable for support. Through the HCO’s help desk, support personnel provide frontline or “first-tier” support to HCO users of the software. The vendor’s support personnel provide backup or second-tier support to the HCO’s support personnel as needed, helping to avoid additional support fees incurred if users were to reach out to the vendor directly.
The agreement should clearly indicate the support hours of the vendor. The nature of the software and the HCO’s reliance on it will dictate whether 24/7 support should be requested from the vendor (at higher cost), if business hours are appropriate, or if something in between is needed.
Fees for maintenance and support are typically between 15% and 22% of the initial license fee per year but may range from 10% to 40%. Under a SaaS agreement, the maintenance and support cost is typically included in recurring SaaS fees.
Vendors will often include a term permitting annual increases in fees such as a 3% increase per year in the contract. HCOs should aim to cap increases on fees. The cap may be based on a percentage or CPI (a specified customer price index) or other limit. The HCO should also consider negotiating for multiyear fixed prices to facilitate budget planning and to preserve discounts.
A significant issue is how long the vendor will commit to providing support and maintenance. This should be at least 5 years and preferably a longer period sufficient to cover the expected return on the investment. However, HCOs should not be locked to use the services for that same number of years as they should preserve a termination right if they choose to discontinue use of the software. It would be costly (and embarrassing!) to pay for support and maintenance of software no longer being used.
Payment for support and maintenance should also entitle the HCO to updates and new releases of the software. The fine print in the agreement may make exceptions to this obligation or charge extra fees in some cases.
The agreement should indicate how far back versions of the software will be supported and maintained. For example, an agreement may indicate that only the most current version of the software will be supported and maintained, but the HCO may want to continue to use prior versions. Upgrading to a new version may be costly, time consuming, and inconvenient. Security issues may arise when a new version is implemented. On the other hand, upgrading eventually becomes necessary, as security patches may require major upgrades and the HCO cannot reasonably expect the vendor to continue to support and maintain versions with dependencies on hardware or operating systems that are many years old. Compromises on this issue often include support and maintenance for one or two of the most recent prior versions or giving the HCO a transition period to upgrade. Sometimes the vendor may support “out-of-support” versions if the HCO is willing to pay a premium in maintenance fees.
If the overall software solution includes third-party software, then support of the third-party software may not be covered by the support and maintenance obligations in the agreement and may instead depend on the support and maintenance provided by the third party. In general, understanding the roles and obligations of third parties is important prior to signing the agreement.
The license agreement should include, often via attached Scope of Work, other vendor services that the HCO needs or may want, such as installation and implementation, training, data conversion, interfaces, or custom development.
Agreements often include services in support of system implementation, as listed in Box 19.18.
A significant issue can be determining if services are purchased for time versus results. Typically, it is favorable to pay for results since paying by the hour or day is no assurance as to how many hours or days it may take to complete a project. This approach gives certainty in budgeting and a greater chance that the results will be obtained without cost overruns. However, if the HCO insists on a fixed-fee approach, the quote from the vendor is likely to build in a healthy margin for error, possibly resulting in a higher cost to the HCO. If paying for time, the HCO should also include in the agreement the number of hours that the vendor estimates in good faith is needed for completion. The estimate can help the HCO negotiate if the vendor exceeds the estimated hours and asks for more.
Since it is rare for all needs to be anticipated upfront, the HCO should include in the agreement an open-ended obligation for the vendor to provide additional services at the option of the HCO. Needs may occur for additional assistance on installation, implementation, data conversion, training, customization and interfaces, or consultation.
A typical license agreement includes restrictions that prohibit transferring or disclosing the software to any third party, and these restrictions would prohibit the HCO’s use of third-party data centers to host the software for the HCO. Therefore, for any on-premises solution HCOs may want to deliver to users from a third-party data center, HCOs will need to include the right to have a third-party data center host the software and provide data center services. Here is a sample clause that gives the HCO the right to use a third-party data center and other vendors for other purposes:
HCO may outsource to other vendors any of HCO’s needs or requirements for information technology equipment, resources, or services, including, without limitation, hosting, co-location, application management, and data center services. If and to the extent that any such outsourcing is applicable to any of the licensed software licensed to HCO under this Agreement, then this Agreement and the licenses granted to HCO will be reasonably expanded, if and as necessary, to allow such outsourcing, including, without limitation, the right for the licensed software to be run on servers, computers or processors of such vendors, or at their data centers for HCO. Any such vendor must agree in writing that it will not store, run, or use the licensed software for any purpose other than services for HCO and to protect the licensed software from any unauthorized copying, use, or access by others.
From the vendor’s perspective, revenue recognition issues—the timing with which they get paid for or in anticipation of services—affect many key provisions in the agreement. These issues may arise from:
Do not be caught by surprise—this is a huge issue to many vendors, especially those that are public companies. The HCO should expect pressure to commit or finalize the agreement by the end of the quarter or end of the year, but the negotiating team should work together to recognize and avoid this pressure. Vendors will always be happy for the business, and the urgency can return at the end of the next quarter, for example. Often, discounts are conditioned by the vendor on a signing of the agreement by a certain deadline, with the expectation that the HCO will concede on important points of negotiation to meet the deadline. However, HCOs are usually in a strong negotiating position to ignore this urgency and receive the discount in the next quarter.
Shopping enterprise agreements is very different from retail shopping. Prices are frequently considered confidential information of the vendor subject to nondisclosure. For this reason, a confidential RFI/RFP process can be a helpful way to obtain a broad swath of pricing quotes and better enable shopping for value. In general, an HCO should not have to pay list price for a software license, and any discounts should have a long-term life for future purchases. Sometimes, HCOs and other customers ask for “most favored nations” pricing and terms for newer products looking to gain a market foothold, but this is not typically accepted by established vendors who stand to alienate prior customers or risk significant revenue opportunity.
In many cases, vendors are willing to offer discounts for “strategic accounts.” This can mean many different things such as HCOs sharing hard-to-find expertise, participating in case studies, or providing specific feedback that informs future development. This is not charity from the vendor, and they will often need some reassurance that there is value to the HCO’s participation as a strategic or beta customer. Discounts can be deep (e.g., 75% of the cost of the software) if vendors perceive this will enable subsequent sales at the purchasing HCO or similar HCOs that are not yet customers.
When negotiating the agreement, HCOs may seek opportunities to lock in prices or discounts on optional software, expansions, or future projects. The HCO has the most leverage before signing the agreement and loses that leverage after signing. The HCO should negotiate for a payment schedule that ties some payments to milestones and acceptance. This is a good way to motivate a vendor to stay on schedule. The agreement will often provide that the HCO pay for the vendor’s expenses and other charges, especially with respect to some services. This should not apply to support and maintenance services. For other services, expenses should be reasonable, capped, and documented.
The HCO should consider credits, refunds, or other financial consequences for delays, breaches, or other failures by the vendor. If custom development or lengthy and complicated implementations and rollouts are involved, this can be important. For legal reasons, these credits, refunds, and other financial consequences should not be characterized as “penalties,” even though non-attorneys tend to do so. In some cases, it may be appropriate to characterize them as “liquidated damages.” When faced with the prospect of credits, refunds, or other financial consequences, a vendor may respond by asking for incentives (e.g., additional payment) if time schedules or other performances are overachieved by the vendor. The HCO should be prepared for this response by the vendor and can usually reject it.
The HCO should make sure that everything is covered. The vendor should provide line-by-line pricing for the system selection and/or the negotiating team to review to avoid unpleasant surprises. Open-ended obligations to pay for services (e.g., implementation) may lead to unexpected budget overruns.
It is tempting to expect an implementation and software solution to work as advertised. However, the sales process typically inflates the ease of implementation and use. When things do not meet initial expectations, the termination provisions may be the most important part of the license agreement and represent a key source of negotiating leverage. On one hand, the agreement may be terminated simply because its term expires or because both parties amicably agree to an early termination. On the other hand, breach of the agreement by the HCO or vendor is usually defined as a cause for termination. Sometimes, the agreement includes a clause giving the HCO the right to terminate for convenience—with great reluctance from vendors—or for dissatisfaction. For example, failure of the vendor to meet a nonbinding time schedule or an SLA performance level might not be a breach of the agreement but could trigger a right on the part of the HCO to terminate the agreement if this right is sought prior to signing. HCOs should not give this right to a vendor. Other termination rights may include termination for bankruptcy or insolvency.
Multiyear agreements are often written with an annual auto-renewal term. This indicates that the HCO and vendor intend to work together for several years but offers an annual frequency with which the HCO can terminate the contract for convenience. Vendors typically require 30-, 60-, or 90-days’ notice prior to the renewal date if terminating a contract with auto-renewal.
It should be noted that a license agreement usually includes a survival clause that indicates that certain provisions of the agreement will continue in effect after termination of the agreement. Confidentiality provisions, data storage, and auditing rights are a few such examples. Rarely, the license itself can survive, but other provisions, such as maintenance and support, will terminate.
Nearly every license agreement includes a clause giving each party the right to terminate the agreement if the other party breaches the agreement. Sometimes, one-sided license agreements only give the vendor this right, but in such cases, it is typically easy for the HCO to successfully negotiate for reciprocity.
From the perspective of the HCO, termination, even for a breach by the HCO, can be much more dangerous and unreasonable than meets the eye. If the software is mission critical, it is not practical or realistic to expect the HCO to suddenly stop using the software being relied upon. For example, if the electronic health record (EHR) of the HCO is reliant on the software, the HCO could not possibly stop use of it without severe consequences to patients and operations. Typically, provisions are included that obligate the HCO to stop using the software upon termination. Without a license, continued use of the software would be an infringement of the copyright and other intellectual property of the vendor.
An agreement includes many provisions that can potentially be breached by the HCO. For example, confidentiality provisions could be inadvertently or carelessly breached. Other restrictions, such as a prohibition against benchmark testing, may be breached without realizing that the agreement includes this prohibition. Exceeding the scope of the license is also a breach and can be done unintentionally. In a payment dispute, the vendor can claim a breach and threaten termination if the HCO does not concede and pay the disputed amount. Examining the agreement will reveal many provisions that might be breached.
In the case of an “on-premises” license, the HCO might ignore a notice of termination for breach by the vendor and continue to use the software running on the HCO’s computers to provide continuity of patient care operations. The HCO would do so without support and maintenance from the vendor. The vendor would then be forced to seek an injunction from a court to order the HCO to stop use. Hopefully, a court would not issue such an order if patient safety were jeopardized, but it may be hard to explain to the court why the HCO agreed that it would stop use upon termination for breach and now refuses to do so. The situation is riskier in the case of a SaaS license because the SaaS vendor can more easily terminate HCO access to the software running on the vendor’s servers. Hopefully, the vendor would not do this, but it is particularly unwise for the HCO to agree to breach termination provisions for SaaS. In any event, the vendor is likely to use the threat of termination to extract concessions to its advantage.
At the very least, the HCO should insist that the agreement include provisions that require (1) the breach be “material” to justify termination and (2) the vendor give the HCO notice of the breach and an opportunity to cure the breach before termination (typically 30 days). If the breach is timely cured, then no right exists for the vendor to terminate. Sometimes, more than 30 days is needed to complete a cure, so the HCO should request a clause that allows for an extension of the 30 days if the cure begins within the 30-day period and is diligently pursued to completion.
The ultimate protection for an HCO is to include in the agreement a provision to the effect that the license will survive termination of the agreement even if there is a breach of the agreement. This does not excuse the breach, as the HCO remains liable for damages caused by the breach. The vendor can still obtain injunctive relief to stop the breach, but it is very difficult to get vendors to agree to such a provision. Their attorneys are often adamant that termination of the license is essential for protection of the vendor’s software and intellectual property. This concern is somewhat overstated because (1) the HCO is only seeking the right to continue to use the software within the scope of a license that the HCO has already paid for, and (2) the vendor can always obtain injunctive relief against any use, disclosure, distribution, or copying beyond the scope of that license.
If the HCO cannot get the ultimate protection described previously, the following clause or a variation is reasonable despite the vendor’s dislike for it. It will as often as not be accepted by the vendor:
In view of the mission critical nature of the Licensed Software to HCO and HCO’s reliance on it and of the responsibility of HCO to protect the safety, health, and well-being of patients, Vendor may not suspend or terminate the License [or any services or rights of HCO under this Agreement or any access to or use of the Licensed Software by HCO or its users] unless this Agreement is terminated in accordance with this Section. The vendor may terminate this Agreement only upon a material breach of this Agreement by HCO that is not cured by HCO within 30 days after receiving written notice from the vendor of such breach. The notice must specifically identify the provisions of this Agreement that are breached and must state the actions that the vendor believes are necessary for HCO to cure the breach and must give notice of the vendor’s intention to terminate the Agreement if the breach is not cured. If more than 30 days are needed to cure the breach, then HCO will be allowed such additional time as is reasonably required for the cure, provided that HCO gives notice of the need and begins the cure within the 30-day period and that HCO is thereafter diligent in pursuing the cure to completion. If the breach is not curable, then for the purposes of this Section, the breach will be deemed cured if HCO takes reasonable steps to prevent a repeat of the breach. HCO remains liable for damages caused by its breach and nothing in this Section excuses monetary liability for those damages, but damages are subject to the agreed upon limitations of liability. If HCO disputes in good faith that a material breach has occurred, then the issue must first be decided through the dispute resolution provisions and, if necessary, litigation in accordance with governing law and forum provisions of this Agreement. If a court holds that a material breach occurred, then HCO shall have an opportunity to cure the breach as described above (or to address an incurable breach as described above) to preserve its license and rights and to avoid termination of the Agreement by the vendor. The 30-day cure period will begin when HCO receives notice of the final decision of the court in writing and such 30-day cure period is subject to extension as described above. Nothing herein permits HCO to use, distribute, or copy the Licensed Software outside the scope of the License and rights granted to HCO. Nothing prohibits or delays Vendor from obtaining an injunction to stop HCO from using, distributing, or copying the Licensed Software outside of such license and rights or from otherwise infringing or misappropriating any intellectual property or confidentiality information of Vendor.
Do not think that the nightmare of termination cannot happen. It does and can happen, although rarely. Even if a vendor is very unlikely to abuse termination rights in the agreement if the HCO acts in good faith and is repentant, the HCO is still exposed to the “termination blackmail” threat when the HCO disputes the existence of a breach or disputes what the remedy should be for the breach.
As a final comment on the issue of termination, the importance of this issue is proportional to the significance of the HCO’s reliance on the software and the ease of transitioning to a substitute solution in the event of termination. Many situations exist where the HCO can, with relative safety, ignore the issue because the risk or downside of termination is so low that negotiating with the vendor is not justified. If the software is mission critical to the HCO, then the risk can be summed up as follows: (1) the probability of a serious termination issue occurring is very low, but (2) in the unlikely event that it does occur, the consequences can be very serious. In a worst-case scenario, it may be difficult for the HCO’s representatives responsible for approving the agreement to explain to management why the HCO agreed to allow the vendor to terminate or threaten to terminate the use of mission critical software.
As an additional protection in case of termination, the HCO may want to add a clause entitling it to transition rights and a transition period. A clause of this nature might read as follows:
If the Agreement is terminated for any reason or expires and if the safety, health, or well-being of any patients or healthcare or business operations of the HCO are jeopardized or compromised by such termination or expiration, then the HCO will be entitled to a reasonable transition period to transition to computer programs, products, services, and solutions from another vendor that are a substitute for the Licensed Software, Services, and Solution of this Agreement. During this transition period, HCO may continue to use and exercise the License and rights with respect to the Licensed Software, Services, and Solution pursuant to this Agreement and subject to this Agreement. In effect, the transition period is an extension of the term of this Agreement and delays termination or expiration until the end of the transition period. The transition period must be sufficient in duration to allow for an orderly transition to substitute computer programs, products, services, and solutions, but HCO may not extend the transition period beyond one year. HCO will give notice to Vendor after the transition period ends.
Sometimes, especially for an SaaS license, the transition clause will require the vendor to provide transition services at the vendor’s current standard fees plus expenses.
License agreements frequently include exclusive remedy clauses that state that the HCO’s sole and exclusive remedy for a breach is limited to one specific remedy and not others. For example, a section may state that if the services are not performed in accordance with the warranties, then the exclusive remedy is that the services will be re-performed. Even if performed properly later, there is no compensation to the HCO for the delay. The agreement may even include a provision stating the exclusive remedy still applies even if the remedy “fails of its essential purpose.” The provision then leaves the HCO without a meaningful remedy.
No other damages or remedies can be recovered if the exclusive remedy clause is enforced. Usually, an exclusive remedy clause is applied to warranties, but they can be applied to any obligation in the agreement. Sometimes, vendors are overly aggressive and broad in the language of an exclusive remedy clause and incorrectly (or unfairly) apply it to any breach of the agreement. For example, an exclusive remedy may mention having a vendor re-perform an activity as the sole remedy for any breach of the agreement. However, this action would be illogical for a security or confidentiality breach by a vendor. The exclusive remedy should make sense in the context of the specific breach to which it applies and should only apply to specific breach of contract claims, not to other claims such as negligence or damage to property.
A license agreement will almost always include clauses on limitations and exclusions of liability (EHR contracts untangled, 2016). The HCO should understand these clauses and impacts to the business if invoked.
A limitation of liability clause limits the HCO’s liability to an amount or cap that cannot be exceeded. For example, “In no event shall Vendor’s aggregate liability exceed an amount equal to the license fee paid to Vendor under this Agreement.” The consequence of an HCO agreeing that the vendor’s liability is limited means that the HCO cannot recover damages from the vendor more than the cap, even if the HCO can prove a higher amount of damages. Vendors will typically defend this clause during negotiation, so an HCO strategy may be to require that the limitation instead be a multiple of the license fee (e.g., 300%, 500% of the license fee). It may be better to increase the cap to all amounts paid under the Agreement (e.g., to include support, maintenance, training, implementation, and other service fees in addition to the license fee). Carve-outs on limitations of liability are also common. For example, if Protected Health Information is necessary to use the service, breaches of patient privacy and confidentiality are often carved out and handled elsewhere in an agreement (e.g., a business associate agreement) with higher caps.
An exclusion of liability clause totally excludes certain types of damages from recovery. For example, “In no event shall Vendor be liable for any consequential, indirect, special, punitive, or incidental damages, or for any loss of business, opportunity, profits, revenue, data, or programs.” The consequence of the HCO agreeing to this means that the HCO recovers nothing for these types of damages, even if the HCO can prove that it suffered the damages. Only direct damages remain recoverable, subject to the limitation of liability cap described previously.
The HCO should insist these clauses are reciprocal, so they benefit the HCO, not just the vendor. When these clauses are made reciprocal, the vendor will often insist on exceptions for infringement of its intellectual property, breach of confidentiality, indemnification, and possibly some other clauses. The HCO should negotiate for other exceptions, such as breach of a business associate agreement or data security agreement, intentional breaches, willful misconduct, and wrongful suspension or termination. For example, if the vendor were to wrongfully suspend or terminate a SaaS license and access to the software, the HCO would have little or no monetary recourse against the vendor because the limitation and exclusion of liabilities would prevent recovery of the most significant damages, including loss of revenue and disruption of business. Having these exceptions in the agreement will make a SaaS vendor leery about being too quick to suspend or terminate services for fear of being exposed to unlimited liability for doing so wrongfully.
The vendor should agree to maintain adequate liability insurance, including cyber liability insurance governing data privacy, security breaches, and business continuity. The HCO may need recourse against the insurance for negligence and other covered faults of the vendor, or the HCO may need to be additionally protected. The HCO should carefully consider whether it should be named as an additional insured party in the vendor’s insurance policy, because existing insurance policies may not cover claims against another insured (e.g., the HCO). The limitations and exclusions of liability should not limit or exclude any losses and liabilities covered by the vendor’s insurance policies. The HCO insurance advisor or risk management officer should work with the HCO’s negotiating team in deciding on adequate insurance requirements expected of the vendor.
Some license agreements require a dispute resolution process before litigation or arbitration. There is no single standard for what a contractual dispute resolution process looks like, but a reasonable example may be to hold a meeting to discuss and attempt to resolve the dispute. If that meeting is unsuccessful, the dispute must be escalated to a higher level of management of both parties for discussion and resolution. In some cases, there are even joint steering boards with explicit voting rights as a final step prior to arbitration or litigation. It is often easier to agree to a process for dispute resolution rather than an outcome of a dispute, so having a process defined upfront is a good approach for HCOs, especially as a prerequisite to termination.
The license agreement typically includes confidentiality protections for the parties and their confidential information. The HCO’s confidential information may include RFPs, plans, financial information, and anything that can be learned by the vendor’s access to any networks or computer systems of the HCO. The party receiving the other party’s confidential information should agree not only to keep the information confidential but also to not use it for any purpose other than performing obligations or exercising rights under the agreement.
The HCO should expect to see some or all of the following exceptions in Box 19.19 to the confidentiality provisions. The HCO should make sure that these exceptions do not apply to protected health information or other personally identifiable information, or to any obligation under a business associate agreement or data security agreement. The confidentiality provisions should not prohibit a disclosure required by law, regulation, or court or government order, but a protective order or similar protection should be sought.
An important issue is the duration of the confidentiality obligations. The confidentiality obligations may be indefinite or may expire a certain number of years after the date of the agreement or after the date of first disclosure.
The vendor will include provisions that specifically protect the software and documentation against disclosure or transfer to others. It is not always clear if and to what extent protections apply to screen displays and output (e.g., reports). Because of the broad and restrictive nature of confidentiality provisions, the HCO may want to include an exception for incidental disclosures. For example:
Nothing in this Confidentiality Section or any other confidentiality provisions of this Agreement prohibits any disclosure that reasonably or inherently occurs as part of the licensed use of the Licensed Software or the servicing by contractors of hardware or systems for the HCO. By way of non-limiting examples, screen displays, interfaces and reports generated by the Licensed Software may be visible to visitors to HCO’s facilities and reports and other output generated by the Licensed Software may be given to others in the ordinary course of business.
If the vendor, especially a SaaS vendor, holds or stores any of the HCO’s data, then data security provisions will be needed in addition to the confidentiality provisions of the agreement. These provisions may include absolute restrictions from disclosing certain confidential information to third parties or, more likely, disclosure without written approval of the HCO. Commonly, vendors are asked to complete a Security Risk Assessment document that includes questions for the vendor to complete about compliance with security principles, process for reviewing personnel and avoidance of “bad actors,” use of contracted third parties, network security practices, system security practices, and use of third-party applications. Software security breaches can expose an enterprise to fraud, ransomware, or other threats, so it is advisable to include an IT security review as a part of any software licensing review.
HCO data can confer important strategic advantages to the organization and involves additional considerations and protection under HIPAA in the case of patient data. To the extent patient data are involved, the HCO may want to go beyond the protections afforded by a business associate agreement. Vendors will often include a provision to de-identify patient data to support product development or other commercial purposes. Once appropriately de-identified, the data are no longer protected by HIPAA, essentially offering the vendor a license to use the data as it sees fit. HCOs should seek provisions that specifically protect patient data even if de-identified and aggregated. Furthermore, the agreement should specify data ownership, especially for aggregated data generated through use of the vendor’s software. The HCO will want to consider carefully how population health data will be managed, define who owns the resulting data, and include these aspects in the agreement.
The license agreement should include a warranty of non-infringement and a clause indemnifying (providing compensation for a particular loss) the HCO and its users of the software against claims that the software or its licensed use infringes or misappropriates any patent, copyright, trade secret, or other intellectual property. Often, the vendor will not offer a warranty of non-infringement, saying instead that it only offers an indemnification clause. These clauses can be complex and include exceptions that need to be carefully considered. The clause might indemnify against monetary judgments payable to the owner of the intellectual property, but often not against the HCO’s own losses or damages if it must suddenly cease use of the software because of an infringement claim. The HCO will want broader indemnification protection.
The vendor may seek to have the HCO indemnify the vendor against claims by others arising from the HCO’s use of or reliance on the software or its use, results, and output. It is not uncommon to see vendors disclaim responsibility for the results and output of the software and to require HCOs to examine and verify those results and output, such as accuracy of medication calculations. The best approach is to delete these types of provisions, especially indemnification by the HCO, and simply make each party responsible for its own fault in the event of any claims by a third party.
The HCO should take careful note of restrictive covenants and feedback clauses and should only agree to them if they are reasonable and understood by the HCO. Restrictive covenants include non-compete clauses and other restrictions on doing business or conducting certain activities with others, as well as clauses that prohibit the hiring or solicitation of the other party’s personnel.
Feedback clauses may require the HCO to assign ownership of feedback and its intellectual property to the vendor. Feedback is typically defined as suggestions, ideas, recommendations, improvements, and enhancements relating to the software or a service of the vendor. This can become a serious problem if the HCO wants to use or commercialize the feedback independent of the vendor or to share the feedback with other vendors. At most, a feedback clause should only grant to the vendor a nonexclusive license to use the feedback in the vendor’s software and services. This license should be granted on an “as is” basis without any warranty. Any feedback clause requires careful consideration and possible exceptions (e.g., for copyrights and patents).
These clauses indicate which jurisdiction’s law will govern the agreement. The forum clause indicates the jurisdiction and venue for any litigation between the parties (i.e., where a lawsuit will take place). It may seem odd, but a court in one state may apply the law of another state to the agreement and dispute. With respect to jurisdiction and venue, one compromise is to say that a party may only bring an action in the state (or more specific venue) of the other party. This may discourage litigation.
License agreements generally prohibit an assignment (of license and other rights and delegation or transfer of duties and obligations) or transfer of the agreement to a third party. Given the possibility that the HCO may merge with or be acquired by another entity in the future, it is a good idea to at least allow the HCO to assign or transfer the agreement if the HCO or its assets or business is acquired by sale, merger, or otherwise. A change of HCO control should not be deemed as a prohibited assignment or transfer.
The license agreement should prohibit the vendor from using the HCO’s name, trademark, service mark, or logo in any marketing, sales, or promotional materials; on a website; or in any other public communication without the written consent of the HCO in each case, including the right of prior review. Use of the HCO’s name in a list of customers or a press release may be permitted by the agreement without that consent. Vendors should not be allowed to use these materials to imply any HCO affiliation, endorsement, or sponsorship of the vendor or its software, product, or service. Sometimes, HCOs may want to allow certain types of endorsement, for example, as a reference customer or by participating in a published case study, but these tend to be the exception for strategic relationships with vendors. In addition to HCO brand protections, similar restrictions should be considered for the name of any officer, researcher, developer, clinical informatician, physician, or other healthcare professional employed by the HCO.
License agreements are an essential part of an HCO’s software procurement process. An understanding of those agreements and a willingness to negotiate for reasonable terms and conditions can reduce risk, save money, and protect the HCO against unpleasant surprises. An agreement, no matter how favorable to the HCO, is never an acceptable substitute for due diligence prior to the signing of the agreement or for a careful and systematic vendor selection process. After the agreement is signed, the HCO should have a process for ensuring and monitoring compliance with the agreement and for using the protections and advantages successfully negotiated into the agreement. Although it may seem obvious, the HCO should have an organized archive of agreements and an index and summary of the important agreements that can be consulted when needed. Finally, never underestimate the leverage that an HCO may have to contractually protect itself. The future of license agreements will only grow more complex as technology and data become more distributed over time. As data are merged from different sources, data ownership and security breaches will continue to be issues in the future.
The authors wish to acknowledge the contribution of Jon C. Christiansen to the previous edition of this chapter.
Best Bet Hospital is a tertiary care medical center with 500 acute care beds, 35 ambulatory clinics, a Level-1 emergency department, a 75-bed skilled nursing facility, and telehealth services for both stroke and dermatology services. The leadership decided to change its EHR after a 10-year life cycle and shift to a SaaS agreement. You are the long-term care representative on the selection committee. Due to your expertise in healthcare, leadership has asked you to assist with the licensing agreement for this purchase.