A big thanks to L-J Cunningham (@UXforHealth) for tweeting out this really cool time lapse video that shows SoftServe‘s work doing the UX design for the mEMR application. While the process they use is really cool to watch, it’s also interesting to see what a mobile EHR UI could look like.
Psst. Hey, Buddy, wanna see an EHR, visit’s workflow? Here it is, thanks to the National Institutes of Standards and Technology’s (NIST) new report, NISTIR 7988, Integrating Electronic Health Records into Clinical Workflow, etc.
NIST wants to make EHRs usable and useful. It first took aim at patient safety EHR functions that endangered, confused users or were error prone. To counter these, it developed and recommended EHR usability protocols.
Now, in an extensive report, it’s tackled EHR workflow to determine where problems occur. The result is a comprehensive work with significant findings and recommendations. The question is: Is anyone listening?
NIST’s Analytical Approach
NIST decided to create a typical workflow by interviewing knowledgeable physicians, who it calls Subject Matter Experts, SMEs. The physicians had different specialties and used different EHRs, though who they were, NIST doesn’t say.
From their discussions, NIST’s analysts created the above chart, NIST’s Figure 2. NIST’s authors recognize that actual workflows will vary based on setting, sequences, staffing, etc., but that it provides a useful way to look at these issues.
What They Did With It
Working with their physicians, NIST’s analysts broke down the workflow into three sections: before, during and after the visit. Then, they broke down, or decomposed, each of those sections, like opening nested Russian dolls. For example, they segmented the physician’s encounter, below, and once again, broke each down into its functions.
It was at this stage the analysts found significant variations among the EHRs used by their physicians,
[T]here appeared to be high variation in whether and how the EHR was used during this period, how extensive each of the activities typically were for each SME, different based upon the type of patient, how complex the patient was, context of how busy the day was, and other factors. NSTIR 7988, p 18.
Despite these differences, the physicians identified two issues that crossed their EHRs:
- Working Diagnoses. The physicians wanted systems that let them create a working diagnosis and modify it as they worked until they made a final diagnosis. Similarly, they wanted to be able to back up and make changes as needed, something current systems make hard.
- Multiple Diagnoses. Diagnoses usually involve multiple causes, not single factors. They wanted their EHRs to support this.
These types of issues aren’t new to those familiar with EHR problems. What’s new is NIST, as an independent, scientific organization, defining, cataloguing and explaining them and their consequences.
What They Recommended
From this work, NIST’s analysts developed extensive and persuasive recommendations, in three categories:
- EHR Functions
- System Settings, and
- System Supports
NIST’s recommends reducing practitioner workload, while increasing their options and supports. For example, they suggest:
- Workload Projections. Give practitioners a way to see their patient workloads in advance, so they can plan their work more effectively
- Notes to Self. Let users create reminder notes about upcoming visit issues or to highlight significant ,patient information. These would be analogous to their hand written notes they used to put on paper charts.
- Single Page Summaries. Create single page labs summaries rather than making users plow through long reports for new information.
- Single Page Discharge Summaries. Eliminate excessive boiler plate with more intelligent and useful discharge sheets.
- Highlight Time Critical Information. Segregate time critical information. Often they get mixed in with other notices where they may be overlooked or hard to find.
- Allow Time Pressure Overrides. When time is critical, EHRs should allow skipping certain functions.
- System Settings
NIST recommendations echo the familiar litany of issues that characterize poor implementations:
- Allow Patient Eye Contact. Exam room designs should put the doctor and patient in a comfortable, direct relationship with the computer as a support.
- Login Simplification. Allow continuous logins or otherwise cut down on constant login and outs.
The physicians recognized they often caused workflow bottlenecks. NIST recommended off loading work to medical assistants, nurse practitioners, physician assistants, etc.. For example, physician assistants could draft predicted orders for routine situations for the physician to review and approve.
Progress Note Frustrations
In the thorny area of clinical documentation, the report details physician frustration with their EHRs. All experienced excessive or missing options, click option hell, excessive output, puzzling terms, etc. These were compounded by time consuming system steps that did not aid in diagnosis or solving patient problems. The report discusses their attempts at improving documentation:
Several of the SMEs had attempted and then abandoned strategies to increase the efficiency of documentation. One SME reported that copying and pasting and “smart text” where typing commands generate auto-text had a “vigilance problem.” The issue was that it would be too easy to put the wrong or outdated information in or in the wrong place and not detect it, and then someone later, including himself, could act on it not realizing that it was incorrect.
One physician described an attempt to use automated speech recognition for dictation for a patient with scleritis, which is inflammation of the white of the eye. He stopped using the software when what was documented in the note was “squirrel actress.”
Another SME described that colleagues relied upon medical assistants to draft the note and then completed it, but they did not like that approach because it was too tempting to rely upon what was typed without reviewing it, and he felt the medical knowledge level was not high enough for this task.
One SME described a reluctance to use any scribe, including a medical student, because the risk would be too high of misunderstanding and thus not correctly documenting the historical information, diagnosis, and treatment plan. This was particularly problematic if the physician had information from prior visits, which contributed to these elements, which were not discussed in detail during the visit. NSTIR 7988, p. 28
Coding their diagnoses into progress notes also came in for criticism:
All SMEs described frustration with requirements to enter information into progress notes, …, which were applied to the notes in order to have sufficient justification to receive reimbursement for services. Although all of the SMEs acknowledged the central importance of receiving reimbursement in order to function as a business, this information was often not important for clinical needs. NSTIR 7988, p. 28
Role Based Progress Note
Unlike other areas of the report, the doctors could not agree on what to do, nor does NIST offer any specific cures for documentation problems. Instead, NIST recommends using a new, role based, progress note:
[T]he progress note for a primary care physician would have a different view from a specialist such as a urologist physician, who might not need to see all of the information displayed to the primary care physician. Similarly, the view of the note for primary care providers could differ from the view of a billing and coding specialist. … NSTIR 7988, p. 28
Will ONC Respond?
In this and its prior reports, NIST covers a lot of EHR issues making sensible recommendations that not only improve functionality, but more importantly improve patient safety. However, NIST’s recommendations are just that. It’s not a regulatory agency, nor is supposed to be one. Instead, its role is to work with industry and experts to develop usable, practical approaches to tough technical, often safety related, problems. To its credit, it’s done this in a vast number of fields from airplane cockpits, nuclear reactors, and atomic clocks to bullet proof vests.
However, its EHR actions have not gained any noticeable traction. If any EHR vendor has implemented NIST’s usability protocols, they haven’t said so. They are not alone.
Notably ONC, one of NIST’s major EHR partners, refuses to incorporate any of NIST’s usability recommendations. Instead, ONC requires vendors to implement User Centered Design, but does not define it, letting each vendor do that for themselves.
NIST has many answers to common EHR workflow and usability problems. The question is, who will bring them to bear?
Editor’s Note: A big welcome to Carl as a writer on EMR and EHR. He’s been writing guest posts across the Healthcare Scene network for many years, but we’re happy to have him now writing formally on EMR and EHR. You’ll be able to read all of Carl’s past and present posts on EMR and EHR here.
Sometimes it seems that EHRs and usability are like Earth and Mars. Their orbits get relatively close, but they’re never going to occupy the same place and time.
Of course, the two we’re occupied with aren’t cosmic equals. EHRs are specific systems, while usability is, at best, a concept with various definitions. In fact, the closer you get to a definition of usability the less focused it becomes. My late brother used to call things like that, “Far aways.” “The farther away you get the better they look.”
Indeed, most definitions of usability say it’s something that’s useful. Ugh. So, is there any way to bring some clarity to its definition, so it has greater precision?
Doing so, I think, requires not only defining what usability is, but also tackling when it’s not present what’s wrong.
Usability: A Different Definition Approach
Most definitions of usability I’ve seen push the issue off onto use or useful. That is, usability is defined as something that is useable. This isn’t far from using a word to define itself, which was a grammar school no no. It also fails to involve the user’s expectation. I would define it this way:
Usability is the ability of a system to supply a desired result with the minimum necessary information, conditions or steps.
This definition hinges on a user getting what they want expeditiously. Simply put, usability means no unneeded fuss or feathers. As I look at it, usability is to systems what parsimony is to logic. In logic, the simplest explanation that explains the occurrence is the best. Similarly, the most usable system is the one that requires the least effort to supply the correct response.
User Hostile Systems
If I left matters at this juncture, however, I wouldn’t have addressed a major related issue. When a system is user hostile, just where has it gone wrong. Each of us has experienced or heard these tales. You make a simple request and wind up in wilderness of documentation or your options are have everything but what you want.
These are negative examples of usability. It is, however, not enough to just stamp them as such and move on. It’s also important to say exactly where usability fails. To get a handle on these issues, I divide them into three classes:
Class One: Bug. Generally, a computer or software bug is anything that caused a wrong or unexpected response. I take a narrower view. To me, a bug represents a properly designed system that’s incorrectly implemented. That is, the program code fails to carry out the system designer’s intent. For example, you click Print and the system emails your Aunt Edna.
Class Two: Design Failure. In these, the code is OK, but the requirements failed. The classic refrain for these is, “ Yes, that‘s what I asked for, but it isn’t what I wanted.” Fixing these, unlike bugs, requires correcting the requirements and conforming the code.
Class Three: Missing Requirement. Sherlock Holmes in the Silver Blaze mystery had this to say about EHR usability:
“Is there any point to which you would wish to draw my attention?” “To the curious incident of the dog in the night-time.” “The dog did nothing in the night-time.” “That was the curious incident,” remarked Sherlock Holmes.
Nothing is less usable than something that doesn’t exist. It’s not a matter of getting wrong. It’s a matter of not getting it at all.
What makes this a difficult category to apply is the issue of user need. What some users think is fundamental, others may regard as a frill or not necessary at all. Usability, therefore, hinges on neither design nor programming but on policy. However, if policy deems the function important, then its omission is far more serious than the other two categories.
An example. I use a large practice associated with a local medical school. It uses Jardogs’ Followmyhealth (FMH) web portal. It conveniently combines PHR, email and scheduling. I especially like being able to email my PCP. Recently, however, I ran into a class three problem.
FMH lists my PCP and any other of my providers. My PCP suggested I see a specialist for a problem. I went to FMH to find a list of specialists and phone numbers. I got nowhere. I could remove a provider, but not find a new one. I searched FMH’s knowledge base for provider and got 40 hits, but nothing on finding one. I then went through the FMH Patient Guide again without luck. Frustrated, I left the system and went to the practice’s public web site. It had the list. I found the department and number I wanted. Once I got set up, the new provider appeared in FMH.
Wondering if I had missed something, I called support with the problem. The support rep spent several minutes, came back, and confirmed that it could not be done, which surprised him. He agreed they should at least have a link in FMH to search for providers. Whether FMH adds it, of course, is a policy question.
Ideally, EHRs make the clinical exams more efficient and effective, ultimately saving or even making more money for medical practices. But the reality is that they bypass other parts of the patient encounter where much of the costs and inefficiencies are generated, according to a whitepaper by athenahealth, “The Economics of Patient Workflow: Cracking the Code of Successful EHR Design.”
As the paper notes, 100 percent of practice revenue is generated by the patient exam. Other stages of managing a practice, such as orders and results management, generate 30 percent to 40 percent of costs but no revenue at all. So having an EHR in place which does little to improve exam efficiency — or actually reduces it — is a dangerous thing to do to a practice.
Worse, as the paper points out, there are some major flaws with typical, software-based EHRs:
* They’re too expensive: Typical cost is $33,000 per physician plus $1,500 per doctor per month for maintenance.
* They don’t save money because they slow doctors down: Most EHRs force physicians to do a lot of data entry, much in time-consuming, structured formats.
* They aren’t designed to manage the P4P cycle seamlessly: With most EHRs, doctors have to dig out the data needed to create pay for performance reports.
* They usually don’t offer an efficient, closed-loop solution to the problem of monitoring paper and electronic orders and results: Remember, orders and result management generates as much as 40 percent of practice expenses. EHRs’ failure to make such tracking efficient is a major obstacle for medical practices.
* Few EHRs support follow-up work from orders and results effectively: Most EHRs don’t include built-in management and tracking of patient communications, forcing providers to do inefficient and potentially risky manual follow-up.
The white paper goes on to make the argument that there are several reasons why Web-based EHRs solve these problems, largely by requiring no up front cost, using up less physician time on data entry, optimizing collection of data for P4P programs, digitizing all paperwork and tracking practice results.
I want to take a look at the complaint I hear over and over and over again when it comes to EHR software. I’ve heard this comment said about every single EHR vendor out there. I’ve also heard it from doctors in every specialty and from every size organization. It comes in a few different forms, but all communicates the same idea. This is the doctor complaint I’m talking about:
Did the EHR vendor even talk to a practicing doctor when they developed this EHR?
Yes, the complaint is usually voiced as a question, but the question is lathered up with an unbelievable shock that an EHR vendor could misunderstand a doctor’s workflow needs so terribly. Plus, it’s reinforced with the belief that if the EHR vendor had somehow just talked to a doctor, any doctor, that this wouldn’t be the result.
Of course, the situation is much more complicated than that statement supposes. In fact, there’s a great thread on the HIMSS LinkedIn group that has a bunch of deep discussion on how to create a healthy partnership between providers and EHR companies.
One key to understanding this relationship is first that every single EHR company has consulted doctors (usually many many doctors) in the development of their EHR software.
Many doctors will then wonder how they could have an experience like the one I described above if the EHR vendor consulted a practicing doctor (and I assure you many many doctors have had the experience above). The answer to that question has multiple layers. The first layer that most practicing doctors see is that “most doctors that consult EHR companies aren’t really practicing doctors.” In many cases, this is definitely the case. Many Chief Medical Officers at EHR companies have made EHR their full time job and no longer practice medicine. Many physician founded EHR companies have a physician leading the company that no longer practices medicine. Certainly some portion of the EHR workflow disconnect could be related to non-practicing providers driving the EHR development process, but that’s just one layer.
The second layer is that in every case I’ve seen there’s always been practicing providers involved in the EHR development process as well. They are active in user groups. They sit in focus groups. EHR vendors go to the practicing physician’s office to learn from them first hand. Most EHR companies really do make a sincere effort to understand the practicing physicians and not just try and guess at what the practicing physicians want.
Another layer to this problem is translating what the practicing physician requests into the EHR workflow. Now imagine that two practicing physicians request the polar opposite feature (yes, this happens a lot too). How then do you translate that feature into something that’s going to satisfy both physicians. That’s not an easy thing to accomplish.
The next challenge to consider is that many physicians aren’t technically astute enough to know what they want. When this is the case, they don’t know what they should even be asking for. I’m sure many doctors will scoff at this idea, but it’s the same concept for programmers. Many programmers aren’t technically astute enough to understand the medical world well enough to develop what the doctor wants. It’s a two way street and is why it’s so important for EHR companies to create an amazing collaboration between the right doctors and the right programmers. That’s a special breed of person that is not easily found.
Of course, I haven’t even mentioned the specialty layer. A technically astute practicing physician in cardiology will likely do a terrible job designing an EHR workflow that works well for pediatrics, OB, and general medicine. If you thought it was hard creating an EHR workflow that works for all the doctors in one specialty, now try and do that across 40+ medical specialties.
If you remember back to the paper chart world (which many of you are still living in), how come we didn’t have a standard paper form that every doctor used to document the visit? In fact, it was pretty rare that any 2 non-affiliated clinics used the same form at all. Sure, some forms were exchanged at the medical societies, but in most cases each clinic wanted to modify the form to fit their own clinic’s needs and desires. This happens in the EMR world to some extent, but it takes more training and skill to modify an EHR workflow than the Word document you got from your colleague. Plus, many don’t want to invest the time to make those modifications.
I’m not trying to put the blame for this on anyone in particular. Plus, I don’t want to make this sound like an excuse for EHR vendors to be lazy in how they approach their EHR development. We can be sure that some of the issues I describe above aren’t because the doctors didn’t provide good requirements and not because the programmer didn’t know how to meet those requirements. Some of the problems we see have to do with a combination of rushed release times or lazy programming (which are related). When this is the case, EHR vendors should take it on the chin and deal with the issues rather than trying to blame someone else.
With that said, hopefully I’ve made clear that it’s not enough for an EHR vendor to just consult a practicing physician. If that was the case, then all 300+ EHR companies would have beautifully designed EHRs that physicians’ love. Instead, I think the fact that so many of the 300+ EHR vendors have this issue, it illustrates how hard it is to get a technically astute practicing physician that can get programmers to make a beautiful interface that applies across all specialties.
From now on, I hope to hear physicians who have this problem change their question to, “Did the EHR vendor even talk to a technically astute practicing doctor in my specialty that works the way I like to work and practices medicine the way I like to practice medicine and bills the way I bill and in the region I live when they developed this EHR?” Then, we’ll all be able to easily answer “No, it seems like not.“
Most of the critiques I read of EMR design ding the EMR for its difficulty to use or its inability to accomodate the workflow of the institution that bought it — and of course, sometimes both. What I’ve never heard suggested, however, is the following idea proposed by Chuck Webster, a guy who clearly doesn’t stop short when he decides to study something. (He’s an MD, an MSIE and an MSIS in intelligent systems design, which is only one of the reasons I think he’s onto something here.)
In a thoughtful and nuanced blog entry, Dr. Webster outlines the work of a pioneer in usability design, Donald Norman, and comes away with the conclusion that the current trend toward “human-centered design” might actually be a mistake. What a pain — health IT limps along catching up with a trend from the 1980s, and now may be too late to catch the bus.
In any event, Dr. Webster argues instead of focusing on human/user-centered design, EMR vendors should be focused on activity- or process-centered design. I love what he says about one of the potential problems with human-centered UIs:
Optimization around a user, or user screen, risks the ultimate systems engineering sin: suboptimization. Individual EHR user screens are routinely optimized at the expense of total EHR system workflow usability…I’ve seen EHR screens, which, considered individually, are jewel-like in appearance and cognitive science-savvy in design philosophy, but which do not work together well.
It’s better, he suggests, to have EMRs model “interleaved and interacting sequences of task accomplishment” first and foremost. For example, he writes, key task collections that should be considered as a whole include workflow management systems, business process management, case management and process-aware information systems.
While there’s much more to say here, of course, I’ll close with Dr. Webster’s words, who once makes his point with wonderful clarity:
User-centered EHR design does help get to good EHRs. Good isn’t good enough. If EHRs and HIT are going to help transform healthcare they need to be better than world-class (compared to what?). They need to be stellar. Traditional user-centered design isn’t going to get us there.
The question I’m left with, readers, is whether you can have your cake and eat it too. Does one side of UI/UX design literally have to be jettisoned to support the other?