Prelude: If you have a sentinel event, and if you don’t have a formal process already in place, you’ve essentially lost this battle already, because you’re in the position of crisis functioning. Recoup by bearing in mind that the JCAHO is expecting a gradual development of processes for conducting Root Cause Analyses™, and is likely to be quite lenient in terms of the very short time parameter (45 days) which has been established in which to complete a “thorough and credible” Root Cause analysis. If you do not now have a sentinel event which you must investigate, establish your processes now, so that you are not functioning in a crisis mode when a sentinel or other adverse event occurs. As you do so you must keep in mind all the rather vague terms by which the JCAHO will judge the quality of your analyses. The JCAHO has not yet clearly articulated the criteria by which compliance with the Standards will be measured; this will be an iterative and evolutionary process, as with most JCAHO Standards. Do your practice Root Cause Analyses™ on non-sentinel events; we conducted a Root Cause analysis for training purposes on a simple patient fall, with no real adverse outcome, but which ended saving the involved hospital approximately $525,000 in direct costs, and an unknown amount in prevented litigation incidents.
You should also be aware that the JCAHO Sentinel Event Policy has been labeled “a lawsuit kit for attorneys” (Healthcare Risk Management, July 1998)
We wish first to offer two descriptions of sentinel events.
The first is by a prominent software developer who is now marketing his non-medically oriented Root Cause analysis software to the health care industry: “All sentinel events are the result of human errors that queue up in a particular sequence.”
The second is by Lucian Leape, an internationally known expert in quality management: “Errors must be accepted as system flaws, not character flaws.”
Clearly the philosophy articulated by the first of these is not consistent with performance improvement thinking in the health care arena. The Root Cause analysis methodology chosen must be carefully selected to reflect the philosophy espoused by the organization conducting the analysis.
In the remainder of this article, we offer a simplified representation of the process we use and teach in conducting Root Cause Analyses. Our experience has been that following this process leads to effective problem identification and effective system improvements, with a much reduced resource expenditure. Our data indicates that using this process costs approximately that of other processes, with no apparent decrement in the “thoroughness and credibility” or value of the analysis.
If you are unclear about any of the steps outlined in the following, please do not hesitate to contact us via email.
Identify that an adverse event has occurred. You must have defined and disseminated information throughout your organization as to what constitutes both a sentinel event and an adverse event (yes, we advocate conducting Root Cause Analyses on non-sentinel events) about which you wish to be notified, and you must designate who is to be notified and how. Make the notification simple. Use common sense. You want people to report to you, not to the newspaper or the JCAHO. THANK them for reporting the incident, make it easy to do, and make certain that they are included for feedback when the final results are announced.
By having a reporting process established, you also have defined to whom those reports go. That office, typically the office of the risk manager, then must determine expeditiously whether or not a Root Cause Analysis is needed. This may involve a decision by a Risk Management Advisory Board or equivalent. That body can’t just meet monthly….
If a Root Cause Analysis is deemed appropriate:
Appoint an RCA facilitator and an RCA team leader — you need both
Facilitator: the process expert on conducting a Root Cause Analysis
Team Leader: the content matter expert pertaining to the event
Who’s in charge? The Facilitator
The team leader and facilitator sit down and identify:
What data has to be acquired and/or safeguarded, who should do it and how: medical records, statements from personnel, maintenance records, instruction manuals, policy manuals, literature, etc.
Who should be on the team? It is far better to be over-inclusive than under-inclusive. In point of fact, in our consultations we invite every person in the involved department(s) to every Root Cause Analysis irrelevant of their involvement with the incident under analysis. There are two reasons:
Everyone learns the process
Some of the best ideas come from those not involved in the event.
Notify each invited person to bring with them a written (preferably on disk) sequence of everything that they observed, every idea which has occurred to them.
Establish the first meeting date and time. This is where we break with the JCAHO. The JCAHO manual suggests that everything gets done by the Root Cause Analysis team. Our studies have shown that this will virtually guarantee your facility going into receivership; it simply costs too much. Therefore what is outlined here is the model which we use, teach and advocate. It should be mentioned at this juncture that the feedback received from JCAHO reviewers on the Root Cause Analyses conducted using this approach have been very well received. The fact that facilities with which we consulted presented Root Cause Analyses which were conducted on non-sentinel events amazed the reviewers. That they were done well impressed them even more.
This is our format. We feel that three and occasionally four meetings of no longer than two hours each are sufficient for a worthwhile Root Cause Analysis, excluding additional time spent between those meetings. Schedule two hours each, the third may well be less and the fourth may not be needed, but typically allow a week between meetings.
Start the first meeting; we prefer an active interplay between the facilitator and the team leader. Allow for brief introductions if there is anyone unknown. Always have a recorder to take notes (preferably not an active participant in the analysis). Always have one or more “white boards” and if possible have a computer with projector.
Tell everyone why the group is meeting. “We are here to find out all we can about such and such an event; how it happened, how it might be prevented in the future.” Emphasize that the purpose is not to find fault, but to prevent future mishaps. There will be some initial disbelief here — tell the group that you expect that, and you just hope that they will come to trust the team and the process. We frequently give examples of RCA’s in which it initially appeared that specific persons were at fault but that the analytic outcome demonstrated a series of system failures which were corrected without action against any person. We will commonly repeat the National Patient Safety Foundation’s philosophy that “…most errors result from faulty systems rather than human error … that people are in essence ‘set up’ to make errors for which they are not truly responsible.” You want an example — an incorrect medication order by a resident who has been on duty for 36 hours, to a nurse who is just finishing a double shift. Who’s at fault? The exhausted resident and nurse? Or the system parameters, the process, which assigned those work schedules? Now we’re looking at the distinction between a proximal cause and a root cause (or as we prefer, root contributor or contributory factor). Block off a part of the board as a ‘parking lot’ in which to write items that don’t apply now, but which should not be forgotten. Start by generating the sequence of events. In the event of an injection of KCl that sequence might cover only several hours, while with an inpatient suicide it might be months. Type this via computer projector on the screen so that it can be easily seen and modified. During this time, people will start suggesting causes, solutions, etc. Write them down in the parking lot, avoiding discussion of anything but the event sequence for now. Make the sequence detailed and complete, and continue until everyone is satisfied. This will typically take about one hour. Save it to disk. Identify the immediate corrective actions which were taken at or near the time of the event. Save it to disk. Now take a break — though some teams will prefer to drive on, which should be allowed if that feeling is unanimous. Have the team look at the sequence of events and mark every item which might in some way have contributed to the adverse event. If just one person thinks it should be marked, mark it. Now go to traditional brainstorming with the marked items from the event sequence serving as a starting point, letting the group come up with any and all ideas about events, conditions or whatever which might in some way have contributed to (not caused) the adverse event under analysis. Use the parking lot when appropriate, to record ideas that are solutions, or incidental but interesting thoughts. We advise verbal brainstorming, since we have found that people tend to stimulate others’ thoughts. Review the JCAHO manual (“Conducting a Root Cause Analysis in Response to a Sentinel Event”) wherein among other things you will find a list of possible contributors common in medically-related sentinel events. Use such items as prompts to stimulate the team’s brainstorming efforts. Use Barrier Identification (a simplified variant of barrier analysis) to identify those barriers which either failed to function or did not exist. Add these to the list of potentially contributory factors developed by brainstorming. Now affinitize. Let the team eliminate duplications, combine items, and then form logical clusters from the brainstorm items. When everyone is reasonably satisfied with the affinitization or clustering process, the first meeting ends, with the second meeting typically scheduled for one week later.
During the intervening week, the team leader and facilitator meet together and attempt to develop a “Contributory Factor Diagram” from the material generated by the team. This term does not appear in the literature — but there are lots of terms that do. We use this label to emphasize that we wish to identify not just causes, but contributors to an adverse event. The diagram is nothing but a flowchart with all the lines eventually leading upwards to the adverse event. That’s the top of the diagram. The second level is the names assigned to each cluster from the affinitization process your team went through. Under each cluster name, in parallel so that equal weighting is implied, lies every member of that cluster. Move clusters around, see if one subsumes another, etc. Play with the diagram. Needless to say, good flowcharting software is a great assist here (We use allCLEAR 4.5 by SPSS). Even try to re-affinitize the items, so long as you also retain an original version as your team left it. Take a look at each of those third tier items and ask the question “WHY?” or “HOW?” You may identify areas of insufficient data, or you may be able to place new items at the fourth, fifth or even sixth level. Your goal is to go as far as possible with the facilitator and team leader asking the question “Why?” until it can no longer be meaningfully asked. Do this for every third tier item. Code each of the bottom items of every branch as “Insufficient Data”, “Non-Contributory”, or “Contributory Factor” and color/shape code those three categories.
Assign persons to get the missing data before the next team meeting.
Start your next meeting, and ask for the team’s input on your “Contributory Factor Diagram or Tree.” Let them check for omissions, better organization and more logical flow. Let them generate alternatives. Have the team verify or dispute your categorization; see if they can ask the question “Why?” more or in different ways. Reach a consensus on the diagram. This will typically take approximately one hour. By the end of this time, there should be few or no Insufficient Data labels. Make certain that every factor labeled “Non-Correctable” is in fact so. Every “Contributory Factor” which has no lower-level derivatives is a root cause — we just avoid that terminology for psychological and legal purposes.
Examine the items you have identified as “Non-Contributory.” In the most formal quality improvement sense, such items should not appear in your Root Cause Analysis, since they are, as indicated, “Non-Contributory.” In point of fact, certain of these items will be of such high visibility that you must mention them just so that reviewers, either internal or external (like JCAHO) know that they were considered. Prepare a list of such items. We frequently go so far as to retain them on the Contributory Factor Diagram labeled as “High-Visibility, Non-Contributory Factors.”
You have just completed the Root Cause Analysis proper — Now for the action plan.
Have the team generate at least one corrective action or improvement for each “Contributory Factor.” In some cases that action will be to recommend that hospital administration designate a working group to address a specific issue. But every “Contributory Factor” must have some corrective action associated with it.
Develop a Root Cause Analysis reporting table or grid with columns for:
Action Due Date,
Person(s) Responsible, and,
The team may not be able to complete this grid in this meeting. If not, it becomes the task of the team facilitator and leader to do so to the best of their abilities, before the third meeting, one week hence, for review and further elaboration by the team.
You are now ready for the third, and typically final meeting of the Root Cause Analysis team.
Present to the team the:
Contributory Factor Diagram, and,
Root Cause Analysis Reporting Grid.
Ask for feedback and changes, especially in the area of additional opportunities for improvement. Identify as a team who should receive copies of the entire work, and who is responsible to distributing those copies (typically the facilitator and team leader). At a minimum the communication in whole or part should include the heads of involved departments, all involved persons, the office of risk management and the office of continuous performance improvement (change names to suit your agency). Don’t forget to at least discuss the findings with the person who reported the event.
Address parking lot items if not already done. Terminate the team.
It becomes the obligation of the continuous improvement office within each facility to monitor progress made in the corrective actions proposed, and in evaluating the measurements used to evaluate those improvements. That office must have established suitable processes to ensure that there is appropriate follow-through in accordance with the action plan.