Chapter 10. Human Factors Informed Root Cause Analysis
Section 10.1. Setting the Stage
Root Cause Analysis (RCA) is a retrospective incident investigation framework,
initially developed as a quality management engineering tool, that is now widely used in
many industries to support the improved safety of systems following an accident or
incident. In healthcare, regulators such as The Joint Commission have mandated immediate
investigation and response following a sentinel event, which is “an unexpected occurrence
involving death or serious physical or psychological injury, or the risk thereof” . RCA is
a means by which this type of investigation and response can be accomplished.
Like the other human factors methods presented in this handbook, a central tenet of
RCA is that in healthcare, inherently people do not want to cause harm. Consequently, this
method focuses on identifying the system factors and issues contributing to an incident,
rather than what a person might have done wrong. The root causes inherent to the system,
and not the people, are the factors that will need to be addressed to improve overall system
safety. When individuals are blamed for an incident, remedial action tends to focus on the
person or people involved, but this represents a missed opportunity to make wider
reaching changes to the system, aimed at preventing future occurrences of the same, or a
similar error. Unfortunately, there are many examples of healthcare professionals who
have unintentionally made errors as a result of a poor system design, and who have
received harsh punishments such as losing their professional license, or being criminally
charged [45, 46]. These punishments are in addition to the guilt, mental anguish, and loss
of self-confidence experienced as a “second victim” of the incident [47, 48]. In the case of
one such second victim blamed for an accidental calcium chloride overdose that led to the
death of an eight month old patient, the emotional stress of the aftermath of the incident
led her to commit suicide .
These types of tragic outcomes for staff involved in an incident are not inevitable.
Rather than assigning blame, if one instead applies systems thinking and views an incident
as a series of system failures ultimately contributing to a sentinel event, identifying and
addressing those system failures will serve to strengthen the system and improve the
likelihood that future similar incidents will be eliminated.
To support the completion of an RCA several quality and safety organizations, such
as The Joint Commission, the VA National Centre for Patient Safety, ISMP Canada, the
Canadian Patient Safety Institute, and the NHS (UK) have developed different RCA
frameworks and tools. For example, the Joint Commission offers an online RCA framework,
along with publications about specific sentinel events that have been investigated using
RCA. Additionally, the VA has online tools and triage cards, ISMP Canada has
published several high profile RCA investigations, ISMP Canada and CPSI have jointly
authored the comprehensive Canadian Incident Analysis Framework  and the NHS
(UK) has an online Root Cause Analysis Toolkit and eLearning Programme .
For the purposes of this handbook, portions of these RCA frameworks will be
combined and various human factors methods will be incorporated to create an HFRCA
Section 10.2. What is HFRCA
HFRCA is a human factors analysis method used to retrospectively identify root
causes and contributing factors leading to a incident. A root cause can be considered an
initiating factor leading to a particular effect or outcome and a contributing factor can be
considered a condition that influences a particular effect or outcome. Ideally, a
multidisciplinary team works together to collect information, document the incident,
identify the root causes and contributing factors, and identify mitigating strategies targeted
at improving the system in order to prevent similar incidents from happening again.
The HFRCA aims to improve on the more traditional RCA method by incorporating a
range of human factors methods during the analysis to:
• Determine whether an HFRCA should be completed at all
• Promote the collection of accurate and quality data and artefacts from the
field in a tactful manner
• Document the events leading up to the sentinel event
• Enable the identification of root causes from a human factors perspective by
taking our natural human strengths and limitations into account
• Identify human factors informed mitigating strategies and set expectations
about how much risk is likely to be mitigated given the proposed solutions
Section 10.3. Why use HFRCA
After a sentinel event, or a near miss that could have negatively impacted patient
safety, an HFRCA should be conducted to examine and identify the root causes that
contributed to the event. Completing an HFRCA is strongly recommended because this
method allows the biomedical technology professional to go beyond the surface level
contributing factors, to the true underlying root causes of the issue. It is only when the true
root causes are addressed, that a reliable improvement to safety can be realized. These
more surface level contributing factors, called active failures, tend to be focused on a
person’s actions and are highly dependent on the context of the specific incident. When an
investigation stops here, it means that when other people find themselves in the same or a
similar situation, the sentinel event is likely to recur because the system factors that were
in place during the incident, still exist. In contrast, when the underlying root causes, also
called latent failures, can be identified and addressed, the design of the system is inherently
improved to support staff in performing safely, making the occurrence of a similar sentinel
When done well, an HFRCA can unite staff from across the organization who have
been touched by a patient safety incident. Organizational culture can be strengthened when
staff work together to identify the root causes that contributed to an incident, which can
lead to a strong resolve among staff members to improve the system in order to promote
From the biomedical technology professional’s perspective, completing an HFRCA
will be helpful for:
• Preventing similar sentinel events from recurring
• Retrospectively examining and managing the root causes contributing to a
• Retrospectively examining and managing the root causes contributing to a
• Meeting accreditation requirements following an incident
Section 10.4. When to use HFRCA
An HFRCA should be conducted following a sentinel event, an incident that resulted
in serious harm or death, or a near miss that could have resulted in serious patient harm.
Completing an HFRCA on a serious near miss that was caught can be an excellent
opportunity to proactively prevent other similar events from occurring.
Prior to conducting an HFRCA, the biomedical technology professional should ensure
they have the support and buy-in of management to increase the chance for uptake and
positive changes stemming from the analysis. In the case of a near miss, although an HFRCA
may not be required from a regulatory body perspective, a strong case can still be made
based on the liability associated with a possible future sentinel event with a history of near
Completing an HFRCA following an incident can be a cathartic experience for those
involved, providing an opportunity to strengthen workplace culture and unite staff in the
face of a tragedy.
Section 10.5. In Preparation for an HFRCA
There is little that can be done in preparation for an HFRCA. Often sentinel events
seem to occur suddenly, and so just being familiar with the HFRCA framework and being
prepared to work with senior leaders and act quickly once an incident has occurred, is the
Section 10.6. Completing an HFRCA
The HFRCA process comprises six steps, outlined in Figure 25. Each step will be
outlined and described in this section.
Figure 25. The six steps and opportunities to incorporate human factors as part of an HFRCA
Section 10.6.1. Determine Whether an HFRCA is Required
Following a sentinel event, the first step is to determine whether an HFRCA is
required. This should be done as quickly as possible to increase the chance of collecting all
equipment, supplies, and as much information as possible from the location of the incident
before anything is adjusted or removed by others.
As noted previously, a determination of whether the incident is considered
unintentional will have to be made. To assist with this determination, an Incident Decision
Tree developed by the NHS (UK)  and adapted for this text (Figure 26) should be used.
The decision tree is a tool that guides the process of determining whether an individual or
the system is culpable for a sentinel event.
To apply the incident decision tree, each of the four tests from Figure 26 should be
applied sequentially. If the actions were as intended and/or there is evidence of ill health or
substance abuse, the incident may have stemmed from a wilful action, and is not a good
candidate for analysis using HFRCA. In these cases, consult with the appropriate regulatory
bodies and union representatives, if applicable, and consider how the situation will be
handled by the healthcare organization.
Figure 26. Incident Decision Tree For Responding to Patient Safety Events. Reprinted with
permission (adapted from the UK National Health Service).
If the individual’s actions were not as intended and there is no evidence of ill health
or substance abuse, the foresight test is applied. In cases where an individual departed
from an agreed upon protocol or safe procedure, it is important to consider whether (1) the
protocols and procedures make sense, (2) they were readily used, and (3) they were
readily available to staff. Remember that given what we know about inherent human
limitations, trying to influence behaviour by writing expected actions in a protocol is not a
very robust strategy to prevent errors.
The final test requires the biomedical technology professional to consider whether
another individual in similar circumstances is likely to behave in the same way. It is
important to approach this final question from a human factors perspective, that is, to
consider the system factors that may have led someone to behave in a certain way. Keep in
mind our inherent human limitations (Chapter 3) and consider whether there might be any
deficiencies in training, experience, or supervision. In most cases, the biomedical
technology professional will find that sentinel events are a result of unintentional actions
leading to system failures, rather than from wilfully harmful actions.
When the incident decision tree points to an unintentional action resulting in a
failure, it indicates it is the system that has failed. These types of events are good
candidates for analysis using an HFRCA. In these cases, the healthcare institution will have
to determine whether the sentinel event will move forward for investigation using an
HFRCA. This decision will likely be based on many factors including legislative
requirements, accreditation standards, hospital policies, and resources. Since conducting
an HFRCA can be resource intensive, this kind of undertaking is more likely to be supported
when the organization is required to perform this type of analysis.
Section 10.6.2. Secure Items
As soon as the decision has been made to move forward with an HFRCA, it is critical
that all items used at the time of the incident, and any used shortly beforehand, be collected
and secured. If a technology is involved, the device must immediately be taken out of use
and the logs retained to ensure this information is available to the team going forward.
Other things to collect might include, but are not limited to:
• All medications and fluids, including packaging and sharps
• Copies of medication orders
• Medication labels
• Scrap paper used for calculations
• Any other supplies and packaging
• Photographs of the environment
• Photographs of the technology set up
• Screen shots from any electronic systems
• The patient’s health record
If the patient’s health record is obtained, make a copy for the unit to continue using
if the patient is receiving ongoing care and be sure to follow all privacy regulations when
handling the health record. Information about the unit such as a schedule, any shift
changes, new procedures, changes to equipment or supplies, organizational practices, and
policies can also be quite valuable if they are available.
Once these things have been collected from the field, a photograph should be taken
of each item and all lot numbers, serial numbers, and expiration dates should be recorded.
The items should be reviewed, and the biomedical technology professional should consider
whether there is any evidence of items that are inherently confusing, complicated, or seem
to be outside of what would be considered normal procedure (e.g., handwritten changes to
an order, look alike sound alike medications). Any of these types of observations should be
noted for future reference.
It is important to collect and document this information (e.g., through photographs
and written records) in a timely manner to ensure it is as accurate as possible because in
stressful situations especially, humans have inherent limitations in memory.
Section 10.6.3. Establish the Team
Once items have been secured from the field, a core analysis team must be
established to conduct the HFRCA. Team members should be knowledgeable about one or
more topics related to the sentinel event, be analytical, and have a mindset that supports a
just culture where health care organizations are accountable for the systems they have
designed and staff are accountable for their behavioural choices and reporting errors and
system vulnerabilities [56, 57]. Core team members should participate over the course of
the entire analysis but others may be involved as team members on an as needed basis to
support certain aspects of the analysis. For example, patients and family members, and
some subject matter experts, may only be involved while an initial understanding of the
incident is being developed. Thus, the size of the larger team will vary not only depending
on the context of the incident, but also the stage of the analysis.
Generally, teams should be multidisciplinary, including both clinical and non-clinical
staff, to represent a broad range of perspectives, and to provide valuable insight and
leadership to support the analysis.
Section 10.6.3.1 Complete a Confidentiality Agreement
Depending on the policies of your healthcare organization, team members may have
to sign a confidentiality agreement prior to participating as part of an HFRCA team. Signing
this kind of agreement can serve as a reminder of team members’ responsibility to protect
any information obtained as part of the HFRCA. The Canadian Incident Analysis Framework
 provides a sample confidentiality agreement in the event your healthcare organization
does not have a template prepared.
Section 10.6.3.2 Team Member Roles
Individual team members will need to fulfill a number of roles to ensure a successful
HFRCA. These roles include a leader, a facilitator, and a senior leadership representative. In
addition, you will need subject matter experts who are knowledgeable and can provide
information and think critically about the system factors that may have led to the sentinel
event such as technologies, processes, environmental factors, policies, training programs,
organizational changes, etc. One team member should take on the role of scribe, and ideally,
a human factors expert should also be included as part of the HFRCA team.
Finally, depending on your institution, you may want to reach out to the patient and
family to see if they are willing to participate as part of the HFRCA team. Patients and family
members can provide an essential perspective that will be unique from that of any of the
clinical team members. In addition, involving patients and family members can provide a
needed sense of closure and contribution in some cases. It is essential to note, however,
that including those who were directly involved in the incident, whether they are patients
and family members or staff, can be difficult, and will have to be approached with extreme
sensitivity to ensure the experience is positive and not defensive or punitive.
According to the Canadian Incident Analysis Framework  a leader is someone
who has a general understanding of the incident that occurred, and has the authority to
undertake an investigation. An individual in a senior clinical management role who
possesses strong clinical and analytical skills would be a good candidate. The leader will be
• Keeping the team focused
• Supporting cultural change
• Supporting other team members in their analysis
• Removing barriers encountered by other team members
A facilitator is someone who can manage group dynamics, delegate tasks, and
facilitate group consensus building. An individual that is a specialist in quality or risk
management, who possesses confidence and has expertise in analytical methods, would be
a strong candidate. The facilitator will be responsible for:
• Coordinating team meetings
• Ensuring the team stays focused
• Facilitating constructive discussion among team members
• Monitoring timelines
• Ensuring the analysis process follows the healthcare organization’s protocol
• Ensuring the completion of a final report, if applicable
Senior Leadership Representative
A senior leadership representative is someone who has the authority for decision-
making, and helps to drive a culture of safety. An individual who is a senior manager for the
organization will be a strong candidate. The senior leadership representative will be
• Ensuring any actions and mitigating strategies are implemented
• Authorizing scheduled time away from staff member’s regular duties to
participate in the analysis
• Encouraging and supporting the broad communication of the results and
• Ensuring those involved in the sentinel event, including patients and families,
and staff, are supported so the experience is as positive as possible
Subject Matter Experts
Subject matter experts are individuals who are knowledgeable about one or more
topics related to the sentinel event. They should have a detailed understanding of any
technologies, processes, environments, policies, training, and organizational structures or
changes that may have contributed to the incident. Subject matter experts should be critical
thinkers, capable of providing feedback and input over the course of the HFRCA. These team
members will carry out the bulk of the hands-on analysis including developing an initial
understanding of the incident, identifying root causes and contributing factors, and
developing mitigating strategies.
The scribe is responsible for capturing any discussion or decisions made whenever
the team convenes. The scribe should circulate meeting minutes to the entire team and an
agenda of what the team hopes to accomplish prior to each meeting.
Human Factors Expert
Ideally, the HFRCA team will include at least one human factors expert. The human
factors perspective is important for an HFRCA because this will facilitate the inclusion of
various human factors methods, and ensure the analysis takes our inherent human
limitations into account, especially when thinking through the root causes and contributing
factors to the sentinel event. If it is not possible to include a human factors expert, the
health technology professional can apply their newfound human factors knowledge
(supported by this book and the additional resources highlighted in this book) during the
HFRCA in order to fulfill this role. Another more cost effective option to consider is to bring
in a graduate student of human factors and their advisor to help provide this insight, if
Patient and Family
If the patient and family are included as part of the HFRCA team, they will be able to
provide invaluable information about the sentinel event from a unique perspective that no
other team member will have. They will serve as subject matter experts from the
perspective of the ones receiving care.
Section 10.6.4. Develop Initial Understanding of Incident
Developing a thorough and accurate initial understanding of the incident will be key
in supporting the identification of the actual root causes and contributing factors, and the
development of robust and effective mitigating strategies.
Section 10.6.4.1 Create an Initial Process Flow Diagram
To start, create a process flow diagram (Chapter 6) based on your preliminary
understanding of the incident. This initial understanding should be informed with any
information collected from the staff who were involved, information from any incident
reports, a chart review, history logs of any devices, any information that can be acquired
from hospital systems, and artefacts. The defined goal for this task analysis should match
that of the individual(s) at the time of the sentinel event. The scope for this task analysis
should also match the conditions and context present at the time of the sentinel event. The
initial process flow diagram should describe the actual, rather than the ideal or prescribed
process and sequence of events.
As the diagram is being created, keep track of any questions that arise or areas of
uncertainty, as these will have to be addressed as the diagram is updated iteratively.
Section 10.6.4.2 Iteratively Update the Process Flow Diagram
Once this initial diagram has been created to describe the sequence of events, it is
essential the diagram be shared with the HFRCA team to get any feedback. As with any task
analysis, the creation of a process flow diagram is an iterative one, requiring multiple
rounds of sharing, incorporating feedback, and review. To support the HFRCA method, in
addition to sharing the diagram with the HFRCA team for feedback, observations (Chapter
4), and interviews (Chapter 5) should also be done to further improve the process flow
diagram. Once several rounds of iteration have been completed and the diagram reflects
the actual workflow during the sentinel event as closely as possible, the diagram can be
considered complete; in the event new information comes to light, however, this diagram
should be updated no matter what point of the HFRCA the team is at to ensure the diagram
reflects the most accurate information possible.
Section 10.6.4.3 Layer Other Contextual Information on to the Process Flow Diagram
This process flow diagram can be used as the backbone for developing an initial
understanding of the incident. In addition to an overview of the tasks leading up to the
sentinel event, this diagram can also be used to document the timing of various tasks and
events, and as a legend or key to link to artefacts, policies, procedures, and other contextual
information that was collected as items were secured.
The biomedical technology professional may also find it helpful to indicate not only
the actual events leading to the sentinel event, but also the “expected working process” and
the “typical working process” so that any deviations can be highlighted. The expected
working process is the series of steps that should be performed by staff as outlined by a
healthcare organization’s policies and procedures. The typical working process is the series
of steps most staff carry out as a result of the reality of daily operations including factors
such as work, time, and cost pressures. Expected and typical working processes are likely
to differ, as typical working processes will include things like workarounds and shortcuts
that most staff use to try to get their work done as efficiently and safely as possible. Adding
information about the expected and typical working processes to the diagram of the actual
events leading to the sentinel event can be extremely helpful because any points at which
there are deviations serve as clues that the system as designed is failing to support the
people working within it. The policies and procedures that have been developed may look
right on paper, but when the context and reality of the front lines are taken into account,
policies and procedures can be cumbersome to follow.
Section 10.6.4.4 Finalize the Process Flow Diagram
Once the diagram has been created, updated iteratively, and used as a basis for
linking artefacts and other contextual information, including any deviations from expected
and typical workflows, it should be circulated to the core HFRCA team for any additional
feedback. This diagram will be used as the basis for identifying the root causes and
contributing factors leading to the sentinel event.
Section 10.6.4.5 Create a Factual Description of the Events Leading to the Incident
Based on the finalized process flow diagram, a written, factual description of the
events that led up to the sentinel event should be created. This description will be more
accessible for staff who are outside of the core and extended HFRCA teams when it is time to
share information about the incident with them.
Section 10.6.5. Identify Contributing Factors
Once the team has a clear initial understanding of what happened leading up to the
incident, the next and most important step of an HFRCA is to understand the root causes and
contributing factors leading to why the incident happened. It is critical to note that a
sentinel event is almost always caused by multiple factors, rather than just a single root
cause. The root cause is typically considered to be only the first in a chain of contributing
factors leading to the incident. The contributing factors can be considered circumstances,
actions, or other influential factors that are likely to have played a role, or increased the
chance of, the incident occurring .
A helpful starting point when identifying causes can be to write down the task or
action that went wrong, and then to keep asking why it went wrong using the process flow
diagram and any artefacts as you go. This approach will allow the team to build an
understanding of the system context that surrounded the incident. At this point it will
already have been established that the individuals involved in the sentinel event did not
intend to cause harm, so as is the case for HFFMEA, it is important to avoid focusing only on
the human centric causes, and failures of individuals to comply with established protocols
and procedures (Section 13.2.6). If an individual makes a mistake or fails to comply with an
established protocol or procedure, the job of the HFRCA team is to ask why that might have
been. The systems we work within should not require us to be superhuman, but rather,
systems should be designed to take our human limitations into account. Features of a
system that do not support us in our inherent strengths and limitations have the potential
to lead us to make mistakes, and thus should be thought of as contributing factors.
Section 10.6.5.1 Human-tech/Swiss Cheese Model Framework
To help in identifying the system features contributing to a sentinel event, several
human factors methods, such as observations (Chapter 4), interviews (Chapter 5),
heuristics (Chapter 7), or usability testing (Chapter 8) can be used. In addition, a
combination of the Human-tech ladder (Section 3.2), and Reason’s Swiss Cheese Model of
Error (Section 3.4) is highly recommended as a guiding tool (Figure 27).
Figure 27. Human factors framework adapted from Reason’s Swiss Cheese Model, 2000 and
Vicente’s Human-tech ladder, 2004
This human factors framework illustrates the importance of thinking beyond the
human centric causes, to thinking about contributing factors related to the physical,
psychological, team, organizational, and political levels of the system. Latent factors at each
of these levels typically translate into system weaknesses that can combine to allow a
sentinel event to occur. For example, if an HFRCA team is trying to identify contributing
factors leading to an incident where a calculation error was made leading to a patient
overdose, the adapted human factors framework could be used as follows (Figure 28).
Figure 28. Using Reason’s Swiss Cheese Model and Vicente’s Human-tech ladder to identify
contributing factors to a sentinel event
In addition to this human factors framework, and the other human factors methods
mentioned above (i.e., observations, interviews, heuristics, usability testing), The Joint
Commission’s RCA Framework , Table 18, provides a series of helpful prompts to
encourage the HFRCA team to think through a wide range of potential contributing factors.
Table 18. RCA Action Plan Tool (© The Joint Commission, 2013. Reprinted with permission.)
Analysis Question Prompts
What was the intended
List the relevant process steps as defined by the
policy, procedure, protocol, or guidelines in effect at
the time of the event. You may need to include
Note: The process steps as they occurred in the event
will be entered in the next question.
Examples of defined process steps may include, but
are not limited to:
• Site verification protocol
• Instrument, sponge, sharps count procedures
• Patient identification protocol
• Assessment (pain, suicide risk, physical, and
• Fall risk/fall prevention guidelines
Were there any steps in the
process that did not occur as
Explain in detail any deviation from the intended
processes listed in Analysis Item #1 above.
What human factors were
relevant to the outcome?
Discuss staff-related human performance factors
that contributed to the event.
Examples may include, but are not limited to:
• Failure to follow established policies/procedures
• Inability to focus on task
• Inattentional blindness/ confirmation bias
• Personal problems
• Lack of complex critical thinking skills
• Rushing to complete task
• Substance abuse
How did the equipment
performance affect the
Consider all medical equipment and devices used in
the course of patient care, including AED devices,
crash carts, suction, oxygen, instruments, monitors,
infusion equipment, etc. In your discussion, provide
information on the following, as applicable:
• Descriptions of biomedical checks
• Availability and condition of equipment
• Descriptions of equipment with multiple or
• Location of equipment and its accessibility to
staff and patients
• Staff knowledge of or education on
equipment, including applicable
• Correct calibration, setting, operation of
alarms, displays, and controls
directly affected this
What environmental factors within the
organization’s control affected the outcome?
Examples may include, but are not limited to:
• Overhead paging that cannot be heard
• Safety or security risks
• Risks involving activities of visitors
• Lighting or space issues
The response to this question may be addressed
more globally in Question #17.This response should
be specific to this event.
external factors influenced
Identify any factors the organization cannot change
that contributed to a breakdown in the internal
process, for example natural disasters.
Were there any other factors
that directly influenced this
List any other factors not yet discussed.
What are the other areas in
the organization where this
List all other areas in which the potential exists for
similar circumstances. For example:
• Inpatient surgery/outpatient surgery
• Inpatient psychiatric care/outpatient
Identification of other areas within the organization
that have the potential to impact patient safety in a
similar manner. This information will help drive the
scope of your action plan.
[Were]… staff properly
qualified and currently
competent for their
responsibilities at the time of
Include information on the following for all staff and
providers involved in the event. Comment on the
processes in place to ensure staff is competent and
qualified. Examples may include but are not limited
• Competency assessment (What competencies
do the staff have and how do you evaluate
• Provider and/or staff scope of practice
• Whether the provider was credentialed and
privileged for the care and services he or she
• The credentialing and privileging policy and
• Provider and/or staff performance issues
How did actual staffing
compare with ideal levels?
Include ideal staffing ratios and actual staffing ratios
along with unit census at the time of the event. Note
any unusual circumstance that occurred at this time.
What process is used to determine the care area’s
staffing ratio, experience level and skill mix?
What is the plan for dealing
with staffing contingencies?
Include information on what the organization does
during a staffing crisis, such as call-ins, bad weather
or increased patient acuity.
Describe the organization’s use of alternative
staffing. Examples may include, but are not limited
• Agency nurses
• Cross training
• Float pool
• Mandatory overtime
• PRN pool
Were such contingencies a If alternative staff were used, describe their
orientation to the area, verification of competency
12 factor in this event? and environmental familiarity.
Did staff performance during
the event meet expectations?
Describe whether staff performed as expected within
or outside of the processes. To what extent was
leadership aware of any performance deviations at
the time? What proactive surveillance processes are
in place for leadership to identify deviations from
expected processes? Include omissions in critical
thinking and/or performance variance(s) from
defined policy, procedure, protocol and guidelines in
effect at the time.
To what degree was all the
available when needed?
Discuss whether patient assessments were
completed, shared and accessed by members of the
treatment team, to include providers, according to
the organizational processes.
Identify the information systems used during patient
Discuss to what extent the available patient
information (e.g. radiology studies, lab results or
medical record) was clear and sufficient to provide
an adequate summary of the patient’s condition,
treatment and response to treatment.
Describe staff utilization and adequacy of policy,
procedure, protocol and guidelines specific to the
patient care provided.
To what degree was the
participants adequate for
Analysis of factors related to communication should
include evaluation of verbal, written, electronic
communication or the lack thereof. Consider the
following in your response, as appropriate:
• The timing of communication of key information
• Misunderstandings related to language/cultural
barriers, abbreviations, terminology, etc.
• Proper completion of internal and external hand-
• Involvement of patient, family and/or significant
Was this the appropriate Consider processes that proactively manage the
16 physical environment for the
processes being carried out
for this situation?
patient care environment. This response may
correlate to the response in question 6 on a more
What evaluation tool or method is in place to
evaluate process needs and mitigate physical and
patient care environmental risks?
How are these process needs addressed
Examples may include, but are not limited to:
• alarm audibility testing
• evaluation of egress points
• patient acuity level and setting of care
managed across the continuum,
• preparation of medication outside of
What systems are in place to
Identify environmental risk assessments.
• Does the current environment meet codes,
• Does staff know how to report environmental
• Was there an environmental risk involved in
the event that was not previously identified?
What emergency and failure-
mode responses have been
planned and tested?
Describe variances in expected process due to an
actual emergency or failure mode response in
connection to the event.
Related to this event, what safety evaluations and
drills have been conducted and at what frequency
(e.g. mock code blue, rapid response, behavioural
emergencies, patient abduction or patient
Emergency responses may include, but are not
• External disaster
• Mass casualty
• Medical emergency
Failure mode responses may include, but are not
• Computer down time
• Diversion planning
• Facility construction
• Power loss
• Utility issues
How does the organization’s
culture support risk
How does the overall culture encourage change,
suggestions and warnings from staff regarding risky
situations or problematic areas?
• How does leadership demonstrate the
organization’s culture and safety values?
• How does the organization measure culture
• How does leadership establish methods to
identify areas of risk or access employee
suggestions for change?
• How are changes implemented?
What are the barriers to
communication of potential
Describe specific barriers to effective
communication among caregivers that have been
identified by the organization. For example, residual
intimidation or reluctance to report co-worker
Identify the measures being taken to break down
barriers (e.g. use of SBAR). If there are no barriers to
communication discuss how this is known.
How is the prevention of
communicated as a high
Describe the organization’s adverse outcome
procedures and how leadership plays a role within
How can orientation and in-
service training be revised to
reduce the risk of such
events in the future?
Describe how orientation and ongoing education
needs of the staff are evaluated and discuss its
relevance to event. (e.g. competencies, critical
thinking skills, use of simulation labs, evidence based
Was available technology
used as intended?
Examples may include, but are not limited to:
• CT scanning equipment
• Electronic charting
• Medication delivery system
• Tele-radiology services
How might technology be
introduced or redesigned to
reduce risk in the future?
Describe any future plans for implementation or
redesign. Describe the ideal technology system that
can help mitigate potential adverse events in the
In addition to the Human-tech/Swiss Cheese Model Framework (Figure 27) and The
Joint Commission’s action plan tool, the Canadian Incident Analysis Framework outlines a
set of guiding questions that can encourage the HFRCA team to identify potential
contributing factors at various levels of the system (Table 19).
Table 19. Guiding questions to support identifying contributing factors2
Task (care/work process):
• Were there previous or predicted failures for this task or process?
• Were specialized skills required to perform the task?
• Was a fixed process or sequence of steps required (e.g. order sets, checklists)?
• Did it exist and was it followed?
• Was a protocol available, was it up-to-date, and was it followed in this case?
• Were there constraints or pressures (e.g. time, resources) when performing
• Was the information required to make care decisions available and up-to-date
(e.g. test results, documentation, patient identification)?
• Was there a risk assessment/audit/quality control program in place for the
Equipment (including information and communication systems):
• Were the displays and controls understandable?
• Did the equipment automatically detect and display problems?
• Was the display functional?
• Were the warning labels, reference guide and safety mechanisms functional
and readily visible/accessible?
• Were the maintenance and upgrades up-to-date?
• Was the equipment standardized?
• Would the users describe this equipment as “easy-to-use”?
• Were the communication systems (phone, pager, software, hardware, etc.)
available and operational?
• Did noise levels interfere with the alarms?
• Was the lighting adequate for the task?
• Was the work area adequate for the task(s) being performed (e.g. space,
layout, location and accessibility of resources)?
• Did the patient(s) have the information to assist in avoiding the incident?
• If not, what would have supported the patient in assisting their care team?
• Did factors like age, sex, medications, allergies, diagnosis, other medical
conditions, contribute to the incident? How did they contribute?
• Did any social or cultural factors contribute to the incident?
• What factors? In which way?
• Was language a barrier?
2 Reprinted from the Canadian Incident Analysis Framework. Copyright (2012) with permission from the
Canadian Patient Safety Institute.
Care team: Caregiver(s):
• Were the education, experience, training and skill level appropriate?
• Was fatigue, stressors, health or other factors an issue?
• Was the workload appropriate?
• Were appropriate and timely help or supervision available?
Care team: Supporting team (all involved in care process):
• Was there a clear understanding of roles and responsibilities?
• Was the quality and quantity of communication (verbal and/or written)
between team members appropriate (clear, accurate, free of jargon, relevant,
complete and timely)?
• Were there regular team briefings/debriefings about important care issues?
• Was team morale good? Do team members support each other?
• Were the communication channels available and appropriate to support the
needs of the team (e.g. email, pager, and phone)?
Organization: Policies and priorities:
• Were the relevant policies and procedures available, known, accessible, and
did they meet the needs of users
• Were there workarounds to the documented policy/procedure?
• Was there a mechanism in place to identify and resolve gaps between policy
• Were the strategic priorities of the organization clear to all?
• Was everyone (patients, clinicians, other staff) comfortable to speak-up about
• Was there visible support from leadership and board for safe patient care?
• Was communication between staff and management supportive of day-to-day
safe patient care?
• Were incidents considered system failures with people not blamed?
Organization: Capacity (resources):
• Did scheduling influence the staffing level, or cause stress, fatigue?
• Was there sufficient capacity in the system to perform effectively (e.g., access
• Were formal and/or incentives appropriate?
Other - consider:
• Were there any local conditions or circumstances that may have influenced
the incident and/or an outcome?
• Were there any sector specific conditions or circumstances that may have
influenced the incident and/or outcome?
Section 10.6.5.2 Traditional RCA Tools for Documenting Contributing Factors
The HFRCA team may also find other types of diagrams useful for documenting
contributing factors identified at different levels of the system. Many documentation tools
and approaches may be used, but three examples often used as part of a traditional RCA
method are included here: the Ishikawa Diagram, the Tree Diagram, and the Constellation
Diagram. Further detail about these diagrams is available as part of the Canadian Incident
An Ishikawa diagram, named for its’ creator, is also known as a fishbone diagram. To
create this type of diagram a straight line that ends in a box containing the incident is
drawn (Figure 29). Next categories representing contributing factors are indicated and
connected to the straight line leading to the incident (Figure 30). Finally, more detailed
information about the contributing factors is noted under each category of contributing
factor (Figure 31). Ishikawa diagrams do not generally allow for a clear understanding of
the order in which contributing factors occur, but rather, they provide a means of
categorizing and summarizing contributing factors at a glance.
Figure 29. Ishikawa Diagram: Straight line ending in a box containing the incident
Figure 30. Ishikawa Diagram: Categories of contributing factors
Figure 31. Ishikawa Diagram: Detailed information about contributing factors by category
A tree diagram (Figure 32) is a linear cause-consequence diagram that starts with
the incident and grows backwards as the actions or conditions leading to the preceding
action are documented. Unlike Ishikawa Diagrams, tree diagrams allow causal chains to be
denoted, where the respective causes and effects of a series of actions can be traced from
root cause to incident. In most cases however, tree diagrams will be too simplistic as a
documentation tool because in reality, incidents result from multiple contributing factors,
rather than a one-to-one cause and effect relationship.
Figure 32. Tree diagram4
A constellation diagram (Figure 33) is a more versatile documentation tool than
either the Ishikawa diagram or tree diagram that allows one to categorize and illustrate the
causal relationships between all the identified contributing factors.
Figure 33. Constellation Diagram5
This type of diagram will likely be the most useful to the biomedical technology
professional once the Human-tech/Swiss Cheese Model framework (Figure 27) has been
applied, as the levels of the Human-tech ladder can be used as categories, and the causal
relationships between contributing factors can be indicated in a flexible way (Figure 33).
With a constellation diagram, every contributing factor should be connected to at least one
other factor, or a category of factors. If a contributing factor does not connect to either
another factor or a category, a new category will have to be created, or the factor does not
belong in the analysis.
Section 10.6.5.3 Finalize Documentation of Contributing Factors
Once the root causes and contributing factors have been identified and documented,
the analysis should be shared with the HFRCA team to gather any feedback. As the analysis
is reviewed, the HFRCA team should consider three main questions:
What are the factors that:
1. If corrected, would have prevented the incident or mitigated the harm?
2. If corrected, would NOT have prevented the incident or mitigated the harm,
but are still important to enhance patient and/or staff safety in general?
3. Prevented the incident from having more serious consequences, and thus,
represent safeguards that should remain in place?
Regardless of the approach to documenting contributing factors, these three questions
should be used as the basis for prioritizing which factors warrant the further consideration
and development of recommendations and mitigating strategies.
Section 10.6.6. Develop Mitigating Strategies
After the root causes and contributing factors leading to the incident have been
identified, documented, and prioritized using the three questions from Section 10.6.5.3,
mitigating strategies will have to be developed. Since most healthcare organizations have
limited resources, a selection, rather than every root cause and contributing factor, will end
up being addressed. The number and types of mitigating strategies implemented will
depend on the context of the incident, your healthcare organization, and the resources
available. To help guide the HFRCA team in figuring out which root causes and contributing
factors to address, a number of tips are included below.
Section 10.6.6.1 Use the Hierarchy of Effectiveness to Develop System-Focused Strategies
Focus on system-level mitigating strategies rather than person-centered solutions.
Use the Hierarchy of Effectiveness (Section 3.5) to determine whether a proposed solution
is system focused. Person-centered solutions will not result in system improvements, and
when person-centered solutions are implemented without addressing the system issues,
the same, or a similar incident is likely to happen again.
Section 10.6.6.2 Quality Over Quantity
Rather than trying to implement many, lower impact mitigating strategies, aim to
implement a few, well thought out recommendations that target system change. A well
planned and carefully executed mitigating strategy that targets system improvement will
be a more robust and long-term solution to prevent similar incidents from occurring again.
Section 10.6.6.3 Use the SMART framework
When drafting recommendations ensure they are SMART  (Table 20):
Table 20. SMART framework 
Specific Target a clearly defined issue with known scope
Measurable Demonstrate an impact on outcomes through an indicator or progress
Attainable Can be achieved given the available resources
Realistic Results are possible given the available resources
Timely Achievable in the defined implementation timeframe
As part of the SMART framework, try to ensure any primary mitigating strategies
fall within the locus of control of the healthcare organization, rather than an outside group,
such as a manufacturer or vendor. Although it may be necessary to work closely with a
manufacturer to implement a mitigating strategy, solutions that originate outside of the
healthcare organization will naturally be much harder to advance and control. When it is
necessary to implement a solution that originates outside the healthcare organization,
working closely with regulators, policy makers, and other healthcare organizations
experiencing similar challenges, can help sustain momentum for a change to be realized.
Section 10.6.6.4 Validate Potential Mitigating Strategies
Prior to implementing a mitigating strategy, it should be validated to ensure it will
have the intended effect without introducing other unintended consequences into the
system. Gathering evidence from the literature, experiences from other healthcare
organizations, and recommendations from professional and safety organizations can be a
useful exercise to get a baseline understanding of potential implications. When little
evidence exists, or there are features or factors that make your healthcare institution
unique, applying human factors methods such as observations (Chapter 4), interviews,
focus groups and surveys (Chapter 5), heuristics (Chapter 7), usability testing (Chapter 8),
or a HFFMEA (Chapter 9), are recommended.
The Canadian Incident Analysis Framework provides templates both for assessing
potential mitigating strategies while taking these considerations into account (Table 21),
and tracking progress during the implementation of mitigating strategies (Table 22). The
individual responsible for implementing each strategy that is agreed upon by the HFRCA
team should put a plan together that outlines a project plan, timelines, required resources,
and measures of success. The individual or team that implements each mitigating strategy
does not have to be the same as the HFRCA team; however, depending on the incident and
mitigating strategy, it may be helpful to keep the HFRCA team involved as an advisory group
to maintain some consistency and oversight.
Table 21. Prioritized list of RCA actions 
Table 22. Follow through actions from a RCA 
# Recommendation Source and ID #
Section 10.7. What to do with a Completed HFRCA
Section 10.7.1. Create a Draft Report
Once the HFRCA has been completed and a decision made about which mitigating
strategies the healthcare organization will move forward with, a report should be created
that summarizes the incident and HFRCA process. Remove as much identifying information
about the patient and staff involved in the incident as possible for privacy purposes.
Once drafted, the report should be labeled “Draft” and “Confidential” and then
shared with any key stakeholders for review. Preparing a report following an incident that
includes information about the information gathering, documentation, analysis, and
mitigating strategy development process can contribute to organizational learning and
memory when another sentinel event occurs. When shared with staff, this type of report
can provide helpful context so those responsible for and affected by mitigating strategies
understand the rationale driving any changes.
Consider sharing de-identified information about the incident, analysis, and planned
mitigating strategies, beyond your healthcare institution if senior management supports
this type of dissemination. If this type of sharing is supported, it can be an invaluable
opportunity for other organizations to learn from the incident so similar events can be
avoided in other institutions.
Section 10.7.2. Conduct an HFFMEA
Depending on the context of the incident and findings from the HFRCA, the HFRCA
team may want to consider conducting an HFFMEA to identify more general risk factors not
immediately implicated in the sentinel event, but that could contribute to a future incident.
See Chapter 12 for information about how to conduct an HFFMEA.
Section 10.8. Limitations of HFRCA
Although HFRCA can be an excellent means of understanding the root causes that
contributed to a sentinel event, there are also some challenges and limitations to consider.
Section 10.8.1. The Resources Required
Properly carrying out an HFRCA is resource intensive, as it can be time consuming
for a multi-disciplinary team to identify the root causes of a sentinel event. For an HFRCA to
have impact, the multi-disciplinary team will also have to dedicate time to identifying and
implementing mitigating strategies to address the identified root causes. Although HFRCA
can be resource intensive, the benefits to successfully completing this type of analysis are
substantial. Preventing future patients from being harmed as a result of a similar event is
an invaluable opportunity.
Section 10.8.2. HFRCA is not Appropriate for Every Incident
Given that HFRCA is intended to identify system level root causes and contributing
factors, incidents where a person wilfully causes harm are not appropriate for analysis
using HFRCA. Examples of such circumstances include criminal acts, purposely unsafe acts,
substance abuse by staff, and patient abuse of any kind. To determine whether an incident
falls into the category of unintended harm caused by system factors or wilful harm, the
Incident Decision Tree (Figure 26) is recommended.
Section 10.8.3. Completing an HFRCA Requires Tact
Following a sentinel event, it is normal for staff involved in the incident to be upset
and scared about potential punitive actions towards them, or towards their colleagues,
particularly if this approach was used historically. Consequently, it is of the utmost
importance that those conducting the investigation are sensitive, and recognize that any
interactions should leave staff feeling supported, rather than perpetuating any feelings of
fear or paranoia. Follow the guidance provided for conducting observations (Chapter 4)
and interviews (Chapter 5) such that staff do not feel they are being audited or judged, but
rather that you are there to learn from them to make the system around them safer.
Section 10.9. Additional Resources
1. Incident Analysis Collaborating Parties. Canadian Incident Analysis Framework.
Edmonton, AB: Canadian Patient Safety Institute; 2012. Incident Analysis
Collaborating Parties are Canadian Patient Safety Institute (CPSI), Institute for Safe
Medication Practices Canada, Saskatchewan Health, Patients for Patient Safety
Canada (a patient-led program of CPSI), Paula Beard, Carolyn E. Hoffman and
Micheline Ste-Marie. Available at www.patientsafetyinstitute.ca
Tools and Frameworks Available Online
1. Veterans Affairs National Centre for Patient Safety Root Cause Analysis Tools
2. Veterans Affairs National Centre for Patient Safety Root Cause Analysis Triage
and Triggering Questions
3. The Joint Commission Framework for Conducting a Root Cause Analysis and
4. National Health Services (UK) Root Cause Analysis Toolkit
Examples of Root Cause Analyses
1. ISMP Canada published RCA’s:
• Fluorouracil Incident Root Cause Analysis
• Hydromorphone/Morphine Event
• The Joint Commission - Sentinel Event Data: Root Causes by Event Type
• The Joint Commission - Sentinel Event Data: Root Causes by Event Type