2011

Contracting for Electronic

Health Records:

Guidelines for Hospitals

1

The American Recovery and Reinvestment Act of 2009(ARRA) authorized incentive payments under Medicare

and Medicaid to “meaningful users” of certified electronichealth records (EHRs) beginning in fiscal year (FY) 2011.Beginning in FY 2015, ARRA also phases in penalties forthose who fail to meet “meaningful use.” To be eligiblefor these incentives and to avoid future penalties, hospi-tals and physicians must use EHRs that have been certi-fied through a new federal certification processestablished by the Office of the National Coordinator forHealth Information Technology (ONC).

To assist hospitals in working with health informationtechnology (IT) vendors to achieve meaningful use, theAmerican Hospital Association (AHA) has developed thefollowing guidelines for EHR contracting. These guide-lines address the most common issues for hospitals thatlicense EHR software applications and/or obtain relatedproducts and services from a vendor.

The guidelines are intended to help hospitals, especiallysmaller hospitals and those just beginning to implementIT, identify and address critical concerns involved in es-tablishing EHR vendor relationships. They are NOT in-tended to, and cannot, substitute for responsible legaladvice. Working closely with appropriate legal counsel,hospitals should examine and carefully evaluate how touse the guidelines as part of their efforts to establish ap-propriate vendor relationships to address their particulartechnology needs.

The guidelines provide a checklist of general topics thathospitals need to consider when establishing a vendorcontract. They identify some of the specific questions tobe addressed in each area and, where appropriate, sug-gest options for addressing a particular question.

The guidelines focus on licensing for software applica-tions and are applicable primarily to the scenario where ahospital will license the applications to be run on the hos-pital’s servers. Remotely hosted applications (i.e., cloudcomputing solutions) raise a series of additional issues,primarily due to the hospital’s loss of control over thehardware, software and its data. Hospitals that are con-sidering a remotely hosted application, for example, willneed to give consideration to:

• Availability: If access to the vendor’s cloud computingsolution is interrupted, what procedures and remediesare in place to minimize the impact on the hospital andensure a prompt resolution?

• Data control:Who owns the data processed on the sys-tem, and what rights will the vendor claim to use suchdata? Will the hospital be able to readily access its dataat any time and in a mutually agreed upon format?

• Privacy:Where will the data be stored (i.e., jurisdiction)and how will this impact the applicable privacy regula-tions?

• Data security:What is the vendor doing to address con-fidentiality, theft, data corruption and data loss of thehospital’s data stored and processed on the vendor’sservers?

• Data breach: The parties need to address data breachnotification laws and allocate responsibility and cost be-tween the vendor and the hospital when a data breachis caused by the vendor.

An in-depth consideration of these additional issues, how-ever, is beyond the scope of these particular guidelines.

Using the Guidelines

2

DEVELOPMENTDoes the application require custom development, en-hancements or modifications prior to use by the hospital?If so, consider the following:

• Custom development issues generally: If the applicationrequires custom development, enhancements or modi-fications prior to use by the hospital, consider the spe-cific needs related to that custom development.

• Specifications: The vendor should perform the customdevelopment in accordance with mutually agreed uponspecifications that should be detailed in an exhibit or in-corporated by reference into the agreement. The agree-ment should include a process to manage changes tothe specifications.

• Schedule: The agreement should include a detailed de-velopment schedule, including milestones.

• Cost of development: For any custom developmentwork, specify whether the fee for custom developmentservices will be charged at a fixed price, on a time andmaterials basis, or already is incorporated in the licensefee structure. Also, consider whether custom develop-ment will impact the cost of maintenance and supportservices.

• Other potential issues to consider: The hospital maywant to consider whether there are other standards thatit would like to see included in the EHR specifications.For example, a hospital may want to consider customdevelopment such as compatibility with HL7 interoper-ability standards, FDA Part 11 rules for electronicrecords in clinical trials and other types of standards.

SCOPE of LICENSEThe hospital will want to understand the scope of the li-cense it obtains from the vendor. Consider:

• Scope of license: Review the scope of license rights toensure that the scope is broad enough to cover all of thehospital’s anticipated needs.

• Licensed subject matter: Address whether the hospitalneeds source code, object code, user documentation, in-ternal documentation and/or updates of the application.If the hospital will receive source code, it also should re-ceive all materials needed to use the source code effec-tively. Note that, prior to obtaining rights to modify theapplication’s source code, the hospital should considerthe implications and potential liabilities, including anyimpact on the application’s performance, compliancewith regulatory standards, etc.

• Licensed rights: Address whether the license is exclu-sive or non-exclusive. Include, as applicable, rights touse, copy, modify, distribute and display. Include theright to sublicense the foregoing rights if applicable.

• Users and equipment: Determine who can use the ap-plication and where the application will reside. Considertypes of licenses: network, CPU, seat, concurrent user,named users, server, site or enterprise. Also considerwhether the application must be used in conjunctionwith specified hardware or software. Will the hospitalneed the right for affiliates, contractors, independentphysician practices or other third parties to use the ap-plication? If applicable, specify the scope of sites andfacilities where the hospital needs to use the application.Can a third-party service provider operate the applicationfor the benefit of the hospital?

• Hosted environment: Will the hospital have the right todeploy the application in a hosted environment or willany of the components of the application be accessibleto the hospital’s users through the Internet?

• Territory: If the vendor imposes any geographic limita-tion of use (e.g., limiting use to the U.S.), considerwhether those limitations are problematic for the hospi-tal’s proposed scope of use.

Contracting for Electronic Health Records:Guidelines for Hospitals

These guidelines are designed to address some of the most common issues that arise when a

hospital licenses electronic health records (EHR) software applications and obtains related products

and services from a vendor. They are most applicable to the scenario where the hospital will license

an application to be run on the hospital’s servers. Issues raised by remotely hosted applications

(i.e., cloud computing solutions) are beyond the scope of this checklist.

3

RESTRICTIONS on LICENSE GRANTUnderstand the implications of any restrictions on the li-cense for the application that are imposed by the vendorto ensure that the license restrictions remain consistentwith the hospital’s intended use and other business ob-jectives. Consider:

• Restrictions on copying the application and documen-tation: Consider the need of the hospital to copy the ap-plication for archival and backup purposes and copy thedocumentation for training and distribution.

• Restrictions on using or modifying the application:Carefully read the license restrictions in light of businessobjectives, such as limitations on how the applicationcan be used, or prohibitions on modifying the applica-tion.

• Sublicense flowdown requirements: Where the hospitalwill sublicense the application to third parties, carefullyreview any provisions that the vendor requires the hos-pital to include in the hospital’s agreements with thethird parties.

CERTIFIED EHR TECHNOLOGY STANDARDSCarefully review contract provisions that specify the ven-dor’s obligations to meet the certification requirementsset by the federal government to support meaningful use.Consider:

•Warranties regarding compliance with regulatory stan-dards: Carefully review the representation and warrantyby the vendor that the application currently complies inall material respects with the Stage 1 requirements nec-essary for eligible hospitals to successfully demonstratemeaningful use of certified EHR technology and receivethe associated incentive payments. Address whether theapplication will continue to meet or exceed Stage 1 re-quirements throughout the term of the contract.

• Alternative language: If software is not intended to meetall of the meaningful use Stage 1 specifications (for ex-ample, because the hospital is purchasing various EHRModules rather than a Complete EHR), include a repre-sentation and warranty that the application currentlycomplies with the specific capabilities applicable to theEHR Module.

• Meaningful use Stage 2 and 3 requirements: The vendorshould agree that the application will be updated to meetthe Complete EHR (or EHR Module, as appropriate) stan-dards that will be mandated for eligible hospitals to meetthe requirements for incentive payments in Stages 2 and3.

• Manner of providing updates: The vendor could provideupdates by providing replacement third-party or vendorsoftware that meets the Stage 2 and/or 3 requirements.

• Timeframe: Updates should be provided sufficiently inadvance to allow for a testing period prior to the effectivedate.

• Remedies: Address the available remedies for the ven-dor’s failure to update the application to meet Stage 2 or3 requirements by the effective date of the applicable re-quirements. Examples of remedies may include: termi-nation right without penalty; source code escrow release;service credits (such as savings on ongoing support feeswhile not in compliance); damages in the amount ofmeaningful use incentive payments not received by thehospital or in the amount of payment reductions im-posed on the hospital in 2015 or later.

• Ongoing obligation to maintain certification: Considerobligating the vendor to agree to maintain certificationof the application over the course of agreement, for aparticular version or all versions of the application.

• Remedies for failure to maintain certification: Considerpossible remedies where the vendor fails to maintainsuch a certification, such as costs to change vendors (orsome period of time in which costs of changing vendorswill be covered), and/or any lost Medicare/Medicaid in-centive payments.

• Agreement to seek certification as applicable certifica-tion standards are updated or modified: Consider seek-ing a representation from the vendor that it will seek theappropriate certifications as new applicable certificationcriteria are required. This may be an alternative to re-quiring that a vendor warrant that it will meet certifica-tion criteria established in the future, instead requiringthe vendor to agree to engage in the certificationprocess.

4

DELIVERY and IMPLEMENTATIONSpell out the obligations related to the delivery and im-plementation of the application. Consider:

• Delivery: Specify when and how the application will bedelivered and/or accessed (such as being delivered tothe hospital and installed on hardware, or accessed viathe Internet). When establishing an application deliverydate, consider the hospital’s timing for going live withthe application and possible contingencies that maydelay the process.

• Penalties for late delivery: Consider including late de-livery consequences to incentivize on-time delivery.

• Installation and integration: Address whether the vendorwill install the application. Clarify which party is respon-sible for integrating the application with the hospital’sexisting systems. Will the vendor be responsible for de-veloping programming interfaces between the hospital’sexisting systems and the application? For complex im-plementations, the hospital should ensure there is a ro-bust project management structure and clearly definedprocedures in place to guide the implementation. Plansfor more complex implementations typically include de-tailed project timelines, identifying internal and externalresource requirements and specific responsibilities ofthe parties involved. In certain instances, the hospitalmay find that an “off-the-shelf” implementation plan pro-vided by the vendor is not sufficient to address the hos-pital’s unique internal processes and requirements.Depending upon the complexity of the task, the partiesmay address implementation services through a sepa-rate agreement or addendum.

• Data conversion: Address whether the vendor will pro-vide data conversion services and the associated fees.

HARDWARE and EQUIPMENTEstablish the responsibilities and obligations of eachparty to ensure that the appropriate hardware and otherequipment are in place for the application to operate.Consider:

• Equipment and facilities: Address any hardware, third-party software, content and/or network requirements forthe application to operate and specify which party is re-sponsible for obtaining any such hardware, software,content and network requirements. When evaluatingthese types of requirements, consider compatibility is-sues with the hospital’s existing information technologyinfrastructure.

• Hardware: If purchasing hardware from the vendor, ad-dress: (1) schedule for delivery; (2) title transfer andrisk of loss; (3) responsibility for installation; (4) the hos-pital’s obligation to meet minimum requirements for theinstallation site (such as power supply, Internet connec-tivity and temperature/humidity controls); and (5) hard-ware maintenance obligations.

• Hardware purchase vs. lease: Consider implications tothe hospital of leasing instead of purchasing certainhardware, including any restrictions placed on use ofleased hardware.

5

TRAININGOutline the respective responsibilities of the parties fortraining hospital staff and others to use the application.Consider:

• Training and materials: Address whether the vendor willprovide training services and, if so, the timeframe to rollout training for hospital personnel. Specify whether thevendor will be responsible for developing and/or deliv-ering training materials for use by the hospital. Whatlevel of training is included without a separate charge?

• Location: Will training be conducted at the hospital’s fa-cilities, will the hospital need to send employees to thevendor’s central training facilities or will training be con-ducted remotely?

• Audience: Will the vendor provide comprehensive train-ing for users throughout the hospital or will the vendor“train the trainer,” whereby key hospital employees willbe trained to use the application and then be responsiblefor training other end users?

TESTING and ACCEPTANCEAddress how the application will be tested to ensure itmeets product specifications and clearly outline criteriaand procedures for final acceptance of the application bythe hospital. Consider:

• Testing: The hospital should have the right to review,inspect and test the application before the purchase isfinal, particularly if the hospital is acquiring a customproduct which has not gone through the rigorous prod-uct testing processes of off-the-shelf software. It is ad-visable to ensure participation in the testing process bythe types of individuals within the organization that willactually be using the application in the future.

• Acceptance criteria: These criteria should be detailedand in writing. The criteria should include conformanceof the application with the product specifications. Suchspecifications should be sufficiently detailed.

• Mechanism for rejection, fixing, retesting, etc.: Theseprovisions also should be detailed in writing and shouldaddress time periods for each party to comply. At somepoint in the process, if the application still fails to meetthe specifications, the hospital should be able to returnthe application for a complete refund.

• Payment holdback: In order to maintain sufficient lever-age to ensure the vendor adequately addresses issuesidentified during the acceptance testing process, considerstructuring the hospital’s payment schedule to retain ameaningful payment holdback until after final acceptance.

MAINTENANCE and SUPPORTConsider the vendor’s obligations to support and main-tain the application over time:

• Provision of support: The vendor should typically pro-vide maintenance and support services unless the hos-pital receives source code and intends to handle allmaintenance and support in-house.

• Help desk support: Consider whether the hospital needscontinuous all-hours support or only support during de-fined business hours. Support should include correctingdefects, “bug” fixes, updates and upgrades (and suchterms should be clearly defined in the agreement). Ad-dress whether support will be available to all employeesor only designated contacts.

• Problem resolution procedures: Define problem severitylevels (such as, application non-operational vs. “minor”bug), response times by the vendor, escalation proce-dures (such as the level of involvement of vendor man-agement) and resolution efforts (such as continuouswork until resolution versus effort only during businesshours). Establish a minimum service level commitmentwith set standards.

• Application upgrade obligations: If the vendor requiresthe hospital to install all Application upgrades, addresswhether the hospital can comply. Consider requiring thevendor to support current and previous versions of theapplication for a certain period of time. The hospitalshould clearly understand what updates are includedwithout charge as part of maintenance and support serv-ices and what categories of upgrades may require addi-tional license fees. Are updates to reflectgovernment-mandated changes included as part ofmaintenance and support services?

6

REGULATORY COMPLIANCEEstablish vendor’s obligations to meet all relevant regu-latory requirements. Consider:

• Compliance with laws: Require vendor compliance withall applicable laws, including but not limited to applicablelaws and regulations promulgated by the U.S. Depart-ment of Health and Human Services, the U.S. Food andDrug Administration, and federal and state laws govern-ing the privacy of health information, including theHealth Insurance Portability and Accountability Act of1996 (HIPAA), and the Health Information Technologyfor Economic and Clinical Health Act (HITECH).

Because the exchange of health information in the hospitalsetting is subject to a wide range of compliance require-ments, it will be important to consider a representationthat the application is compatible with those requirements,such as HIPAA, as well as that the vendor itself is in com-pliance with those laws.

HIPAA REQUIREMENTS, INCLUDING BUSINESS ASSOCIATE OBLIGATIONSBecause the application will use, process and store pa-tients’ personal medical information, the application willneed to be compatible with all HIPAA privacy and securityrequirements, including the business associate require-ments, if the vendor will access patient data as part of itstechnical support for the application. Consider:

• Representations regarding HIPAA: Include representa-tion and warranty that the application is compatible withall requirements of the HIPAA Privacy and SecurityRules.

• Business associate activities: If the vendor is accessingdata as part of the vendor’s technical support for the ap-plication, or if the application is accessed remotely toprovide services, consider whether the vendor is a busi-ness associate under HIPAA. If so, the hospital and thevendor also should sign a business associate agreement.

PRICING and PAYMENTPricing and payment obligations are core elements ofthe vendor agreement. Consider:

• License fee structure: Examples of license fee structuresinclude: (1) up-front, one time lump sum payment; (2)monthly, quarterly or annual license or subscription fees;and (3) transaction-based fees.

• Application maintenance fee timing: Negotiate whetherthe application maintenance fees start immediately uponexecution of the agreement, upon delivery of the appli-cation, upon final acceptance of the application by thehospital or following the end of the initial performancewarranty period.

• Other services (such as installation, training, data con-version): If the hospital obtains optional services, ad-dress whether the fees for such services are fixed at acertain amount, at then-current rates or on a time andmaterials basis.

• Application license fee increases: Negotiate up fronthow license fees will increase over time. It may bepreferable to lock in the application license fee perpetu-ally, or to at least set the fees for a certain number ofyears. After the years elapse, try to establish a cap onfee increases. If the hospital has sufficient negotiatingleverage, a most favored pricing clause may be helpfulto ensure preferred pricing in the future.

• Application maintenance fee increases: If the hospitalis unable to lock in the annual maintenance fees for aperiod of years, then provide that the maintenance feesmay increase annually by no more than a certain fixedpercentage (or, alternatively, limit increases to changesin the consumer price index).

• Future changes to hospital’s size and requirements:Once the hospital commits to a particular EHR applica-tion vendor, the cost to change vendors in the future canbe significant. Therefore, consider building in protec-tions to ensure equitable pricing as the hospital growsand its needs evolve. For example, if the license fees arebased on number of users, consider locking in futureuser fees at a discounted rate.

• Expense reimbursement: Include the hospital’s stan-dard policies and requirements for reimbursing vendorexpenses. Limit reimbursement to reasonable and doc-umented expenses and if appropriate, request a cap ontotal out-of-pocket expenses.

• Due date: Establish a set due date for payments to thevendor, such as 30 days after receipt of invoice or asotherwise required for business reasons.

7

TERM and TERMINATIONConsider the time period covered by the agreement aswell as the specific conditions for terminating the agree-ment, including early termination. Consider:

• Term of license: Consider the business implications ofthe time period set for the software license, such asagreeing to a perpetual vs. term license, with automaticrenewal or a fixed term, taking into account issues suchas locking in fee arrangements for a specific period oftime, and being required to use software that may be-come outdated during the term of the license. Addresswhen the license and maintenance periods commence,such as on the effective date of the agreement or uponacceptance by the hospital. Commencement may triggerpayment obligations.

• Termination by vendor: Limit the vendor’s ability to ter-minate the contract to avoid disruption to the hospital’sbusiness. If the vendor can terminate at any time, thehospital may want the vendor to agree to provide main-tenance for a certain period of time and/or obtain a rightto continue using the application for a certain period oftime following termination.

• Termination by hospital for convenience: Considerwhether the hospital needs the right to terminate thecontract for convenience. Where possible, eliminateearly termination fees or tie the penalty to specified per-formance criteria.

• Termination for breach: The hospital should have atleast 30 days to correct a material breach of the agree-ment before the vendor may terminate the license. It isstandard for this to be mutual.

• Termination for failure to comply with meaningful userequirements: Consider whether the hospital wants theright to terminate the contract for failure of the applica-tion to meet Stage 1 and/or Stage 2 or 3 meaningful usecriteria (see “Certified EHR Technology Standards” onpage 3) and/or certification criteria.

• Effect of termination: If the vendor will require the hos-pital to stop using and return or destroy the application,then address whether the hospital will need to keep anarchival copy. Each party should return or destroy (atthe other party’s instruction) the other party’s confiden-tial information. Understand whether the hospital’s dataprocessed through the application is stored in a univer-sal or proprietary format, since this will impact the easeby which the hospital can transition to another system.Also consider requesting a commitment from the vendorfor transition assistance to another application providerfollowing termination.

PROPRIETARY RIGHTSConsider the ownership rights of the parties to the soft-ware application as well as the data held in the EHR:

• Title to standard software: In general, the vendor willretain all ownership rights in its application, subject tothe license rights granted to the hospital.

• Title to customized software: Consider whether the hos-pital wants to obtain from the vendor ownership rightsin certain customizations or other work product devel-oped pursuant to the agreement.

• Third-party software: Does the application include anythird-party software? If so, the hospital should ensureit has appropriate and sufficient rights to such third-party software. In these cases, the agreement will typi-cally include an attachment with any applicable andrelevant licensing terms and restrictions for the third-party software and/or include links to access the relevantlicensing terms online. Be aware of any third-party li-censing terms and restrictions that may be updated bythe third-party provider from time to time and the hos-pital’s obligation to periodically review any changes tothe terms.

• Open source software: Understand whether the appli-cation includes open source software and whether anypart of the application is provided pursuant to separateterms of an open source license.

• Hospital data: To the extent the vendor will have accessto any data input in the application, clarify that the hos-pital owns all rights in such data and the vendor is lim-ited to using such data as necessary to provide servicesunder the agreement. Depending on the level of vendoraccess to the data, consider whether the vendor is aHIPAA business associate, which would require the es-tablishment of a compliance business associate relation-ship (see “HIPAA Requirements” on page 6).

8

WARRANTIESCarefully review the guarantees made by the vendor to en-sure the application performs as expected, and the ven-dor’s obligations if it does not. Consider:

•Warranty of performance: The vendor should warrantthat the application will perform substantially in accor-dance with its written specifications. The duration of thiswarranty is usually negotiable, often ranging between 30– 180 days.

• Specifications: Performance is generally warrantedagainst the contracted specifications. Make sure thesespecifications are detailed enough so that when a prob-lem arises with the application, the hospital has a clearstandard against which to measure application perform-ance. Alternatively, the information may be contained inthe “documentation.”

• Remedies for breach of warranty of performance: Thevendor may try to limit remedies to replacement, repairor refund. If so, make sure the refund option is included.

•Warranty regarding rights: The vendor should warrantthat it has the rights necessary to enter into the agree-ment and that licenses granted and use of the applicationas contemplated will not infringe any third-party rights.This is less critical if the vendor grants a broad intellec-tual property indemnity as necessary to protect the hos-pital (see “Indemnity” on this page).

• Systems integration: If there may be compatibility is-sues regarding integration of the application into thehospital’s systems, have the vendor warrant systems in-tegration. If the vendor refuses, make sure specifica-tions adequately address compatibility requirements.

• Services warranties: The vendor should warrant that allservices provided under the agreement are performedin a professional manner in accordance with industrystandards.

• Third-party warranties: To the extent the vendor is thebeneficiary of any warranties for any third-party softwareor hardware it provides to the hospital under the agree-ment, require the vendor to pass through the benefit ofthose warranties to the hospital.

• Hospital warranties: While it is important for the vendorto offer sufficiently robust warranties to make the hos-pital comfortable licensing the application, the hospital(as the customer) should avoid providing significantwarranties. This will help to reduce the hospital’s riskof contractual liability from breaching those warranties.

INDEMNITYConsider obligating the vendor to hold the hospital harm-less for certain vendor behaviors, including potential in-fringement of third-party intellectual property rights andvendor negligence or willful misconduct:

• Intellectual property infringement indemnity: The ven-dor should indemnify the hospital for third-party claimsthat the application infringes any patent, copyright, tradesecret or other proprietary right.

• Other indemnities: Depending on the hospital’s standardpolicies regarding indemnification, consider indemnifi-cation for injury or damage caused by the negligence orwillful misconduct of the vendor.

LIMITATIONS OF LIABILITYConsider the limitations on the liability of the respectiveparties for damages related to the application or the agree-ment:

• Exclusion of certain types of damages: The hospital (oralternatively, neither party) should be liable for indirect,incidental, consequential or special damages relating tothe agreement or the application. The exception to thisgeneral exclusion for the vendor would be for damagesin the amount of meaningful use incentive payments notreceived by the hospital or in the amount of payment re-ductions imposed on the hospital in 2015 or beyond.

• Liability cap: Typically, vendors will limit their liabilityfor direct damages to the amount of fees received forthe application and related products and services underthe agreement. Sometimes the damages are limited tothe amount of fees received in the prior year. The hos-pital can try to: (1) eliminate the cap; (2) negotiate amutual cap; or (3) try to raise the cap. Be sure to ex-clude the vendor’s indemnification obligations and theconfidentiality/nondisclosure obligations from the li-ability cap and exclusion of damages.

• Limitations on liability: Carefully consider efforts by thevendor to limit liability related to meaningful use and re-lated certification.

SOURCE CODE ESCROWThe hospital should consider requiring deposit of the soft-ware source code with a third-party escrow agent to en-sure that it has access to the source code when themaintenance of the software cannot otherwise be assuredby the vendor.

• Source code escrow: The hospital should consider re-quiring the vendor to place the source code for the ap-plication in escrow with a third-party escrow provider.The agreement should, at a minimum, specify: (1) theconditions for release of the source code; (2) the ven-dor’s obligation to regularly update the escrow materialsthroughout the term; and (3) the scope of the hospital’slicense rights following release. Potential source coderelease conditions include the vendor’s bankruptcy, thevendor ceasing to provide maintenance and support forthe application, and the vendor’s failure to meet certaincritical service level thresholds. The agreement alsoshould specify which party is responsible for the costsof the third-party escrow provider. Note that the vendoralready may have a relationship with a source code es-crow provider for the benefit of its other customers and,if so, the cost to add the hospital as another beneficiaryis usually not significant.

• Meaningful use: Consider also including failure of theapplication to remain compliant with the meaningful usecriteria as a condition for releasing the source code.

OTHER ISSUESContracts for EHRs also may address additional topics,such as:

• Confidentiality: Include standard hospital confidentialityprotections.

• Insurance: Include the hospital’s standard insurance re-quirements for vendors providing services of this scope.

• Customer reference/publicity/trademark license: Includethe hospital’s standard protections, if any, against thevendor’s use of the hospital’s name and trademarks forpublicity purposes.

• Miscellaneous provisions: Include the hospital’s otherstandard contractual provisions, including governinglaw, dispute resolution, notice, assignment (e.g., con-sider whether the hospital needs the ability to assign itsrights under the agreement following a merger or saleof assets), non-waiver, severability, integration, etc.

• Arbitration: Consider whether arbitration is the preferredmethod for resolving disputes about damages resultingfrom application’s failure to meet meaningful use criteria(see “Certified EHR Technology Standards” on page 3and “Limitations of Liability” on page 8).

9

155 N. Wacker Dr.Chicago, Illinois 60606(312) 422-3000

325 7th Street, N.W.Washington, DC 20004-2802(202) 638-1100

www.aha.org 1/11