Root Cause Investigation

This article contains tools or brief idea about for finding out Root cause i.e. Methods of Root Cause Investigation

Methods of Root Cause Investigation 

1 Introduction :

Within the regulatory framework of pharmaceutical manufacturing the claim for detailed and comprehensive investigation of incidents as well as the planning of suitable corrective and preventive actions occurs repeatedly (e.g. EU-GMP Part 1).

The real cause of an incident may not always be obvious and often symptoms are taken for causes.

For example:

A deviation happened because the operator was not trained. So, one could assume the missing training is the cause for the deviation and a suitable CAPA would be to train the operator to prevent the re-occurrence of the deviation. The deviation would probably occur sooner or later again, because the root cause was not identified and the CAPA addressed only a symptom. An RCI maybe would have shown that the training procedure for changes in procedures is insufficient, which is caused by insufficient personnel capacity in QA to train all changed procedures. Therefore, the right CAPA would be to increase the capacity in QA or to shift responsibility for trainings to other departments and to adapt the training procedure.

This means that only if the “real” underlying cause for a deviation or other incident is identified adequate CAPA can be defined to prevent re-occurrence of the same or similar deviations or incident respectively.

There are various methods for root cause investigation which shall be briefly explained below. The methods to be applied should be adequate to the complexity of the deviation or incident. In some cases, a formal root cause analysis is not necessary because the reason is obvious. An example would be a missed review of a SOP – In this case the deviation is of minor criticality and can be fixed by review of the SOP and maybe a re-training of the SOP maintenance procedure to SOP owners.

When you plan a root cause investigation it should be clear that there is no such thing as a generally suitable method for root cause investigation. This is due to the variability of the nature of possible errors as well as their different complexity. All methods have advantages and disadvantages with respect to a specific error situation. Therefore, the application of various root cause investigation tools or a combination of different tools may be appropriate. Following a strict pattern not considering the specific case may also lead to wrong conclusions.

2 Methods of Root Cause Investigation

5 Why Method

The problem is addressed by a “Why-question” which is repeated for the found answer and so on until no further answer can be found. A perquisite is that the procedure is not stopped too early. A good indication that the root cause is found when a Why question addresses a deficient process or missing pr

Example:

During Batch record review it became apparent that the used API manufacturer is not qualified.

01) Why was the API manufacturer not qualified?

Because QA department was not aware that the supplier exists.

02) Why did the QA not know the supplier?

Because Procurement department made no change request.

03) Why did Procurement department no change request?

Because the respective employee was not aware of his obligation.

04) Why was the employee not aware of his obligation?

Because he was not trained

05) Why was he not trained?

Because the responsible person for trainings left the company without a deputy and because the training monitoring system has gaps.

06) Why has the training monitoring system gaps?

Because the monitoring process is not well described in the training SOP and responsibilities are not clearly assigned.

Possible corrective actions:

• Block the product batches until the API manufacturer is qualified
• Qualify the API manufacturer
• Train the procurement department on the Change Control process

Possible preventive actions:

• Review the employee exit procedure
• Review deputizing rules (job descriptions) and close gaps
• Review the training SOP and especially the training monitoring system

Brainstorming

For complex deviation topics a brainstorming with representatives of the different disciplines (e.g. QA. R&D, Production, QC) may be useful to identify the root cause. In first instance the participants communicate all their ideas without any restrictions or discussions on the probability etc. which are recorded. In the second step theses idea are analysed in the group for their probability to represent the root cause. The identified reasons may be further investigated by review of further documents or performance technical/analytical tests to find the true root cause. The protocol participants, date, time and outputs of the Brainstorming becomes part of the deviation documentation.

FMEA (Failure Mode Effects Analysis)

The prospective method is briefly described in SOP Quality Risk Management and further information can be found in the ICH Q) guideline (and unofficial ICH briefing material on ICH web page). If a FMEA was performed for a process in the past the deviation may has been identified already as potential failure.

Ishikawa-Diagram:

The Ishikawa-Diagram (= Fishbone Diagram = Cause-Effect Diagram) is a tool to collect possible influence factors for a specified incident in a team approach. Possible causes are displayed graphically which facilitates the identification of the root cause.

The diagram should be prepared by an interdisciplinary team guided by a moderator. The process starts with a horizontal arrow with the effect at the tip (e.g. broken tablets in the blister).

The main influence factors are connected by oblique arrows with the main line.  The main influence factors can be adjusted but often material, machine, method, humans, management, environment are chosen.

For each main factor secondary and tertiary factors can be identified and connected by smaller arrows.

.