One Way to Interrogate "Human Error" in CAPAs
An approach to a specific, recurring problem that has held up well in practice.
Few topics in quality draw as many strong opinions as how to run a corrective and preventive action investigation.
People’s perspectives often diverge on just about every dimension of it: tools, about how deep is deep enough, and about when a root cause is really the root cause. We think that range of views is actually healthy as it challenges models and techniques in an area where no single method genuinely fits every situation.
We’re okay wading into that debate space from time to time, given just how many CAPA programs we encounter (and build or optimize) in the course of our fieldwork.
Here, we want to cover one part of the work that trips up a lot of investigations: deciding whether a problem that looks like human error actually is one. The approach below is not the only way to do this, but it has worked well for the Quality teams we work alongside and for us, and it holds up under inspection. So let’s break it down in case it’s a model you want to adopt, in full or in part.
First, a little context.
Human error is cited far more often than it happens
Genuine human errors are real, and in FDA-regulated manufacturing and adjacent functions, they do occur. But we see them get written into investigations far more often than they should, and that gap causes problems when it (intentionally or not) papers over what’s actually a systems problem that looked like a human error.
Most issues that first look like human error, especially ones that recur, trace back to a process or system that will keep producing the same problem until someone changes it. Labeling the cause “human error” puts a band-aid over that system and leaves it intact. The next occurrence is already on its way.
There’s an obvious inspection risk here, too. When an investigator sees human error cited more often than it could plausibly happen, it reads as a sign that problems aren’t being investigated thoroughly. That can move the investigator into problem-hunting mode and open the wider quality system to more scrutiny. We see this quite often in our audit and mock inspection work.
The exception is the one-time error made by a well-trained person following a sound process, where a passing distraction led to a mistake. That classification can be justified, but only after a thorough investigation has looked everywhere else and found nothing. It’s a conclusion you earn by exhausting the alternatives, not a place to start.
A model for telling genuine human error apart
It helps to have a structured way to test whether an apparent human error was deliberate or inadvertent, and if inadvertent, what kind of error it was.
The Skills, Rules, Knowledge framework, paired with the Generic Error Modeling System, does this well. It’s simple to follow, and it pushes you past the easy label toward the place a real problem is likely to sit. Just about every team can use this.
Let’s break it down:
The first question is whether the action was deliberate or inadvertent. An inadvertent action is the only kind that counts as a genuine human error in this model. From there, inadvertent errors fall into three types: skill-based, rule-based, and knowledge-based.
Skill-based errors are further split into slips and lapses. Both point to the same root cause: a lack of attention, showing up either as momentary memory loss or as a routine action that wasn’t performed. These are the closest things to a true human error, and they should be pretty rare.
Rule-based errors are more technical, such as applying the wrong rounding rule, resulting in an out-of-specification result. Before faulting someone’s judgment, ask whether they were set up to perform the task correctly:
Did training give them enough practice?
Did that practice match the operation they actually perform on the floor?
Does the procedure spell out the details needed to do the task correctly?
Knowledge-based errors tend to show up when someone is multitasking beyond their capacity or can’t give a task the focus it needs. The useful question is why they were in that position at all:
Were they asked to do too many things at once?
Is the department under-resourced?
Did the supervisor know the person was stretched past their limit?
In the rule-based and knowledge-based cases, notice that the questions point away from the individual and toward training, procedures, workload, and oversight. That’s the point of the exercise!
Two places systemic “human” error usually hides
When an error turns out to be less human than it first appeared, the next question is about how the work actually gets done. Two areas are worth a hard look.