Analysis of EHR Errors From Malpractice Claims
William A. Hyman
Professor Emeritus, Biomedical Engineering
Texas A&M University, w-hyman@tamu.edu
Read other articles by this author
A forthcoming article in Patient Safety & Quality Healthcare (now available online) details some findings from a malpractice claims analysis of EHR errors. While a variety of EHR related mishaps are mentioned, two in particular caught my attention.
The first is described as “A patient’s height is 60 inches but it is recorded as 60 centimeters, which distorts her body mass index (BMI)”. It is not made clear if this is a software error or a data entry error. In either case one might note that the use of 60 centimeters distorts more than the BMI, it makes the patient just under 2 feet tall. This would be a great opportunity for an EHR to apply a minimum of date screening support by noting that an adult patient under 2 feet tall could be reasonably described as highly unusual. It should also be possible to compare the current entry with past data, if there is any, to see if a person who is less than 2 feet tall was also that short the last time her height was entered. The BMI calculation offers a similar opportunity since it is going to be low by a noticeable factor of about 85% since the formula is weight divided by height squared. Again the result, while not impossible perhaps, should be worth noting as unusual and a major change from a previous result. Such presumed outliers could be flagged for confirmation, although there is the behavioral risk that when asked, people tend to confirm their work even when it is clearly wrong. The alternative of having the software change things on its own is however not desirable because there is the slight chance that even unusual entries are correct. Another challenge is where to draw the flag line. If a 2 foot tall adult is unlikely, what about 3? What about 4? Perhaps the EHR could also “learn” that a person is in fact an outlier, and stop flagging at some point.
The second anecdote that interested me was: “The data is entered correctly, but the computer auto-converts it without the user noticing. For example, 2.5 changes to 25, which becomes a medication error when a clinician acts on the higher number.” This seems to mean that the software ignored the decimal point even though it was typed, which makes this some interesting programming. It is not explained what the variable was or why the computer converted it. Nor was it explained if the software always does this, or if some unique collection of circumstances occurred in the case of interest. Regardless, here the value is off by a factor of ten, as compared to that above which was 2.5 (until you square it to get BMI). For what variables is there a reasonably expected range that varies over a factor of ten? What was the resulting medication error? Was the dosage 1/10th of what it should be, or 10 times? Or was the error even more? Wouldn’t this be noticeable, if someone were bothering to notice? This situation again suggests that automatic screening for an unusual value could be a helpful EHR utility, subject to the limitations noted above. A non-EHR example of this is that some infusion pumps have library values against which a manually entered dose is compared. If the dose is outside the expected range the user is notified and asked for additional confirmation. This sounds easy enough, but among the challenges is that for some drugs the library has to be adjusted for type of patient, and kept up-to-date.
It is no surprise that software can create some unusual data and data processing either because of fundamental programming flaws, or erroneous entries and inadequate error filtering. This suggests that some good old fashioned checking of one’s work is always in order (assuming the value the system has clearly displayed), as well as users applying some logical thinking to the input and the results. Of course it would be far better if the software didn’t do things such as those described.