Defining EHR Usability Isn’t for the Timid

Posted on December 30, 2013 I Written By

When Carl Bergman isn't rooting for the Washington Nationals or searching for a Steeler bar, he’s Managing Partner of the last dozen years, he’s concentrated on EHR consulting and writing. He spent the 80s and 90s as an itinerant project manager doing his small part for the dot com bubble. Prior to that, Bergman served a ten year stretch in the District of Columbia government as a policy and fiscal analyst, a role he recently repeated for a Council member.

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.