A Proposal to Increase the Transparency and Quality of Electronic Health Records

flying cadeucii 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.

Categories: Uncategorized

Tagged as: , , , ,

12 replies »

  1. When an electronic health record attempts to connect technology with the patient experience without the assistance of those who care for the patient, it becomes very frustrating. Initially, the EHR that we implemented had a limited number of providers that were involved in the building of the program. They have, since then, attempted to incorporate nurses and physicians in the build of the programs. There is still a lot of confusion from hospital to hospital concerning each other’s EHR. When attempting to read the printed chart, the information is often in ambiguous places. There are times that navigating the medical record becomes difficult for those that work with it daily. Not to mention the accessories that come with the EHR that fail to work in the midst of patient care.

    We have a generation that feels that they are unable to administer care without the assistance of the medical record. I know that it can be daunting at times because we are used to the EHR in modern times. However, this does not negate the the fact that patient care is first and figuring out how to document that care is last.

  2. For more transparency and quality Electronic Health Records, we have created a very user friendly platform in which the health records would be uploaded by our partnered Health Service Providers directly into a log in ID of the patient. If the Health Service Provider is not partnered with us then there is an option to self upload the health records also. This will cost the patients just INR 120 p.a. or approximately $2.00 p.a. and they can access their health records anywhere, anytime.

    As an introductory offer, we are not charging anything as of now.

    Please register at http://www.medicalui.com and review it.

  3. Drivers of increased transparency by commercial entities, such as software vendors, can be legislated or derived from market and financial forces. Enterprise software vendors choose to include open-source components such as Linux or Apache Tomcat in their commercial software distributions because doing so lowers R&D costs and total cost of ownership for their customers. There are components of base EHR functionality which may be similar low-hanging fruit for open-source to prevent each vendor from reinventing the wheel for what is essentially a commodity capability. Take clinical quality measure (CQM) calculation. Enormously complicated and consumed 50%+ of all R&D resources by one of the top 3 vendors by market share to implement in their first Meaningful Use certified EHR release. Yet, it’s part of the base EHR definition and thereby is a commodity with little room for differentiation in terms of user-interface design or value-added functionality. Ripe for an open source play, and that is what the PopHealth open-source CQM project is all about. Perhaps EHR vendors need to re-evaluate or perhaps openly support and contribute to open-source projects which can lower their own R&D costs and support costs while enabling them to put more resources towards parts of EHR functionality which they can more truly differentiate themselves on. That’s why fierce competitors such as Facebook, Google, and Yahoo have collaborated on certain open-source database projects, such as Map Reduce, which they all use and benefit from by pushing a commodity capability into the public domain, so they can each put more resources toward what makes them better than each other.

  4. “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.”

    Agree. Beyond the broader contentious issue, a good place to have started would have been a “Standard Data Dictionary” as a requirement for ONC certification, given the “interoperability” needs.

    e.g., http://regionalextensioncenter.blogspot.com/2015/10/interoperability-we-dont-need-no.html

  5. Thank you Hayward for shining a light on this very important topic. Secret software is now becoming secret medicine. If there is some kind of limit to medical secrecy then that limit will also apply to software that implements that functionality.

    As for errors, proprietary software vendors have an incentive to hide errors (including gag clauses) whereas open source software has the incentive to make the errors public so they will get fixed.

  6. I was mainly tongue-in-cheek of course but not sure that “most physicians” are as devoted to their EMR’s as you believe. Every doc I know absolutely despises theirs as an abomination. I’m actually happy with pen/paper, but since I also went to lawyer skool [sic] I am also pretty damn handy with a keyboard. I can type faster than most docs can talk, so I still prefer to “free text” most of my data entry. This naturally makes me hated by the coders.

    On the other hand, if you are talking about the ability to pull up DATA on my computer, like my patient’s last echo report, or his chem 7 from 3 months ago, or that discharge summary, then yeah, you got me, that’s a big advantage in the ER. But I don’t view that as an “EHR,” as much as it is “retrievable digitized information.” A 1990’s era scanner and a dictated report can provide this.

    An EHR is the Roman Galley with doctors chained to the freakin oars. “What is your crime, number 42?” sayeth Quintus Arrius to Judah Ben-Hur. Mine was going to med school when doctors wrote on charts, and now are data entry clerks.

  7. Well designed EHRs can be useful. I could not survive without my EHR.

    Polls show that most physicians do not want to give up their EHR and return to pen and ink. They want a better designed/more functional EHR. There is promise in EHRs, but, in my opinion, they have been overhyped are not likely “the solution” to the healthcare cost/quality problem.

  8. Dr. Zwerling, I think I can fix your problem for you:

    All we need is a couple of patients who have been allegedly harmed by those “e-iatrogenic” errors to call their attorneys. They can initiate litigation, and claim punitive damages just like the sure-to-come Volkswagen mass tort actions.

    Then, we can be subjected to endless and varied television commercials by attorneys seeking clients who have been “e-harmed” by their doctor’s EHR. It will be a welcome change of pace from the lame old mesothelioma ads. The lawyers can sue the EHR’s out of existence, and we can go back to using pens and paper, saving trillions of valuable and expensive physician man-hours, but at nominal expense of trees.

    Not gonna happen? Just ask any of the folks who manufactured Bendectin, or IUD’s, or Propulsid, or silicon breast implants, or pedicle screws, or Rezulin, or COX-2 agents, or Baycol, or Trovan or Lotronox or . . . well, you get the idea.

  9. While you may be correct about the local issues, I think the bigger issue is that the practice of medicine is based on a transparent assessment of the underlying science and technology. By insisting that the underlying fundamentals of medicine remain transparent, we can be certain that we will serially improve our understanding of medicine and the treatment of patients.

    If we allow the source code of EHRs to remain proprietary, it fundamentally changes the future of medicine. We can no longer be certain that errors in the EHR will be identified and corrected, or that “bias” in the EHR will be avoided/eliminated, precisely because these things will remain hidden from the physicians who use the EHR.

  10. To get the full story CIOs and IT departments will need to open up as well as EMR vendors. The settings that have the most impact on the patient/clinician experience are often organization specific i.e. the hospital configures their system as part of the installation. Looking at the source code will not tell you how the various alerts, screens/workflows, medication formularies etc are actually configured and used at the point of care. For this reason, the same EMR product may be safe and easy(or easier) to use at one provider but clunky with patient safety concerns at another.

Leave a Reply

Your email address will not be published. Required fields are marked *