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.
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.
Shouldn't even a a busy physician review diagnostic results carefully? Sure, some additional red letters might improve the thing but I think that doctors should review diagnostic information that they receive very carefully. I hope my doc isn't too busy to read my test results thoroughly or at least have them thoroughly reviewed by an equally busy nurse!
ReplyDeleteIT people have to review their specifications carefully and test plans carefully. If not, they are accused of being careless idiots! Why are physicians exempted from being careful and reviewing information completely? Isn't their attention to important details at least some part of why they are compensated so highly?
Shouldn't even a a busy physician review diagnostic results carefully?
ReplyDeleteI think this anonymous person did not review my essay carefully about why basic principles of good interface design are important, and why physicians should not have to be the "human workarounds" to sloppy HCI.
IT people have to review their specifications carefully and test plans carefully
Spin all you want regarding exclusion of such a simple feature, consistent with the basic premises of creating a good user experience and of resilience engineering. Such exclusion is not excusable.
Isn't their attention to important details at least some part of why they are compensated so highly?
Yes, and that's why HIT designers should go out of their way to misdesign HIT, so physicians at 3 AM during a Code Blue can earn their highly paid salary by compensating for crap IT. (/sarc)
Wait until you see parts 4-10 of this series.
Interesting post, I've seen some EHR's if you can call them that, post clinical results like an email. Could you imagine 10 tests a day on a patient and read it like an email thread? I've seen that ridiculous I thought, I wasn't sure how you could read this.
ReplyDeleteAs far as doctors paying attention to the results I agree that example is horrible, from my experience when a doctor see's that a test is FINAL it is FINAL, if there's an addendum it should nicely noted that there is more information to read. These are just failures I've seen day in and day out in HIT.
By the way, I've made a mental note of EMR's that I've worked with where, if I were to walk into my physician's office, and they ran these application's I would walk out and find a new doctor immediately. I'll take my chances without a doctor than a doctor on those applications.
As far as doctors paying attention to the results I agree that example is horrible, from my experience when a doctor see's that a test is FINAL it is FINAL, if there's an addendum it should nicely noted that there is more information to read. These are just failures I've seen day in and day out in HIT.
ReplyDeleteI used the title "Are Health IT Designers, Testers and Purchasers Idiots" as a provocative literary technique not to be taken literally. However, comments like the "Shouldn't even a a busy physician review diagnostic results carefully?" one make me believe perhaps I should use it literally.
What, in fact, is the supposed purpose of HIT? Is it not to make a clinician's workflow easier and reduce error?
If it simply replaces the need for a clinician to "review carefully" paper forms with "reviewing carefully" unflagged scrolling lists of tests on computer screens, then where's the "value added" for the expense and for the transfer of clerical work in data entry from clerical peronnel to the physician?
Idiots indeed.
-- SS
To date, the purpose of HIT was to be able to bill better. Most EHR in the market today are basically large billing machines. Like you're so wonderfully showing, most EHR are completely lacking in usability and forget the most important parts of a doctor's office: patient care and the doctor.
ReplyDeleteI'm looking forward to parts 4-10.
I think the supposition here is that the laboratory system generates an abnormal flag for this result.
ReplyDeleteI suspect that the EHR is just presenting the same report on screen as it would appear on paper.
The laboratory staff should actually call the physician in charge of the patient and report the revised findings. That's what used to happen ...
I am assuming that the data in the graphic is entirely fabricated, and not completely realistic, as the date of the addendum appears to be 2 days earlier than the collection date and 5 days earlier than the 'results' date... ??
ReplyDeleteOr am I missing something/
Having said that - I clearly understand the irony of warning about a lack of warnings!
Eric
The laboratory staff should actually call the physician in charge of the patient and report the revised findings. That's what used to happen ...
ReplyDeleteYes, but the HIT is supposed to reduce error when humans forget to do that. Not be a second tier of error!
I am assuming that the data in the graphic is entirely fabricated, and not completely realistic, as the date of the addendum appears to be 2 days earlier than the collection date and 5 days earlier than the 'results' date... ??
The date of collection of lab #1 was 2/19, result date was 2/22.
The result date of lab report #2 (partially shown at bottom) is 2/17. I forgot a scroll bar.
Having said that - I clearly understand the irony of warning about a lack of warnings!
It's simply not excusable on any grounds in a "live" system. Any excuse would not be on technology grounds but more likely of the "we don't have the resources" or "the vendor has it in the queue", both of which are lame excuses when patients are being put at risk.
The next few screens will show even worse problems. I'm not an artist and they will take more effort, but they are coming soon.
-- SS
There is an old say with computer "garbage in garbage out" It is very likely the EMR is simply displaying what the lab gave them following their protocols, with that said our EMR actually will turn the link to the labs red if there are any abnormals or flags - but because the doc is ultimately responsible and the lab will not dance to the EMRs programmers tune - there is a line between useability and function that requires creativity. We could make the abnormal results come up first but then some docs will say they want it logically by date - more options more visual confusion.
ReplyDeletecheck out Medscribbler - for sanity in design because we use handwriting as a key input
...there is a line between useability and function that requires creativity.
ReplyDeleteAgreed. But a lot of EHR software looks like it was designed by back-end or middleware programmers being asked to double as true UI designers. It does take creativity and experience to balance the various needs and limitations with good usability while keeping the interface effective.
Most HIT would embarrass any skilled UI programmer, even before we start talking about trenchant issues like workflow and frequent interruptions. Investing in a top-notch UI designer or interaction designer with strong HCI/usability grounding should be the de facto standard. And perhaps we should go further: Boeing has human factors engineers on staff; why shouldn’t the person building your doctor’s information “control panel” be as skilled as the one building an airline pilot’s?
Instead it seems HIT vendors release their applications as fast as possible, like kicking baby birds out of the nest, rather than making sure their apps will "fly" right in practice. This might be okay (while not great) for your word processor, but not for life-or-death information aids like HIT apps.
It’s outrageous that HIT vendors can enforce gag rules on their users’ bad experiences with their software, and supposedly can’t be held responsible for causing errors or flat-out misleading clinicians. You can bet Boeing would be. Will it take a mass kill-off of patients to make the point?
I think what the writer of this article is (rightly)trying to convey is that IT is supposed to help the clinician improve the quality of care and help him avoid mistakes (a clinician is human too). Unfortunately some of these badly designed apps do just the opposite. I agree with one of the views that an ergonomist should a mandatory team member to ensure an usable UI.
ReplyDeleteAs an IT professional I can only agree that the current crop of EHR/MHR etc at times add to the likelihood of error. This is form a non USA based reality where the EHR/MHR are supposed to be decision support tools for the clinical staff not revenue generators.
ReplyDeleteTo talk to some of the issues with the Lab results. We had an EHR that did provide warnings, yet there was a result that was inbound of acceptable results limits that was actually dangerous for the patient. No warning so the clinician missed the issue with the result. The clinical board decided to remove warning as it was seen that the system should not do decision support when it was not able to be authority in the way it gave advice.
The UI of the systems are terrible. The issue is simply that the vendors in this space tend to be cottage industry providers that have grown into what they provide. The end point is at time not a very professional output. To change this will need growth in professionalism and basic cost of the systems. The best UI systems have significant cost.
The end point is though, we have to get these systems issues fixed if we are to delivery health care at a affordable and safe price.