Free EMR Newsletter Want to receive the latest news on EMR, Meaningful Use, ARRA and Healthcare IT sent straight to your email? Join thousands of healthcare pros who subscribe to EMR and EHR for FREE!

EHR Usability: Is There a Right Path?

Posted on December 9, 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 EHRSelector.com, a free service for matching users and EHRs. For the last dozen years, he’s concentrated on EHR consulting and writing. He spent the 80s and 90s as an itinerant project manger 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.

The following is a guest post by Carl Bergman from EHR Selector.

Earlier this fall, the AMA sponsored a Rand Corporation study on physician’s professional satisfaction. Based on interviews with physicians in 30 practices, the study covers a variety of topics from workplace setting to quality of care, EHRs and health reform, etc. At the time, the report generated discussion about dissatisfaction in general with EHRs and MU in particular.

Usability, Part of MU?
Overlooked in the discussion was a new and important recommendation on usability. Here’s what is says:

Physicians look forward to future EHRs that will solve current problems of data entry, difficult user interfaces, and information overload. Specific steps to hasten these technological advances are beyond the scope of this report. However, as a general principle, our findings suggest including improved EHR usability as a precondition for federal EHR certification. (Factors Affecting Physician Professional Satisfaction and Their Implications for Patient Care, Health Systems, and Health Policy, p.142) Emphasis added.

It would be overkill to say that this represents adopted AMA policy, however, it’s not overkill to say that the recommendation is part of a project that the AMA initiated and supports. As such, it is most significant that it recognizes the need to bring some coherence to EHR usability and that the MU system is the logical place to put it.

Changing the Vendor – User Relationship
One commentator who did notice the recommendation was EHR Intelligence’s Robert Green. In his review, Green took a different tack. While agreeing that usability needs improvement, he saw a different way to get change:

Usability remains an enigma in many clinic-EHR vendor relationships because it hasn’t been nearly as important in the recent years’ dialogue as “meaningful use.” But among the competing priorities, usability among physicians and their EHR vendor is a real opportunity to develop shared expectations for a new user experience.

As a patient, I would rather not see the delegation of the “usability” dialogue of EHR to those in the roles of meaningful use certification. Instead, physicians who have spent many years of their lives learning how to “take care of patients” could seize the moment to define their own expectations with their EHR vendor of choice within and beyond their practice. (How connected is EHR user satisfaction to vendor choice?) Emphasis added.

I think these two different paths put the question squarely. They agree that usability needs increased action. Users have gotten their message across with alacrity: all systems fail users in some aspect. Some fail catastrophically. Though some vendors take usability to heart, the industry’s response has been uneven and sporadic.

Where these two approaches differ is tactics. Rand looks at usability, and sees an analog to MU functions. It opts for adding usability to MU’s tests. Green sees it as part of the dialogue between user and vendor.

As a project manager and analyst, my heart is with Green. Indeed, helping users find a system that’s a best fit is why we started the Selector.

Marketplace Practicalities
Nevertheless, relying on a physician – vendor dialogue is, at best, limited and at worst unworkable. It won’t work for several reasons:

  • Nature of the Market. There’s not just one EHR market place where vendors contend for user dollars, there are several. The basic divide is between ambulatory and in patient types. In each of these there are many subdivisions depending on practice size and specialty. Though a vendor may place the same product name on its offerings in these areas, their structure, features and target groups differ greatly. What this means is that practices find themselves in small sellers’ markets and that they have little leverage for requesting mods.
  • Resources. Neither vendors nor practices have the resources needed to tailor each installation’s interface and workflow. Asking a vendor, under the best of circumstances, to change their product to suit a particular practice’s interface approach not only would be expensive, but also would create a support nightmare.
  • Cloud Computing. For vendors, putting their product in the cloud has the major advantage of supporting only one, live application. Supporting a variety of versions is something vendors want to avoid. Similarly, users don’t want to hear that a feature is available, but not to them.
  • More Chaos. Having each practice define usability could lead to no agreement on any basics leaving users even worse off. It’s bad enough now. For example as Ross Koppel points out, EHRs record blood pressure in dozens of different ways. Letting a thousand EHRs blossom, as it were, would make matters worse.

ONC as Facilitator Not Developer
If the vendor – buyer relationship won’t work, here’s a way the MU process could work. ONC would use an existing usability protocol and report on compliance.

Reluctance to put ONC in charge of usability standards is understandable. It’s no secret that the MU standards aren’t a hands down hit. All three MU stages have spawned much criticism. The criticism, however, is not that there are standards so much as individual ONC’s standards are too arcane, vague or difficult to meet. ONC doesn’t need to develop what already exists. The National Institutes of Standards and Technology usability protocols were openly developed, drawing from many sources. They are respected and are not seen as captured by any one faction. (See NISTIR 7804. And see EMRandEHR.com, June 14, 2012.)

As I’ve written elsewhere, NIST’s protocols aren’t perfect, but they give vendors and users a solid standard for measuring EHR usability. Using them, ONC could require that each vendor run a series of tests and compare the results to the NIST protocols. The tool to do this, TURF, already exists.

Rather than rate each product’s on a pass – fail basis, ONC would publish each product’s test results. Buyers could rate product against their needs. Vendors whose products tested poorly would have a strong incentive to change.

EHRs make sense in theory. They also need to work in practice, but don’t. The AMA –Rand study is a call for ONC to step up and takes a usability leadership role. Practice needs to match promise.

NIST’s EHR Usability Conference Breaks Both Old Ground and New Focuses on EMR Patient Safety Protocol

Posted on June 14, 2012 I Written By

When Carl Bergman isn't rooting for the Washington Nationals or searching for a Steeler bar, he’s Managing Partner of EHRSelector.com, a free service for matching users and EHRs. For the last dozen years, he’s concentrated on EHR consulting and writing. He spent the 80s and 90s as an itinerant project manger 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.

Regular reader, Carl Bergman from EHR Selector, attended the recent NIST EMR Usability Conference and sent over the following guest post on what was said. Thanks Carl for sharing your experience with us.

A year ago last June I attended NIST’s (National Institute of Standards and Technology) conference on EMR/EHRs usability. [See Carl’s post on the NIST EHR Usability Conference from 2011.] It was a mixed bag. There were several excellent presentations on the fundamentals of usability, how to analyze an EMR and where the field was headed. Unfortunately, NIST’s staff took a narrow view confining their work to EMR error conditions and assiduously avoiding interface, workflow and clinical setting issues. It was odd that an agency that prided itself on redesigning nuclear control rooms after Three Mile Island or the design of airplane cockpits would ignore EMR user interfaces.

New Approach: New Protocol

At this year’s conference at NIST headquarters in Gaithersburg, MD, the past was not prolog. Last week’s conference focus was on a comprehensive EMR usability protocol, NISTIR 7804, that NIST produced last February. (For a good synopsis, see Katherine Rourke’s Design Errors That Cause Patient Harm per NIST.) NIST’s staff pulled together a notable group of speakers on patient safety in general and implementing the protocol in particular. (NIST is posting the presentations here.)

The protocol, designed to review an EMR, is not a trivial undertaking since it has about 180 line item questions. It asks, for example, if the EMR:

  • Keeps patient identities distinct from each other? That is, does the system prevent one record from writing over another or erroneously sharing data elements?
  • Lays out pages in a consistent manner using color, icons and links identically?
  • Uses measurements consistently? That is, if weight is entered in pounds and ounces in one place, do they show that way in other places?
  • Displays fields fully rather than being truncated?
  • Sorts logically based on the subject?
  • Show dosages, etc., with all needed information on the page?
  • Displays multipage entries or lookups with proper navigation choices?
  • Has error messages that state what is wrong and how to cure the problem?
  • Accommodates different levels of user knowledge? That is, does it have extended help for novice users, refresher information for occasional users and short cuts for experienced users?

Developers Present in Force

If NIST’s major intent was to get developer attention, they succeeded. Of the hundred or so attendees, about 20 percent were from major systems. 3m, Allscripts, Athenahealth, Centricity, McKesson, NextGen, etc., each had one or more representatives present. Others present included Kaiser, HIMSS, Medstar, First Choice, ACP, Columbia, etc.

Unfortunately, there is no way to know developer reaction to the protocol. The conference had no comment session. I don’t know if this was by design or if time just ran out. NIST staff did indicate that next year the conference would be two days rather than one. However, a year is a long time to wait for reactions. This is especially pertinent since NIST is not a regulatory agency. Its protocols are strictly voluntary and depend on vendor acceptance.

What NIST did do is offer several presentations that emphasized how fragile patient safety can be in an HIT world. One breakout session used an actual, unnamed product’s screen that had dozens of misleading or ambiguous fields. For example, the screen’s fields cut off drug names, used red to indicate several different findings and used a pop up that blocked a view of a pertinent entry.

In another more broadly based patient safety presentation, University of Pennsylvania’s voluble Ross Koppel drove home how common elements in EMRs such as blood pressure – he’s found 40 different ways to show it so far – are subject to many formats for capture and display. Moreover, if you think EMRs have problems, Koppel shows how bar codes and work arounds can play havoc with workflow and patient safety.

Wanted: One Good Policy Compass

For those of us possessed of an EMR design demon, it was both a good chance to wonder out loud just what it all meant and where, if anywhere, things were headed. Sadly, the most common answer was who knows? There were some common points:

  • It’s better to have NIST’s protocol than not.
  • You can forget the FDA playing a bigger role. It’s under funded and over worked.
  • HIMSS will wait for the industry and the industry has shown no hurry.
  • EMR adverse incident reporting would be great, but who would do it and how open would it be?

In short, if you’re shopping for an EMR, regardless of your size, don’t count on anyone handing you a usability report on an EMR anytime soon. Moreover, don’t try to run NIST’s protocol on your own unless you have full access to the proposed EMR, lots of time on your hands and a good grasp of the protocols details.

There are some things you can do. You can ask potential vendors questions such as these:

  • Have they run the NIST protocol and what did they do as a result?
  • If not NIST, do they have a written usability protocol and, if so, can you see it? How have they implemented it?
  • Have they tested their EMR’s usability with outside, independent users? What were the results?
  • Have they used any interface designers?
  • What usability changes do they plan?

There is no guarantee that you’ll get a great product, but it could mean that you get one that doesn’t bite your patients or you.

Better EMR Design

Posted on May 23, 2012 I Written By

Priya Ramachandran is a Maryland based freelance writer. In a former life, she wrote software code and managed Sarbanes Oxley related audits for IT departments. She now enjoys writing about healthcare, science and technology.

Now that we’ve heard the statistics about EMR use, we’re also hearing a lot of opinions on EMRs, and not all of them are laudatory. In fact I read some separate articles recently, and they pretty much said the same things in so many different words:

– EMRs are not intuitively designed. They do not reflect actual workflows that most doctors or hospitals follow. Rather the applications look like they’ve been designed by a bunch of programmers who then design the UI to look like how they’re underlying data are structured.
– Because they’re pretty much being foisted on hospitals and doctor’s offices through “incentive” programs, often the resources expended on them are sunk costs. To improve the workflow of a software to accurately reflect the needs of a particular hospital, you will need to pump extra money into it. That’s about as likely to happen as a software vendor providing you a customized solution without charging you anything extra.

Let me assure you – the medical establishment has it exactly right, at least in my experience. I work as a technical writer, so much of my working life consists of documenting the products that make it to your doorsteps, and I have experienced some of the same frustrations as you. I’ve complained about them, made myself unpopular with development teams and added my two cents to feature request lists, just like many of you.

But, I also see things from a programming perspective too, and I’m here as a sort of ambassador between both worlds. Many teams I worked with had an actual designer working as part of the team.
But the designer’s role was often making the colors look attractive enough, or the font large enough to appeal to a cross-section of users. One of my old bosses, different industry and everything, called this our Lipstick on a Pig game, and plenty of times that’s what the designer’s role was. Inventing plenty of shades of lipstick for the proverbial pig.

Ergonomic design was not what the designer was tasked with doing. One place I worked at even had a doctor on payroll. Except he had a doctor’s degree from Shanghai, had not cleared his exams in the States and had no idea how medicine is practiced in the States. It sure looked good on paper when their sales team went out to clients and talked about having a dedicated doctor on staff to help with software design.

And the effect of poor design on functionality is often perplexing, sometimes disastrous. Case in point – documenting all the drugs administered to a patient. It has been drilled into programmers that clicks are sacred things, you don’t want doctors wasting too many of them.

So because we don’t want too many clicks, we list each and every medication a patient has been administered, add some pagination logic around it and call it a day.

The doctor, who is the end user, for whom we designed this software system, now sees all the information in a “convenient” list and doesn’t need to open up a medication tree to view the medications under it. Except if she has a very sick patient with multiple encounters, the case history reveals a medication that is 31 pages deep. To get to Xanax, she might have to page through 30 previous pages.

While these “features” fall into the realm of merely annoying, they’re nowhere as disastrous as those modal alerts that Barbara J. Moore talks about in her KevinMD piece. A modal window is one of those annoying windows that you have to take an action on, otherwise you can’t proceed any further in your workflow. Moore points out the hazards of such alerts which force a doctor to take a choice, any choice, but aren’t available later if the doctor wishes to review the alerts at leisure.

So yes, software vendors need people who know the workflow to design the systems. But more importantly, you – the medical establishment – must keep requesting changes or suggesting features, or vendors will remain complacent about what they put out.

Are “User” And “Process” – Centered EMR Design On A Collision Course?

Posted on April 3, 2012 I Written By

Anne Zieger is veteran healthcare consultant and analyst with 20 years of industry experience. Zieger formerly served as editor-in-chief of FierceHealthcare.com and her commentaries have appeared in dozens of international business publications, including Forbes, Business Week and Information Week. She has also contributed content to hundreds of healthcare and health IT organizations, including several Fortune 500 companies. Contact her at @ziegerhealth on Twitter or visit her site at Zieger Healthcare.

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?