Root Cause Analysis for Medical Device Development

Part of medical device development, or any product development for that matter, is understanding when things go wrong. What corrective actions or mitigations should we take to ensure that we have solved the problem? Without diving into identifying the actual root cause of the problem, we may think we have solved the problem only for it to return again and again.

With respect to medical devices, Root Cause Analysis (RCA) is required in a variety of areas: market surveillance, non-conformances, change control, and CAPA processes (corrective and preventative actions), among others.

What is RCA?

Root Cause Analysis (RCA) is a systematic method for delving into the problem and logically determining the true cause of the problem. In this blog I’ll list a few RCA tools, list some parts of the process that are important, then circle back on some  tools and highlight some pros and cons with each.

Root Cause Analysis has a long history dating back to the late 19th century. Modern RCA was pioneered by Walter Shewhart (PDCA) and expanded upon by many others.

Being around for some time, RCA has many tools that have been developed and used widely. Which tool is the best depends on the fault and situation at hand. Each tool has pros and cons the user needs to be aware of. Otherwise the root cause may be missed, or excessive time will be spent on a problem where the root cause could have been arrived at using simpler methods.

Listed below are a few of the more common tools:

  • Ishikawa (fishbone)
  • 5-Why’s
  • Fault Tree Analysis
  • Barrier Analysis
  • Causal Factor
  • Change Analysis

RCA Process

Problem Definition

Regardless of which tool is used, any root cause begins with stating the problem. This alone can be a challenging and often overlooked task. RCA works best when the problem statement is concise. A good problem statement shares these characteristics:

  • States the problem in terms of what’s different between the current state and the desired state
  • Does not offer a solution
  • Does not assign blame
  • Factual and/or objective
  • Can be followed by “because” (as in “because of this root cause”, once it is known)

Root cause analysis is best done as a team. One important aspect of the problem statement is that it is understood by all participating members. Having everyone on the same page and starting from the same point is critical to the success of the process.

Data Analysis

After stating the problem, analyzing what data is available is important, and can provide direction to the RCA team. It may be that more data is needed to better understand the problem.

Pareto Charts are good for understanding complaints, returns, or similar lists by highlighting the more problematic issues.

The root cause of a problem may be the interaction between different parameters. Scatter diagrams can help determine if any pairs of variables are correlated. As Scatter Diagrams work on pairs of variables; a problem where there are many related factors can quickly become more than Scatter Diagrams can handle. In those cases, a design of experiments (DOE) may be required to gather more data in a systematic way so variables can be controlled and cross correlated.

Where processes are involved, a Causal Factor chart can be helpful to understand the process flow. These charts are great for stepping through and documenting processes. Just walking through the process may uncover steps that not everyone is aware of, and this may yield the root cause in and of itself.

Illustration of a casual factor chart to help understand the process flow.

Root Cause Tools

Fishbone or Ishikawa Diagrams

Ishikawa diagrams are known as fishbone diagrams due to their skeleton-like appearance. Starting with the problem statement, several main causes or issues branch off along the spine, typically listed as People, Methods, Environment, Process, Measurement, and Materials. Each branch can have many sub-branches which gives it a fishbone look.

The method is a broad approach, and while this is where the power of the tool lies, it has pitfalls to go along with it. Because the main branch lists the problem statement, fishbone diagrams are one of the tools that can be impacted by a poor statement. It also looks at all factors. Investigating all factors can be a time-consuming process with the team spending a lot of time on issues that do not directly influence the root cause.  On the flip side, for complex issues, such as why an ultrasound isn’t delivering the expected signal to noise ratio, a fishbone diagram might yield causes that were not initially thought of.

5 Why’s

The 5-Why’s approach is a simple yet powerful tool that can be used in many situations. The thought process is that you haven’t reached the root of the problem unless you’ve asked “Why” at least 5 times. As a rule of thumb, five is a reasonable number, but the point is to ask why enough times until the team feels they’ve reached the root case. As mentioned above, the 5-Why’s can be sensitive to its starting point. Too far upstream, and it could stop too early, not reaching the root cause. Because the 5-Why’s only looks downstream, starting too late means it could miss the root cause altogether. So, for example, air bubbles entering a system might miss negative pressure generation if the Why’s are focused on seals and leakage.

Fault Tree Analysis

Fault Tree analysis was pioneered by the US military in the 1960’s and works almost opposite to Ishikawa diagrams. Starting with the problem, the fault tree starts looking at what could cause the condition and continues to step through each of these causes until all causes are known. The analysis is a powerful method as well, but again, can suffer from not asking the right question, or formulating the problem poorly. An additional benefit of the fault tree is that probabilities and relationships (like “add” or “nor” relations) can be added to each fault, allowing overall probability to be determined. For example, if there are duplicate seals as a safety factor, there could be a fault where both seals fail under the same conditions (like low temperature), and therefore, a single fault would cause both seals to fail.

Dana Trousil is a StarFish Medical Mechanical Engineering Team manager. He has successfully launched many products, with experience in a variety of processes, including NPI for medical devices.

Images: StarFish Medical