#realrca

Article Context:

iQMS for Life Science Industry

Let’s face it; nothing new can be said about root cause analysis (RCA). Standard RCA techniques have been around for decades, and before them being documented and referred to as RCA techniques, they were being employed. It is human to ask why. While it may not be human to ask why five times, it is natural to get to the bottom of problems. Unfortunately, in the regulated world of medical device and pharmaceutical manufacturing, there is a temptation to require intense documentation to prove that not only was the real root cause found but that it was accomplished by following strict processes. The emphasis on establishing the work was done often takes away from real RCA and actual problem-solving.

When MDIC’s Case for Quality took on the Make CAPA Cool project, the intent was to remove barriers to RCA and problem-solving. Engineers voiced frustration that they were spending most of their time in meetings and completing documentation during root cause investigations and spending very little time genuinely solving problems.

To solve a problem and prevent it from recurring, the actual cause must be found. This process isn’t always easy, and from time to time, the results can be inconvenient. Every RCA has two strikes against it before it begins. 1. Getting to the real cause takes time and resources 2. Sometimes the root cause identified is too broad for real problem solving to work.

1.     Getting to the real cause takes time and resources. True. Of course, recalls take time and resources. Consider, though, that RCA is Recall Prevention. If you perform RCA on a problem that never results in a recall, consider whether the effort is worth the time. Those are great opportunities to free up your engineers to go ahead and solve the problem-free from the documentation burden that often comes with CAPA. If the problem you are trying to solve could have resulted in a recall, had it not been caught, then put as much effort into the RCA as you would into a recall investigation. Assemble the investigation team as you would a product recall team. Regulatory, product design, manufacturing, quality engineering, and QA should all be involved. If it makes sense, include any other functions close to the problem, such as sterilization or supplier management. The key is to not view the RCA as an exercise in making things look right to an auditor. Rebrand RCA as Recall Prevention and get to work identifying and preventing the real cause of the problem.

2.     The root cause identified is too broad for real problem-solving. Sometimes the initial root cause is product design, a failure of a quality system element, or something else with broad implications. When general systems are implicated in root cause analysis, it is likely a sign that the RCA team is lacking appropriate subject matter experts. It does not mean that there aren’t occasions when the product design is the cause of failures or that fundamental quality system elements cannot fail. But given the rigor of product verification and validation required to get a product to market, these situations should be rare. Including the product design team in the RCA can help in these situations. If your company has an RCA, Product or Medical Specialists should be involved. If an overall system is implicated, include those experts in the RCA team regarding training, supplier quality, SOP writing, etc., before finalizing your root cause. Those closest to the problem are the most knowledgeable and have skin in the game, making them most likely to identify the actual cause.

iQuality QMS for Life Science Industry

iQuality QMS is a SAAS (Software as a Service) based QMS application designed especially for life science industries in alignment with the compliance regulations (21 CFR Part 11, ISO 9001:2015).  iQuality has a power-packed QMS (Quality Management System), and DMS (Document Management System) interlinked and integrated with analytics. The platform is user-friendly and straightforward with clever configurational aspects as per the needs of an organization and the industry type and built to scale and pay per use model.