Guest Article: What will make healthcare software usable?

Last month I posted several entries about how difficult most healthcare software is to use – those articles garnered lots of “yes, you’re right” type of comments along with a number of emails asking for help on how to improve usability. Usability describes the "ability to use" something — the goal for a usable system is to make it easy to use. Given how hard it is to actually make something easy to use (yes, ironic), I invited an expert in this field — Paul Nuschke, a usability specialist at Electronic Ink – to write about what it takes to make software usable, with emphasis on healthcare IT systems. Paul went beyond a simple introduction to the field and gives specific advice to software designers; it’s clear these guys know what they are doing. If you’re building a new EMR (and hey, we have billions of dollars to spend now so what are you waiting for?) please take Paul’s advice:

In a previous post on this blog, three prototypes compared simple experiences using Apple and Google products with the complicated experience found in Healthcare Information Systems (HIS). However, the diagrams begged the question: if an application cannot be as simple as a search field and a Submit button, how can they be usable? Is simplicity the only way to make usable software?

Fortunately, practitioners in the design and usability field have been studying this problem for a long time. In this article, I am going to summarize three essential attributes of usable software that apply to HISs and Electronic Health Records (EHR). To be considered usable, applications should be easy to learn, efficient, and they should prevent errors.

Easy to learn

Imagine a nurse logging into an EHR application for the first time. Does he or she know what to do next? Or does the nurse need a day of training before being able to start? What about a rotating physician or a per diem nurse who uses a system once every few months? Can they remember how to use it?

With EHRs, your medical providers most likely need training, they commonly forget key system terminology, and they probably forget how to use key portions of the system. Why does this happen? Briefly, it happens because those systems require providers to learn about the system. The systems force providers to learn new vocabulary, workflows, and annoying number of system “quirks.” Instead of being a tool that supports patient care, these systems can disrupt and change the way that care is delivered.

Well-designed software is easy to learn and allows its users to get work done right away. Imagine for a moment an alternative, easy-to-learn system that meets the following requirements:

  • Uses terminology already familiar to users
  • Does not force users to memorize system codes, phrases, and terminology (e.g., see image below)
  • Allows users to follow familiar task flows
  • Does not require users to recall lengthy procedures that are not familiar to them
  • Hides systems processes that are irrelevant to the user
  • Shows icons and images that users can readily identify
  • Presents both textual and graphic information in a clear way
  • Reduces the amount of information clutter
  • Provides intuitive ways to navigate through the application
  • Gives users help exactly where they need it
  • Allows users to explore and make errors without severe consequences



Figure 1: What are "Delayed Orders"? Why are certain orders blue? Why are CAPS used? These all require users to learn.

When an application fails to deliver on each of these requirements, it becomes cumbersome, complicated and difficult to use. To put it another way: if you are a patient do you want your providers using a system that doesn’t meet these requirements?

Unfortunately, instead of fixing the problems, most EHR companies like to explain that their software is complicated. They have convinced CIO’s and CTO’s that training can overcome any confusion and is a necessary part of any complex system. In the design community, we see training as a symptom of poorly designed software. The reason is rather simple—applications require training because they do not work in a way that most people find intuitive and they contain information and terminology that does not make sense to users.


How quickly and easily can users complete their tasks? Efficient applications are not only technically sound, supporting quick page load times, but they also provide an optimal task flow for both novice and expert users and a visual design that facilitates quick understanding and information retrieval.

Unfortunately, EHRs are anything but efficient. Providers often spend more time documenting their patient care, and less time actually providing that care, than when they used paper records. In the design world, since nearly every application has some type of data entry form, a set of best practices has evolved about how to design efficient forms. Given the importance of the data entry part of the process, you would think that EHRs would be at the cutting edge of form design. Instead, you have forms that use the wrong input fields and that suffer from poor layout, lack of shortcuts (e.g., using “tab” to advance), and many other issues.

Making matters worse, once information is in the system, providers and administrators have a lot of difficulty finding it. Why? Because EHR developers have spent virtually no time trying to format or organize the information in a way that makes sense. How can you tell? The systems display the information using logic that is similar to the database structures that contain it, resulting in two approaches. The worst approach is to dump all of the information onto one page, forcing providers to sift through hundreds of fields often irrelevant to their current task. Or they group the information by data type (e.g., prescriptions), placing each group on a separate tab (see figure below). This tab system forces users to navigate and recall information from multiple tabs. Not only does this additional cognitive load reduce efficiency, but it can also lead providers into making costly errors.



Figure 2: Is this a good use of space? What is currently happening with this patient? Oh, that’s on a separate screen.

Given how far current systems are from supporting efficient work, you might be wondering what one looks like. Consider the simplistic example of Google’s search. Novices know that they can simply type text into the textbox and press “Google Search”. Eventually these users learn that entering more search terms narrows the results. They might also learn that they can use modifiers like “OR” and “define:” to further narrow results. Recognizing that users need help constructing searches and spelling certain words, after they begin typing Google provides a list of suggestions that further helps users refine their search:



Figure 3: Google suggesting searches. Note how it doesn’t force you to choose one.

What can more complicated applications learn from this interface? Translating these characteristics into general requirements, an efficient system:

  • Allows users to follow familiar task flows (e.g., enter text in textbox and click button or press Return)
  • Does not require users to recall lengthy, unfamiliar procedures (e.g., registering before use)
  • Hides systems processes that are irrelevant to the user (e.g., database query language)
  • Presents both textual and graphic information in a way that is clear
  • Reduces the amount of information clutter where possible (e.g., the copious white space on every Google page)
  • Provides intuitive ways to navigate through the application (e.g., Next buttons on the search results page)
  • Provides shortcuts for advanced users (e.g., “define:”), while providing more obvious mechanisms for novices to accomplish the same tasks (e.g., simply searching)
  • Provides decision support tools that aid rather than force decision making (e.g., drop-down list with suggestions)
  • Prioritizes information in a way that supports tasks (e.g., best result listed first)

In these requirements, note the overlap between efficiency and learnable systems. This is not an accident: Learnable systems are almost always more efficient, especially for novice and intermediate users. Moreover, learnable systems are less prone to errors, my next topic.

Prevent Errors

Consider Dennis Quaid’s well-known case: when his twin infants were being treated in the hospital for a staph infection, they were both accidentally given the adult dose of a blood thinner that was 1000 times higher than standard for infants. The same error had happened at another hospital with six infants, where three infants died. What circumstances led the medical providers to make this mistake? How could the same error type happen repeatedly? The packagings for the different doses of medication were nearly identical, causing providers to confuse the different doses even when they were being vigilant. This “persistence” is one indicator of a particularly onerous usability problem.

IT practitioners have become accustomed to thinking of errors in terms of system crashes and pop-up messages with arcane system terminology like “Error Number: 1249245. Please try again.” For medical providers, discussion about errors involves “medical errors,” like when a surgeon operates on the wrong body part, or as in the example above, when the wrong dosage of a medication is given. In the usability field, we have a more expansive definition: errors happen every time an action does not result in the desired outcome.

Through our research, we know that behind these errors is a system or a process that virtually assures an error is going to happen. Designs that do not take into account human limitations and context-of-use will always lead to errors. For example, suppose that you designed the following form:


How can such a simple form create errors? Because it requires users to recall which date format they need to use. Is it “mmddyyyy”, “mm/dd/yy”, or if you’re European, “dd/mm/yy”? How does the system recover from your error? Does it wipe out all of your data and force you to start all over again?

As in the Dennis Quaid case, errors also occur when people misinterpret information. In particular, the form in which data is presented can greatly affect how people interpret it. Consider the following “Order Details” text box from VistA:



Figure 4

This “Orders Details” screen broaches a number of questions. What was this order? Was it completed? Why was the attending physician listed so prominently? Why was it formatted in plain text? What does “>>” mean? Why are certain bits of information in CAPS? Why is “Order Text” indented?

This screen essentially a dump of information contained in the database. Imagine being a tired and hurried physician trying to wade through it to find the piece of relevant information. What if they miss “unreleased”? Maybe the patient sits in their bed for an extra two hours because the physician forgot to “sign” the order.

While catastrophic medical errors get news attention, providers typically experience many of these “small” errors in a given day. We don’t hear about these smaller errors very often for two reasons. First, users often attribute the problem to their failure to remember the system’s rules (e.g., “I should’ve remembered that date format!”). Second, amazingly, many hospitals are contractually obligated not to talk about the errors. In any case, these errors add up to decreased efficiency, lost income, distrust of the system, frustration amongst providers, and worsened patient care.

Preventing errors, improving efficiency, and making the systems easier to learn is a tall order for the EHR industry. As this blog attests, there are several roadblocks—including interoperability and system architecture—that stand in the way. However, with more attention to design and usability, EHR vendors can make large and immediate strides towards improving their systems. Should they need help, there is an entire design industry that has been underutilized and that is, believe it or not, even excited to help improve these applications.

Newsletter Sign Up

19 thoughts on “Guest Article: What will make healthcare software usable?

  1. Great article, and glad you mentioned that a day of training on the new system is NOT the way to solve this. Research shows that 3 weeks after classroom training most people only remember 15 percent of what they learned or less. In healthcare situations, that could be disastrous. Best way is what you said.. make the usability so good users rarely need any help. And when they do need it, make it instantly available, easy to find and delivered in small bites. More on this at

  2. Excellent Artile! As the maker of software for scientific analysis, I find this just as relevant to our industry as it is to EHR. I am sending this one up the ladder to the rest of the organization.

  3. Pingback: ICMCC Website - Articles » Blog Archive » Guest Article: What will make healthcare software usable?

  4. I work in India on health record related software. I agree with all the points that are made in the article. But I have some reasons on why things are the way they are.
    The primary way to get doctors to use software is a promise that using the computers will offer minimal disruption of their tried and trusted methods of work . This basically means that conversion of paper forms as is into the web.
    Trying a minimalist approach on the doctors elicits a response which is typically : The software guys are trying to change our way of work and cannot be adopted.
    So as a software designer you take the path of least resistance and then try to get a foothold in the hospital and hope for change later

  5. Pingback: Health Wonk Review: The Carousel of Progress

  6. There is a saying in human computer interaction environments that bad usability is still bad usability after training.

    You can’t train your way out of a usability problem, you can alleviate some of the pain by discovering workarounds, but that doesn’t remove the original problem. If your software has a faulty design, it’s better to change the one piece of software rather than to eternally teaching all your users to work around it.

    Why people still think that “it gets better when you get used to it” – is beyond me.

  7. Thanks everyone for your comments so far.

    I have heard the argument a lot that medical providers want to use their old way of doing things and that is the primary reason that they do not want to use HISs. While that may be true for a very small portion of providers, a great many of them see the potential benefits and want to use the software, but the systems are so clunky, and the processes in the system are so backwards and unintuitive, that it makes a lot of sense for providers to resist.

    Without question, if we had well-designed systems the user adoption and satisfaction would be substantially higher. What surprises me is how few EHR companies have caught on to this–it’s a tremendous opportunity for one to really grab some market share.

  8. Pingback: Chasing the perfect User Interface | My life as it unfolds

  9. Other tidbits to consider:

    Design for intermediate FIRST, not the noob… especially on software/products used daily. Initially this seems counter-intuitive, but allow the repeat, advanced user to ROCK… let their skills sing… and you’ll amplify their creative and technical output… and then you have a devoted group who will preach for you.

    Get the damn interface out of the way. Often the interface takes up a large amount of screen real estate (up to 60%) and the data takes a backseat = criminal design practice but seen everywhere in Health services. Also, I shouldn’t notice the interface over time. It should literally disappear (a la the photo browser on the iPhone).

    Use grids, leverage great type and graphic design practices.

    Beauty and elegance = a requirement for surprising and apostle-driven software. Where are the beautiful health services? We can count them on a few digits.

    … and many more software interface design tenets.

    Good first cut,

  10. @Juhan Sonin and others:
    Add to this progressive disclosure: Show people the basics first then allow them to ramp it up. Like Juhan Sonin said, tho, aim at the intermediate. Or, perhaps, provide a flexible interface that grows with the user.

    Make an interface that is context-aware: Provide elements that are relevant to the task. If the user seeks out a certain feature during a particular task that is not already present in the initial set of features then the system should be smart enough to provide that feature again for the user. This is a great opportunity for the developer to get user feedback and perhaps feed it back into the next version of the product, or, hopefully, the product will be flexible enough that the change can be deployed in an existing installation without having to upgrade and that the change can be made by the system manager and not the software vendor.

    Human-Computer Interaction is a huge field and, though there are several people doing research in this field, I don’t see any/many HIT vendors using many of their findings or of the HCI field in general.

    This is a great topic and I hope you get more people to provide articles.

  11. Although I do agree that software design need improvement, I disagree with some basic principles mentioned in this article.

    a. It is very unrealistic (and unfair) to compare Google search to an EMR. I challenge anyone who can really redraw the same VisTA screen in Figure 2 of this article into some ‘very user friendly screen’. It is impossible to achieve a user interface which will show all the allergy information, all of the reminders and all of the medications etc. and still be not overwhelming information and still present ‘what is the current status’ of the patient without navigating to another screen. My friends, IT industry’s current input devices (keyboard, mouse etc.) and current output devices (monitor, sound etc.) cannot possibly achieve this mighty goal.

    b. It is again unrealistic to design a system so user friendly such that users can use it with no training at all. It is like asking a second grader to take up a course in algebra! The problem is once again the comparison to Google search and other such tools which are for laymen. Try instead comparing EMRs to industry standard products such as SAP or Microsoft CRM. Another problem lies with the quality of the users. One bunch of highly qualified users do not have the time to ‘spend with this new IT guys’ another set of users are a ‘floating crowd’ of temporary workers who know little about healthcare, let alone IT in healthcare. Compare this with other industries: Can a factory worker or a CFO in any other industry “refuse” to learn the software he is supposed to use everyday? Everybody needs training for software this size and this complexity.

    c. It makes me mad (and sad) whenever I hear someone blaming the IT system for any medical error. Doctors and hospitals should take responsibility for medical errors, period. The computer did not place the order on its own, it did not pull out the medicine from the draw on its own, it did not administer the medicine on its own. It was all a human error.

  12. Sudhakar :
    c.It makes me mad (and sad) whenever I hear someone blaming the IT system for any medical error. Doctors and hospitals should take responsibility for medical errors, period. The computer did not place the order on its own, it did not pull out the medicine from the draw on its own, it did not administer the medicine on its own. It was all a human error.
    Sudhakar did not rate this post.

    Well, there are several instances where IT systems have caused detrimental results, beyond what any physician (or other health care worker) could be blamed for.

    Notably (and well published) the increase in mortality after CPOE introduction:

    There are countless other examples of bad health care informatics killing people, so blaming it all on the doctors is unfair.

  13. @DrFirst – In this day and age various doctors are benefiting from the internet to conduct web consultations. Medical Software Systems generate accurate reports from anywhere in the world. Also, health maintenance reminders can establish a linked connection with an EMR system to provide superior patient care.

    The software integrates with ease – it's compatible with Windows, Mac & Linux. It's great for out billing system too!

  14. the view of the passage i [url=]ugg boots for sale[/url]is totally correct, the key problem about health is that we lack of exercises because of high efficiency lifestyle ,and we are less care of our diet. In fact we should take more care of our i [url=]ugg boots for sale[/url]health and take more exercises. Here I recommend some excellent websites for you: it [url=]louis vuitton handbags[/url]

  15. The Usability People


    I am excited that Usability is FINALLY getting some attention in the healthcare field.

    Most enterprise software had always been designed with an “engineering-centered” design philosophy and it never worked well for most end-users. Remember the HP calculators of the 1970s (see ) ? They were great for mathematicians, but the general public was confused. These calculators were very much analogous to the focus on “expert users” in large enterprise and HIT systems.

    Healthcare IT has been very slow to catch up with the Enterprise software world. It would be nice if HIT doesn’t make the same mistakes that was made so many times before. (If you don know the past you don’t know the future!)

    The answer is User-Centered design. A design philosophy that creates a culture of understanding and enabling end users to perform “their” tasks using an information architecture and taxonomy that matches “their” mental model.

    I’m thrilled that the meaningful use stage 2 funding will require a report of summative usability testings (using the NIST CCIF template).

    I’m scared that this report will become similar to the “VPAT” for Section 508 compliance, As long as you have VPAT report you are in compliance–irrespective of the number of violations of the principles of accessibility and universal design.

  16. Pingback: Paul Nuschke

Add Comment