Article

IT Contract Negotiation Tips and Techniques

14M02 MLH Using-Stark-Anti-Kickback

Whether your organization is a large healthcare system or small medical group, there is more to information technology (IT) vendor contract negotiations than getting a good price. Numerous factors, such as the cost of systems, the potential for implementation failure, and the complexity of switching vendors once a system is implemented make it very important to thoroughly understand any contract before it is signed and to negotiate key points to the best of one’s ability. This article covers the key contract elements that need careful negotiation to ensure that you get optimal value.

Understanding an IT Contract

A good contract should be balanced, clear, and easy to follow. Unfortunately, standard vendor contracts are designed to protect the interests of the vendor, not the organizations or communities using the system.

Agreements vary by vendor but typically consist of the following:

  • End User License Agreement (EULA) – The EULA grants the license to the organization and states the conditions for doing so. This includes the licensing metrics or how the product is priced (e.g., number of physicians, number of providers, named users, concurrent users [expected number of individuals to be accessing the system at any time], seats, visit volumes); the term or duration of the license; protections and warranties; procedures in the event of breach and/or termination of the contract; and costs and payment terms.
  • Master Services Agreement (MSA) – The MSA describes the services to be provided in support of the license. These typically include implementation assistance, maintenance, upgrades, ongoing system support, and processes to seek resolution if needs are not met (also called “escalation”). Sometimes the EULA and the MSA are a single document. In many cases, the MSA may simply be several sections of the EULA.
  • Bill of Materials (BOM) – The BOM indicates the items to be purchased, quantities of each, and related cost. Examples include system modules, number of licenses, data to be converted or interfaced, and implementation services. Often, the BOM includes components and services that are purchased directly from the vendor along with items that are provided by third parties (such as hardware, operating systems, databases, reference materials, and clinical content). The BOM may be part of the EULA or it may be an addendum.

Application service providers (ASPs) are organizations that provide their information systems via the Internet on a per provider per month (PPPM) basis and typically do not grant a user license. Instead, they may use an MSA in combination with a hosting agreement to describe how the application is going to be supported. Software as a service (SaaS) models, which may be referred to as cloud-based, are similar.A complete negotiated contract may consist of the documents listed in the table below.

The items listed in the Attachments row of the table above are typically found in agreements with larger organizations and are important because they can eliminate ambiguity. If your organization has not issued an RFP and therefore does not have an RFP response to append, you may wish to create a simple statement affirming key system functionality, timelines, commitments made during the sales process, and other critical requirements.

Negotiation: Asking the Right Questions

A major IT purchase needs to take into account how the product will be used, how long it will be used, and what will happen when it is no longer necessary. The following key issues should be considered to ensure that there is consensus on the main points of an IT agreement.

  • Duration of Agreement – It is important to consider how long it will take you to implement and gain a full understanding of the application. From that point, you should determine how long you anticipate using the system. While the ideal answer may be “forever,” in reality, many businesses change significantly every 3 to 5 years, and it may not be feasible to project further. Therefore, an agreement that commits the organization to using a tool for more than 5 years may become a hindrance.
  • Timing – You should consider whether the time of year or other events (e.g., vacation, bringing on a new practitioner, opening a new clinic) might affect the overall success of the implementation and plan for these in your implementation and timing of payments. For example, many vendors require a portion of payment on signing and then the remainder of payment upon delivery of the software (which typically takes place within a very brief period after signing). If the organization may not be able to take full use of the system for some period after signing, it may be prudent to negotiate milestone-based payments (i.e., upon go-live or active use of the software) or to delay signing until the organization is in a position to move forward. Similarly, some vendors charge for implementation services upon signing or based on an implementation plan, with penalties if the implementation is delayed for any reason. Understand that there may be foreseeable delays and plan for these in order to prevent a financial impact to the organization.
  • Meaningful Use – Because many organizations are trying to implement new systems to take advantage of meaningful use-based stimulus dollars, there may need to be commitments that the vendor will assist the organization in a timely manner and that the system will be certified so that the eligible provider or eligible hospital can meet the meaningful use conditions. Even if a vendor is meaningful use-certified or provides a meaningful use guarantee, it should be understood that the criteria will change and become more stringent over time and that the organization will need assistance (as well as interoperability and reporting) to meet the criteria.
  • Integration and Conversion – If the system is going be interfaced to other systems (e.g., laboratories, imaging centers, practice management) or if data is going to be converted from an old system to the new one, the contract should clearly state all integration/conversion fees as a not-to-exceed number. It should be recognized, though, that other vendors involved in the integration/ conversion may charge for their efforts as well.
  • Growth Assumptions – While it can be difficult to predict how an organization may grow (or shrink) over the useful life of the system, it is important to understand which fees may increase as the organization grows and whether fees will be reduced if the organization shrinks.

There need to be reasonable assurances that the vendor will be able to make the system compliant with new regulations in a timely manner.

  • Uncertainty of Government Mandates – An increasingly troublesome issue regarding IT vendor contracts is the uncertainty surrounding both the content and timing of federal and state regulations. When new regulations such as ICD-10 are promulgated, what are the rights and obligations of the vendor? First, there need to be reasonable assurances from the vendor that it will be able to make the system compliant with new regulations in a timely manner.

Second, the vendor needs to be transparent about whether system revisions will be priced as a new product or service. Users are obviously vulnerable to vendors aggressively pricing required system revisions. While payment to the vendor for such system enhancements may be reasonable, the pricing should reflect the vendor costs spread across all users who will be impacted by the changes. Contract language that addresses pricing policies for such contingencies should be developed in the negotiation process.

Reviewing the Documents

Prior to negotiation, request all contractual documents from the vendor. Read through the documents and highlight any terms that are unclear. Make sure that all supporting documents (e.g., BOM) refer to the right number of providers, locations, and uses of information based on the organization’s understanding. If there are any interfaces to be developed (e.g., with community laboratories, between an electronic medical record and a practice management system), ensure that these are noted. If the language seems ambiguous or one-sided, be sure to highlight it. Think through the key assumptions and business risks, and make sure they are covered.

Specific questions that can be asked to identify items for negotiation include:

  • Is the term of the agreement long enough to achieve meaningful use of the software? Is it so long that it creates a business risk? How does the term of the agreement relate to the ability to terminate it? A perpetual license may be adequate as long as the organization can terminate the agreement without penalty with adequate notice. If the vendor is going to terminate the agreement, notice should be adequate to enable the organization to find and transition to a different solution.
  • What should happen if the software is discontinued or the vendor goes out of business? Will source code be kept in escrow? Can the organization continue to use the system from a different supporting organization?
  • Who owns patient data? How is this protected? What rights or controls does the organization have over use of its information or patient information?

The answers to these questions and others will assist in formulating negotiation strategy, going-in positions (initial statements), and fallback positions (acceptable outcomes)

A qualified healthcare IT attorney can be very helpful in reviewing proposed contracts and identifying terms for negotiation. We suggest engaging legal counsel during the acquisition process because presenting key terms and conditions up front will lead to a better outcome.

The Negotiation Process

The goal of the negotiation should be to achieve a balanced agreement. It can be helpful but is not typical to conduct negotiations face-to-face. If the negotiations take place over the telephone, it is important to first establish a rapport with the negotiation team and ensure that they understand the perspective of the organization.

An overly aggressive initial stance can result in a loss of credibility and potentially failed negotiations.

For a system with limited scope, one to two key stakeholders and the salesperson typically conduct negotiation discussions one on one. Since it may not be cost-effective to engage a negotiator, rapport is crucial to moving beyond individual desires and striking a balance.

It is also helpful to have individuals responsible for implementation and services available to listen to the negotiation so that they understand how to administer the contract after signing. Often, organizations strike balanced deals, but implementers on each side are unaware of these terms and conditions. For example, if the deal includes acceptance criteria, the implementers should be involved in the development and sign off of those criteria.

When initiating negotiations, be sure to establish clear ground rules. Examples include ensuring that both sides are comfortable asking for time to confer in the event that a contentious subject is discussed. In face-to-face negotiations, it is helpful to have a spare room and conference line ready to allow individuals to discuss privately or confer with colleagues who are important to the decision-making process. When negotiating over the telephone, it can be helpful to set up instant messaging accounts among the negotiation team for private, nonverbal communication.

Prior to negotiations, ensure that the team is in agreement on key positions that will be requested during the negotiation. Often, an organization will take a stronger going-in position knowing that it has room to fall back. However, an overly aggressive initial stance can result in a loss of credibility and potentially failed negotiations.

In terms of process, it is often best to clearly explain the reasoning behind certain requests so that each side can determine how to meet the objective without making undue compromises. For example, if payments terms are initially one-sided in favor of the vendor (i.e., front-loaded), the organization may explain concerns (the need for a successful pilot, the risk of failure, specific needed developmental functionality, or concerns regarding competition for vendor resources) that thus require a milestone-based payment or at least a balance between front-loaded and back-loaded (conclusion-oriented) payments. Vendors that are publicly traded may have concerns about how to book revenue from contracts that are milestone- rather than date-based. In this example, a logical and reasonable conclusion can usually be negotiated.

Review the final agreement with the individual from the organization (project manager) and the vendor (implementation lead/project manager) who will be responsible for implementation to ensure they are aware of key contract terms and can follow them.

To keep the negotiation focused, it is helpful to create an issues list. The issues list indicates the specific areas to be negotiated, starting language, going-in positions, fallback positions, and progress. This issues list tracks specific deal points and can be very helpful to summarize key concessions toward the end of the negotiation, when it becomes clear that both parties will need to make concessions in order to bring the deal to closure. It is always important to seek the advice of legal counsel prior to and during negotiations to ensure that legal risks are evaluated. The final step of negotiation is to review all documents in their final format against the issues list and ensure that there are no typographical or conceptual errors prior to signing. After signing, it may also be helpful to review the contract with individuals involved in implementation from both the organization and the vendor to ensure that everyone understands the key contract terms that pertain to implementation and maintenance and that all parties are prepared to administer the agreement. The other key is billing. Make sure the vendor can bill to the contract terms and that the organization knows who is on point to review invoices prior to payment.

Conclusions

While it might seem to be the last box to check off prior to implementing a system, negotiating a vendor agreement requires careful thought and consideration. Rushing this process or blindly signing agreements can result in arrangements that are unbalanced in favor of the vendor and difficult to exit. It is also important to ensure that the structure and form of the agreement adequately support the relationship between the vendor and the organization. Preparing for the negotiation by outlining organizational requirements and, subsequently, key terms and conditions will make for a clearer and smoother negotiation, as well as a smoother implementation and maintenance of the product. Qualified legal counsel should always be engaged to review documents prior to signing, as legal terms and considerations in these arrangements are extremely complex.

Comments