By HAYWARD ZWERLING, MD

The electronic health record (EHR) is now used by the majority of physicians during every patient encounter. The EHR has become the most important tool in our “black bag” and precisely for that reason, the EHR must be highly accurate and free of bias. As our most heavily utilized tool, the EHR must also be flexible and highly optimized so as to ensure it does not adversely impact the delivery of healthcare. Unfortunately, numerous surveys have found widespread physician dissatisfaction with EHR design.

The fact that EHR programming code is shielded from objective scrutiny by independent evaluators increases the risk that the EHR will contain errors and bias which could adversely impact our patient’s health, hinder our ability to deliver healthcare, “warp” the design of the healthcare system and drain financial resources from our patients and society.

EHR “errors” are well documented in the literature and are referred to as “e-iatrogenesis” or “technology induced” errors. “Bias” in EHR programming code is not discussed in the literature.

EHR errors and bias can be divided into the following categories:

.1: There are programming errors which crash the EHR and brings the patient encounter and/or the healthcare system to an abrupt halt. (1)

2: There are random programming errors which have resulted in:

1. erroneous information being presented to the physician
2. data that was electronically “filed” into the wrong patient chart
3. failure of the EHR to detect important Rx dosing errors, Rx-Rx interactions and Rx-Dx interactions
4. incessant “red flag” warnings that force providers to turn-off all warning messages
5. confusing “pick lists” which have led to clinical errors (2,3,4)

3: There may be unintentional programming bias, which presents information as a “fact,” when a more nuanced presentation would be more accurate. (e.g. A treatment recommendation which fails to mention that there is no data to support the recommendation for elderly patients.)

4: There may be programming code whose sole purpose is to enhance an EHR vendor’s fiduciary interests. (e.g. A pharmaceutical or medical device company pays an EHR vendor to prioritize their product on the treatment recommendations list.)

5: There are programming decisions that create EHR “work-flow” characteristics which impedes a physician’s ability to take care of their patient. (e.g. The need to click a “box” when the data is present in another section of the EHR or an EHR company refuses to improve the functionality of a feature for bureaucratic reasons.)

6: There are EHR design decisions which lead to the exclusion of a “feature” for corporate strategic reasons. (e.g. The decision to exclude an interoperability module as a means of generating additional revenue or to protect market share.)

7: There are unintentional design errors of omission when a feature is not included in an EHR because of the vendor’s lack of imagination or their failure to understand the needs of a healthcare provider. (e.g. An EHR may lack the ability to: display/sort only the patient’s “abnormal” lab results, readily create a list of all uncontrolled diabetic patients or print an envelope addressed to the patient.)

Without a doubt, the proprietary nature of EHR programming code has the potential to adversely impact healthcare. (5)

At its most fundamental level, the practice of medicine is predicated on the rational application of scientific principles which have been vetted using a transparent evaluative process. This process has served the public interest well. The proprietary nature of commercial EHRs has shielded them from the same level of scientific scrutiny which we mandate from new pharmaceuticals and medical devices. Currently, we wait for someone to report an EHR error before the error is fixed. In the clinical realm, this would be tantamount to waiting for a patient to have their first episode of angina before we initiate a statin. Rationally, we proactively measure our patient’s lipid profile and intervene before their first clinical event. In the same vein, we should demand full transparency of EHR programming code and proactively evaluate the code as a means to reduce EHR errors and bias.

The need for code transparency was recently highlighted by a Politico investigative report which found that the contracts of six large EHRs all contained a “gag clause” which prohibited the users from publicly disclosing errors in their EHR.(6) I also know from personal experience that EHR users have been dissuaded from publicly disclosing errors in their EHR and some EHR companies contractually proscribe users from publishing screen shots from the EHR without vendor permission.

The adverse consequences of proprietary source code has lately become a topic of public discussion when it was discovered that Volkswagen had used proprietary software to altered the emission control systems of their vehicles so as to fool regulators into believing that their diesel engine were compliant with national emission control standards, when in fact Volkswagen vehicles were emitting far larger amounts of nitrogen oxide than was allowed by law. (7) Had Volkswagen’s software code been “published information” this deception would have been detected a long time ago and tons of pollution would not have been added to our atmosphere.

An objective assessment of healths related apps, which are built using proprietary source code, have found serious flaws that have resulted in the dispensing of incorrect medical information and a disregard for patient privacy. The editorialists who had review 3 such studies concluded that “most people would be surprised at the low standards of apps … and disappointed that the safeguards they rely upon … such as truth in advertising, professional practice standards, or clinical testing of medical products, appear to be absent.” (8)

In 2015, the Institute for Medicine had recommended that the Federal Government should mandate that health IT vendors should be required to “…routinely submit their products for independent evaluation.”(9) In my opinion, it would be a mistake to assign this responsibility to the Federal Government as it tends to be overly bureaucratic, secretive, inflexible and prone to external fiduciary interests.

Clearly, increased EHR transparency needs to be imposed on the EHR industry and this needs to be done in a way which is fully transparent to the public.

While others have voiced concerns about EHR errors and/or encouraged increased EHR transparency, none have proposed a mechanism to increased transparency. (10,11, 12)

I believe we can improve EHRs, without disrupting the EHR market or incurring Federal or private expense, if all EHR programming code was published to the web as a PDF or as a text file and accessible to be read by anybody. I would call this type of source code “published information.” “Published information” is not the same as “open source” software, as the latter gives the user the ability to modify the source code. While there will be some technical or logistic issues if the EHR industry published their source code, none of the impediments are unsurmountable.

As a means of pressuring the EHR industry to publish their source code, medical schools, training programs and medical societies should begin to teach their trainees and members that physicians have a professional obligation to prioritize the use of “evidence based” EHRs and should favor EHRs which have “published” their programming code, in the same way physicians are taught to favor “evidence based” treatment options. Concurrently, these organizations should begin to educate our politicians on this subject.

Large businesses, commercial insurers and the Federal Government should attach financial incentives to encourage the use of EHRs whose programming code is “published information” much in the same vein as some of these entities now ascribe financial incentives/disincentives arising from the use of “Certified” EHRs and  achieving “Meaningful Use” and “PQRS” mandates.

Undoubtedly, EHR vendors will argue that forcing them to publish programming code was tantamount to requiring that they reveal “trade secrets.” As a programmer with more than 2 decades of programming experience accumulated during the creation of a Stage I ONC Certified EHR, I can categorically state that the “trade secret” argument is derived from a misunderstanding of the coding process. If I learn about a feature that is in another EHR which I think will be useful in my EHR, I will add it using de-novo programming. Similarly, when Steve Jobs saw Xerox’s “mouse,” his software engineers did not need to see the coding which supported Xerox’s “mouse” in order for them to incorporate the mouse into Apple’s operating system. (13)

The EHR industry has benefited immensely from the Federal Government’s $30+ billion investment and have a responsibility to ensure that their EHRs meet the needs of our society. This could be efficiently and inexpensively accomplished if they made their EHR programming code “published information.” After the EHR programming code is “published information,” and the academic, medical and technical communities have scrutinized the code, we can expect to see fewer EHR errors and bias. This will help ensure that EHRs evolve into the accurate, flexible and highly optimize tools which we need to delivery low cost and high quality healthcare.

1. Boston Children’s EHR down for days, Bernie Monegain, Healthcare IT News. 3/27/2015http://www.bostonglobe.com/metro/2015/03/25/boston-children-emerges-from-day-shutdown-electronic-medical-records/Q6sE7hRM4CxFeMEDYWP8IK/story.html
2. Review of Reported Clinical Information System Adverse Events in US Food and Drug Administration Databases. Myers RB, Jones SL, Sittig DF. Appl Clin Inform. 2011;2(1):63-74.
3. A red-flag-based approach to risk management of EHR-related safety concerns.  Sittig DF, Singh H. J Healthc Risk Manag. 2013;33(2):21-6
4. A clinical case of electronic health record drug alert fatigue: consequences for patient outcome. Carspecken CW(1), Sharek PJ, Longhurst C, Pageler NM. Pediatrics. 2013 Jun;131(6):e1970-3.
5. Engineering the electronic health record for safety: a multi-level video-based approach to diagnosing and preventing technology-induced error arising from usability problems. Borycki EM(1), Kushniruk AW, Kuwata S, Kannry J. Stud Health Technol Inform. 2011;166:197-205
6. Doctors barred from discussing safety glitches in U.S.-funded software, Tahir, D, Politico, 9/11/2015, http://www.politico.com/story/2015/09/doctors-barred-from-discussing-safety-glitches-in-us-funded-software-213553)
7. VW Is Said to Cheat on Diesel Emissions; U.S. to Order Big Recall, New York Times, 9/18/2015,http://www.nytimes.com/2015/09/19/business/volkswagen-is-ordered-to-recall-nearly-500000-vehicles-over-emissions-software.html
8. ‘Trust but verify’ – five approaches to ensure safe medical apps. Paul Wicks and Emil Chiauzzi, BMC Medicine (2015) 13:205
9. Safe use of electronic health records and health information technology systems: trust but verify. Denham CR, Classen DC, Swenson SJ, Henderson MJ, Zeltner T, Bates DW. J Patient Saf. 2013 Dec;9(4):177-89
10. Improving Diagnosis in Health Care, Institute for Medicine. Sept 2015 https://iom.nationalacademies.org/~/media/Files/Report%20Files/2015/Improving-Diagnosis/Diagnosis_Recommendations.pdf
11. Electronic Health Records and National Patient-Safety Goals. Dean F. Sittig, Ph.D.,  Hardeep Singh, M.D., M.P.H. NEJM 2012:367;19
12. Report of the AMIA EHR 2020 Task Force on the Status and Future Direction of EHRs. Payne TH, et al. J Am Med Inform Assoc 2015;0:1–11
13. Triumph Of The Nerds Part 3, Great Artists Steal, PBS, 1996, https://archive.org/details/PBS.Triumph.of.the.Nerds.3of3Hayward Zwerling, MD practices at the Lowell Diabetes and Endocrine Center and is Vice Chair of the Committee for Information Technology of the Massachusetts Medical Society. This proposal does not reflect the views of the Massachusetts Medical Society.