Scope of Software License

Ensure the licensed scope covers your intended use both internally and in connection with physician, patient, and community outreach.

Many vendor licenses are written in terms allowing you to use the software for your “internal purposes only.” Such a restriction will likely not encompass all of the uses to which you may want to put the software. A better, more encompassing approach is to draft the license in terms of permitting you to use the software for your “business purposes.”

“No service bureau” provisions are common in software licenses and may preclude you from utilizing your system with physicians and patients if the concept of “service bureau” is not appropriately addressed. As such, this issue should be carefully considered in every license agreement. Ask the question, “Will we need the ability to process the data of, or on behalf of, any other entities or individuals?” If so, the “no service bureau” provision should be revised to permit your intended uses.

In addition, many businesses are outsourcing all or part of their IT operations. EHR vendors generally prohibit outsourcing vendors from operating their software for the benefit of the licensee without additional fees and the negotiation of a separate agreement with the outsourcing vendor. If you intend to use an outsourcer or a hosting provider, either now or in the future, you must ensure the scope of your license includes that use.

Vendor Staff Continuity and Experience

There are a limited number of proven vendors, and an even more limited number of true subject matter experts (SMEs) with application-specific and battle tested experience for EHR implementation projects. Moreover, the EHR incentive programs under the American Recovery and Reinvestment Act of 2009 (ARRA) are accelerating the adoption of health information technology (HIT) and, with the significant increase of EHR projects, eligible professionals and hospitals are vying for the same pool of vendor and other expert resources. Capturing the right SMEs for your project, including staff continuity protections in the agreement, and appropriately enforcing such protections to manage vendor employee turnover are keys to success.

Integration and System Configuration

Companies are typically buying an EHR solution — not a piece of software. The agreement should require that the EHR applications must integrate, interface, and interoperate with each other, third-party software, and the existing customer systems, and work properly on the designated hardware platform.

In addition, consider adding a warranty that the existing customer system, together with the EHR software and the vendor’s recommended configuration, is sufficient in size, capacity, and processing capability to operate the EHR software, and requiring that the vendor be financially responsible for acquiring and installing any additional equipment, applications, interfaces, network infrastructure, connectivity, or operating systems later determined to be necessary.

Compliance With HITECH Act and Meaningful Use Requirements

The vendor should be engaged in helping you achieve meaningful use of certified EHR technology at each stage of the meaningful use requirements (including, but not limited to, as it relates to performance objectives and measures, clinical quality measures, and incentive payments).

The agreement should include a warranty that the EHR software will provide the capabilities required to comply with the Health Information Technology for Economic and Clinical Health Act of 2009 (HITECH Act) and all rules implementing the HITECH Act and affecting EHRs, including that the EHR software has been tested and certified by an ONC-Authorized Testing and Certification Body (ONC-ATCB) as “certified EHR technology” for use as a complete EHR in the ambulatory and/or inpatient practice settings, as applicable, at each stage of the meaningful use requirements.

The vendor also should warrant that it meets each of the Certification Commission for Health Information Technology (CCHIT) requirements applicable to the care setting for which you are acquiring the EHR software (e.g., “CCHIT Certified 2011 In-Patient EHR Criteria”).

The vendor should warrant ongoing assistance to maintain meaningful use, and the warranty period should be extended through the final stage of achieving meaningful use under ARRA.

Specific acceptance criteria tied to achieving meaningful use also should be established, including the capability to deliver Stage 1 objectives, sufficient integration and ease of use to promote achievement of Stage 1 objectives, and ongoing vendor requirements to assist with attainment of Stage 2 and Stage 3 objectives.

Also, consider including a warranty for compliance with Health Insurance Portability and Accountability Act of 1996 (HIPAA) Transaction and Code Set Standards, including compliance with (a) Version 5010 of the Accredited Standards Committee (ASC) X12 standards for HIPAA transactions, (b) Version D.0 of the National Council for Prescription Drug Program (NCPDP) standards for pharmacy and supplier transactions, (c) Version 3.0 of the NCPDP standard for Medicaid pharmacy subrogation, and (d) ICD-10 (International Classification of Diseases, 10th Revision) code set standard for coding diagnoses and procedures.

Project Management

Understanding upfront what is required to succeed will position you for success. In addition, payment must (to the maximum extent) be tied to performance, and effective performance-based payment requires a detailed project plan. Even if complete resource loading is not possible, the key milestones and timing must be negotiated upfront, and you must aggressively and proactively manage the milestones.

In addition, consider the need for and cost of thirdparty, independent project management capability, which may provide independent assessment of project progress and issues, heightened attention to “early warning signs,” and assistance in mitigating project issues.

Confidentiality and Security

For business and regulatory reasons, confidentiality and data security are critical issues, particularly as related to protected health information (PHI). The vendor must execute the applicable business associate agreement (BAA) as required by HIPAA Privacy and Security Rules and as modified to comply with the HITECH Act. To summarize, as a business associate, the vendor must comply with the following requirements:

  • The security breach notification requirements imposed by the HITECH Act, which require business associates to notify their covered entities of any breaches of “unsecured PHI” within a specified time period.
  • The HIPAA security rule standards and implementation specifications for administrative, physical, and technical safeguards. To comply with such requirements, the vendor should conduct a “gap analysis” to identify the areas where the vendor’s information security system and programs fall short of meeting the HIPAA security requirements. The vendor must then remedy any deficiencies.
  • A requirement added by the HITECH Act that if the vendor uses subcontractors that will have access to the vendor’s electronic PHI, the vendor must enter into a business associate agreement with such subcontractors incorporating all the requirements that the business associate itself must satisfy.

Continuous Software Support

EHR vendors are in a state of flux (e.g., Eclipsys and Allscripts merger in August 2010). Further acquisitions and consolidations are likely, potentially impacting licensee investments in product, process change, and strategy. As such, consider including protections providing you a right to move to a “replacement product” of a successor entity at no additional cost, in the event the original EHR software is not being adequately supported by the successor entity.

Maintenance/Support and Service Levels

All forms of software improvements should be included in your maintenance and support, including revisions to achieve the Stage 2 and Stage 3 meaningful use requirements. If this issue is not addressed, you may be charged more for “new” functions.

You should seek to obtain service levels relating to support request response and resolution time to ensure that errors are being addressed in a timely manner. System availability and software transaction response time service levels also should be considered, as a system that is not functioning properly in terms of availability response times is viewed by users as broken, even if the EHR system does what it is supposed to do. In order to motivate the vendor to meet these various service levels, appropriate credit remedies must be associated with service-level failures, and you should have a termination right for vendor’s repeated service-level failures.

Limitation of Liability

The loss or delay of incentive payments can be material to an eligible professional or hospital. Typically such damages are considered “consequential” and are often limited or precluded contractually.

Consider attaining more alignment with your vendor as to timing and performance required to attain incentives by adding “carve outs” from the limitation of liability as it relates to lost incentive payments, including carve outs for (a) lost incentive payments, (b) cost of deferred incentive payments, and (c) penalties under the ARRA arising from acts or the failure to act by vendor.

Alternatively, the above “carve outs” could be defined as “direct damages.”

The above will be difficult provisions to obtain, as vendors will argue they do not control the end result and timing, and they are not insurers. You should counter that there is no liability at all if it is not determined by a court or arbitration that the damages sought were caused by the vendor’s actions or inactions

Business Solution Aligning With Customer Strategy

Achievement of your business objectives must be an integral element of the EHR implementation. Your organization should identify the specific business benefits that support the business case for the EHR before beginning your EHR initiative. In addition to implementing the EHR software to function in accordance with the EHR vendor specifications, the vendor should be charged with delivering an implementation that is capable of producing the identified business benefits. Having a “businessbenefits focus” in the agreement will enable you to better manage to the attainment of those objectives.

Interim Remedies (e.g., Withhold Remedy, Project Schedule Defaults)

Interim remedies are essential to a successful implementation, as they motivate the vendor to perform in accordance with the agreement or correct problems with performance.

For example, the withhold remedy is one of the most useful remedies in practice, allowing you to withhold payment in the event the vendor is not performing under the agreement.

In addition, in the event the vendor fails to achieve any of the specified service or deliverable delivery dates specified in a statement of work (SOW), a credit remedy can be used for each day of delay beyond the cheduled completion dates.

Definition of Services

Effectively managing change, vendor scope, and budget creep, is critical to a successful implementation. The definition of “services” is of critical importance in an EHR implementation agreement. Whether the agreement is priced as a fixed-fee transaction, time and materials, or a hybrid, the importance of the definition of services is constant. EHR implementations are characterized by a good deal of “in-flight” change. Change is necessary. But if change is not minimized and adequately controlled in the SOWs, it can be very expensive. Typically, vendors take the position that any task not included in the applicable SOW is a change — and the vendor is not obligated to work on a change if it does not agree on price and schedule adjustments. Therefore, it is important that each SOW provide a complete and detailed description of “services.”

High-level SOWs will not work well in the context of an EHR agreement. Even assuming that an above-average level of detail is included in a SOW, if a task (even though it is logically linked to other tasks described in a SOW) is not specifically described in the SOW, a vendor will likely request a change. Though changes typically require agreement from the customer, this is often an illusory protection. As the project progresses, the right to “disagree” with requested changes is often coupled with a decision to stop work. Frequently, the need to continue working trumps legitimate disagreements about changes. To avoid this result, we recommend including a sweeping definition of “services,” which is useful in limiting vendor claims of “out-of-scope” activity and requests for additional money, and that great attention be paid to the SOW development and that the detail be such that the nature of the day-to-day activities of each resource, whether the vendor’s or yours, can be understood.