A Usability Conundrum: Whether it is EHRs or Hospital Gowns, One Size Never Fits All…

by Jerome Carter on September 21, 2015 · 6 comments

Building clinical care systems that intimately support clinical work has to begin with the acknowledgement that clinicians perform many tasks within the context of a patient encounter, and those tasks very in type, number, and sequence.   Everyone knows this. So, one might ask, if this is common knowledge, why are there so many problems with EHR usability? The answer is very simple.   EHR systems are designed to be one-size-fits-all.

One-size-fits-all (OSFA) is such a fundamental precept of EHR design that no one even questions it.   Instead, there is a pursuit of every possible means of fixing EHR systems, while allowing them to remain OSFA. Why? Because it is a design assumption carried over from past software design/development limitations.   Achieving the highest possible level of usability requires dumping deeply-ingrained OSFA thinking.

How did OSFA become so entrenched in EHR designs? Here are the main reasons.

Poor choice of design metaphor
Paper charts are the inspiration for current EHR systems.   Charts are OSFA. No clinician was allowed to customize the chart to fit his/her personal work habits or information needs. Every hospital or practice has strict rules about chart organization and use. There are legal rules that dictate how charts must be stored and what they must contain. There is an entire profession dedicated to charts. Charts are designed to be standardized information repositories; they are not designed to aid in care delivery. Paper charts are a means to an end, and I have never heard anyone gush over how wonderful a paper chart was or how it made their lives so much better. However, since paper charts are (were) a fact of life, one simply adapted to them, like it or not.

Skeuomorphism
Real world objects are relatively immutable, software isn’t. However, when real-world objects are used as a basis for software designs, there is a tendency to forget software has different limitations. When one looks at real world objects – cars, houses, luggage – anything really, what is seen rarely can be changed once it is built. As a result, no one expects a car to adapt to his/her height.   If you are 6’6”, you buy a big car; at 4’ 11”, a small car makes sense. Furniture is bought in the desired finish and color because no one expects to able to make significant changes later.

When patient charts became electronic, they brought the look and feel/behavior of the paper chart to a new medium.   Paper charts do not have explicit support for processes and neither do EHR systems. No clinician expects to have a custom paper chart and the same holds for electronic systems, but why? Why can’t a system made essentially of electron states of 0 or 1 adjust to each user? There is no reason aside from the OSFA mindset.

Failure to separate out personal from group and institutional workflows
I have yet to see an EHR advertisement that does not say the product supports clinician workflows.   However, as I have learned in reading clinical workflow research from different domains, the notion of what “workflow” is varies greatly (see Workflows with Friends…). It is a term that is both widely-used and widely-confused. Workflows are a series of tasks that accomplish some goal. Tasks consume and produce information and require resources.

Workflows come in different types.   They may be group-based or personal (see Preventing Your EHR from Working Against You, Part II: Personal Workflow Analysis). Group workflows describe how work moves from one person/role/location to the next. These are essentially handoffs. Handoffs can be standardized without much trouble because the information and rules for moving work across boundaries is relatively easy to set because the handoff represents a completed set of tasks at each boundary. A clerk passes a patient on to a nurse who passes the patient on to the doctor. At each handoff, the information and patient state required by the receiver can be verified prior to the workflow continuing. Group workflows are the most widely studied, and most discussions tacitly make use of group workflow notions.

Personal workflows have not been widely studied, though human factors researchers are changing this.   Personal workflows are very much based on personal work habits, which means they vary widely from person to person.   In the era of paper charts, I used a detailed template to capture information during patient encounters.   I also tended to look up information frequently. At the end of a clinic session, I either wrote or dictated full notes from the template. Conversely, I had colleagues who wrote notes before the patient left the exam room while others dictated in front of the patient. Everyone did what was most comfortable—that was the good thing about paper; it did not enforce a specific task sequence.

Electronic systems are more restrictive, and since they are designed with specific task sequences in mind (implicit workflows), they can be disruptive to clinicians’ personal workflows. Personal workflows must be taken into account when designing electronic systems. And here, we begin to see the OSFA problem.

A recent paper by Holman et al., The Myth of Standardized Workflow in Primary Care confirms the variation in task sequences among primary care providers.  The authors make the following observations and suggestions.

EHRs have been widely adopted in clinical settings in the hope of providing more efficient, more effective, and safer patient care as well as more patient-centered care, but, to date, they have not performed as anticipated. Most EHRs are organized on the assumption that physician workflows are linear or standardized or relate to a single problem, and, therefore, EHRs do not facilitate workflows that are more personalized and unpredictable. As healthcare moves forward and builds systems such as the Patient-Centered Medical Home, the tools that clinicians use, including EHRs, must support such systems. Hence, to begin bridging the gap in knowledge between healthcare professionals and non-healthcare professionals who design, modify, create, or manage tools or systems for providers, we recommend expanding the traditional grounded approach by have EHR/HIT system designers observe healthcare professionals doing their work, which would include a discussion about why the approach for the same task was different for one patient compared to another.

Yes, clinical work is situational and non-linear – a statement of the obvious. Yes, closer work between designers and clinicians would be helpful as well. However, the bigger problem is OSFA thinking and more interaction and observation won’t fix that. OSFA thinking has to go as well.

Lack of explicit process representation and support in EHR designs
If the goal is providing clinicians with EHR systems that adjust to their personal work habits, then obviously, the software has to be adjustable. At a minimum, process support and the user interface are two the EHR components that MUST be adjustable to allow for personal customization.   Now here is where user-centered design (UCD) and usability initiatives eventually run into problems.  If the user interface AND process support are NOT personally customizable, then the underlying EHR system is necessarily OSFA.   UCD and usability testing can only improve OSFA systems but so much before hitting a wall. This is an inescapable fact.

Clearly, building clinical care systems that support personal and group workflows requires a complete rethinking of the underlying architecture and design assumptions of current EHR systems.   There is also an additional problem: development tools are required that support explicit representation and manipulation of processes.

Wrong development tools
Explicit process support requires a workflow engine and a workflow programming language. Using workflow technology (BPM suite) allows for process support to be represented visually and executed programmatically. Group workflows can be encoded with rules for boundary handoffs and, ideally, personal workflows could be created and adjusted as desired. I am not advocating that, for example, every primary care provider (PCP) be given a set of standard primacy care tasks. While PCPs have a finite set of tasks that they all perform, when, why, and how they do them varies. Thus, I am suggesting that those tasks should be made explicit using BPM technology and that PCPs should choose the level of task support desired by adjusting their user profiles.

For example, once within the span of two weeks, I had 10 or so patients with microscopic hematuria (MH).   After making sure the lab had not been providing spurious results, I created a list of these patients and followed a protocol for their follow-up.   It would have great to be able to create a workflow protocol for MH that tracked lab results, consults, visits, and sent me notifications as the patient progressed through the protocol. That would have made my life much better.

As more workflow research appears and the calls for usability testing and UCD grow, let’s keep in mind that current EHR systems are one-size-fits-all. Moving to systems that better support clinicians requires fundamental changes in architecture and other aspects of EHR design. Otherwise, the outcomes of UCD and usability interventions will not live up to expectations.   Think about it. Can you think of any example where one size really does fit all???

Facebooktwitterpinterestlinkedinmail

Leave a Comment

{ 6 comments… read them below or add one }

Adam Bazer October 6, 2015 at 10:54 AM

Great post, Jerome! Your insights around how design metaphors effect the development & usage of a product are spot on. To move from a literal paper chart to a metaphorical one helps the design issues around paper charts migrate along with everything else into software solution.

If you were designing an EHR from scratch, without the paper chart metaphor, what design metaphor would you consider?

Reply

Jerome Carter October 6, 2015 at 7:50 PM

I would use processes. The chart metaphor relies on providing information as the main aid to supporting care. However, care happens in the form of processes that consume/produce information. Processes are implicit in EHR designs, and I would make those processes explicit by way of a workflow engine. The other major changes would be decoupling the UI and making it user configurable and creating an information model that would mange data accesses and storage. I would make the information model public.

Reply

Charles Dinerstein September 24, 2015 at 5:42 AM

I certainly agree with your assessment. I found that even trying to re-present laboratory information based upon specialist’s interests is impossible so patient views are also fixed. Assuming that a more customizable system existed how do you foresee an individual clinician making the changes they wanted. Using a ‘preference system’ which I would think still have components of central design or a system that learns your interests as you use it?

Reply

Jerome Carter September 24, 2015 at 9:08 PM

Hi Charles, thanks for your comment. Preferences would be a starting point. A system where the UI was completely decoupled from the underlying system (Model-View_Controller) would allow this to some extent. The main problem is that EHR systems are designed around the idea that all patient data should be exposed at all times, which is not how most clinicians work. No matter what, getting more usable systems requires a fundamental redesign.

Reply

Clyde Bailey September 21, 2015 at 9:37 AM

A couple of thoughts:
1. True, truly customized forms are not happening, however, it is possible for a clinician to be allowed to decide which form(s) to use in a particular circumstance allowing a certain amount of flexibility. I have also seen semi-customization where a form is partially filled out for a common situation, photocopied, and then only the stuff that us really unique to the situation needs to be filled out for a particular patient. Doing the equivalent of that in a typical EMR is more of a project.
2. I am struck by the similarity in concept between picking what forms need to be filled out in a situation and “SOA”. We need to capitalize on this.

Reply

Jerome Carter September 21, 2015 at 2:32 PM

Clyde, thanks for your comment. The constraints faced by users are very much due to specific design decisions. Allowing for end-user adjustments will be a major feature of generation systems. The similarity to SOA is an interesting notion…

Reply

Previous post:

Next post: