Human Error Is The Leading Cause Of GMP Deviations – Or Is It?

By Joanna Gallant, owner/president, Joanna Gallant Training Associates, LLC

Let’s do a magic trick.  Through this computer screen, I’ll read your mind…

Think of your company’s deviations. Concentrate on their most common root cause – the one you see most often and have the hardest time fixing. My high-tech-mind-reading-helmet tells me your answer is human error, correct? Magicians aren’t supposed to reveal their tricks, but this one really isn’t much of a trick.  Every company wrestles with human error.  We know humans have error rates – we’re not perfect.  But how many is too many?

I recently spoke with someone who said a whopping 58% of their root causes were identified as human error.  Average run rates at companies seem to hover in the neighborhood of 25% – and I was on the receiving end of a 483 observation in a company where this was the case.  So I can say with certainty that our target should be assigning a “human error” root cause to only a small quantity of deviations.

However, industry and the regulators seem to have differing expectations on this point.

How Do Industry And Regulatory Expectations And Approaches Differ?

Existing regulation supports that industry regulators expect only a small quantity of deviations to result from human error.  From Chapter 1 of the European GMPs:

1.4 (xiv): …Where human error is suspected or identified as the cause, this should

be justified, having taken care to ensure that process, procedural or system-based

errors or problems have not been overlooked, if present…

Our regulators see human error as a last resort.  Their expectation is that you can - and have - eliminated any possible process issues and confirmed that the individual had everything they needed and simply wasn’t focused.

Industry sees human error as a first-line response.  We almost assume our processes, procedures and training are bulletproof, and the issue must have resulted from someone not paying appropriate attention to what they were doing at the time.  When we do look at our training, procedures or process, we often verify that they make sense to us – the reviewer.  And then we retrain the operator on the same process or procedure, using the same training process – quickly! – so they can return to performing the task again.

How Should We Approach Human Errors?

To illustrate what we’re expected to do, let’s take a fairly common event:  Failure to follow procedure.  Under many circumstances, we don’t give this more than a glance before categorizing it as human error.  And it very well may be.  But let’s consider other possible areas before rushing to that decision. Asking one simple question -  “Why wasn’t the procedure followed?” - can lead to many different underlying reasons, such as:

• The procedure was inadequate, and not able to be followed:  Let’s face it, we all have procedures that need improvement. And procedures can be a catch-22: Too much detail creates long, difficult-to-use procedures that may be too confining for the task, thereby increasing the potential for deviations. Not enough detail leads to inconsistent performance of the task – which also leads to deviations. 

Worse, our process for changing procedures has its own challenges: Too many reviewers, difficult change processes, people who hold their changes to a procedure until someone else initiates a change and then try adding their changes on, and more. So we put off changing procedures that we know need help because of the difficulty of the change process.

Prior to categorizing the failure as a human error, assess your procedure for the following:

• Did the procedure specifically require the step to be performed?
• Did the procedure describe how the step should be performed?
• Do the procedure and the way the operation is being performed match?

• The training didn’t prepare the person to perform the task: We train people on procedures – but do we do a good enough job? On the job training (OJT) on a task should include reading the procedures, learning to perform the task, and being assessed against the required level of knowledge, skill and technique needed to perform the task independently.

Some companies still do only read and understand training when more is needed.  Others perform OJT, but don’t assess the trainee prior to releasing them to perform.  Yet others don’t provide supporting information the trainee needs to perform the task.

And there’s a more fundamental piece, related to the GMP foundation we provide.  People must understand GMP expectations enough to see that the only acceptable way of performing a task is as documented in the procedure.

Prior to calling the failure a human error, ask these questions of your training program:

• Did the training reflect the procedure content – and are all operators performing the task doing it the same way?
• Was it the operator’s first time performing the task independently? Were they allowed enough practice on the task, or was training rushed?  Was training time used for appropriate training activities?
• Did the trainer verify the operator’s ability to perform each required element of the task? Against what standard?
• Is all the information the trainee needs to perform the task correctly accessible to them?
• Did the trainer teach them the correct way to do the task?  Did the trainer have the knowledge and skills required to teach it?

• The process isn’t designed to prevent errors:  How we design processes can drive the error rate in their performance. We make some processes difficult, and have designed multiple Band-Aids into others, which can make them prone to errors. 

If we make it easy for someone to make a mistake, they will.  We need to make it easy for someone to do the right thing.

Lean and human error reduction activities should be used to find extra, wasted efforts and error-prone activities and design those out of the processes.  Too often, these processes are used to justify cost-cutting, making things worse. 

Again, prior to deciding the failure was human error, consider the design of the process the operator was performing. Ask these and any other applicable process design questions about the failure:

• Did the procedure reflect the current process, in its entirety?
• Is this process prone to errors? Why?
• Can one person realistically perform the process, or does it demand multiple people (complexity, multiple tasks performed at once, etc.)?
• Is the procedure available to the operator while performing the task, or are they performing from memory? (See observation #3 in this warning letter as an example)

• The environment in which they were asked to perform wasn’t conducive to proper performance: Environmental stressors may affect a person’s ability to perform and lead to errors – even if they have previously performed the task correctly. 

If operators multitask, or are frequently interrupted, the likelihood of an error increases due to multiple shifts of focus.  Sometimes this will be raised as a concern, but sometimes not – especially in resource-constrained environments where operators feel concerns have fallen on deaf ears.

Management plays a significant role in this situation. The assignment and alignment of work and projects, timing of meetings, using operators to provide training, and more affect how an operator works and their focus on tasks being performed.  While these are human error situations, they are driven not by the operator, but by the manager’s decisions and how much functional oversight and process management takes place.

Once again, prior to categorizing the failure as human error, ask questions like these about the situation:

• Was the operator spread too thin? Were they assigned too many work tasks at once?
• Was the operator rushing? Would structuring the person’s time or task list differently have avoided the error?
• Did the operator ask for assistance and not get it? Were required resources (like reviewers or witnesses) available when needed?
• Did the manager clearly set expectations that included performing the task per the procedure, and with the procedure in hand?

The Power Of “Why?”

A simple root cause analysis tool called “5 Whys” is a quick, easy way to identify the underlying conditions leading to a deviation.  A very brief version was presented in the above content.  We asked the first of the five “Why?” questions – and raised possibilities beyond human error that could have caused the failure with one simple question. 

Problems appearing as human error should always be explored further. Human error often isn’t the root cause – it’s a symptom of an underlying problem.  Using the “5 Whys” will help identify the underlying causes of the problem.  Through asking “Why?” repeatedly, you begin to understand what led to the problem – and ultimately identify the root cause. It generally takes a chain of five “Why?” questions to get to root cause.

A “5 Whys” analysis can help you meet the regulatory expectation of assessing whether process, procedure, or system based problems contributed to a human error.  If you go through the analysis and find nothing but the operator making an honest error, you can be confident in – and able to support - your assessment of human error as the root cause.