How to Perform Effective Root Cause Analysis

Picture this: something goes wrong with a medical device, and a complaint is issued. In a post-market situation, the medical device company responsible might get notified that there’s a problem with their product. 

Unfortunately, it's common for the complaint to be reported by someone who didn’t actually experience the problem themselves. As a result, pinpointing the real root cause is a lot like a high stakes game of telephone.

Oftentimes, the information about the complaint comes back to the manufacturer in fragments; or the complaint might not even be about your specific device - it may just somehow involve your product.

So, as you might imagine, there are many challenges for device makers when it comes to identifying the real root cause of an issue, and you’ll need to channel your inner investigative skills to uncover the facts.

Below, we’ll look at some ways you can improve the accuracy of your investigation, despite the obvious challenges.

BONUS CONTENT: 5 Things Hurting Your Root Cause Analysis. Click here to download this free PDF.

What is Root Cause Analysis?

Root cause analysis is a method that helps understand the primary cause of a problem or why a problem occurred in the first place.

It helps you to dig into the underlying causes of the situation, thus allowing you to find appropriate solutions for it. 

There are several root cause analysis tools and techniques that can be used in the investigation of a problem. But before we get to that, let’s understand how to conduct a root cause analysis first.

Process for Finding the Real Root Cause

Whether you're selling in the U.S. market or in Europe, the regulations are clear when it comes to the complaint process. You need to do a thorough complaint investigation for every, single complaint that is reported, which begins with a root cause analysis to get to the bottom of the issue.

Through the FDA lens, their job is to protect the public. So, if there’s a complaint, the FDA is on high alert, given that medical device failures could represent a broader public health risk. The FDA needs to find out if the device in question has the potential to deliver adverse effect and whether that product will need to be recalled.

CAPA is “Corrective Action or Preventive Action” a process that medical device companies must go through if a systemic issue is identified.

Unfortunately, it’s during this CAPA stage where companies get dinged by the FDA.

A typical mistake is to restate the problem as the root cause, rather than identifying the actual problem. Or, the investigator is working off of an assumption rather than hard data. As such, medical device companies can land in hot water if they apply the CAPA to the wrong issue.

Anytime a complaint is issued, FDA inspectors will always look for any CAPAs. Their goal is to check that they are appropriately managed, hence the importance of getting root cause analysis right from the get-go.

A successful root cause analysis will almost always involve some variation of these five steps:

• Step 1. Define the problem your organization is facing and gather data and evidence relevant to it and necessary to understand the current situation. 

Create a problem statement which should include information about the problem like the actual impact, potential impact, the focal point, etc. However keep the statement concise. 

• Step 2: Determine the factors that caused the problem. Gather a team of people directly involved in the execution of the process and corrective actions, and experts whose input can help find solutions faster.

Together with the team, brainstorm the possible factors for the problem by asking ‘why?’. You can use a 5 whys diagram or a fishbone diagram here. 

• Step 3: Identify the root cause. Did deeper by continuing to ask why after the first layer of causal factors. Keep at it until finally you have discovered the fundamental cause for the problem at hand.
• Step 4: Decide the corrective actions you need to take to eliminate the problem and prevent it from recurring. Make sure that you clearly communicate them to the people who will be involved.

• Step 5: Review and evaluate the impact of the corrective actions. Make improvements as necessary. 

Below, we'll expand upon those steps to give you a comprehensive understanding of what you'll need to do to start uncovering the real source of the problem.

Gather as Much Information as Possible

Companies need to gather as many facts about the situation as they can. It is your responsibility to try to identify as much information as possible.

Root cause analysis requires us to ask why the end users did what they did. And if the user was in fact at fault, finding out the answers to these important questions:

• What caused the error?
• How did the standard operating procedure (SOP) contribute to the error?
• How was the product being used?
• Did they fail to read the instructions or was the language confusing?
• Is there something about patient demographics there that might be important?

The medical device company needs to find information that reveals whether there’s anything they can do on their end to prevent user errors from happening in the future. For instance, can labeling be improved? What about the instructions?

HIPAA guidelines limit your ability to dive too deep into patient specifics, but maybe the facility can provide some background. After gathering the situational information surrounding the failure, you’ll also need to gather identifying details for the product.

Ask the person filing the complaint to provide as many technical details as possible. Think lot numbers, serial numbers, any notable defects, or damage.

Is this a one-off event or are similar issues occurring elsewhere? The more details you can collect, the easier it will be to pinpoint the root cause(s) and start solving the problem.

Reference your Documentation

In the past, we’ve seen complaint teams go back to the design team after an issue occurs. Now, if you can speak with the designer, that’s great, and they may be able to help you identify some potential root causes. But you might not always be able to get in contact with the designer. Or, they may have trouble recalling key details needed to perform a thorough root cause analysis.

So, written (or rather, cloud-based) documentation is vital. The first place you’ll want to look is the risk analysis file which should have been created during the design validation phase of development.

The reason being, that if a complaint comes in, the investigation team will have something to refer back to. They can identify which, if any, issues came up during user testing or even the initial development and design process.

This also reveals whether the complaint qualifies as new information or if this issue came up before the product went to market.

Can You Get the Product in Question?

Knowing the situation and circumstances that played into the failure is helpful, as it allows you to see what went wrong. But, a list of complaints can't replace a hands-on examination.

The best possible situation is getting your hands on the exact product in question.

When you have the actual device in your hands, you can try to replicate the situation. Is there any specific style, method, technique, that you weren’t aware of? Is there a part that malfunctioned? These physical clues offer a ton of context for researchers who, again, may be the second or third line of communication.

A lot of facilities do not release the product after a complaint. Unfortunately, this can hinder the investigation process.

If you can’t get your hands on the product, it’s in your best interest to replicate the situation on your own. The next best thing is to get your hands on a product from the same lot or batch.

Unfortunately, a lot of facilities won’t release the product that failed. There are several reasons they might hang onto an item, but it handicaps a team running a root cause investigation. The knee-jerk reaction from a lot of researchers is — well we did what we could, but we couldn’t get the product.

If the complaint or the issue has the potential to cause an adverse effect, this isn’t good enough. Still, it’s your responsibility to try to replicate this situation on your own. Try to get your hands on a device from a product from the same lot or something similar.

Review Design, Development, and Evaluation Processes

The single leading indicator of complaints is what happens during the design and development stage. Rushing the process so you can make it through regulatory clearance faster will only come back to haunt you.

In the event that you didn’t capture all possible harms, you’ll need to go back and revise your risk management file.

The thing about complaints is, you don’t hear about all of them. Medical device manufacturers must be proactive about soliciting customer feedback. This gives you the ability to identify systemic issues before they turn into a problem, and continually improve the quality of your product.

Root Cause Analysis Tools and Methods

There are several methods for identifying the real root cause and coming up with the corrective actions needed to prevent it from happening again. Your goal here is to assess all possibilities, so you can circle back to any issues that surfaced during the development or user-testing stage.

Here are a few of the most common methods to consider when conducting your own analysis:

5 Whys Analysis

As the name suggests, in the 5 whys analysis the question ‘why?’ is asked five times in the course of finding the root cause of a problem. 

To carry out a 5 whys analysis, you need to gather a team of people who are affected by the problem.

Once you have asked ‘why’ five times and figured out the root cause, come up with improvement measure you need to apply. Assign everyone the corrective actions that need to be taken.

^{5 Whys Analysis (Click on the template to edit it online)}

Cause and Effect Analysis (Fishbone/Ishikawa diagram)

Once you have identified the problem, you can use the cause and effect analysis to explore the causes of a problem and its effects. For the analysis, you can use a cause and effect diagram.

Just as it helps explore the factors that are preventing an outcome, it can also be used to identify the factors needed to generate the desired outcome. 

^{Fishbone Diagram (Click on the template to edit it online)}

Fault Tree Analysis

Fault tree analysis is a deductive analysis to that visually represent the failure path. You can use the fault tree analysis to determine the possible causes of a problem or an event. The fault tree starts with the event at the top and the possible causes are placed below.

^{Fault Tree Analysis (Click on the template to edit it online)}

Pareto Chart

Pareto chart is a combination of a bar chart and a line graph. While the length of the bars represent the frequency or cost of faults, they are arranged in such a way that highlights the most frequent to least frequent. The chart helps prioritize your issues based on the cumulative effect they have on a system.

The Pareto chart is based on the theory that 80% of the total problems that occur are caused by 20% of problem causes. This means if you have solutions to your major problems, you can also solve a majority of your other smaller problems. 

^{Pareto Chart Example (Click on the template to edit it online)}

Scatter Diagram

Scatter diagrams or scatter plot diagrams can be used to visualize the relationship between two variables. Once you have created a cause and effect diagram and identified potential causes to your problem, you can use the scatter diagram to determine which causes are responsible for the variation. 

While the independent variable is plotted along the horizontal axis, the vertical axis is for the dependent axis.

^{Scatter Diagram Example (Click on the diagram to edit it online)}

I would always encourage you to never get too comfortable with one method of root cause analysis. You'll benefit most from mastering a few of these proven methods and then alternating between them to look at the problem from a few different angles. 

FMEA

Failure Modes and Effects Analysis (FMEA) is a systematic method for evaluating a process. It can be used with the premise that a failure has already happened for which you’re trying to identify the cause and severity of the failure mode, or it can be used proactively. This would mean assuming a failure or evaluating a process to determine where it might fail, then taking steps to manage any parts of the process that are identified as prone to failure.

BONUS CONTENT: 5 Things Hurting Your Root Cause Analysis. Click here to download this free PDF.

Final Thoughts

Unfortunately, some companies spend too little time working to identify the real root cause. Instead, it’s important to slow down and make sure you get this right the first time so that your CAPAs are more effective long-term.

It doesn’t have to be an intimidating task to carry out an investigation. Use the tools you are comfortable with, get input from other team members and resources, clearly determine root causes, and treat the exercise as a valuable learning experience for your company.

Part of improving your root cause analysis process is having the right tools in place. Greenlight Guru makes it easy for companies to manage risk with built-in workflows to provide full visibility into every design, development and production process. By using a risk-based approach to every process of your quality system, Greenlight Guru's software provides the safeguards to help you manage risk effectively and easily isolate the root cause of any issue to prevent systemic ones in the future.

Looking for a design control solution to help you bring safer medical devices to market faster with less risk? Click here to take a quick tour of Greenlight Guru's Medical Device QMS software →