Health Information Design Principles

Much of my work has been in the area of health information and clinical systems. These systems present some special requirements that are distinct from general design work, while some priniciples (such as testing) are the same. It seemed useful to gather them into one list.

Summarize information

In clinical applications, the volume of information for a typical patient, much less a group of patients, makes it impossible (or impractical) to show everything at once. Moreover, showing everything would overwhelm the user; most clinicians want to see information that is either new, abnormal or significant (typically serious chronic problems, significant procedures, current medications or immunizations, and allergies). So the goal of a good medical UI is to show these things first, and use the principle of progressive disclosure to let the user see more when they need it.

Data half-life

It is not generally acknowledged (perhaps because clinical utility and legal requirements are different) but there are widely divergent half-lives for clinical information. What this means is that some information is just about worthless after a day or so, while other information never loses its value. For example: in Laboratory results, an electrolyte panel generally means very little after a couple of days (the patient's values will have changed) where a positive Hepatitis B antibody screen will always be valuable (it will not change and says something important about the patient). A good design will take advantage of this fact and intelligently present information by being sensitive to its half-life.

Be trustworthy

While it may seem to contradict the previous principle, it is important to show clinical users all the information when they ask for it. If users perceive that they are not getting the full story when they will quickly revert to their trustworthy (if inefficient) manual systems. No matter that the manual systems result in redundant test ordering, missed data, and poor clinical communication. This missing information typically can come from one of three sources:

  • Data Errors - either the database is not receiving or storing the information, or else is not returning it when queried.
  • Lack of Synonyms/Poor Search - clinical users have a wide variety of synonyms and acronyms; a good system should support this in any search. With the near ubiquitousness of Google, users have come to expect completent, robust and fast search results. Searches that return incomplete results lose users' trust quickly.
  • Intentional Data Hiding - this is usually the result of some misguided security effort that seeks to show clinical information on a "need to know" basis. Often this kind of "feature" is disabled within a month or so of going live. My only advice: don't do it.

If you can address these issues in the design and make the system be consistent in its presentation of data users will be grateful and the lawyers will be happy.

Keep it simple

This is more of a general design principle, but it seems to come up frequently when developing medical systems. One scenario is that developers hear from users (typically physicians) that there are "too many clicks" in the system, so the developers figure out ways to do different things "under the covers" depending on the state of the system or on the data, as a way to save steps. This approach almost inevitably ends up being confusing for users and causing usability problems down the road. It is much better that the system appear to be transparent to the user.

The second scenario is when developers get overwhelmed by the complexity of the tasks in healthcare and decide to offer all the alternatives all the time, rather than doing an analysis and applying the "80/20" rule. This also covers the "too many clicks" complaint. Unfortunately this means that the application shows too many options for the most common situations and tasks, and ends up overwhelming most users most of the time.

There is no typical user

This design principle becomes an issue when companies or clients expect one piece of software to work for all users in the clinical setting. Unfortunately there is not only a big variation in clinical expertise and computer skill within job classifications, but the difference in training, job responsibilities and tasks is enormous between the job classifications. It is really unfair and counter-productive to expect a medical assistant to use the same software as a physician. Good software should be tailored to the user and their tasks.

Leverage what users know

Of all clinical users, physicians represent the biggest design challenge. Most modern/GUI software relies on object recognition rather than user recall. For novice users, this is clearly a benefit over a command-line interface that requires the user to recall arcane computer commands. Unfortunately, the recognition approach doesn't work well for physicians; as a group they have tremendous capability to memorize. This is not accidental - medical schools select for it, and their training reinforces it. By the time they have completed their training they have already memorized a huge quantity of medical facts. Memorizing some system commands is almost trivial to them, and is really second nature. Recognition slows them down, whereas recall requires some additional learning curve, but is much faster in daily use. Good system design for physicians promotes the use of "macros" and "shortcuts" that can be memorized and quickly entered.

Classification and Hierarchy
Often users are asked to wade through an artifical hierarchy in order to accomplish a task. An example of this would be order entry systems that use a classification scheme to reduce the number of choices presented to the user. An item like a CBC might be easily found under "Laboratory", but other items like traction set up might be under "Medical Devices", "Orthopedics" or other categories. Users quickly become frustrated trying to guess which category is correct and turn to searching instead.

One exception to avoiding deep hierarchies is when the hierarchy is well understood and shared among users. An example of this is when observations are categorized under body systems. Physicians and nurses would understand to look for ACL tear under "Musculoskeletal". Just be aware that this shared understanding doesn not hold true for allied health personnel. I've seen nursing assistants struggle to find items in just such a system.

Avoid interruptions

Clinical users, especially physicians, seem to be more bothered by system interruptions, message boxes, etc. than typical users. Perhaps it is because the task of forming a picture of the patient and what they need requires so much concentration that it is easily disrupted by a "chatty" system. Clinical users really only want to know if something may be about to harm the patient; most everything else can wait.

Window management

A diversity in user computer expertise means that the issue of window management can be important. Multiple Document Interface (MDI) applications are generally falling out of favor, and have been shown to be a problem in clinical applications. Most significantly, when more than one patient can be seen, even if in their own window, the liklihood of users mistakenly viewing entering data on the wrong patient skyrocket. These kinds of user errors can have obvious and serious consequences. Avoid an MDI design, and especially any design that shows more than one patient at a time.

When you think you are done, TEST IT!

When you have finished your design you must test it. There are no excuses! It doesn't matter what the deadlines, how many clinicians work on the design, or whether the VP of development is an MD. None of these get you off the hook. You should really be testing your designs all along the way, starting with hand-drawn paper prototypes, through more polished screens done in Photoshop or something similar, onto interactive prototypes done in Visual Basic or Director. For more information on this I suggest you read Jakob Nielsen's book Usability Engineering.