EHR Malpractice—Coming to a Location Near You?

by Jerome Carter on March 14, 2016 · 0 comments

The first time an attorney contacted me after reading EHR Science, it was on behalf of a plaintiff who had a delayed diagnosis during a changeover from paper to an EHR.   That was three years ago.   Recently, a defense attorney contacted me because the plaintiff was challenging the validity of EHR data. Although I have acted as an expert witness in the past, it is not something I advertise.   When looking through Google Analytics reports, I am noticing more legal practices among EHR Science visitors.   Welcome to EHR adoption, the sequel…

Defendants win most malpractices cases, so lawyers tend not to take cases unless there seems to be a good chance of winning.   Generally speaking, lawyers are not more tech savvy than other non-technical professionals. Consequently, it takes time to learn when an EHR case might be winnable.   I bring this up because attorney confidence does not seem to be factored into studies of EHR malpractice rates.

Before HITECH, EHR use was low. However, there was also a dearth of information about EHR design flaws and EHR-related errors.   Six years ago, an attorney wishing to file a lawsuit with an EHR at the center had to figure out what approach to use. Today, with the ever-increasing availability of quality information detailing EHR safety and usability issues, lawyers may have to spend less time deciding if they may have a case.

I wonder how healthcare entities and EHR vendors view EHR malpractice?   Do they see a trend?   I ask these questions because prior safety reviews of EHR systems found few cases of serious harm (1, 2). Seeing these reports, one could easily decide that pursuing an EHR malpractice case might not be worth the effort. However, Graber and Siegal et al. may be leading the way in changing this perception for vendors, providers, and attorneys (3).

The authors reviewed cases taken from the CRICO claims database looking specifically for EHR-related claims. They found a total of 248 cases (less than 1% of claims). Significantly, the amount of serious harm, however, was quite high.

A total of 248 cases (<1%) involving health IT were identified and coded using a proprietary taxonomy that identifies user- and system-related sociotechnical factors. Ambulatory care accounted for most of the cases (146 cases). Cases were most typically filed as a result of an error involving medications (31%), diagnosis (28%), or a complication of treatment (31%). More than 80% of cases involved moderate or severe harm, although lethal cases were less likely in cases from ambulatory settings. Etiologic factors spanned all of the sociotechnical dimensions, and many recurring patterns of error were identified.

So it appears that EHR-related harm, while apparently infrequent, can be quite serious.

Harm etiology was divided into two broad groups: system-related and user-related.   Here are a few examples they offered for each type.

System-related
A primary care provider could not access the patient’s radiology studies at the time of a patient’s visit; the paper results were filed without the MD seeing these. The patient experienced delayed diagnosis of lung cancer.

Reminiscent of a recently-publicized case involving a patient with Ebola infection, a physician was unable to access the nursing ED triage note, which would have changed management; the patient died of subarachnoid hemorrhage.

Test results and evaluations were filed in multiple locations, contributing to the failure to note the overall decline of a patient’s vital signs and lab tests; the patient died of sepsis.

A patient complained of “sudden onset of chest pains with burning epigastric pain, some relief with antacid”; Because the ‘complaint’ field in the EHR was too small, the entry was noted only as “epigastric pain”; no electrocardiogram was done and the patient experienced a cardiac event days later.

User-related
An obstetrician did not have EHR access and could not access a patient’s clinic notes documenting abnormal fetal size; the clinician stated he\she never received training or a password.

A physician received an alert that the patient was allergic to amoxicillin but ordered it anyway, resulting in an allergic reaction.

A patient developed amiodarone toxicity because the patient’s history and medications were copied from a previous note that did not document that the patient was already on the medication.

While these are examples of harm, how often do system or user-related issues occur when no obvious harm results? (That is, how bad are the actual designs???) How many labs go unnoticed for too long and how many drug-related alerts are ignored? How much important information is buried behind too many clicks to access it?

The authors offer seven examples — EHR safety issues that providers should address and EHR vulnerabilities that vendors should fix — that could be used as a sort of diagnostic tree by plaintiffs’ attorneys.

Safety issues
The danger inherent in hybrid systems and EHR conversions: We identified repeated examples of injurious problems during periods when organizations are transitioning their record systems. Transitions require a well-defined action plan and appropriate resources to ensure complete and accurate data is available as rapidly as possible.

The dangers of delayed, missing, or incorrect data, services, or actions: Many malpractice claims originated from limitations created by the EHR in providing the correct data, information or services needed for safe patient care. These problems were compounded by the expectation on the part of providers that the medical record system was working as they expected it should, when in fact it was not.

The danger of over-reliance on the EHR: As just noted, providers would be well served to be wary of situations where information is incomplete or possibly inaccurate. The electronic record is an ideal tool to support clinical judgment, but cannot not replace it.

The inherent risks using copy\paste functionality, overriding alerts, and employing ‘workarounds’. These are all well-known vulnerabilities.

Vulnerabilities
Routing problems: We encountered repeated examples of laboratory results going to the wrong provider, documentation not being available to the providers who needed it, and assorted other problems of getting the right data to the right provider.

Pre-population: Although implemented as a time-saver, pre-population by its nature creates the opportunity for data that is outdated or frankly incorrect to be repeated or misinterpreted.

Intrinsic cross-checking: An intelligent medical record system should be able to detect a decimal point error in ordering a medication, as this would fall outside of the acceptable dosing range. It would detect that an order for potassium in a patient already hyperkalemic is probably inappropriate.

The first case I was contacted about was a hybrid system issue and the most recent, a data-related problem – mirroring the first two safety items listed. End-to-end results management would address the routing issue. (Default values are a known design problem.) Faced with a potential malpractice case, I could imagine a plaintiff’s attorney asking if the site had an EHR, then going down a list of safety and vulnerability concerns to see what might fit the situation. On the other hand, I could see defense attorneys doing the same thing when looking for what may have gone wrong.

Usability, user-centered design, and product liability
EHR contracts are written in ways that shield vendors from many types of liabilities. Clinicians are the “learned intermediaries” who foot the blame when malpractice occurs.   However, I wonder if there is a product liability issue on the horizon for vendors.   Now that we have claims data that allow harms to be attributed to design flaws inside an EHR system, can clinicians still be held solely responsible for harms that arise from known design flaws?   For example, if product X is found to be the culprit in a few lawsuits where the same design issue is the cause, how should responsibility be attributed — to the clinicians or the product?   Without widespread adoption and a national claims database, the prevalence and effects of specific design flaws would have been nearly impossible to determine.

User-related errors that could have been prevented during development may end up being a source of product liability cases as development practices of EHR vendors gain more scrutiny.   Ratwani and colleagues have shown that UCD processes vary greatly among EHR vendors (4). What about development practices for other EHR properties? How well do vendors test for security breaches or evaluate drug interaction algorithms? What data integrity algorithms are used to test data quality? I have a feeling that testing for many aspects of EHR systems mirror the UCD processes.

No one really used EHR systems before 2009, so the numbers were not there to draw attention to safety issues.   Now, with a growing body of evidence that EHR safety issues are real and can cause considerable harm, vendors and health systems are finding themselves in new territory.

EHR systems are everywhere, safety issues and harm are being documented, and attorneys are reading blogs about EHR design. Think I should expect more calls?

  1. Magrabi F, Baker M, Sinha I, Ong MS, Harrison S, Kidd MR, Runciman WB, Coiera E. Clinical safety of England’s national programme for IT: a retrospective analysis of all reported safety events 2005 to 2011. Int J Med Inform. 2015;84:198–206.
  2. Sparnon E, MarellaWM. The role of the electronic health record in patient safety events. Pa Patient Saf Advis. 2012;9:113–121.
  3. Graber ML, Siegal D, Riah H, Johnston D, Kenyon K. Electronic Health Record-Related Events in Medical Malpractice Claims. J Patient Saf. 2015 Nov 6.[E]
  4. Ratwani RM, Fairbanks RJ, Hettinger AZ, Benda NC. Electronic health record usability: analysis of the user-centered design processes of eleven electronic health record vendors. J Am Med Inform Assoc. 2015 Nov;22(6):1179-82.
Facebooktwitterpinterestlinkedinmail

Leave a Comment

{ 0 comments… add one now }

Previous post:

Next post: