What Steps Might Vendors Take to Reduce Design Errors?

By Larry Ozeran MD, President, Clinical Informatics Inc.

HIMSS core objective as an organization is to improve healthcare quality and patient safety through the best use of IT and management systems. As hospitals and providers work to implement electronic health records and other IT and management systems, HIMSS is launching a blog series on health IT and patient safety to help providers and hospitals identify potential risks to patient safety that have resulted from problems with EHR implementations and mitigate those risks through proactive measures.

Let’s start by considering the design choice in our case study to permit a configurable flag to delete medications in the same pharmacologic class. We can make arguments for and against this being a design error.

On the design error side, many patients are on multiple drugs in the same class, so this should never be an option. On the valuable feature side, it is more common to start a new medication as a replacement for one in the same class than to add a second drug from the same class.

Which side of the argument is “right”?

Perhaps the best approach is to have a deep discussion with end-users before finalizing your product design. Understanding how users might use or misuse an option can direct your development of safeguards for features that, in some circumstances, might cause harm.

There are many types of software design errors, from overflow bugs to security risks to user interfaces that obstruct workflow. While at some level, each can lead to a patient safety risk, here, the focus will be on those most proximate causes of patient safety risk: human-computer interface (HCI) to workflow mismatch, HCI inconsistency, and calculation error.

At best, when the human-computer interface is inconsistent with user workflow, this mismatch slows the user relative to their prior performance. At worst, it promotes errors and forces workarounds. Along this continuum, there are many opportunities for patient harm by omission or commission. Workarounds can lead to steps being skipped. Errors can lead to incorrect medication being given.

How do you know when your software supports or impedes workflow?

Your users will tell you. As a result, the earlier you get their feedback, and the more often you ask them after implementation, the sooner you will learn about the challenges and find solutions. Naturally, it is better if you can get this feedback before, as well as after, your release, despite the various pressures that push the release cycle.

Inconsistent user interfaces commonly lead to errors of commission. An action is taken based on a learned pattern whether:

-visual (based on color, text style or word length),

-spatial (by screen location),

-contextual, or

-auditory.

What happens when bold text on the medication orders means preferred, but bold on the culture results means antibiotics to avoid due to patient allergy?

They are two different areas, but in a more global context, bold means “good” when ordering medication, but “bad” when ordering antibiotics based on culture results. In this situation, especially when the user is busy or interrupted by other events, it is easy for a mistake to occur. Yes, you can blame the user for making the mistake, but the software promoted the likelihood of the mistake because of the inconsistency.

Unlike workflow errors, which can vary by specialty and geography, most interface errors can be resolved before the product leaves the developers. This is a field that has been well studied for decades, and NIST has developed resources to assist those EHR developers who have not created their own processes. Other health IT developers are likely to find useful tips as well at www.nist.gov/itl/iad/ehr-032012.cfm and www.nist.gov/itl/iad/creating-usable-ehrs.cfm

Calculation errors can be tricky to identify. Simple ones, like division by zero, appear early in testing. More complex calculations, based on multiple inputs, may not be immediately clear unless rigorous consideration is given to edge cases.

  • What happens if the units we expect (e.g. kilograms) are different than the units we receive (e.g. pounds)? How will we know what the units are?
  • Do our algorithms work in all stages of a patient’s life: intrauterine, immediately postpartum, less than a month old, less than a year old, infant, child, adolescent, young adult, adult, elderly?
  • Will different specialties (e.g. pediatrics, OB/GYN, cardiology, cardiac surgery) interpret the data or data request in the same way? Are we asking for the data using clear language? Is specific training needed?
  • Do laws and regulations in different states or countries impact our assumptions?

In most cases, the best answers will come from thoroughly involving your users in the design of your products.

This entry was posted in Health IT and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s