a primer on electronic health record license agreements · computers have also grown faster and...

Chapter 9

A Primer on Electronic HealthRecord License Agreements

by Daniel F. Shay

I. INTRODUCTION

§ 9:1 Generally§ 9:2 Government initiatives§ 9:3 Technological advances and media attention

II. EHR OVERVIEW

§ 9:4 EHR de�nition and functions§ 9:5 Pros and cons of an EHR

III. LICENSE AGREEMENT CLAUSES

§ 9:6 Generally§ 9:7 Scope of license§ 9:8 Warranties and liability disclaimers§ 9:9 Support clauses§ 9:10 Data ownership clauses§ 9:11 Sub-licensing§ 9:12 Delivery/timeframes/installation clauses§ 9:13 Modi�cation§ 9:14 Assignment§ 9:15 Choice of law and venue§ 9:16 Termination

IV. CONCLUSION

§ 9:17 Generally

425

KeyCiteL: Cases and other legal materials listed in KeyCite Scope can beresearched through the KeyCite service on WestlawL. Use KeyCite tocheck citations for form, parallel references, prior and later history, andcomprehensive citator information, including citations to other decisionsand secondary materials.

I. INTRODUCTION§ 9:1 Generally

Electronic health records (“EHRs”) and electronic medicalrecords (“EMRs”) are part of one of the hottest trends in thepractice of medicine today: the integration of informationtechnology into health care. The United States health careindustry has arguably reached the ‘‘tipping point’’ for EHRadoption. The recent growth of interest in EHRs and EMRshas been spurred by several factors, including governmentinterest in both the regulation and funding of such technol-ogy, the advancement of supporting technology to a pointwhere EHRs actually function in useful ways, and increasedmedia attention regarding the bene�ts of using EHRs.

§ 9:2 Government initiativesIn his State of the Union address on January 20, 2004,

President Bush brought EHRs into the common lexicon.1

Shortly thereafter, he issued Executive Order 13335,2 creat-ing the O�ce of National Coordinator for Health Informa-tion Technology. Since his appointment to the position onMay 6, 2004, David J. Brailer, M.D., Ph.D. has been an out-spoken proponent of EHR adoption and the advancement ofimplementation of health information technology in theUnited States health care industry. During the keynote ad-dress at the 77th Convention and Exhibit of the AmericanHealth Information Management Association, Dr. Brailerstated, “We will look back at [October] as the point when wemoved out of the formative stage—about 85% of what I've

[Section 9:2]1‘‘By computerizing health records, we can avoid dangerous medical

mistakes, reduce costs, and improve care.’’ State of the Union address,January 20, 2004. http://www.whitehouse.gov/news/releases/2004/01/20040120-11.html.

2Executive Order 13335 (April 27, 2004). See http://www.whitehouse.gov/news/releases/2004/04/20040427-4.html.

Health Law Handbook

426

talked about doing is getting started this month.”3 ‘‘Gettingstarted’’ at the federal level includes initiatives to developcerti�cation criteria for EHRs, establish the infrastructurenecessary to create a national health information network(“NHIN”), and proposed changes to the Stark rule whichwould permit hospitals to help physician practices adopt in-formation technology.4

The overarching goal of the federal government is to imple-ment an NHIN, across which patient information may beshared. Towards that end, most government initiatives aredriven by a desire for interoperability and higher adoptionrate for technology. However, to spur both, the governmentbelieves standards for EHR software must be adopted. Dr.Brailer has likened the current state of health informationtechnology (“HIT”) to the state of the nation's railroadnetwork prior to the standardization of railroad gauges, andhas pointed to success stories such as the wi-� industry asexamples that the HIT industry must follow:

The wi-� industry took o� because the three di�erent stan-dards that were out there caused people to step back, not onlybecause they didn't know whether a product they bought couldconnect to somebody else's hub. The bigger question was thatthey didn't know which one would prevail in the end, so theyjust waited it out. The wireless industry came together andcleared a single standard for wi-� because they knew thatwould grow the market substantially.5

Thus, if a central standard is developed, the federal govern-ment expects the industry to more readily adopt the technol-ogy required to establish an NHIN.

As part of this same initiative, the government hasdeveloped the VistA-O�ce EHR software—a platform basedon EHR software used at Veterans' Association hospitals forthe past twenty years.6 The government intends to distrib-ute this software as a low-cost EHR for smaller physiciano�ces. While there are hurdles that physician practices will

3‘‘Brailer: We're at the Tipping Point,’’ Health Data Management(Oct. 18, 2005). http://www.healthdatamanagement.com/html/PortalStory.cfm?type=gov&DID=13153.

4In fact, the proposed changes to the Stark rule were published inthe Federal Register on October 11, 2005. See 70 Fed. Reg. 59182.

5Cunningham, ‘‘Action Through Collaboration: A Conversation withDavid Brailer,’’ Health A�airs, at 1150, 1151 (Sept./Oct. 2005).

6See http://www.vista-o�ce.org.

§ 9:2Electronic Health Record License Agreements

427

have to overcome in implementing VistA-O�ce software,such as costs incurred during installation and implementa-tion, and determining whether the feature set o�ered byVistA-O�ce is worthwhile, the VistA-O�ce program repre-sents a signi�cant step by the government in the develop-ment of EHRs on a national scale. Unfortunately, as of thiswriting, the full release of VistA-O�ce has been delayed andthe program has moved to ‘‘beta’’ testing, where it will bereleased to selected physician o�ces.7

State and local initiatives are also underway. For example,Governor Mark Warner of Virginia has advocated the cre-ation of standard electronic records that can be shared byproviders when necessary. He has estimated that switchingto electronic records will save the state's health careprograms between 8 and 15 percent.8 In Massachusetts, theMassachusetts eHealth Collaborative, an organization exist-ing as an o�shoot of the Massachusetts Health DataConsortium, has developed a pilot program in which partici-pants must develop operational and �nancial models to as-sist the statewide adoption of EHRs. The Collaborative isfunded by entities such as Blue Cross Blue Shield of Mas-sachusetts, and one of the project's leaders is the Governorhimself.9

§ 9:3 Technological advances and media attentionNone of the government initiatives would have been at-

tractive without the technological advances of the pastdecade. For example, the concept of an NHIN is far more vi-able with the development of a faster Internet infrastructure,thanks to the widespread availability of broadband Internetconnections. Electronic claims submission, computerizedscheduling, and the insinuation of technology into the clini-cal aspects of the practice of medicine have further condi-tioned practitioners to become more comfortable withtechnology, and thus more receptive to the idea of EHRs.Computers have also grown faster and more user-friendly in

7Tennant and Schneck, ‘‘CMS delays full release of much-publicizedVistA-O�ce EHR,’’ MGMA Connexion, at 29-30 (Nov./Dec. 2005).

8Kantor, ‘‘State Sees Technology as Avenue to Savings,’’ RoanokeTimes (Sept. 20, 2005). http://www.roanoke.com/business/wb/32994.

9Frisse, ‘‘State and Community-Based E�orts to Foster Interoper-ability,’’ Health A�airs, 1191-96 (Sept./Oct. 2005).

§ 9:2 Health Law Handbook

428

the past decade, allowing for the development of more robustand sophisticated programming. Finally, the cost for technol-ogy has continued to drop. Where a basic black-and-whitescanner alone might have cost several hundred dollars in1995, in 2005 you can purchase a printer, scanner, copier,and fax machine all in one single desktop unit for under$300.

Technological advances alone, however, would be insuf-�cient to spur adoption and interest to its current level. The�nal piece in the puzzle is the recent intense media focus onEHRs and IT. Articles touting the bene�ts of EHRs, discuss-ing why now is a good time to purchase an EHR, or discuss-ing physician satisfaction or adoption rates for EHRs have�ooded the industry media, pointing out, among other things,how EHRs lead to higher pro�ts and greater e�ciency.

In the midst of the increased attention on EHRs, manyphysician practices may be considering adopting an EHR.EHRs are attractive across the spectrum of health careprovider types, from large hospital networks to small physi-cian practices and those in between. EHRs o�er enhancedpractice management abilities, the potential for error reduc-tion, improvement in the quality of services, and mostimportantly increased e�ciency and potential pro�ts.However, smaller physician practices have di�erent needsand concerns from larger entities. In a practice's desire to�nd software that is a�ordable, meets the practice's needs,and can most e�ectively be implemented, the practice maynot pay attention to the license agreement which will ac-company the software. The focus of this chapter will be onthe concerns of the smaller physician practice, rather thanlarger organizations.

II. EHR OVERVIEW§ 9:4 EHR de�nition and functions

For a meaningful discussion of EHRs one might thinkthere must be a clear understanding of what exactly an EHRis, and how it di�ers from an EMR. Both terms, however,are used interchangeably in the marketplace and in thepress, which may lead to confusion. One de�nition character-izes EMRs as ‘‘an application environment composed of theclinical data repository (“CDR”), clinical decision supportsystem (“CDSS”), controlled medical vocabulary (“CMV”),


429

computerized provider order entry (“CPOE”), [and] pharmacyand clinical documentation applications,’’ whereas an EHRis a “subset of each [hospital or physician o�ce's] EMR, pres-ently assumed to include summaries, such as ASTM's Conti-nuity of Care Record (“CCR”) and HL7's Care Record sum-mary (“CRS”).’’1 The de�nition further states ‘‘the data in theEMR is the legal record of what happened to the patientduring encounters at the [hospital or physician's o�ce],’’whereas the EHR is designed to be the system which allowsthe patient to move their health information across theproposed NHIN.2 Under this de�nition, an EHR is essentiallythe summary of information contained in the EMR, which isdesigned to be portable across the NHIN.

The federal government appears to have taken a di�erentapproach to de�ning EHRs. In its recently proposed revi-sions to the Stark regulations, the Department of Healthand Human Services (“HHS”) is considering creating anexception to Stark which would permit hospitals and grouppractices to donate EHR software to physicians. As part ofthe proposed regulations, HHS is considering developing ade�nition for EHRs.3 However, even without such a de�ni-tion, HHS seems to take a di�erent view of what an EHRshould do from the �rst de�nition. For example, an EHRunder the proposed regulations would require that thesoftware include a CPOE component, as well as ane-prescribing component.

At the same time, press releases and product names blurthe lines between EMRs and EHRs. One product may de-scribe several common components of the Garets & Davisde�nition, without making any reference to interoperabilityor summarizing capabilities. Another product descriptionmay discuss how the software operates as part of a RegionalHealth Information Organization (“RHIO”), but makes nomention of CPOE capabilities. Faced with imprecise usage of

[Section 9:4]1Garets and Davis, ‘‘EMRs and EHRs,’’ Healthcare Informatics (Oct.

2005). http://www.healthcare-informatics.com/issues/2005/10�05/garets.htm.

2Garets and Davis, ‘‘EMRs and EHRs,’’ Healthcare Informatics (Oct.2005). http://www.healthcare-informatics.com/issues/2005/10�05/garets.htm.

3See 70 Fed. Reg. 59182.


430

the terms ‘‘EHR’’ and ‘‘EMR,’’ physicians may becomeconfused, or may simply use the terms interchangeablythemselves. For the purposes of this chapter, the term ‘‘EHR’’and ‘‘EMR’’ will be considered interchangeable; and both willrefer to software which combines both an electronic record ofthe patient's medical history and additional components suchas CPOE, clinical diagnosis tools, or other practice manage-ment software (such as billing and scheduling components).

Most EHR software includes the ability to enter informa-tion into a patient's chart, and many o�er some practicemanagement features (such as an included billing system, orthe ability to interface with existing billing systems andscheduling functions). Charts are typically maintained viaelectronic templates, into which the physician may inputspeci�c information. Some use ‘‘auto �lls’’ to automaticallyinput commonly used notes into the patient's chart. Othersprovide the ability to generate custom form letters by plac-ing information from the patient chart into a letter templatein Microsoft Word. EHRs may also be designed for certainspecialties such as medical or radiation oncology, or cardio-vascular practices.

Although EHR software is often con�gured to work in a lo-cal area network, among computers connected in an o�cesetting (or in a wide area network, between several con-nected o�ces), EHRs may also be used on web-basedsystems, where data is stored o�-site. This will necessarilyraise additional practical and legal considerations, since thepractice may have less control over the data.

§ 9:5 Pros and cons of an EHRCurrently, EHR adoption is on the rise, and has been for

several years. In 2004, the American Academy of FamilyPhysicians published a report indicating that the market ap-peared to be maturing.1 From the 2001 to 2003 period, adop-tion rates showed that the smaller the group, the less likelyit was to adopt an EHR. During this period, only 13% of solopractitioners had adopted, as compared with 38.9% of groups

[Section 9:5]1Edsall, ‘‘Are Electronic Records Catching On?,’’ Family Practice

Management, at 13 (Mar. 2004); http://www.aafp.org/fpm/20040300/13area.html.


431

of 20 or more having adopted.2 Two years later, the 2005�gures were similar, although some increase in adoptionrates had been shown.3 One reason for the increase is the at-traction of EHRs as bolstered by positive stories.

Practices report signi�cant returns on investment (“ROI”),improved e�ciency, increased pro�ts, all of which give theimpression that an EHR is the potential silver bullet for anynumber of problems. ‘‘Pull a patient chart within seconds,rather than minutes . . . . Track pending orders for lab testsand diagnostic imaging . . . . Fax prescriptions from yourcomputer to the pharmacy instead of handing them topatients, who might lose or alter them . . . . Review a sum-mary of the patient's health information at a glance insteadof �ipping through pages’’4 touts one article. Commentariesdiscuss how practices increase their e�ciency (even securinghigher payment rates from insurers),5 or note increasedpro�ts resulting from EHR adoption.6 ‘‘In virtually everyspecialty, the practices that spend the most on IT (morethan $20,000 per [full-time equivalent] physician) have themost pro�t. For multi-specialty groups with primary andspecialty care, the pro�t was 42 percent greater than thepractices that spent less than $7,000 on IT.’’7 With all of thepotential features and bene�ts of an EHR, what would standin the way of any practice adopting such a system?

The most common stumbling block for most practices isthe high cost of EHR adoption—and the cost of the softwarealone is not the only expense associated with switching froma paper-based system to an electronic system. A simple

2Burt and Sisk, ‘‘Which Physicians and Practices are UsingElectronic Medical Records?,’’ Health A�airs, at 1334-43 (Sept./Oct. 2005).The article also notes adoption rates of 16.2% for groups of 2-4, 19.9% ofgroups of 5-9, and 28.% for groups of 10-19.

3Burt and Sisk, ‘‘Which Physicians and Practices are UsingElectronic Medical Records?,’’ Health A�airs, at 1326 (Sept./Oct. 2005).

4Lowes, ‘‘50 Reasons to get an EHR,’’ Medical Economics, at 52-53(Sept. 16, 2005).

5Colwell, ‘‘A small practice juggles EHR's high costs and big payo�s,’’ACP Observer (Sept. 2005), at http://www.acponline.org/journals/news/sepo5/ehr.htm.

6‘‘Does Technology Pay? (Yes),’’ MGMA Connexion, at 22-24, Vol. 5,No. 6 (July 2005).

7‘‘Does Technology Pay? (Yes),’’ MGMA Connexion, at 24, Vol. 5, No.6 (July 2005).


432

questionnaire distributed to medical group practices by theMedical Group Management Association (with support fromthe Agency for Healthcare Research and Quality) found thatthe number one reason for not adopting an EHR was not thecost of the program, but rather the cost of implementation.8

Even for a practice that successfully makes the switch frompaper to an EHR, the cost can be considerable. For example,a two-physician internal medicine practice in northern Vir-ginia listed total startup costs alone of nearly $80,000, withmaintenance costs amounting to over $10,000 per year.9

In addition to the cost for the license itself, practices mayhave to purchase additional hardware, adapt existingtechnology to the new software, train personnel in the use ofthe software and/or hire additional personnel. During thistime, the practice may lose productivity, creating an ad-ditional economic burden. In light of these issues, thischapter will discuss typical clauses in EHR license agree-ments, paying special attention to the implementation andpractical concerns facing physician practices in the processof EHR adoption which arise from the legal issues in theagreements.

III. LICENSE AGREEMENT CLAUSES§ 9:6 Generally

Although physicians are understandably excited aboutadopting an EHR, there are practical hurdles that must besurpassed before a practice may reap the bene�ts of an EHR.

825% of respondents cited cost as the number one reason. Otherreasons included lack of physician support (15%); insu�cient time toselect, contract, install and implement (10%); insu�cient return on invest-ment (9%); and inability to easily input historical medical record data intothe system (8%). Vuletich, ‘‘EHR use varies widely by practice; No. 1 rea-son for not using it varies little,’’ MGMA e-Connexion, Issue 66 (Nov.2004), at http://www3.mgma.com/articles/index.cfm?fuseaction=detail.main&articleID=13125.

9See ‘‘A small practice juggles EHR's high costs and big payo�s,’’ACP Observer (Sept. 2005). Startup costs included a user license for eachphysician, training, practice management software, consultation fees forimplementation and training, hardware costs, and website costs; the costswere spread out over time. Maintenance includes ongoing maintenanceand EHR support fees, an annual support fee to maintain links to outsideradiology groups and other consultants, information technology consultantfees, and ongoing website maintenance fees.


433

Before even getting to implementation, there is the licenseagreement. Most software will include some form of licenseagreement, from a basic ‘‘click to proceed’’ agreement, to amore elaborate written agreement. The license agreementwill control the relationship between the practice and thevendor. It will describe the obligations of each party, theduration of the relationship, and the rights the practice hasto the software. This chapter will examine three general ar-eas of license agreements: the scope of the license, warrantyand liability provisions, and support and other miscellaneousprovisions. These three areas of concern cover the buildingblocks of the relationship between the practice and vendor,and thus are essential in understanding the practice's posi-tion in the transaction. The goal of this chapter, therefore, isto provide guidance on common clauses in EHR licenseagreements and their signi�cance. With a better understand-ing of the importance of the speci�c language in theseclauses, an attorney can help make the EHR implementa-tion process that much easier for his or her client.

§ 9:7 Scope of licenseThe scope of a license speci�es what is being transferred

from the vendor to the practice. The scope of a license forsoftware typically will fall under the aegis of the CopyrightAct, although depending on the nature of the agreement, itmay also be subject to the Patent Act.1 Under copyright law,a rights holder is entitled to certain statutory rights, whichinclude use, distribution, reproduction, and the right to makederivative works of the underlying copyrighted work.2 Licen-sors can restrict these rights on virtually any basis. Forexample, a license might only permit a practice to use thesoftware on a single computer (or might charge an additionalfee for multiple installations); might restrict the type of us-ers to only speci�cally trained users; or might restrict thenumber of users that can simultaneously log into the system.It is crucial that the practice understands the scope of thelicense, as that scope pertains to the speci�c needs of thatparticular practice.

[Section 9:7]117 U.S.C.A. §§ 101 et seq.; 15 U.S.C.A. §§ 101 et seq., respectively.217 U.S.C.A. § 104.


434

Conceivably, a license could grant a perpetual, non-exclusive right to use the software only at a speci�c address,on a single machine, by a speci�c list of users established inadvance. However, as a practical matter, the scope of alicense will not be anywhere as restrictive, since such alicense would be extremely unattractive to potential users. Itis more common to restrict licenses based on the number ofusers and/or computers, or by the type of user. Consider thefollowing example:

Example A: Under this Agreement, You are purchasing, andCompany grants solely to You, a nonexclusive, non-transferable, limited use license for the term set forth below,to: (i) install the Software on a server at Your Designated Lo-cation and workstation(s) within Your facilities; and (ii) forYou and Your A�liated Practices to use and execute theSoftware solely within the Territory. The total number ofworkstations accessing the Software shall not exceed �ve timesthe number of Provider Licenses purchased by You.

As is the case in all of the agreements reviewed for thischapter, the license is non-exclusive. This permits the vendorto license the use of the software to other parties as well. Ifthe license were exclusive, the software would essentially be‘‘one of a kind.’’ While some health systems and practicesmay purchase custom EHR software, if a license is exclusive,the price for the software will likely rise considerably.

This scope of license clause is useful in that it permits apractice to install on multiple workstations for the cost of asingle provider license. Rather than limit the practice to in-stallation on a single workstation, or in a single location,this agreement focuses solely on the number of workstationsor number of users. For a group practice with multiple physi-cians working at multiple o�ce locations, this type of licenseis ideal. In addition, the practice is not required to purchaseadditional licenses for multiple users, so physicians, non-physician practitioners, and o�ce sta� alike may all use thesoftware wherever it is installed.

By comparison, Example B only permits the user to installon designated computers.

Example B: Subject to the provisions of this Agreement,[Company] hereby grants to Customer, and Customer herebyaccepts from [Company], a nonexclusive, nontransferable,nonassignable limited license to use the [Company] Product onthe Designated Equipment for internal purposes only in accor-dance with this agreement during the term speci�ed [herein].


435

Customer acknowledges and agrees that the [Company] Prod-uct is the proprietary information and a trade secret of[Company] and that this Agreement grants Customer no titleor rights of ownership in the [Company] Product. Customeragrees not to market, sublicense, distribute, permit timeshare,or allow any other access to the [Company] Product other thanCustomer's own internal use as permitted hereby. The data�les and patient data stored in the software are and shallremain the exclusive property of Customer.

Because this license focuses on designated equipment, it willbe more bene�cial for a practice with relatively fewcomputers. In the case of software which is priced on a per-computer basis, a practice with twelve potential users butonly three computers on which the software will be installedwill bene�t far more from language like that of Example Bthan a practice with seven computers and only two potentialusers.

A per-computer license will also raise an additionalconcern: namely, how ‘‘installed’’ is de�ned. If the practiceintends to use software on multiple computers, but thosecomputers are simply workstations that link to a centralserver that will house the software itself, has the practiceactually ‘‘installed’’ the software on the workstations? Whilethis issue may be precluded by the nature of the softwareitself and the structure of the practice's computer network,the agreement should specify what constitutes installationand whether a practice must purchase additional licenses foreach workstation.

As an alternative, an agreement which focuses on usersrather than the number of computers would bene�t apractice that has only a few users, but multiple computers.For example, a practice with only two physicians, one non-physician practitioner, and one sta� member who will usethe software, but which keeps computers at a front desk andin six exam rooms may �nd it more practical to purchase anEHR which controls its scope solely based on the number ofusers rather than the number of computers, as in thelanguage of Example C below.

Example C: Permitted Users and Facilities may have access tothe Application Services for Client's internal use only andsolely for purposes of viewing and processing data resultingfrom or related to clinical procedures or �nancial transactionsperformed at the Permitted Facility or for Client in a mannerconsistent with this Agreement and for which the [Company]Software was designed.


436

The mention of permitted facilities raises an additional is-sue—the facility or site license. In the case of site licenses,the practice obtains a license for the physical location wherethe software will be installed, rather than for a speci�cnumber of users or computers. Site licenses are most bene�-cial to larger practices operating in a single building, or asmaller practice with a large number of computers. Bycontrast, a license based on the number of locations may beinappropriate for a practice with a relatively small numberof computers and users who provide services in multiplelocations.

Some licenses, however, may not even have explicit scopeof license language in the body of the agreement. Pricingmay be controlled by a separate document which the scope ofthe license does not address:

Example D: [Company] hereby grants to Customer a nonexclu-sive, nontransferable license, during the term of this Agree-ment, to use the [Company] developed technology solely forpurposes of using the Service(s). Customer shall have no rightto use such technology for any purpose other than using theServices(s).

In this case, the license focuses primarily on the purpose ofthe software's use, rather than on the number of computers,users, or physical locations. Language elsewhere in the bodyof the agreement from which Example D comes addressesthe speci�c work order which will control pricing.

Each of the above examples may be useful for a practicewith one set of needs, and less useful for a practice with dif-ferent needs. By understanding the practice's infrastructureand how it intends to use the software, an attorney maymore e�ectively advise the practice on the implications ofthe scope of the license.

§ 9:8 Warranties and liability disclaimers

In general contract law, warranties function as assurancesfrom seller to buyer about the goods being sold. EHRsoftware licenses typically will touch on several types ofwarranties, including the warranty of merchantability, war-ranty of noninfringement, and warranty of �tness for a par-ticular purpose. The warranty of merchantability indicatesthat a product will perform as well as most other products of


437

the same type.1 By comparison, the warranty of �tness for aparticular purpose exists when the seller knows the buyerwill use the goods for a particular purpose, and is an assur-ance that the goods will function for that speci�c purpose.2

The warranty of noninfringement is simply a guarantee thatthe seller can legally transfer title under the contract freefrom third party claims of infringement.3 These warrantiesare typically implied in the regular course of sales, but maybe (and universally are in EHR software licenses) disclaimedwithin the contract. By disclaiming these warranties, theseller avoids potential liability.

Similarly, EHR vendors typically include language whichdisclaims or otherwise limits liability for damages. Theseclauses are usually very broad in scope, and include exem-plary damages, consequential damages, or other morespeci�c damages. In combination with an e�ective warrantydisclaimer and absent a claim of fraud, a liability disclaimerwill leave the buyer with little by way of legal options shouldthe software fail to perform or if the software somehowcauses damages to the buyer or a third party whom the buyerserves.

This type of language is crucial for software vendors, espe-cially in the medical �eld. Consider the potential harm thatan EHR system could cause, both to a practice's businessand to its patients. An EHR with clinical features whichfails to function properly could contribute to misdiagnosis ofa patient. An EHR with practice management features thatfail could lead to considerable loss of revenue and/or data. Inboth cases, without a warranty or liability disclaimer, thevendor is left exposed to potential liability. Moreover, al-though vendors may work with practices to adapt thesoftware to a practice's existing hardware, given thepotential variety of hardware and software interactions, itmay be impossible for the vendor to ensure that the softwarewill always function as intended. There are simply too manyvariables for a vendor to address. It should therefore comeas no surprise that these disclaimer clauses appear in everyEHR software license.

[Section 9:8]1Hunter, Modern Law of Contracts, § 9.5 (2004).2Hunter, Modern Law of Contracts, § 9.5 (2004).3U.C.C. § 2-312(3).


438

Consider the following example:Warranty Disclaimer: [Company] EXPRESSLY DIS-CLAIMS ALL IMPLIED WARRANTIES, WITHOUTLIMITATION, WARRANTIES OF MERCHANTABILITY,NONINFRINGEMENT, AND FITNESS FOR A PARTIC-ULAR PURPOSE. NO ORAL OR WRITTEN INFORMA-TION OR ADVICE GIVEN BY [COMPANY], ITS EM-PLOYEES, DISTRIBUTORS, DEALERS OR AGENTSSHALL CREATE ANY WARRANTIES. THE PATIENTDATA, PRACTICE DATA, SERVICES AND [COMPANY]TECHNOLOGY ARE PROVIDED ON AN ‘‘AS-IS’’ BASIS.

LIMITATION OF LIABILITY: UNDER NO CIRCUM-STANCES AND UNDER NO LEGAL THEORY, TORT(INCLUDING NEGLIGENCE), CONTRACT, STRICT LI-ABILITY OR OTHERWISE, SHALL [ COMPANY ] ORITS SUPPLIERS OR AGENTS, OFFICERS, EMPLOY-EES, PRINCIPALS, DIRECTORS OR SUBSIDIARIESBE LIABLE TO CUSTOMER OR ANY OTHER PERSONFOR ANY DAMAGES OF ANY KIND ARISING OUT OF[COMPANY]'S DELIVERY OF OR FAILURE TO DE-LIVER THE SERVICES, THE USE OR INABILITY TOUSE THE SOFTWARE, [COMPANY] TECHNOLOGYOR SERVICES OR ANY DATA SUPPLIED THERE-WITH, OR FOR THEFT OR UNAUTORIZED ACCESSTO PATIENT DATA, OR OTHERWISE OUT OF THISAGREEMENT, REGARDLESS OF WHETHER THEYARE DIRECT, INDIRECT, SPECIAL, INCIDENTAL, ORCONSEQUENTIAL DAMAGES OF ANY KIND, IN-CLUDING WITHOUT LIMITATION, DAMAGES FORLOSS OF GOODWILL, WORK STOPPAGE, COMPUTERFAILURE OR MALFUNCTION, INTERNET INACCES-SIBILITY OR ANY OTHER AND ALL OTHER COM-MERCIAL DAMAGES OR LOSSES, EVEN IF ]COM-PANY] SHALL HAVE BEEN INFORMED OF THEPOSSIBILITY OF SUCH DAMAGES, OR FOR ANYCLAIM BY ANY THURD PARTY. THIS LIMITATIONOF LIABILITY SHALL APPLY TO LIABILITY FORDEATH OR PERSONAL INJURY.

In all of the agreements reviewed for this article, thelanguage of the disclaimers is nearly identical for the war-ranty disclaimer.


439

The Uniform Commercial Code (“UCC”) permits parties todisclaim express warranties otherwise stated in the agree-ment, so long as doing so is not unreasonable.4 With respectto implied warranties, an implied warranty of merchant-ability may be disclaimed if the agreement mentionsdisclaimer of merchantability and is conspicuous.5 Todisclaim an implied warranty of �tness, the agreementlanguage must be conspicuous.6 To simply disclaim allimplied warranties, the agreement need merely statesomething to the e�ect that ‘‘There are no warranties whichextend beyond the description on the face hereof.’’7

Problems which can arise here are numerous. For example,in Evolution, Inc. v. SunTrust Bank,8 the District Court forthe District of Kansas addressed a case in which a softwaredeveloper sued a licensee for copyright infringement. The li-censee counterclaimed for breach of contract, fraud andmisrepresentation. In the motions for summary judgment,the licensee claimed that the developer's limitation of dam-ages clause amounted to an impermissible attempt todisclaim an express warranty. The court stated, ‘‘UnderKansas law, an express warranty is created by any a�rma-tion of fact or promise made by the seller to the buyer whichrelates to the goods and becomes part of the basis for thebargain.’’ However the court noted that words or conductwhich created such a warranty would be construed consis-tently with words or conduct which sought to negate such awarranty whenever reasonable.9 The court did not addresswhether an express warranty had been created in the case,however, and left that decision to the jury.10

The more important disclaimer for a medical practice willbe the disclaimer of liability. The practical e�ect in mostcases will be that, in the event of a failure of the software for

4U.C.C. § 2-316(1).5U.C.C. § 2-316(2).6U.C.C. § 2-316(2).7U.C.C. § 2-316(2).8Evolution, Inc. v. SunTrust Bank, 342 F. Supp. 2d 964 (D. Kan.

2004).9Evolution, Inc. v. SunTrust Bank, 342 F. Supp. 2d 964, 969 (D.

Kan. 2004).10Evolution, Inc. v. SunTrust Bank, 342 F. Supp. 2d 964, 971 (D.

Kan. 2004).


440

any reason, the practice will only be able to sue the vendorfor the cost of the software. If a patient is killed or otherwiseharmed by a faulty EHR or if the software causes the entirepractice local network to crash and lose months of billingand patient data, the practice will still only be able to suefor the cost of the software.

§ 9:9 Support clausesOften, EHR software licenses will include support services

with the initial software; in these cases, the practice is buy-ing not only the software, but also the ongoing supportprovided by the company. Support clauses are important inthat they typically provide support when problems arise,and may also include updates to the software. Given theimpending development of EHR standards by the Federalgovernment, support clauses will take on greater importance.Both the O�ce of Inspector General and the Centers forMedicare and Medicaid Services have proposed exceptions tothe Federal anti-kickback statute and the Stark statute forEHR software.1 In addition, competing standards for EHRsare developing in the private sector.2 Because standards arenot fully developed yet and may in fact prove con�icting tosome degree, practices will need to know that support willinclude more than simple bug �xes and enhanced features.The license must therefore anticipate updated requirementsfor EHRs imposed by new regulations and the eventualdevelopment of industry-wide standards for EHRs.

The scope and conditions of support vary from agreementto agreement. Support services may be included in the costsfor the EHR license, or may be available as an option forpurchase by the practice. Support services may include a va-riety of speci�c services, such as on-site support (supportprovided at the practice's o�ce), and o�-site support (such as

[Section 9:9]1The proposed exceptions have appeared at 70 Fed. Reg. 59015 and

70 Fed. Reg. 59182, respectively. The OIG's exception for EHR software,however, has not appeared as an additional safe harbor in 42 C.F.R.§ 1001.952.

2For example, both Health Level 7 and The Certi�cation Commis-sion for Healthcare Information Technology are developing standards forfunctionality of EHR software. See http://www.hl7.org and http://www.cchit.org, respectively.


441

e-mail, telephone, or web support). A support clause mayalso distinguish between hardware and software support,and may condition support on various customer actions.

Example A: The customer is charged for services, althoughsupport fees may be altered after a two year period by either a10% increase or an increase of 3% of the Consumer PriceIndex. Maintenance fees will double if ‘‘at any time [Customer]fail[s] to have a [contact person on site, trained by theCompany in operation of software] for more than a three-month period.’’ Doubled fees will continue until a new practicemember or employee is trained in the operation of thesoftware.

Example A's requirement that the practice designate an in-dividual who serves as the on-site point of contact, or facedoubled support fees is signi�cant. A practice may not wantto rely on a single point of contact through which all supportcommunications must run. If that individual leaves thepractice for any reason, the practice will be forced to �nd anew contact person who has been appropriately trained bythe company within three months or pay the doubled fees.Similarly, spending the time to train the person may placean additional strain on the practice as it may impact produc-tivity during the training process. On the other hand, thepractice may bene�t from the single point of contact andmay �nd that, after the initial training costs are surpassed,this method may provide a more streamlined approach tosoftware support.

By contrast, the following example allows the practice amore open-ended approach to interaction with the vendorwith respect to software support.

Example B: The customer is charged for support services, butthe charges are waived for �rst year. After this initial period,the customer is charged for support. The practice must performroutine maintenance as required by the software documenta-tion for products, maintain certain environmental conditionsrequired by the products, install new updates as requested by[Company], install recommended communication software(including an industry standard modem and dedicated com-munication line or provide the company with access for remotediagnostics according to the Company's system requirements),grant supervisor security rights to the Company on thehardware where installed, schedule time for on-site installa-tion and training, and perform other routine maintenance asrequested.

Example B permits the practice to rely primarily on the


442

company itself for speci�c software support, although it doesrequire the practice to maintain its site within the limitsspeci�ed by the software documentation. The practice mustalso take time to train its sta� on-site, and perform routinemaintenance, which will impact productivity to some degree.As a positive, however, because the support is free duringthe �rst year, the practice will receive free support duringinstallation and in the months that follow, when it is morelikely to run into di�culties with the software. Presumably,by the end of the �rst year, the practice would be morecomfortable with the software and its operation, and requireless support service.

Example C: There is no speci�c charge for support services.However, the practice pays a monthly fee for the EHR servicesitself. Thus, the cost of support is likely factored into themonthly fee. Support is ‘‘Provided to a single point of contactestablished at the Client site.’’ The agreement also requiresthat the practice ‘‘(i) maintain a support sta� capable ofperforming problem determination prior to engaging[COMPANY]'s support services, (ii) provide access to worldwide web support resources for its internal support organiza-tion, (iii) provide e-mail capabilities to support personnel, and(iv) perform an annual support self-assessment.’’

Like Example A, Example C requires a single point ofcontact. However, because there is no additional support feeimposed, the practice may face a lower economic burdenthan if it uses a di�erent EHR which requires support fees.Regardless, no matter what a practice does to address sup-port issues, adding to the duties of existing personnel or hir-ing additional personnel to perform these tasks, the bottomline is that it will cost the practice to meet the requirementsof each of these agreements. If the practice adds to existingpersonnel's duties, it runs the risk of lost productivity. If thepractice hires additional personnel, it will place additionalcosts on the practice. Because one choice may be moreeconomical than another, depending on how the practiceoperates, recognizing the speci�c requirements of a supportclause in light of a practice's usual operation will help an at-torney to guide to the practice in assessing the licenseagreement.

Moreover, not all agreements will specify that support iseven provided. If an agreement does not specify this, thepractice should at least inquire as to whether the companyo�ers support services separately. Support services can


443

include version updates (used to �x bugs in the software andbring the software into compliance with regulatory changes),and technical support for troubleshooting. It is therefore in apractice's best interests to purchase an EHR that eitherincludes support services, or which o�ers them as an ad-ditional service.

§ 9:10 Data ownership clausesAnother signi�cant issue for practices will be data owner-

ship, depending on the nature of the EHR itself. If the vendornever has access to the practice's data—such as in the caseof an EHR that operates only at the practice's o�ce(s)—dataownership may not be as great a concern.1 However, if thepractice uses a web-based EHR, or if the practice com-municates data to a vendor's server, data ownership will bea more important issue. Data itself is valuable in multipleways. It can be used as a tool for quality improvement, soldto third parties in de-identi�ed form, or used as the basis ofadvertising. Given the value of data, a practice will want tokeep as much data as possible.

In EHR software licenses, typically the vendor either ownsor licenses whatever intellectual property it has brought tothe transaction, and retains this information as its own bothduring and after the term of the agreement (except insofaras it licenses the use of its information to the practice). Thepractice usually will retain whatever information it inputsinto the system, such as patient data. However, in somecases, an agreement may have the practice transfer de-identi�ed data to the vendor.

Example A: ‘‘[COMPANY] shall have access to the activitydata of Client processed with the [CORE SOFTWARE] so longas such data do not allow the identi�cation of an individualperson (such data hereinafter referred to as ‘‘blinded data’’)and only to the extent permitted by law and by Client's agree-ments with third parties. Client hereby grants to [Corecompany] and [Company] an irrevocable, nonexclusive,transferable, perpetual license to use the blinded data for anypurpose permitted by law, including, without limitation,comparative data analysis and the development, marketing

[Section 9:10]1Shay, ‘‘Commerce in Provider Data: What, Why and Provider

Contractual Controls,’’ Health Law Handbook, 285 (A. Gos�eld, ed. 2005).


444

and distribution of other products or services. In exchange forits participation in this process, Client may subscribe to[Company]'s subscription services for value-added comparativedata and other related services and products.’’2

In the �rst example, the practice turns over de-identi�eddata to the vendor. Although the clause does not specify theintended use for the data, it strongly suggests that the datawill be used in comparative analysis and marketing, as wellas the development of additional products and services. Thepractice, however, is given access to comparative data inexchange for the transfer. By comparison, in Example B, thevendor makes no ownership claim to the data.

Example B: ‘‘All business data obtained by the Customer isthe property of the customer. This includes patient clinical,�nancial and insurance related information. How the data ispresented (i.e. the forms and software programming that pre-sents the data) is the function and property of [Company].’’This clause also grants the company a license to enter thedatabase (where the practice's data is stored) at any time fordebugging and improvement of the company's software.In addition, note that the license is non-exclusive. Thus,

the practice may still use this data itself, or transfer it to an-other entity. However, the license is also irrevocable andperpetual, which means that the practice can never termi-nate the vendor's right to use the data, and such right willnever expire on its own. Practically speaking, the value ofthe data to subsequent users may be reduced, since anotherparty already has access to it.

Depending on the nature of the practice, the optimal dataownership relationship may vary. For example, ahematology/oncology group making extensive use of cancertreatment drugs might want to maintain control over itsdata, so that it could sell the de-identi�ed information to athird party, such as IMS. For such a practice, Example Bwould be far more attractive. On the other hand, a smallfamily practice which has no intention of using the data foranything but its own internal practice improvement andpatient treatment might be perfectly content with ExampleA, especially since they gain access to additional data andservices in exchange. Whatever the speci�c concerns of the

2In this example, the software is provided by a vendor, but isdeveloped by another company. Thus, [Company] represents the vendorand the developer of the core software is referred to as [Core Company].


445

practice may be, it is still important to be aware of who willhave control and ownership of, as well as access to the data.

§ 9:11 Sub-licensingAlthough many EHRs are developed and licensed to a

practice by the same company, some EHRs arrive at apractice's doorstep having been created by a party otherthan the actual vendor. In these situations, the vendor issub-licensing the software to the practice. This raises issueswhich are not a concern when a practice buys its EHRsoftware directly from the developer. For example, one agree-ment reviewed for this chapter was for a software systemlicensed from another company, to which additional modi�ca-tions had been made by the vendor. Although this was ex-plicit in the terms of the license agreement, sub-licensedsoftware will highlight issues such as support clauses. If thepractice cannot turn to the developer because of a lack ofprivity of contract, it will want to make sure that the vendoro�ers su�cient support services.

This style of ‘‘downstreaming,’’ where the practice receivesthe software from an entity other than the developer, maybecome increasingly more popular, depending on how the�nal Stark rule on EHRs develops. Currently, HHS hasproposed an exception to the Stark prohibition against selfreferrals which would permit a hospital to provide EHRsoftware to physician members of its medical sta�. In theproposed regulation at 42 C.F.R. § 411.357(w), a hospitalwould be permitted to supply EHR software to a physicianmember of the hospital's medical sta� (or by a group practiceto a member of the group), provided the physician took noaction to limit or unnecessarily restrict the use or compat-ibility of the software with other EHRs.1 In addition, neitherthe physician nor the physician's practice may condition do-ing business with the hospital on the basis of receipt of EHRsoftware.2 The eligibility of the physician and the nature ofthe EHR software must be determined in a manner whichdoes not take into account the volume or value of referralsgenerated between the parties, and the arrangement must

[Section 9:11]170 Fed. Reg. 59197.270 Fed. Reg. 59197.


446

be set out in writing, specify the items or services beingprovided, and contain a certi�cation by the physician thatthe items and services are not technically nor functionallyequivalent to items or services that the physician alreadypossesses.3 However, recipients of this software must providewritten certi�cation that the software they receive is notequivalent in function to software they already possess, andthat donors may not recklessly disregard knowledge of arecipient's technology being equivalent to the donatedsoftware.4 Recipients cannot condition their business withthe donor on the receipt of the software, and cannot only of-fer services to certain recipients.5

The regulations covering ‘‘pre-interoperability’’ EHRsoftware are more restrictive than ‘‘post-interoperability’’EHR software which meets the functional standards for‘‘post-interoperability.’’6 The likely e�ect of this will be that,as hospitals and group practices with greater purchasingpower seek to take advantage of the Stark exception, we willbegin to see a move towards the federal standards to beespoused by the regulations. Currently, the standards assuch are fairly broad and unspeci�c, but this is likely tochange as HHS collects comments on the proposed rules andformulates a �nal rule. Most likely, HHS will adopt regula-tions which mimic the style of the Health Information Port-ability and Accessibility Act of 1996 (“HIPAA”) regulations,which are broad and adaptive. The e�ect of all of this onphysicians who fall within the exception as recipients will bethat, as the Stark exception gains popularity, the physicianswill be placed in the position of a downstream sub-licensee.In other words, the hospital will purchase the software froma vendor or developer with whom it has a license, and maythen execute a sub-license with the physician.

Typically, as a sub-licensee, a practice will only be able tobring its concerns to the sub-licensor, rather than to thevendor, due to privity of contract. If the sub-licensor can

370 Fed. Reg. 59197.470 Fed. Reg. 59197.570 Fed. Reg. 59197.6For example, for non-certi�ed EHR software, the donated software

may not include any billing, scheduling, or other o�ce management oradministration functions. The regulations for certi�ed EHRs do not includethis restriction. 70 Fed. Reg. 59197-98.


447

provide adequate support for the software, then this may notbe a problem. Similarly, the sub-licensor will likely disclaimthe same warranties and liability that vendors do. If thepractice is purchasing sub-licensed software, it may want toinquire, however, as to what modi�cations if any the sub-licensor has made to the underlying software. The sub-licensor may have done something as simple as rebrandedthe software by placing its own trademark on it. Alterna-tively, the sub-licensor may be selling its own product, whichcomes packaged with another vendor's product, or whichintegrates components from another vendor. In such situa-tions, at the very least, the practice should know which othervendor's products are involved.

Alternatively, as the Stark EHR exception develops, in ad-dition to concerns regarding liability and privity of contract,physicians will have to comply with the requirements of theStark exception, including providing written certi�cationthat the software they receive is not functionally equivalentto their existing software system. Towards this end, prac-tices and attorneys will need an understanding of thefunctionality of the current software, the donated software,and how both relate to the Stark exception �nal rule once itis proposed.

§ 9:12 Delivery/timeframes/installation clausesEHR license agreements may also include provisions which

control the delivery and/or installation of the software itself,placing requirements on one or both of the parties, such asrequired preparations prior to installation. A delivery clausemay also absolve the vendor of liability in the event of a fail-ure to deliver on time. Such clauses may be either explicit orvague, elaborate or brief. As a practical matter, delivery/installation clauses are important to the smaller physicianpractice because they may contain ‘‘hidden costs.’’

One common factor across agreements is that delivery/installation clauses typically disclaim liability for thevendor's failure to deliver on time. These clauses also usu-ally require the customer to prepare their site forinstallation. Preparation of the site often refers to having allnecessary hardware (computers where the software will beinstalled, inter-o�ce networks, online communicationcapabilities, etc.) in place by the time the company arrives toinstall the software.


448

Where EHR license agreements may di�er, however, is inhow they bind the vendor, how �exible delivery dates are,and whether additional costs are imposed on the customerfor delivery or associated services. For example, a customermay be required to pay for lodging and transportation forvendor employees engaged in on-site customer training inthe software. Likewise, an agreement may require a cus-tomer to pay any costs associated with a customer-causeddelay in installation. This is especially noteworthy, giventhat most agreements have the company disclaiming any li-ability for damages caused by its own delay inimplementation.

A physician practice will bene�t most from a de�nite state-ment that the company will deliver on time (even if ac-companied by a disclaimer of any damages caused by latedelivery/installation) than it will from a clause which o�ersonly vague assurances that ‘‘both parties agree to cooperateto create a mutually agreed to implementation plan and touse commercially reasonable e�orts to implement theSoftware in accordance with such plan.’’ While such languagesounds very accommodating, it o�ers little by way of realobligations. While a vendor may disclaim damages for fail-ure to implement on time, if it sets de�nite dates for deliveryrather than a general ‘‘implementation plan,’’ a customermay still sue for breach of contract if the vendor fails todeliver on time even if the customer may not obtain ad-ditional damages for the breach.

§ 9:13 Modi�cation

Although not every agreement will have a separate clauseregarding modi�cations to the EHR software, most agree-ments do address this issue and prohibit such modi�cationor at least require prior written authorization. While suchlanguage is generally not a concern, if the physician practiceintends to modify the software in any way, the practiceshould be made aware of the legal e�ect of such modi�cation.This may range from voiding the software's warranties, totermination of all vendor obligations, including disabling thesoftware itself. Modi�cation may be permitted with a writ-ten approval by the vendor, or may be prohibited altogether.

The signi�cance of language preventing modi�cationdepends on two factors: the need for the practice to modify


449

the software, and what modi�cation speci�cally means. Apractice may have no need to modify the software in the �rstplace. It may simply install the software and adjust all othersystems, in terms of both hardware and software, aroundthe new EHR. Alternatively, the practice may need to adaptthe EHR itself to mesh with existing systems. If this is thecase, having a clear understanding of what ‘‘modi�cation’’means will be important.

Unfortunately, most agreements do not provide a clearde�nition for ‘‘modi�cation’’ within the text of the agreement.While modi�cation obviously includes actions such as alter-ing the underlying code of the software and how it performs,other less obvious actions might fall within the scope ofmodi�cation language. For example, how will compatibilitywith the practice's existing software be accomplished? If thenew EHR does not interface with other software that thepractice needs, is the practice allowed to modify the EHRprogram to accomplish this end? Moreover, if the vendor'sunderstanding of ‘‘modi�cation’’ and the practice's under-standing do not match, the practice may unintentionally‘‘modify’’ the software.

Ideally, the practice should have no need to modify thesoftware itself, and to the extent such modi�cation is neces-sary, should only do so having previously obtained writtenpermission from the vendor. Ideally, the practice will havedone its homework prior to purchasing the EHR, anddetermined whether the EHR can function with the practice'sexisting systems. To the extent that the EHR isn't im-mediately compatible, the practice should negotiate for thevendor to adapt the software to the practice's system.

However, in the event that the practice still needs to some-how change how the EHR functions (which may include howit interacts with other software), the practice will want aclear understanding of what ‘‘modi�cation’’ means. To theextent possible, it is therefore worthwhile to ask the vendorto include at least an inclusive, if not an all-encompassingde�nition, of ‘‘modi�cation’’ within the body of the agreementitself, or in an exhibit to the agreement. Alternatively, anexhibit with permissible modi�cations listed may also beuseful.

§ 9:14 AssignmentThe ability to assign contract duties generally means that


450

a party can transfer its rights and obligations under thecontract to a new party. The assigning party is then removedfrom the entire equation and the new party stands in itsplace. With EHR licenses, assignment clauses require closescrutiny. In general, to the extent that such issues are ad-dressed, the customer will be unable to assign the agreement.This is less of an issue for practices, however, since theylikely want to continue to receive the bene�t of the EHR.Except in situations of merger or practice sales, most prac-tices will have no reason to want to assign the agreement. Ifthere is any expectation, though, that merger or sale couldoccur, assignability should be addressed. Still, the fact thatmost agreements either entirely prohibit or require writtenauthorization for customer assignment is less of an issue forthe practice.

By contrast, the vendor is often either explicitly allowed toassign the agreement, or is implicitly permitted to assign.Implicit ability to assign usually takes the form of a prohibi-tion on assignment by the customer with no similar prohibi-tion placed on the vendor. For example, ‘‘This agreement isnot assignable without the prior written consent of[Company]. Any attempt to assign any of the rights, duties,or obligations of this Agreement without such consent isvoid. Subject to the foregoing, this Agreement shall be bind-ing upon and inure to the bene�t of the parties and their re-spective successors and assigns.’’ Because any assignmentrequires the company's prior written consent, presumably,the company itself is free to assign.

Prohibitions on customer assignment which implicitly al-low vendor assignment may also appear in ‘‘Binding E�ect’’clauses. Such clauses usually appear as: ‘‘This Agreementshall be binding upon and inure to the bene�t of the partiesand their respective successors. However, Client may not as-sign this Agreement without the express written consent of[Company].’’ In these clauses, the company generally statesthat any successor (such as a company which buys thepractice but wishes to continue using the EHR) may assumethe rights and duties of the agreement. However, becausethe company requires written consent before any other as-signment is possible, it again implies that the company itselfis free to assign.

A company's assignment of an EHR license may or maynot be problematic for the practice, depending on who takes


451

over the license. In a worst-case scenario, the practice maybe subjected to a new company which does not meet thepractice's needs with respect to ongoing support for the EHR.In a best-case scenario, the new company may provide betterservice than the previous company. However, it is more likelythat the company which developed the software initially willbe best suited to provide support and updates to the softwarewith a minimum of bugs (this assumes that the companywith whom the practice is contracting is the actual developerof the EHR software). Accordingly, practices should be madeaware of the company's ability to assign, and the potentialproblems that can arise from such an assignment.

In some agreements, the company may also be permittedto delegate to third parties. The legal implication of this isthat the company remains in the position of receiving thebene�t of the agreement (payment, in the company's case),but has a third party performing its obligations under theagreement. As a practical matter for the practice itself, thisis only a slightly better situation than if the agreement isassigned. In this situation, the practice may still complain tothe original vendor if it is dissatis�ed with the third party'sperformance. Thus, if an agreement only allows the vendorto delegate, this is actually a better position for the practicethan wholesale assignment.

§ 9:15 Choice of law and venueMost agreements include some form of choice of law, and/or

venue (also known as forum selection) clause. Language ofsuch a clause will typically read something like,

This Agreement is made under, and in all respects shall beinterpreted, construed and governed by, and in accordancewith the laws of the State of California. Any cause of actionarising out of or related to this Agreement may only be broughtin the local court of applicable jurisdiction in the State of Cal-ifornia, Orange County, and [Customer] hereby submit[s] tothe jurisdiction and venue of such court.

In this example, both choice of law and venue are addressed.However, some agreements may only address choice of law,and not discuss venue.

In general, both choice of law and forum selection clauseswill be considered enforceable. For example, in addressingchoice of law provisions, the UCC states that ‘‘when a trans-action bears a reasonable relation to this state and also to


452

another state or nation the parties may agree that the laweither of this state or of such other state or nation shall gov-ern their rights and duties. Failing such agreement, this Actapplies to transactions bearing an appropriate relation tothis state.’’1 Likewise, the Second Restatement of Con�icts ofLaws states generally that an agreement may select the ju-risdiction of law to apply to contractual disputes, unless: (a)the chosen state has no material connection to the transac-tion, or (b) the enforcement of the clause would run counterto the fundamental policy of the other state, and such otherstate has a materially greater interest than the state namedin the contract.2

States may also have a subtly di�erent approach to theapplication of both types of clauses. Although there is adearth of caselaw regarding EHR licenses, tangentially re-lated caselaw may provide insight into what a practice mayexpect in addressing such clauses. For example, in NMPCorp. v. Parametric Technology Corp.,3 the enforceability of achoice of law clause in a software license required a closelyscrutinized balancing test between Oklahoma law and Mas-sachusetts law. Here, an Oklahoma purchaser sued a Mas-sachusetts software developer for breach of contract as wellas claims of fraud and misrepresentation. The District Courtfor the Northern District of Oklahoma was asked to enforcea choice of law clause which placed the contract under Mas-sachusetts law. On the breach of contract claims, the defensecentered on two contractual clauses: (1) a warranty that theproduct would function as stated for ninety days followinginstallation, and (2) a contractual limitation of liabilities. Al-though the plainti�s claimed that Oklahoma public policyprohibited contractual limitation periods for contracts fallingoutside the scope of Article 2 of the UCC, the court foundthat Oklahoma public policy was not violated by the applica-tion of Massachusetts law. Accordingly, because Mas-sachusetts law permitted contractual one-year limitationperiods, and because the Massachusetts UCC permitted par-

[Section 9:15]1UCC § 1-105(1).2Restatement 2d of Con�icts of Laws § 187(2).3NMP Corp. v. Parametric Technology Corp., 958 F. Supp. 1536, 32

U.C.C. Rep. Serv. 2d 687 (N.D. Okla. 1997).


453

ties to limit damages as long as the limitation would not beunconscionable, the contractual terms were valid, despitethe plainti�'s claims of a con�ict with Oklahoma law.

In the case of an EHR license, the analysis would be thesame: state law selected by the contract would govern unlesspublic policy was violated in some way. While not every is-sue on which state law may di�er can be predicted, thepractice should at least be aware of the implications of achoice of law clause. For example, a practice in Pennsylvaniapurchasing an EHR from a California vendor, whose licenseapplies California law, should understand that where statelaw di�ers in interpreting contracts, California law willlikely control.

Likewise, caselaw generally upholds forum selectionclauses, so long as they are not unfair or obtained by fraudor overreaching, and are reasonably related to the forumchosen. For example, in CQL Original Products, Inc. v.National Hockey League Players' Assn.,4 the California Ap-peals Court held that a forum selection clause was valid,even though it hailed one party from California to Ontario,Canada. There, a California corporation which had licensedthe rights to produce merchandise bearing the likeness ofNHL players and the NHL Players' Association logo alleg-edly breached its contractual requirements in the productionof such likenesses and logos. The court stated that so long asthe clause was not unreasonable and the choice of forum hada rational basis in light of the facts underlying the transac-tion, the clause would be enforceable.5

Even though in the above case, the license involvedtrademarks and logos, the analysis would be similar if thesubstantive clauses of the agreement were largely the sameand the parties were instead an EHR vendor and a physi-cian practice. In either situation, the potential impact of aforum selection clause is signi�cant. The practice shouldexplicitly understand that if it accepts this speci�c term, itconsents to appear in the selected forum for all disputes

4CQL Original Products, Inc. v. National Hockey League Players'Assn., 39 Cal. App. 4th 1347, 46 Cal. Rptr. 2d 412 (Cal. App. 4th Dist.1995).

5CQL Original Products, Inc. v. National Hockey League Players'Assn., 39 Cal. App. 4th 1347, 46 Cal. Rptr. 2d 412, 416 (Cal. App. 4thDist. 1995).


454

arising from the agreement. As a practical matter, this is amajor concern, since medical practice representativesthemselves will not only have to travel to the forum in ques-tion, but will likely also have to pay for travel expenses forany of the practice's witnesses.

§ 9:16 Termination

Finally, how a contract terminates is equally as importantas how it functions during the life of the contract. Termina-tion and related provisions are important for two reasons:�rst, they determine how parties may exit the agreement;second, they determine what the parties' rights are followingtermination. In this respect, EHR license agreements are noexception. However, agreements vary in the form of termina-tion and the e�ects of termination. Termination may occurfor any reason upon notice, for breach, or in some cases via abuyout of the remainder of the term. Termination clausesmay also di�er in terms of the grounds for termination avail-able to each party.

For example, a contract may permit both the practice andthe vendor to terminate the agreement upon written noticein the event of a breach. The agreement may include awindow within which the breaching party may attempt tocure the breach. By contrast, an agreement may not eveninclude a speci�c termination clause containing grounds fortermination, and may only provide such grounds in the restof the agreement (such as in clauses which state that theirbreach constitutes a default).

In any relationship where the practice is receiving ongoingservices from the vendor, it will want to know how that rela-tionship can end, and especially how the practice itself mayend the relationship. Ongoing relationships should be termi-nable for more than simply breach of the terms; the practiceshould be able to terminate the agreement if it becomes dis-satis�ed with the services it is receiving, even if there hasbeen no breach. For example, if a practice is receiving main-tenance and support, but the support sta� are slow to re-spond to the practice's requests, or if the EHR software doesnot function as e�ectively as the practice had hoped, butthese issues do not rise to the level of a breach, the practicemay want to terminate its relationship with the vendor.Speci�c performance measures (e.g., timeframes, speci�c


455

deliverables such as customizations) are critical to theseprovisions. If there is no mechanism by which this may oc-cur aside from termination for breach, the practice will beplaced in a di�cult position—either continue accepting ser-vices which do not meet its needs, or attempt to terminatefor breach and risk a lawsuit or arbitration. Thus, it is in apractice's best interests to request that a clause for termina-tion for any reason with a notice period. While the vendormay not agree to such terms (at least not without the termsapplying to both parties), it can still be useful to ask for suchprovisions. At the very least, the practice should understandthe implications surrounding how the contract terminates.

Of equal importance, however, is what happens upontermination. Usually, any ongoing services will terminatewith the contract (such as support and updates). In somecases, however, termination may require that the practicereturn all copies of software and manuals to the company.For example,

Termination of this Agreement also terminates [Customer's]Software LicenseUpon termination of this Agreement, [Cus-tomer is] required to return or destroy, as requested byCompany, all copies of the Software in [Customer's] possession(whether modi�ed or unmodi�ed), and all other materials(including but not limited to User Materials) pertaining to thesoftware, including all copies thereof.1

Where this becomes a concern for practices is in the potentialscope of the destruction or return requirements. Most likely,the agreement will not require the practice to destroy itsexisting electronic records in the process of removing thesoftware. However, the practice should request that thevendor explicitly state in the agreement that it will notrequire destruction of existing records.

An additional concern, however, will be the practical issueof whether the practice can use the records in anothersystem. If the electronic records that the practice created us-ing the vendor's software are stored in a format only read-able by the licensed software, the practice will need totransfer these records to another system (assuming the

[Section 9:16]1‘‘User Materials’’ are de�ned essentially as manuals and documenta-

tion supplied to the user along with the software itself. The de�nition inthe agreement does not include records or other user-created materials.


456

practice does not switch back to paper-only records). Whenpurchasing the software, the practice may want to inquireabout the compatibility of the record format with othersystems, and the ability to save the information in a formatwhich can be read by multiple systems. If the informationcannot be read by multiple systems, the practice may eitherwant to obtain software that can convert the records, or printout the information prior to termination of the agreement.Who bears these costs could be conditioned on the reason forthe termination. Specifying the limits on the costs to beborne by either party (e.g., if Customer terminates withoutcause, it shall be solely responsible for the costs of convert-ing data to a new format. If Company fails to cure an allegedbreach and Customer terminates, Company shall in theevent be liable for any cost above $————— for Company toconvert its data to a new format.)

IV. CONCLUSION§ 9:17 Generally

EHRs are a hot topic in health care today, and even at thesmaller practice level, interest is likely to rise. As adoptionrates for EHRs rise, practices will need to have a clearunderstanding of both the functional features of the software,and their legal rights and obligations under the licenseagreements which will accompany that software. An under-standing of both the practical needs of small practices andthe functionality of the software being licensed will bene�tattorneys in providing useful guidance on these contracts.By understanding a practice's needs, the attorney can betterexplain the implications of the various clauses of a licenseagreement. Rather than simply laying out what the variousagreement sections mean in general, an understanding bothof what is typical in software license agreements as well ashis or her speci�c client's needs will allow the attorney topinpoint crucial issues in the agreement.


457

a primer on electronic health record license agreements · computers have also grown faster and...

Documents