Some Interesting EMR Usability Ideas

Not long ago, I wrote a piece slamming the lack of EMR usability standards out there today, arguing that the industry was pretty much going to stay in a rut until we got some.  One of our readers, Prasad Patankar, posted a very thoughtful response which I felt deserved more exposure and discussion.

Here’s his ideas, in italics, with my comments interspersed:

* EMR systems should have a consistent hierarchy for navigation so
  that it is easy for users to locate information.

This is hard to argue. Unfortunately, given the vendor turf wars going on out there, I think we’re going to be stuck with proprietary systems and proprietary hierarchies for some time to come.  But what Prasad suggests here is just common sense, not that we can expect to see a lot of that on display.

* Error messages should be clear. They should explain why the error
  occurred and explain what the users should do next. Definitely not
  any programming language errors.

Again, I agree with Prasad here. This kind of consistency would do much to orient users. The problem is, these systems are still driven largely by developers, who best understand the nasty programming language error codes.  Expecting them to make their EMR products speak plain English is a bit of a stretch, sadly.

* For screens that contain too much information, there should be an
  option available for the users either to see the summary or a
  detailed drill-down capability. Some EMR vendors have started
  incorporating this functionality into their reporting modules.

Beautiful — a function vendors already understand. That’s enough to sell me on the notion that it can be more widely implemented, and soon. In this case, there’s no excuse for vendors to obfuscate;  just go ahead and make the data easier to read already!

* Consistency should be followed in displaying allergies and current
  medications in one single location. Users should not have to click
  multiple windows to get to this. This also applies to past
  encounters(progress notes) which have been migrated prior to
  implementation of the new EMR system.

This is a very good idea. When Your Editor recently read up on research into errors made using EMRs, medication slip-ups were by far the most common event. (And the only event that created serious harm was administration of a drug to which the patient was allergic.  Past notes might not be as urgent, but useful, definitely.

* It would also be interesting to see if EMR vendors could incorporate
  the cultural context and meaning of a color in that context before
  they use the entire color palette in their software.

This is an intruiging idea, though I can’t imagine the big enterprise vendors giving it much thought.  Perhaps if Apple designed their interface… But that’s a tale for another day.

About the author

Anne Zieger

Anne Zieger

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.


  • The real problem here is that there is no one right way make the EHR usable for all specialties.

    Suppose that in the non-medical world, someone suggested there is one right way to display information on a computer screen and all programs should use it. Anyone with half a brain would say this is absurd with the huge number of different types of computer software, users and needs that exist.

    And yet we strive for an EHR interface that is “usable” by every Doctor, no matter the specialty?

    Why would an interface that is usable by a pediatrician be usable by a neurosurgeon? Why would a gynecologist want to have the same interface as an ophthalmologist?

    Until we move to Specialty Specific Interfaces, the EHR will remain what it is, a technology only the Government could love.

  • Having had the unenviable job of trying to improve the design EHR software for the last 8 years (iI just recently left one of the large EHR vendors), I feel the need to comment on some of these concepts and explain what I think are oversimplifications. First of all, Dr. Hughes is absolutely correct in that without a much finer grained (which could be specialty) approach to EHR’s – they will never be “usable” to a braod range of clinicians. But I will also try to offer some context around the points in this article to provide more information into the difficulty of designing these systems.

    Consistent Hierarchy for navigation: This is an great goal, but ideally the navigation structure should be defined by one of two constructs: workflow or information architecture. Workflow varies radiclally from specialty to specialty, and every Doctor will tell you that their workflow is different (and better) – so we can’t define a consistent structure on workflow that providers will consider usable. The other option would be Information architecture – this is another area where there is very little consensus. Even if you look at a very robust and proven ontology like SNOMED CT, many providers will indicate that there is too much granularity or too little, and that it isn’t useful for their day-to-day uses. If you add in the complexity of defining a workflow-based or an IA-based common navigation structure between ambulatory care and acute care products, I would argue that this would take a significant amount of research and some fundamental re-thinking of the EMR to accomplish.

    Error code clarity: This is an area that I agree with whole-heartedly, but the reality is much more complicated. I will share a little secret here – there are an awful lot of times in which the system does not know exactly why the error occured or how to resolve it. There are also times when an error can not be resolved by the end-user, but it requires some sort of admin or IT level access and knowledge to resolve.  Both of these are reasons for which the systems may throw a more generic error code – because it requires more in-depth anlaysis and investigtation to resolve that particular error.  I would agree that this information can and should be included in the error dialog rather than leaving the user in the dark.

    Screens with summary information : Again, I agree with this, but as in most things, it is very complicated.  The problem revolves around which information is at the top level, and which information is at the drill down.  Doctors (again, especially across speciality boundaries) will tell you that different peices of information are important and need to be at the top level.  If you sit in a room with a bunch of providers (and I have) to determine what information needs to be at the top level you will come out of that with the consensus that almost everything needs to be at the top level to account for everyone’s varying needs.  This is the kind of thing that can be customized, but many providers will not take the time to customize it, and many internal IT shops will not allow their providers to customize these things because they are concerned about their effort to support all of their users.  Vendors are making some progress here, but it is not as simple as would seem.

    Allergies and current meds: this is an area that we unequivocably agree – if your EMR doesn’t do this, it could be a significant patient safety issue.  Usability is always in the eye of the beholder, and there are many stakeholders in the EMR so that make defining “usability” a challenge, but safety is easy to define and should not be open for interpretation.

    Color Context – on this point, I can’t speak for all the vendors, but I can speak for my previous direct experience and say that we thought a LOT about color and effective color useage.  Accounting for things like cultural context, color deficiency, contrast, touchscreens, ambient-lighing, glare, emotional branding, visual coplexity, and information priority when we used color in our products.  Obviously, there are many vendors that do not have formally trained visual designers or Human Factors folks on staff, and there is a complexity in color usage that is not easily understood without the formal training and background.

    Sorry for the very long comments, but there is a general lack of understanding of the complexity of designing these systems and it is easy to just assume that they were designed by “a bunch of software developers” – when the reality is that in many companies there are groups of highly trained and skilled professional designers and clinicians that are working to solve really difficult problems with these systems.

Click here to post a comment