The Ethics of EHR Vendors

Last week the American Medical Informatics Association (AMIA) released a position paper titled “Challenges in ethics, safety, best practices, and oversight regarding HIT vendors, their customers, and patients: a report of an AMIA special task force”.  The paper shines a bright light on the alleged contracting practices of EHR vendors and their notorious “hold harmless” clauses, which indemnify the EHR vendor from all liability due to software defects, including liability for personal injury and death of patients. What this means in plain English is that if a software “bug” or incompetency caused an adverse event, and if you (or your hospital) are faced with a malpractice suit, the EHR vendor cannot be named a co-defendant in that suit and you cannot turn around and bring suit against the vendor for failure to deliver a properly functioning product. The AMIA paper also asserts the existence of contractual terms preventing users and purchasers from publicly reporting, or even mentioning, software defects, including ones that may endanger patient safety. The AMIA report goes on to challenge the ethics of both buyers and sellers engaging in such contracts, with an emphasis on the EHR vendors’ primary responsibility to shareholders and the bottom line in general.

As expected, the authors call for Government regulation of HIT products and processes and suggest that contracts should, of course, reflect a shared responsibility between vendors and customers and while public reporting should be allowed (or required) for certain types of software defects, users should be mindful of the vendor’s intellectual property. The interesting portion of the report is the rather novel recommendation for formal Ethics education amongst vendors and purchasers. Presumably, vendors and their customers need to be taught the difference between right and wrong and need to be informed that placing corporate profits (or personal comfort) ahead of patient safety is indeed wrong and therefore unethical. To borrow from the Windows 7 phone commercials, “Really?”

If you ever signed a purchase or service contract, you should know that the opening bid from the seller is just that: the opening bid in the negotiating process to follow. EHR contracts are no different. The initial contracts presented by vendors may contain some, all or none of the following:

• Hold harmless or most often limited liability, for personal injury and death resulting from use of the software. The assertion is frequently made that the software is not intended as a diagnosis and treatment tool and is not a substitute for professional judgment. Many times this clause is accompanied by multiple disclaimers of warranties regarding the accuracy and veracity of the clinical content and decision support provided by the software. The purpose of these terms is to insulate the vendor from malpractice suits. It would be very tempting for a plaintiff, who is usually poor and indebted, to include someone like McKesson or GE in the lawsuit. Juries have even less compassion for corporations than they have for “rich” doctors. The hold harmless clauses, and I have not seen too many, should be removed and the limited liability should be increased from the customary six to twelve months of support fees, to a more significant dollar amount.
• Restrictions placed on the buyer from mentioning the software product name in any format for advertising, marketing or any other purposes, without written permission from the seller. This clause is ridiculous and I presume that’s where the “gag” rules on defect disclosures come from, since I have never seen an explicit line item to that effect. The rather humorous fact is that the vendor usually reserves the right to use the buyer’s name for publicity and marketing purposes. This particular clause should be completely removed, or at the very least changed to only disallow misrepresentation of the relationship between the buyer and the seller.
• Most often the software is warrantied to perform according to the product manuals for ninety days, or not at all, and it is never warrantied to be free of defects or work without interruptions. Would you buy a car with a similar warranty? In all fairness, no software vendor can warranty that the product is “bug free”, because there is no such thing as bug free software. However, respectable vendors in the software industry offer Service Level Agreements (SLAs) outlining processes and timelines for addressing reported issues and financial penalties to the vendor for failing to do so. This brings us to the next salient point.
• Some initial EHR contracts lack any mention of SLAs. There may be descriptions of help desk availability, but no commitments to time frames for resolution and definitely no penalties for non-adherence to SLAs. The buyer must be able to negotiate those into the contract or look elsewhere for software and services.

Contracts containing terms as those described above are examples of a typical purveyor of goods and services trying to make a “good deal” and the buyer’s job is to bargain the terms down to what would be a “good deal” for the buyer, with the final result being somewhere in the middle. Ethical considerations would come into play only if the vendor is knowingly proposing to sell goods that will harm patients, and the buyer knowingly agrees to keep this information secret in return for financial concessions from the vendor, and some of the more vocal opponents of HIT would argue that this is indeed the case. But even then, I seriously doubt that such collusion to disregard patients’ safety for pure monetary gain is a result of vendors and their customers not knowing the difference between right and wrong, or lacking a sound education in the realm of Ethics. Nothing short of legislation and regulation will stop this blatantly predatory behavior if it indeed exists, and I doubt it does.

I would like to submit that there is indeed a need for education, but of a very different nature. Whether the vendor and purchaser agreed to keep issues secret or not, the bugs or defects that can potentially harm patients are the creation of software developers on the bottom of the corporate totem pole. These are not unethical folks and have nothing to gain from cutting corners and endangering people’s lives. But just like physicians sometimes make mistakes, programmers do too and what is most frustrating here is that they don’t even have to make a mistake in order to create a clear and present danger in the software. These mostly young and healthy professionals know very little about the practice of medicine and in many cases have no overarching understanding of the product they are helping to build. They may be experts at the tiny piece they were tasked to develop, but few if any have a grasp of the dire consequences caused by an incorrectly sorted list of medications, for example. The bigger the shop and the more geographically dispersed, the bigger the problem becomes. It is tempting to argue here that EHRs should be designed and built by clinicians, like VistA supposedly was. While clinicians should have much input in design and particularly in acceptance testing of EHRs, it is not economically (or socially) feasible to have hundreds of MDs sitting in little cubbies, writing code for a living. Instead, EHR vendors should indeed engage in educating their workforce, including the most junior developers, on how medicine is practiced. They need not become expert diagnosticians, but it would be great if medical software developers would be required to take rotations (similar to residents) at implementing and supporting the software, preferably at customer sites, before being allowed to touch the code.

Success is brought on by doing the little things right. While there may be some ethically challenged industry captains engaging in questionable contracting practices, the armies of people who do the actual work and create the actual products are by and large capable of telling right from wrong and need no lectures on Ethics. What they need is for someone to compel their employer to invest in their professional education so they are able to do the millions of little things right. And I have seen enough young software developers to know that they really, really want to learn and do the right thing.