Sunday, February 22, 2009

Are Health IT Designers, Testers and Purchasers Trying to Harm Patients? Part 2 of a Series

(Note: Part 1 is here, part 2 is here, part 3 is here, part 4 is here, part 5 is here, part 6 is here, part 7 is here, and part 8 is here.)

At the (deliberately) provocatively-titled piece "Are Health IT Designers, Testers and Purchasers Trying to Harm Patients? Part 1", I wrote that I would be presenting mockups showing the EHR deficiencies I am hearing about. These deficiencies in basic human computer interaction, biomedical information science, and presentation of information create a terrible user experience for clinicians.

The title of these posts are deliberately provocative because the stakes of the issues addressed are so high, not to mention a personal angle. My father died as a result of informational errors at a major hospital that could have been prevented with an effective EHR. They are dedicated to his memory.

These hellish user experiences are causing clinician cognitive overload, distracting and tiring them, and due to violations of fundamental good practices in information display, actually promoting error.

These violations are primarily due to lack of clinician input at design, sluggish vendor correction of reported critical deficits, programmer convenience, contractual gagging of a healthcare organization's ability to share these defects with other users and the public at large, and vendor immunity from liability on the basis of "learned intermediaries" (clinicians) between the defective IT and the patient.

Imagine if aviation worked this way. Imagine if the crash of the Continental Connection Flight 3407 had been due to defective instrumentation as suggested by the pilot's union.

I cannot present actual screen shots of vendor EHR defects, since the vendor contracts forbid that on the basis of intellectual property protection. However, I am drawing mockups to substantially illustrate the problems I am hearing about.

I am starting off with a relatively simple example. Many more will follow in future parts of this series.

This one can be called "Warning, no warnings" and reflects two problems I've heard about rolled into one:


(WARNING! No warnings! Click to enlarge)


This is a fictional representation of a screen from an actual major vendor EHR in use at many large hospitals in this country today.

Note the following:

  • A warning that there are no warnings about abnormal results. "Please review all results carefully, there are no indicator flags" - in 2009?
  • A results section that says "negative" and "results final." Most busy clinicians' eyes would stop there, especially in the wee hours as this report is from.
  • An addendum to the report that the result is actually positive for MRSA, one of the most feared drug resistant pathogens today. In labs and diagnostic departments, a change from an initial impression or result happens. Unfortunately most EMR's do not support the old style method of erasure, or crossing out erroneous data with a pencil!
  • No flag on that addendum of any kind, although at the lab at the point of data entry, a flag was requested and seen by the reporting technician!

The lack of a flag to signal an abnormal result saves a vendor the inclusion and interface of 1 binary bit of information (well, to be fair, 8 bits or one byte, practically speaking) in computers and networks that even at consumer grade can now pass millions of bits/second, and the contents of an entire encyclopedia in milliseconds.

This is sheer stupidity. (It reminds me of the Y2K issue.)

It's bad enough that the clinician is forced to hunt around every result for an indication of normalcy or abnormalcy.

Even worse, there is a disparity between what is seen at the lab - a flag calling attention to an abnormal addendum - and what is seen in the clinician view.

While a fictitious screen, this is not a fictitious example. This type of incident (I say 'type', as the specifics of the patient's condition were different) occurred to a patient whose treatment was in fact delayed until someone more than 24 hours later noticed the addendum. The patient's ultimate fate was not reported to me.

Even still, the leaders at the organization using this EHR are considering adding a report about this flaw to the regular queue of vendor fixes, rather than taking immediate, definitive "FIX THIS, NOW!" action.

This is despite the common sense view that if this happens again before a fix and a patient is harmed or dies, the hospital system will be held seriously accountable for the delays, and IT personnel will likely be on the stand. (The vendor, of course, gets held harmless.)

Imagine a jury's reaction: CIO - "uh, we didn't think the problem all that serious, and didn't have the resources to fix it right away, but we did call the vendor who said they'd attend to it one day real soon."

I can also put blame on the physicians for their physicians' learned helplessness - trying to muddle through their work with such a system, rather than refusing to use them in this condition. Or simply (in the manner of an old time surgeon I once rounded with in a summer NSF program for high school students) picking up the terminals and smashing them as the potentially dangerous junk they are.

One could blame the doctors for not reading below the "negative, results final" mark, but why should that be needed? Why is it the responsibility of the extremely busy physicians and other clinicians to provide their extra labor for the convenience of IT and IT vendors? Would a jury hold the clinicians accountable, seeing this display?

Would an aircraft manufacturer get away with blaming a pilot for an accident caused by horrible user interaction design of a plane's instrument displays, say, a hard to find stall warning that lacked flags or audible alerts?

It is unbelievable to me that a system like this could be put into production in a hospital. Simply unfathomable.

If I am involved as an expert witness in such cases, I will be sure to have the plaintiff attorneys ask the IT personnel about their clinical credentials.

This system was CCHIT "certified", I am told. Of what value is "certification" if it allows this type of design issue, and others to follow in future installments, on to the market?

More screens in part 3 of this series. It gets worse.

Far worse.

(Part 1 of this series is here and
Part 3 is here).

-- SS

addendum:

Some have complained I am being "politically incorrect." At a time when our banks, major industries, investments, lifestyle and retirements have been seriously eroded by a combination of secrecy, incompetence, and criminal behavior on an unprecedented scale, I think such people need to get their priorities in order.

No comments:

Post a Comment