Safe Patient Care

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 charts.

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 action.

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 outage.

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 program.

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
Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.