Conducting a Cost-Effective Root Cause Analysis
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 damned 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, and, |
|
|

|
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 by
SPSS), which we have also embedded in our root cause analysis and peer review software, Root Cause Analyst TM. 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:
|
| |

|
Contributory Factor, |
|
|

|
Corrective Action, |
|
|

|
Person(s) Responsible, |
|
|

|
Action Due Date, |
|
|

|
Measurement Technique, |
|
|

|
Person(s) Responsible, and, |
|
|

|
Follow-up Date. |
|

|
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: |
|
|

|
Event Sequence, |
|
|

|
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.
|
Root Cause AnalystTM is developed in partnership with
Accurate Assessments. Call 1-800-324-7966 to find out how to purchase Root Cause AnalystTM or visit the Accurate Assessments Web site at
www.accurateassessments.com
Root Cause Analyst TM Software | FAQs on the Issues | Root Cause Analysis Training
Cost-Effective Root Cause Analysis | Root Cause Analysis Software - Article
Resource Links | Guestbook | About MRMA | Email MRMA
Sponsored by Medical Risk Management Associates, LLC
HRM Consulting and Software Development Specialists
Copyright© 1998,1999,2000 MRMA, LLC. All rights reserved. All other trademarks are the sole property of their respective owners.
Page last modified 22 March 2000.
|