Safe Patient Care

July 1, 2000

Safe Patient Care

By Pat Tydell, RN, MSN, MPH

This article discusses:
  • How to face one of the major challenges facing healthcare today--becoming a highly
    reliable industry.
  • Why adverse, tragic events have led to a concern about controlling risks.
  • How the work of a small group of physicians, who had also studied error in medicine,
    began to organize and to instruct the field on how to reduce medical errors through using
    many methods including use of root cause analysis, cause-effect relationships, and pareto

Historically, the healthcare industry has not viewed itself as a high-risk industry and
has not used the same type of rigorous, systematic review of each adverse event or
untoward outcome as has been done in high-risk industries like aviation and nuclear power.
For example, there is no oversight entity for the healthcare industry like the National
Transportation Safety Board (NTSB) that deconstructs and analyzes each airline accident to
isolate the critical causative factors and to develop approaches to minimize future
occurrences through technical design changes, system or process changes, or improved
training. Similarly, unlike the nuclear power industry, healthcare has not widely used
detailed process engineering that carefully analyzes alternative scenarios to
prospectively establish the safest, most risk-free method to handle potentially hazardous
situations. The aviation and nuclear power industries have controlled the risk of adverse
events by focusing meticulous attention on the design of their operating systems to make
it difficult for personnel to make mistakes and easy to correct mistakes before they
result in an untoward outcome. The result, contrary to public perception, is that these
high-risk industries have reduced their risk of an adverse event 1,000 to 10,000 times
lower than what occurs in healthcare. One of the major challenges facing healthcare today
is to become a highly reliable industry such as in aviation and nuclear power generation.

The need for reducing risk in the healthcare field has come into clearer focus for the
public beginning with the catastrophes of 1995. That frightening and disorienting year
produced a rash of tragic patient accidents. It began with the news that Betsy Lehman, 39,
a health columnist for The Boston Globe, had died not of breast cancer but of a fourfold
miscalculation in the amount of the chemotherapeutic drug she was receiving at Dana-Farber
Cancer Institute. It happened because the total dose to be given over four days instead
was given on each of the four days, an error that was not corrected by doctors, nurses, or
pharmacists. A similar incident occurred at the University of Chicago Hospitals where a
40-year old man receiving chemotherapy for prostate cancer was given a lethal dose of this
drug. At about the same time of the Dana-Farber incident, a vascular surgeon at a hospital
(Tampa, Fla), was accused of amputating the wrong leg. Then came reports of surgery on the
wrong side of the brain at Sloan-Kettering Cancer Center in New York.

The year ended badly. Seven-year-old Ben Kolb entered Martin Memorial Hospital (Stuart,
Fla) for an elective ear procedure and died during the procedure as a result of receiving
the wrong drug during the surgery--at a lethal dose. A bright, beautiful
twenty-one-year-old with asthma and allergies had been receiving allergy shots for a year.
She was wheezy and congested, so her doctor put her on an antibiotic, steroids, and
several other medications. On December 27, 1995, she went to her appointment and was given
her allergy shot. Her reaction came within minutes of the shot. Her heart stopped. She was
put on life support and was removed from it. She died on December 31, 1995.

The errors continued into 1996. A two-month-old baby boy was given 0.9 milligrams of
Digoxin, a heart drug, when he should have been 0.09 milligrams. The baby died in spite of
all resuscitative efforts. In October 1996, a medication error at a Denver hospital
resulted in the tragic death of a newborn and the indictment of three nurses on charges of
criminal negligent homicide.

These adverse, tragic events did not go unnoticed by practitioners within the
healthcare industry this time. Although the field for studying errors of human factors
began in the 1940s, the healthcare industry, especially medicine, routinely dismissed
these types of studies as unsound and alarmist. After the events of 1995, the work of
these psychologists and engineers came together with the work of a small group of
physicians, who had also studied error in medicine, began to organize and to instruct the
field on how to reduce medical errors. This partnership was formalized into The National
Patient Safety Foundation (NPSF) headquartered at the American Medical Association in
Chicago. This partnership produced two groundbreaking conferences in 1995 and 1998 and an
avalanche of articles, studies, and experiments in the field of error reduction. The
interest in the healthcare field on how to study and to reduce errors has introduced
medical personnel to the tools of psychology and systems engineering. The Joint Commission
has also responded by developing new standards and requirements for their accredited
facilities on how to identify errors, report them, and conduct reviews. The process used
for studying adverse events in an organization will be discussed.

What Can a Healthcare Organization Do to Reduce Errors or to Find the Cause When an
Error Occurs?

When a healthcare organization is faced with an error or needs to uncover the cause of
a near miss or problem, one of the most helpful and useful processes is to conduct a root
cause analysis. A root cause analysis is a process for identifying the most basic or
casual factor or factors that underlie variation in performance, including the occurrence
of adverse events.1 This type of analysis has the following characteristics:

  • Focuses primarily on systems and processes, not individual performance.
  • Uncovers special causes in clinical processes and common causes inherent in the process
    or system.
  • Repeatedly asks "Why?" questions to probe deeper.
  • Identifies changes that could be made in systems and processes to improve the level of
    performance and reduce the risk of serious adverse events occurring in the future.

This analysis uncovers special and common cause variation in whatever process or system
is being studied. All processes have variation inherent in them. Variation is defined as a
change in the form, position, state, or qualities of a thing.1 For example, the
process of sterilizing instruments varies from time of day, day of the week, and the
technician doing the process. To reduce variation, it is necessary to determine its cause.
A common cause is a type of variation inherent in every process. It is the consequences of
the way a process is designed to work. A process that varies only because of common causes
is said to be stable. To improve the level of performance of a stable process, the process
needs to be redesigned. For example, one common cause variation in sterilizing instruments
is the time it takes to clean, sterilize, and return the instruments to be used again. To
improve this process, i.e. decrease the amount of time it takes to complete this cycle, a
redesign of the process would have to be done. This redesign would include standardization
of trays and procedures, assembly line methods, additional instruments or sterilizers, or
more staff. A special cause variation in a process comes from unusual circumstances or
events that are difficult to anticipate. Human error and mechanical malfunction are
examples of special cause variation. In the example above, a special cause variation could
be a utility outage or sterilizer breakdown. Special causes are somewhat easier to
identify and to eliminate. However, special causes in a process are usually the result of
common causes of a system. The department that fails to establish contingency plans for
unplanned utility outages or to implement an equipment maintenance program will continue
to have special cause variations until they redesign their system of planning and
preventive maintenance. When an organization or a department suspects that errors can
occur or have had them occur, a root cause analysis should be done. This determination
will identify those special cause and common cause variations so the facility can take

How Is a Root Cause Analysis Conducted?

A team approach is used to conduct a root cause analysis. This team is composed of
staff who is closest to the process or system and those who have decision-making
authority. The team will be made from staff at various levels of organization. Since power
and control are issues with a team of different experience, education, and status levels,
it is best to have a person trained in group facilitation to be the facilitator. Also
helpful is a resource person to provide help using the tools of root cause analysis. A
leader should be identified clearly, and the group should have the support of top
management to meet as frequently as necessary. Top management should also empower the team
to do its assessment and make changes or recommendations for changes. Resources, including
time, to do its work need to be provided. Lastly, ground rules for team functioning and
composition need to be established at the beginning. Frequently, as the assessment
proceeds, additional members may need to be added or consultants brought in.

The team needs to create a work plan. This plan should include how and when the team
will communicate to senior leadership. It needs to include target dates. Clearly define
the issue(s) regarding the process or system being studied. What is obvious to some
members of the team may not be obvious to all.

The best way to start the analysis is to use the technique of brainstorming all
possible or potential contributing causes. Following traditional brainstorming ground
rules, there are no bad ideas. All ideas are accepted without judgement. It is best to
have the leaders or facilitators write the ideas down. A flip chart is very useful as it
can be mobile and ideas can be displayed. Focus the team on processes, not people. For
each idea, ask "why?" and keep asking until the team has exhausted all possible
questions and causes. This stage of the analysis is the key. It provides the initial
substance for the analysis. If team members are having difficulty, have them write down
their ideas on post-it notes and put them in rows on the flip chart or go around the table
asking each member to identify one idea.

Now take these ideas and categorize and organize them. For example, there may be
several ideas that can be categorized under the theme of "equipment" or
"materials" or "employees." The best way to depict these causes
graphically is to construct a cause and effect (fishbone) diagram. This analysis tool can
help the team see relationships and develop further causes. Begin determining which
process(es) or system(s) each cause is a part of and whether it is a special or common
cause in that process or system. Categorizing the causes as special or common is not an
inherent characteristic of the cause itself. It describes the relationship of the cause to
a specific process or system. A special cause in one process could be a common cause in
another. To assure that the group gets to the root cause, ask "why?" at least
five times in each category. In the example of the utility outage as a special cause of
sterilizing instruments, the questioning would go something like this:

1. Why did sterilization of instruments stop on March 1? Because there was a utility

2. Why was there a utility outage? Because there was a water main break in the city.

3. Why did this water main break in the city affect us? Because we have no back-up plan
or equipment if the bigger system fails.

4. Why don't we have a back-up5 system? Because we haven't planned for one.

5. Why haven't we planned one? Because this problem hasn't happened before.

This process of digging deeper into causes will help point the way to common causes.
Another tool that is especially helpful in showing that a special cause in one area can be
a common cause in another is the flowchart.

Search for a special cause's common cause in a system by using flowcharting. For
example, a special cause may be the technician's inability to make the correct decision
about which type of disinfectant solution to use. This is the human error type of a
special cause. However, in a system flowchart, this special cause could be a common cause
due to inadequate orientation and training of employees. A technician may make the
"wrong" decision because the system does not provide adequate orientation and
on-the-job training or proper supervision.

The root cause analysis does not need to be completed before changes are implemented.
If the team feels that immediate changes are needed, they need to communicate this need to
senior leadership for action. The organization does not need to have the fifth dirty tray
reach the surgical suites to take immediate action. The deeper issues may need to be
assigned to other departments of the organization as part of its quality improvement

Throughout this analysis, do periodic assessments of the team's progress. Interium
reports are useful as are minutes. Remember, you can repeat activities as necessary. The
team can go back to brainstorming if they get stuck creating a cause and effect diagram.
Above all else, be thorough. Although the team may make improvements along the way, it
should not stop its analysis until the root cause is identified. Focusing improvements on
larger systems is a way of correcting common cause variation. This is so frequently the
"cause" of special cause variation. These improvements are redesigns of systems
that involve changes in training, policies, procedures, forms, and equipment. These
changes take time and are resource intensive to the organization.

Lastly, and most important, have a measurement strategy in place to determine if
changes made achieve the desired effect. In the example of a shutdown in sterilization
processes, waiting for another water main to break is impractical. However, conducting a
mock unplanned utility outage to test the new system can provide the organization with
valuable information of the changes made as a result of the root cause analysis. The
utility need not be water. If the organization has truly redesigned their system, any type
of utility could be mock tested.

What Additional Items Need to Be Considered in Doing a Root Cause Analysis?

Three additional issues need to be considered when doing a root cause analysis. The
first is individual error. Errors by individuals should be initially considered as a
special cause variation that leads to the discovery of common causes. Few persons come to
work and decide that this is the day they will make a mistake. The technician who selects
the wrong disinfectant does not stand there with two types of disinfectants in hand and
consciously picks the wrong one. Individual errors are most likely the result of common
cause variation of the system and its processes. Those processes most likely are hiring,
competency review, continuing education to update staff, supervision of staff to measure
their performance, communication and accessibility of the information, and design of
processes in the work area. Management is responsible for designing processes to control
causes that persons cannot control for themselves. In systems, examples of these causes
are purchasing practices and procedures, contract negotiation, and work environment
organization. In individuals, examples of these causes are memory, distraction, fatigue,
and attention. Processes designed to minimize such weak cognitive functions as memory and
attention will alleviate human errors in many work tasks performed. Secondly, a root cause
analysis needs to be organized and procedured in a logical manner. The Joint Commission
has a well-publicized framework for conducting a root cause analysis. It is presented here
as one way to organize this task.

Lastly, there are a variety of statistical and non- statistical tools that can help to
uncover the root causes of a process. These include flowcharts and cause-and-effect
diagrams as non-statistical tools and Pareto charts and scatter diagrams as simple
statistical tools. Though there are other, more complex tools, these will be the mainstay
tools of the analysis. Flowcharts are graphic representations of either the actual or the
ideal path that a process follows from start to finish.2 A cause-and-effect
diagram shows the many casual relationships between various actions or events leading to a
specific outcome.3 A Pareto chart uses a vertical bar graph format to show the
comparison between events according to their relative frequency or magnitude.3 This
is the familiar 80/20 Rule or Pareto's Rule. It states that 80% of your problems/events
comes from 20% of your causes. Therefore, it is used to determine the relative importance
of a number of causes in order to choose the one or two that will have the most impact on
the event. Scatter diagrams are graphs designed to show the statistical correlation
between two variables.3 These diagrams do not necessarily show cause and effect
but a relationship. They are most useful when a team wants to show which changes had an
effect. For example, if a team wanted to show the impact of the redesigned process of
sterilizing instruments, they could depict the relationship between the new process and
the number of rejected instrument trays.


This brief discussion on root cause analysis as a tool for reducing errors is an
introduction into the studies of a great many persons. It is a useful tool to organize and
to systematize the study of errors. It can be used for any process, even if an error has
not occurred in it for the true value in learning about errors and reducing them is to
bring about safe patient care.

Pat Tydell, RN, MSN, MPH, is a Risk Manager responsible for coordination and
oversight of patient safety improvement at the North Chicago Veterans Administration
Medical Center (North Chicago, Ill).

For references, access the ICT Web site.

For a complete list of references click here