(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.
-- SS
OMG...it's ...it's ...it's terrible. Had a hard time trying to find the right word.
ReplyDeleteI think if vendors and their programming, designers, etc. for EMR software followed the activities of clinicians for a day, at least, they might have understood the NEEDS of clinicians, and designed their systems accordingly.
As a former technology exec, and now an RN, I can say, with certainty, that if the programmers and technical staff responsible for developing a system don't have a solid understanding of the problems that clinicians face each day, the end result may NOT be sufficient.
It's unfortunate because I believe EHRs, if designed properly, can not only eliminate the inefficient use of paper, but can provide a more comprehensive view of the patient's medical condition. My theory is this...better information = better decisions = better outcomes.
It's unfortunate because I believe EHRs, if designed properly, can not only eliminate the inefficient use of paper, but can provide a more comprehensive view of the patient's medical condition. My theory is this...better information = better decisions = better outcomes.
ReplyDeleteI completely agree, and have actually done so, see my bio.
-- SS
These examples are so bad, I can't believe they are from more than one really bad EMR. As a CEO of an EMR - I purposely do not look at other products to avoid design problems and possible conflict in courts.
ReplyDeleteSometimes scrolling is almost unavoidable - especially as information is being dynamically created to a page but never should info be "lost" like the example and if it is unavoidable there are tools like "full screen" "view %" "landscape/portrait" etc that can be added.
Medscribbler includes these tools. Plus the example is even worse because there are no flagging, sorting or refill from the list functions.
CEO Mike wrote:
ReplyDeleteAs a CEO of an EMR - I purposely do not look at other products to avoid design problems and possible conflict in courts.
Very interesting.
Trade secrets aside, an industry that does not look at the work others are doing is both intellectually backwaters and nonscientific. Cross-fertilization of ideas is central to scientific creativity. I thought competitive intelligence was central to industry practice as well.
Imagine pharma whose researchers pay no attention to the world's literature.
This is how R&D creates the best products and avoids paths others have taken that have proven to be a failure - or dangerous.
As former Director of Scientific Information Resources at a major pharma, I speak with authority on the value of this philosophy.
I'm really enjoying your article(s), and appreciate your frustration... what I don't understand is the misdirected rage at the actual programmers. Programmers build systems to specifications. Seems like you moved into your new house and hate the layout so you are furious at the construction workers.
ReplyDeleteAlso, its an important distinction you make about which bugs can lead to patient harm... in the case where you have 100 pages of bugs in your bug tracker and limited resources to devote. Can the user entering the bug into the bug tracker specify "Potential for Patient Harm"?