NEGOTIATING HEALTH IT CONTRACTS

Transcription

1 NEGOTIATING HEALTH IT CONTRACTS Physicians and Hospitals Law Institute, Las Vegas, NV, February 2015 American Health Lawyers Association Dawn R. Crumel 1 Shipman & Goodwin LLP Washington, DC Introduction When negotiating health IT agreements physician organizations and hospitals ( Provider(s) ) often find vendors unwilling to negotiate material terms that have financial, operational and regulatory impact on the Provider. While the Request for Proposal (RFP) process may slow down the contracting process, it provides Providers a boost in bargaining position and results in having vendors agreeing to contractual terms prior to being awarded a contract. In addition, a Provider may consider negotiating with more than one vendor at the same time, so that the Provider is not wedded to a particular vendor if negotiations are not as desired despite the RFP process. This paper/outline is intended to address key aspects Providers should consider in negotiating Health IT agreements. The corresponding paper, Critical Requirements for Creating a RFP for HIT Systems, from Jeffrey Daigrepont of the Coker Group addresses the RFP process and using leverage to negotiate better Health IT contracts. Roadmap Prior to purchasing any additional health IT software, a Provider should have a health IT roadmap. A roadmap enables the Provider to look at its long term goals for functionality and see how each solution interconnects. It is advisable for the Provider to evaluate how each solution the Provider currently has works and interfaces with other solutions the Provider has. Any additional solutions should be compatible with the current solutions and help the Provider achieve its IT functionality goals in the roadmap. This consideration is especially important when considering issues of interoperability as discussed herein. Definitions Critical aspects of the Health IT contract turn on the definitions. The Provider should indicate upfront and in writing that the responses to the RFP will be included in the definitions in the 1 The views expressed herein are solely of the author, and should not be attributed to any current or former employer or client. This outline may be used, in whole or in part, in other presentations and articles by the author. The author would like to acknowledge the assistance from Cherie Pardue and Bill Roberts in preparing this paper. 1

2 contract and that the vendor may not make changes after the negotiations to the RFP responses. Issues such as the extent of the license, what the documentation is, when the agreement starts and what warranties include depend on key elements in the definitions. It is critical to include the IT professionals of the Provider in the contract discussions to ensure the descriptions are detailed enough. Key elements to include within the definitions are network components, updates, enhancements, new releases, technical and functional specifications, interfaces, and customizations. The Provider should ensure there is substantial detail in the documentation description as most aspects of functionality and performance will hinge on the specification of the documentation. In addition, some contracts do not clearly define the products and services the vendor will provide, raising the possibility that the vendor later will charge the Provider additional fees for services thought to be included in the original price. Many contracts carefully limit the exact services the vendor will provide including maintenance services. A health IT contract with many maintenance exclusions will result in the Provider incurring additional costs down the road when it needs services that are outside the scope of the definition. Vendors make their bread and butter in the maintenance provisions of health IT contracts. To avoid additional costs outside the basic service fees, the defined services to be provided should be clearly understood and not have unreasonable limitations within the definition. Defining User can be a critical aspect of a health IT contract. Vendors may price contracts on the basis of the number of authorized users or the number of concurrent users. User generally is defined as a specific individual, rather than defined as interchangeable among different people. The Provider will need to pay additional fees to allow any additional individuals access to the data. Another limitation in the definition of User is a particular geographic location. The contract should expressly allow for use in all locations with language addressing expansion or changes in the Provider s location. To illustrate the importance of defining User as broadly as possible, the following sample user license shows how costs pivot on the definition of User: for permitted users to use the software only for customer s (and all permitted users) internal business purposes related to operating the facilities (i) the software may be installed only on equipment located at the facilities (except for back up); (ii) the software may be used only at the facilities (except for back up) and (iii) the software is limited to the number of users identified. Fees The Provider should understand the different sources of vendor fees and negotiate to predetermine those fees in the contract based upon contracted rates rather than market rates the vendor charges at the time of service. Types of fees include: 2

3 Licensing Fees - The Provider pays this fee in order to utilize the vendor s software. Equipment Fees- Providers should account for any additional costs for installation on hardware or third party costs in operating equipment. Maintenance Fees - The vendor charges fees to maintain the software and equipment to the specifications. The contract should define the level of service. This fee should specify any fees associated with the vendor s upgrades to new versions of the software. Professional Services Fees - The Provider pays the vendor in exchange for consulting services and similar professional services. These fees should be contracted rather than market rates. Implementation Service Fees - The vendor charges the Provider for services to set up the software, including data conversion, software loading, equipment installation, software testing, services set-up and training. The level of training should be specified including the length of time training will be provided, whether the training will be onsite or at the vendor s location, the costs of travel for the vendor s trainers or the Provider s staff, and the cost of any additional training. The cost of implementation is often unexpectedly high due to lack of transparency. Interface Fees - The vendor charges for developing interfaces to other health IT systems. Additional Features - Providers should clarify which services and features a base quote includes and any additional subscription or other fees. The vendor will want to allow for increased fees at a later date. It is advisable to limit any increase in fees by the amount and frequency. For instance, the amount of any such increase will not exceed 3% or the percentage annual increase in the Consumer Price Index, and fees may not increase more than annually after the fifth anniversary of the go - live date. Licensing The license provides for the quantity of the service to be provided. It often is quantified by the number of users. It is important to the Provider to ensure as broad of a license as possible. Otherwise, the risk is that there can be payment of significant additional license fees, that the provider is liable for financial penalties for violating the license agreement, and that the license may be terminated for breach. The Provider should ensure the scope of the license covers: all potential users, each computer housing the software and the geographical location. The vendor is unlikely to allow for unlimited users; however, there needs to be allowance for a broad number of users such as affiliates who would use the software in conjunction with the Provider. It is better not to define the scope of users with a specific list of entities owned by the Provider. The definition should include any entity owed or operated so that entities formed at a later date fall under the license. Additional important considerations regarding the license include: The right to utilize in the event of a merger or acquisition; 3

4 The term of the license: fixed, annual, perpetual? Is there a single upfront payment or are there license fees as long as the license remains in effect? Is any third-party software included in the system that may require a sub-license? Negotiate the right to get approval for modifications through the vendor. If the Provider modifies without permission indemnification protection may be lost. Ensure right to have a copy for training, implementation testing and backup of data. The contract should guarantee back up service, as well as training on how to access the stored data in such case as the need arises. The vendor is likely to audit the license use of the software. The purpose of the audit is to determine if there are more users than permitted by the license. If the vendor finds more users, then the provider may owe additional fees. The provider should negotiate the parameters of the audit which can be resource intensive but also to ensure the audit is not overly broad. It is important for the Provider to limit the audit to the scope of the license and to negotiate that all costs associated with audit are covered by the vendor. Another consideration is that there be sufficient time and notice for the audit, and that it be conducted in a manner than does not disrupt the business of Provider. Acceptance Testing It is critical to use acceptance testing to determine whether the vendor provided the agreed upon product. Acceptance testing provisions include the acceptance criteria and the testing process. Providers should not agree to general acceptance testing. Acceptance testing criteria include the product definition, documentation, the functional and performance expectations, and warranties. The testing process should detail the triggers for different levels of testing, when parties report deficiencies and the correction of deficiencies and retesting. Certain payment commitments should be withheld until acceptance testing is final, the first productive use or a period after the go-live date. To illustrate, sample acceptance language is the following: Customer will have the right to test any software delivered by Vendor hereunder to ensue that it performs in all material respects in accordance with the applicable documentation. Such testing will commence on the software delivery date and will end days after the go live date as may be adjusted as provided herein (Testing Period). Prior to the expiration of the Testing Period, Customer may provide Vendor with a reasonably detailed written report identifying any material nonconformance in the performance of the software from the documentation. In such event, the Testing Period will continue and Vendor has days to correct the material nonconformities submitted. Once the software corrections have been delivered to the Customer, Customer has days to test. If Vendor is unable to correct the material nonconformities within _ days, written notification and explanation must be submitted to Customer along with a commercially practicable resolution timeline. Both parties will cooperate in good faith to resolve any issues 4

5 and seek mutual agreement on corrected software delivery timeframe. However, if mutual agreement cannot be reached, Customer has the right to invoke software quality warranties. Payment Milestones, Uptime Guarantees, Warranties Often parties negotiate payment milestones, uptime guarantees and warranties into agreements. Payment milestones allow payments to link to a vendor s performance obligations rather than calendar dates. These milestones should be coordinated with detailed acceptance testing criteria. For instance, 20 percent of the contract price may be paid upon execution, 20 percent upon delivery, 40 percent upon completion of installation, and the remaining 20 percent upon final acceptance or 45 days after go-live. Payment milestones give Providers a better negotiating position than payment at execution or within 45 days after execution, for example. If the vendor pays the full amount due within the first 90 days after execution but implementation has been delayed, the vendor will have less incentive to resolve diligently the implementation issues. Providers should negotiate uptime guarantees from the vendor. Vendors frequently warrant that the software will be up a certain percentage of time and performing pursuant to the documentation. In the event, there is downtime above a certain percentage of time, then the vendor provides the customer with credit for future services. What parties may not realize until implementation is that there may not be a meeting of the minds for process for recording downtime. The software may be up and running, except one segment of the software is not working. To correct the one malfunction of the singular segment of the software, the whole system may need to go into downtime. The vendor may not count this as downtime as the software can be up and running and is only down to correct a specific issue. Warranties are likely to be limited in a vendor form agreement. In negotiating a more extended warranty Providers should address system compliance with functional and performance specifications, compatibility of components, viruses and disabling devices, prevention of unauthorized access or usage of system, and availability of support and maintenance. Warranties are only as good as the documentation definition. The more detailed the documentation description there is the less likely there is to be a dispute over the extent of the warranty. Enhancements, Support and Maintenance Like most technology health IT rapidly changes. It is important for Providers to secure enhancements and updates in an included price in the contract. Moreover, the cost of implementing enhancements and updates is very costly and often over looked in the contract process. Often a Provider does not have the resources to pay for all of the updates. To counter the cost of enhancement implementation costs, Providers may want to negotiate free labor to future upgrades or negotiate the cost of maintenance down in exchange for enhancement implementation fees. 5

6 Support and maintenance are critical implementation factors. The contract should address and clearly define the hours and days support is available and what types of assistance are available. The contract should also address the consequences if the vendor does not meet the support requirements. Maintenance may add significant additional costs to the vendor contract, including for new software releases, new functional capabilities, and other product upgrades or enhancements. It is important that the contract specify what is included in the maintenance agreement and how the maintenance costs are calculated. Interoperability Generally, Interoperability means allowing for information exchange among HIT systems. Specifically, the HIMSS Board of Directors approved the definition of interoperability as In healthcare, interoperability is the ability of different information technology systems and software applications to communicate, exchange data, and use the information that has been exchanged. Data exchange schema and standards should permit data to be shared across vendor. Interoperability means the ability of health information systems to work together within and across organizational boundaries in order to advance the health status of, and the effective delivery of healthcare for, individuals and communities. 2 HIMSS further describes three levels of interoperability as follows: 1. Foundational interoperability allows data exchange from one information technology system to be received by another and does not require the ability for the receiving information technology system to interpret the data. 2. Structural interoperability is an intermediate level that defines the structure or format of data exchange (i.e., the message format standards) where there is uniform movement of health data from one system to another such that the clinical or operational purpose and meaning of the data is preserved and unaltered. Structural interoperability defines the syntax of the data exchange. It ensures that data exchanges between information technology systems can be interpreted at the data field level. 3. Semantic interoperability provides interoperability at the highest level, which is the ability of two or more systems or elements to exchange information and to use the information that has been exchanged. Semantic interoperability takes advantage of 2 standards/what is interoperability 6

7 both the structuring of the data exchange and the codification of the data including vocabulary so that the receiving information technology systems can interpret the data. This level of interoperability supports the electronic exchange of health-related financial data, patient-created wellness data, and patient summary information among caregivers and other authorized parties. This level of interoperability is possible via potentially disparate electronic health record (EHR) systems, business-related information systems, medical devices, mobile technologies, and other systems to improve wellness, as well as the quality, safety, cost-effectiveness, and access to healthcare delivery. 3 Interoperability is not easily achievable. Previously, most products were built around the standard of HL7, and Providers could purchase software solutions from multiple vendors to meet multiple needs without as much concern as to whether the solutions would be interoperable. Vendors moved to create market dominance by creating solutions with very specific platform standards that may not be compatible with those of other vendors. Even with federal standardization requirements such as meaningful use the expense to create interfaces and the lack of clinical standards for data have made interoperability less than easily obtainable. Some larger health systems have moved to single source solutions where there is only one system. For instance, all products are from Cerner or Epic. As such health system affiliates it requires the affiliate provider to utilize the same system or it declines to affiliate to affiliate with such provider. A health system has to have enough market dominance to require a particular health IT platform for affiliates as the expense of losing critical strategic partners can be very high when there is a need for clinical integration. In the event a Provider cannot move to a single source solution due to the expense of its existing long term health IT contracts and lack of market dominance, it should consider solutions such as Commonwealth Health Alliance. Commonwell Health Alliance, with members such as Cerner, athenahealth, McKesson and Allscripts, develops and offers services that are embedded natively in vendors own software to enhance interoperability across vendor lines. Therefore, the different solutions are programmed to interface with one another. Notably, Epic is not a member of this alliance though. In addition, Providers, who cannot single source, are looking to build a platform across solutions on their own. This process can be very resource intensive and time-consuming. However, the Provider s IT employees and consultant may best understand the particular needs in building a specific platform. 3 standards/what is interoperability 7

8 In negotiations with vendors there needs to be particular attention to the standards the vendor utilizes. Lack of full understanding of the facets of a vendor s standards has caused implementation issues down the road after the parties sign the contract. Part of the issue may be that the salesperson may not have the technical knowledge to describe accurately the vendor s standard. It is important to engage the Provider s IT staff and consultants with the vendor s IT staff and consultants as the Provider considers purchasing the solution and before the contracting phase. Additional considerations in addressing interoperability before a contract is executed are: Conducting an internal review of the standards on which the Provider s solutions currently operate. Consider state requirements for HIE. The speed in which data needs to be obtained. Patient engagement - Each solution has its own patient portal so that patients are interfacing with multiple portals. Vendors should commit to assisting Providers to ensure interfaces between the portals to enhance rather than complicate the patient experience. Interfaces Interfaces allow disparate technology and systems to communicate with each other. They are integral to successful implementation and interoperability. It is essential that the vendor provide interfaces to Providers for pre-existing systems to interact. The labor costs associated with interfaces can be expensive. Providers should negotiate reduced or pre-determined costs. Data The reason to have the health IT system is for the Provider to access and rely on the data. Often vendors will not be held responsible for any clinical decisions based upon the data. Ensuring the accuracy of the data is critical to the Provider. The contract may provide for certain testing of the data to ensure it is accurate, however, the Provider may not have the resources for consistent testing. The Provider may consider requiring the vendor to agree to a self-audit, as discussed herein, in the RFP. The contract should give full ownership of all data to the Provider and state that all data will be returned to the Provider if the contract is terminated for any reason. The Provider should be particularly careful about third party contractors retaining data. An additional consideration with data is being able to utilize the data to ensure the safety and quality of care. Clinicians are critical to the discussion of data needs in the contract as they best understand their needs. Providers need to engage their clinicians to ensure a good understanding for the data needs so the patient care can be enhanced. Moreover, with clinically integrated 8

9 networks Providers not only need to show data integration but also must show that Providers are still delivering at least the same level of care. Liability and Indemnification The limitation of liability clause is often highly negotiated. Often vendors try to limit liability to the fees paid for the particular portion of the software causing the issue or fees paid within a year or a low flat dollar amount such as $100,000. The Provider needs to consider if there is a claim how much damages may be before it agrees to limit narrowly the liability. It is advisable to opt for a broad limitation of liability such as all fees paid pursuant to the agreement. Certain causes of liability should be excluded from the limitation of liability including: breach of confidentiality and privacy; intellectual property infringement; and vendor s breach resulting in the Provider s failure to achieve meaningful use in a timely manner. Often vendor form agreements solely offer indemnification for infringement. The contract should contain much broader indemnification provisions. The indemnification should protect the Provider from at least the following: vendor s breach of its obligations; HIPAA and privacy/confidentiality violations by the vendor and third-party claims for bodily harm, injury, or death caused by the vendor s personnel or software. The vendors are most likely to impose indemnification obligations on Providers. Regardless of the cause of the fault vendors may require providers to indemnify them for any third-party claims brought against the vendor as a result of the vendor-provider relationship. For instance, the vendor may hold the Provider responsible for all clinical decisions made even if the Provider relied on faulty data provided by the vendor. Self-Audit Many Providers are unable to audit the vendors with which they contract due to lack of expertise or lack of financial or personnel resources. Other Providers may be unwilling to audit a vendor due to concerns with accepting vendor policies and procedures which may in fact be insufficient or which the Provider may later want to challenge. As a result, health care providers are increasingly turning to a vendor assessment and self-audit protocol, through which the vendor submits information to the Provider regarding its policies, procedures and safeguards relevant to the transaction or engagement. In some instances, the Provider may have a question and answer assessment form that the vendor is asked to complete. The RFP process allows the Provider leverage to have the vendor agree to audit itself. The issues a Provider may seek to have addressed during the self-audit include: Personnel screening - are background checks performed on new hires? Are current personnel checked for exclusions from federal or state health care programs? 9

10 Subcontractor screening - does the vendor screen subcontractors it engages to perform services related to the proposed contract? What does the screening entail? (e.g. experience, qualifications, data security, exclusions) Training - Are vendor s employees and staff trained on applicable compliance issues, such as the privacy and security of health information? If yes, how often is training provided? Information Privacy and Security - what privacy and security measures and safeguards does the vendor employ? (e.g. password protection, malware protection, encryption) What are the vendor s policies for the return or destruction of sensitive information? What are the vendor s breach notification and response policies? Compliance History - has the vendor been the subject of any compliance-related investigations (e.g. data breach)? What was the outcome of such investigation? If an adverse finding resulted, what steps has the vendor taken to prevent such violation from occurring in the future? A Provider may also ask the vendor to self-certify to the information provided during the selfaudit and the results of the self-audit. When adopting a vendor self-audit program, a Provider should consider the following: Assign business persons with contracting authority to request vendors complete the selfaudit. Identify individuals to review the vendor self-audit reports to determine if any risks may prevent the engagement of the vendor from moving forward Train relevant business persons on the self-audit tool and information requests to enable them to interface with vendors and potential vendors and answer questions Termination The reason a Provider enters a health IT contract is to utilize data in a format that can be utilized easily by the Provider. When a Provider exits a health IT contract or it finds the vendor is no longer providing the service, it needs to ensure that it will be able to keep that data in a format that can be utilized easily by the Provider. The time to ensure that the data can be transferred in a format that is useful for the Provider is before the parties execute the contract. Issues to ensure are o Where the data will be; o What type of format; and o How data can be transferred. The contract should require that the vendor assist with the transfer of the data for at least 12 months. When the data is transferred there can be an issue with the data staying in the same format in which it was stored and that it can continue to be utilized after transfer. The Provider should ensure it understands any changes in format. 10

11 However, the vendor may not be in business at the time of transfer. Therefore, the Provider should ensure that it can utilize the data in the format that is market standard or in a format otherwise usable by the Provider. The vendor should allow for a one time transfer in the event of termination of its business. To further protect against issues at the time of termination, the Provider should ensure the contract allows for and that it periodically back up copies of the data on its own onsite server, if available. Costs for transfer of data should be negotiated up front so that the vendor cannot tack on additional charges at the end. Ideally there would be no additional fees. If there is a fee it should be at set or contracted rate. Conclusion While the world of health IT contracting is very much vendor driven, Providers can leverage negotiating power through the use of an RFP and through dual negotiations with vendors. Getting the IT staff involved in the road mapping of solutions and in the details of the standards and documentation early is another key to successful health IT contracting. 11