Session 3: Risk Analysis Tools and Techniques Participants will be able to distinguish and apply two common risk analysis techniques: Fault tree analysis/root cause analysis (FTA/RCA) Design failure modes effects analysis (FMEA) We will provide tool templates for one inductive technique (FMEA) and one deductive technique(RCA).

Standard of Care Manufacturer, not user, responsible for safe and effective product; system use errors from: design, including labeling & training construction, and distribution Inadequate risk management (RM) result in manufacturer ignorance RM is all about knowledge & awareness Ignorance (lack of knowledge & awareness) falls below the Standard of Care

Reducing Product Liability Ignorance (lack of knowledge OR awareness) is below the Standard of Reasonable Care!

Lack of Awareness from Inadequate RM Inadequate risk management Deficient hazard recognition Deficient risk control Deficient risk control VERIFICATIONS Deficient residual risk assessment

Frequent Failure Points Deficient Human Factors Engineering Late or No Formative Evaluations No or Deficient HF&E Risk Analyses No or Deficient Label Comprehension Validation No or Deficient Usability Validation Reliance on “Labeling” instead of redesign or guarding

Frequent Failure Points A frequently observed failure resulting in product liability associated with death and serious injury is the misuse, or incorrect use, of analytic tools for risk analysis. If you can’t correctly analyze the risks associated with your product design, you have no hope of protecting your company, your colleagues, and yourself, much less your customers and their patients. If you do not continually manage risks once your product goes out the door, you miss additional preventive opportunities – it is a reiterative process encompassing the full product life cycle!

Which RA tool do I use? The right tool depends upon the data that you have available AND the type of answer you are trying to get. you cannot use process tools for product risks and you cannot use product tools for process risks, nor can you use tools designed for use with historical quantifiable date in cases where these data do not exist

Data Rules!

Which risks need to be considered? ALL OF THEM (that you don’t want to be responsible for) You rarely build simple tools anymore; you build by interconnecting components and subsystems. Complex systems rarely have single point of serious failure; defending against that has become fairly easy. Hazards of interconnected components interact in nonlinear ways – emergent properties Safety is a system property, not a component or subsystem property – in fact, that is the theoretical reason for requiring design validation, which tests the complete system, not just its components.

Top-Down PLUS Bottom-Up Use a combination of deductive (top-down) and inductive (bottom-up) risk analysis tools; using only one or the other is insufficient. Using bottom-up only (e.g., FMEA) does not allow you to consider the big picture – the obvious system failures that will cause death, serious injury, or malfunction Using top-down only (e.g., FTA/RCA) does not allow you to drill down to the level of detail that an engineer requires to identify a hazard that can be controlled.

Quick Guide to Fault Tree Analysis & RCA FTA RCA Deductive Reliant upon historical quantitative data Deductive Subjective, experiential

Some RCA Features “Root Cause” vs. “Causal Factor” Root cause analysis (RCA) is a systematic method of problem solving used for identifying the root causes of problems. “Root Cause” if removing it prevents the final undesirable event from recurring. “Causal factor” is something that can affects an event's outcome, but is not a root cause. Removing a causal factor can benefit an outcome, but does not necessarily prevent its recurrence. RCA is typically reactive-- after an adverse event has occurred –to reveal problems and solve them. It can also be used as a proactive preventive RA tool, to forecast or predict probable events even before they occur and implement appropriate mitigation.

RCA – some general principles Start with a poor/harmful outcome. Identify factors that contributed to the undesired outcome (nature of, magnitude, timing, location) Determine what behaviors, actions or inactions, conditions must be modified to prevent the harmful outcome from occurring or recurring Identify interventions/mitigations that result in better outcomes and near certainty of preventing recurrence Explore all possible solutions to identify the best and most feasible Systematic, usually part of an investigation and team Conclusions derived from documented evidence. May uncover more than one root cause & several causal factors along the way, which can help determine a “root” cause Identifying the problem properly via correct problem statements and descriptions will forward the goals of an appropriate RCA Can transform a reactive to a proactive culture – but threats to a cultural norm cab be met with resistance. Problem identifiers should not be punished!

Simplistic Sample RCA

Failure Modes, Effects Analysis (FMEA) Highly structured and systematic; best if employed early in design process and reiteratively Involves reviewing as many components, assemblies and subsystems as possible to identify how they may fail (failure mode) and the causes of these, and their effects. Recorded on an FMEA worksheet Can be qualitative or quantitative when mathematical failure rate models are combined with a statistical failure mode ratio data base. There are several types: Functional, Design, Process – our focus today is the dFMEA or design FMEA The “effects analysis” refers to studying the consequences of the failures on different system levels Ideally probability to occur should be lowered to close to “impossible” if root causes can be determined and corrected

Quick Guide to dFMEA Before Risk Control AFTER RISK CONTROL

Quick Guide to dFMEA (continued) Open file “RCA and Design FMEA.xltx” Select dFMEA Do an example

Case Study Exercise – After the Break 30 Minute Break – Please return on time as session will begin promptly at 10:30 a.m. Let’s us quickly review the instruction before the break so we can start immediately upon return. Note: Since we are prevented from giving you the detailed design information that would be available to you, we are providing outcome scenarios so you can backtrack to identify one or more a priori design hazards for the dFMEA case study. The RCA scenario will help you gain familiarity with elements that should have been considered before launching the CPOE as well as post- launch determination of root causes for appropriate mitigation and prevention of future adverse events.