(Note: Part 1 of this series 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. 2011 addendums: a post that can be considered part 9 is here, part 10 is here.)
Electronic health records, or electronic death records?
In this fourth installment of a series whose subtitle could well be "hospitals are paying tens of millions of dollars to healthcare IT (HIT) companies for clinical IT designed as if by rank amateurs, while shortchanging the poor and uninsured", we see yet more screens that create a mission hostile user experience to physicians, nurses and other clinicians trying to take care of patients.
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.
Perhaps part of the problem is the contractual lack of vendor accountability for bad patient outcomes resulting from defects (i.e., as if "learned intermediaries" have unlimited cognitive energy to deal with a poor user experience), and contractual gag orders on sharing actual screen shots. This forces me to draw mock ups to illustrate the problems.
I am aware of major medical centers with lists of HIT user experience problems in recently acquired systems that are 100+ pages long. What percentage of these issues present possible patient risk is not known to me, but I will venture that it is a considerable percentage. Who is designing such medical devices? Who is testing these devices before release for use on patients?
Here is my next mockup. This is of a patient medication list from an HIT system from a major vendor:
The user experience good practices violations that are committed here are numerous and inexcusable.
There is repetition, extraneous information, lack of focus and clarity, lack of any symbolic or diagrammatic representations, and general clutter.
When I write that HIT is designed by business computing personnel as if it were an inventory system, not a clinical device, this exemplifies what I mean.
Imagine clinicians forced to perform their work via screens like this on many patients, each day, day in and day out, and having to make critical decisions on medication orders based upon them. Imagine an on-call physician at 3 in the morning, with more admissions in the ED, interacting with ill conceived screens like this. Madness.
Remember, the purpose of HIT is to facilitate clinicians, not tire them and make them drink information from a firehose.
It would not have been difficult to condense and organize this presentation into a coherent, focused display that could be used at a glance by a clinician to understand a patient's medication profile.
A competent grad student or informatics postdoc in could design such a screen. I know that, because I helped postdocs do such things.
Now, how about screens that force clinicians to resort to use of physical digits instead of virtual ones - i.e., their fingers! - to keep track of what's what?
See this labs viewing screen (note: values and ranges are fictitious)
The clinician user now scrolls to the right and down to see more values and sees this:
Note the row and column headers have scrolled away. The user must hold a finger on the screen to keep track of headings. It is not too diffcult to imagine mistaking one test's value for another.
The amount of coding it would take to maintain fixed row and column headers is far less than the amount of cognitive effort clinicians must expend to use such screens. It is certainly less than the efforts spent in making amends for unfortunate patient outcomes such philistine and mission-hostile IT devices create. Such design problems are inexcusable on prototypes, let alone production systems.
Where are our government watchdogs on these issues?
More violations of simple first principles of providing a good user experience in part 5.