Assess the Problem

A systematic approach will help you pinpoint the underlying causes of the most difficult-to-diagnose EHR-related problems.

Question: How do you pinpoint the causes of unintended consequences?

In some cases the Issues Log may contain all the information you need to identify the root causes of your EHR-related problems. For example, problems that stem from software malfunctions are likely to be diagnosable based on the information collected in the Issues Log. However, issues that arise from interactions between the EHR and other components of the work environment or infrastructure will likely require further investigation.

Pinpointing the Causes of Difficult-to-Diagnose Problems

Below we outline several steps that you can take to identify the root causes of EHR-related problems that result from interactions between the EHR and other components of the work environment and infrastructure. The process outlined below relies on the ISTA framework described in Module III, and uses the first issue reported in the sample Issues Log as a case in point.

Step 1 — Define the problem: This should be a fairly concise description of the problem. The description captured in the Issues Log should provide sufficient information to define the problem. For example the first issue (ID=1) in the sample Issues Log reads:

"CPOE calculated incorrect heparin dose. Dosing error was not identified and patient received an overdose of heparin"

Step 2 — Gather evidence: The Issues Log should contain valuable information about the problem (for example, when and where it occurred, and the potential causes and impacts of the problem.) The evidence collected in the Issues Log will help you formulate hypotheses about why the problem occurred. In the case of the heparin overdose, the Issues Log indicates the date and time when the event took place and notes that the problem was associated with clinicians working with the computerized physician order entry (CPOE) module of the EHR.

Additionally, ask those who were directly involved in the incident or those who have knowledge of the problem to describe what happened. Ask probing questions and follow up with more specific questions to ensure that you are able to focus on the root causes of the problem, rather than just the symptoms. The questions you ask will vary with the context and characteristics of the problem you are facing. Below is a "starter set" of questions that can help you formulate questions to identify the root causes of your EHR-related problems.

Identify Root Causes: This document contains a list of questions that you can use or adapt to identify the root causes of your EHR-related problems. In addition, AHRQ has made information and tools related to conducting root cause analyses available through its patient safety network.

Step 3 — Construct a timeline: Your efforts to gather evidence should yield an extensive list of potential causes. For problems that resulted from a series of events that occurred over time it may be helpful to construct a timeline. (For other types of problems, a cause and effect diagram might be more useful). Carrying forward the example of the heparin overdose in the ED, several potential causes emerged after a review of the Issues Log and interviews with those involved in the incident. Figure 4.1 presents a timeline of events that led up to the adverse event that resulted from the error in the EHR entry.

Figure 4.1 Timeline of events that led to the heparin overdose in the ED (Click image to enlarge)

The timeline makes it possible to construct the chain of events that led to the adverse event. In this case a patient arrived at the ED with a suspected deep venous thrombosis (DVT). During triage, the nurse entered an incorrect weight into the EHR. The physician did not notice the erroneous weight during her examination. Following the exam the physician used a paper form to place an order for heparin infusion. The paper form was picked up by the nurse, who entered the order via the EHR's integrated CPOE module. The system's automated dose calculator used the erroneous weight that was entered earlier to calculate the dose. This resulted in the system recommending a dose significantly higher than was appropriate for the patient. The nurse did not recognize the error and began the infusion using the CPOE recommended dose. Several hours later, the patient experienced severe hemorrhage.

Step 4 — Construct a cause and effect diagram: The cause and effect diagram is frequently used to classify the root causes of problems when many interacting factors are involved. Figure 4.2 illustrates an empty cause and effect diagram that is based on the ISTA framework. The cause and effect diagram consists of a horizontal line pointing to the unintended consequence, and four diagonal lines above or below the horizontal line that are each labeled with one of the ISTA interaction types:

  • The EHR (as designed) interacts with the work environment
  • The EHR (as designed) interacts with the physical or technical infrastructure
  • The work environment interacts with the EHR (as used)
  • The physical or technical infrastructure interacts with the EHR (as used)

 

Figure 4.2 Example of an empty ISTA-based cause and effect diagram (Click image to enlarge)

The cause and effect diagram can be used to graphically classify all of the potential root causes that were identified during your information gathering activities.

Turning back to the example from the Issues Log; the first potential cause of the adverse event in the ED was that a nurse entered an incorrect weight into the EHR during triage. This error was amplified when the system's automatic dose calculator used the previously entered weight to calculate the patient's heparin dose. At this point one might conclude that the adverse event was simply the result of a data entry error; however, the ISTAframework encourages further thought about what other factors might have contributed to this adverse event. For example, questioning those involved in the incident yielded several other potential causes of the adverse event:

  • ED patient volumes have significantly increased; physicians and nurses often feel overwhelmed
  • Computerized order entry increases workload
  • Physicians were not mandated to use the order entry module
  • Paper-based order forms were still available in the ED
  • Physicians often had non-prescribers (nurses and clerks) enter orders
  • There was no policy or procedure that would ensure independent double checks on high risk medications
  • Workstations were located in busy areas, where distractions were more likely to occur

All of the potential causes identified for the example case have been added to the cause and effect diagram displayed below. Each of the suspected causes has been assigned to one of the ISTA interaction types.

Figure 4.3 Example of a completed ISTA-based cause and effect diagram (Click image to enlarge)

In this case it appears that CPOE in the ED created new work for an already busy ED physician. The physician's response was to exploit the lack of an appropriate organizational policy and find a way to work around the system (i.e., shift the order entry burden off to the nurses.) This workaround, combined with the nurse's overdependence on technology, made it possible for a relatively simple data entry error to be amplified into a serious adverse event.

Step 5 — Develop causal statements: The next step is to further refine the list of potential root causes illustrated on the cause and effect diagram. Developing a set of clear and concise causal statements will help you focus on the systemic vulnerabilities that led to the problem, and therefore help you design more targeted approaches to eliminating and managing similar problems in the future.

The National Center for Patient Safety (U.S. Department of Veterans Affairs) recommends five rules for developing usable causal statements:

  1. Clearly show the cause and effect relationship. If you eliminate the root cause or contributing factor you will reduce the likelihood of similar problems occurring in the future.
  2. Use specific and accurate descriptors for what occurred, rather than negative and vague words. Avoid words with non-specific negative connotations or that assign blame (e.g., careless, poor, sloppy, etc.)
  3. Identify the preceding cause(s), not the human error. Focus on systemic vulnerabilities, not human error.
  4. Identify the preceding cause(s) of procedure violations. Focus on the root causes, not the symptoms.
  5. Failure to act is only causal when there is a pre-existing duty to act. In some cases the absence of policies and procedures is the root cause.

Based on the potential causes and contributing factors shown in Figure 4.3, we developed three causal statements for the heparin case.

Causal Statement 1: High patient volumes and distractions in the Emergency Department increase the likelihood of data entry errors. In this case an erroneous weight was entered into the EHR during triage. The erroneous weight led to a miscalculation of the heparin infusion, which caused major bleeding.

Causal Statement 2: Some ED physicians feel that CPOE is slow and prefer to use paper prescription order forms. In this case a physician chose to use a paper order form and gave it to a nurse to enter into the CPOE. The nurse entered the order and the CPOE system recommended an inappropriate dose. The nurse did not recognize the error and initiated the heparin infusion, which caused major bleeding.

Causal Statement 3: Lack of a policy mandating independent double checks of high-risk medications increases the chance for error. In this case, a single nurse did not detect a dosing error and administered an excessive dose of heparin, which caused major bleeding.

The causal statements should enable you to clearly articulate one or more root causes of your EHR-related problems. The next section of Module IV focuses on how to develop a plan for remediating EHR-related problems.