Correction, corrective action, and why 'staff error' is a starting point, not an answer

Five terms get used loosely on the bench and mean different things in an investigation record. A correction fixes the immediate problem in front of you, amending the one report. A corrective action removes or reduces the cause so the same failure mode is less likely to happen again. A preventive control acts before any specific event occurs, closing a gap the laboratory noticed by trend or risk review rather than by an incident. An improvement raises performance above the prior baseline rather than only restoring it.

Use the terms by the decision they support: correction repairs the current event, corrective action changes the condition that allowed recurrence, and an effectiveness check tests whether that change performed as intended during its defined follow-up period.

The instinct after an event like this is to write 'technologist error' and move to retraining. CAP calls for identifying the causal factors that underlie an error rather than stopping at a 'staff error' label; the laboratory has to identify the system condition that allowed the error to occur or let it go undetected. CLSI QMS11 directs the investigation toward why an error was possible and why the existing controls did not catch it, not toward stopping at the person who was at the bench when it surfaced.

James Reason's system approach to error separates active failures, the unsafe act at the point of care, from latent conditions, the upstream design, staffing, training, and organizational decisions that made that act likely. A person-focused response answers an event with blame, discipline, or retraining aimed at the individual. A system-focused response redesigns the process or strengthens a defense. Reason's argument is that the system response produces safety improvement that survives staff turnover, without excusing individual accountability where it genuinely applies.

A related idea, work-as-imagined versus work-as-done, asks what the written procedure assumes happens and what actually happens under real conditions: interruptions, workload, a flag that is technically visible but easy to miss during a busy run. The gap between the two is not automatically noncompliance; adaptation is frequently what makes a process work at all under real load. Investigating a deviation should ask what the procedure assumed, what conditions actually existed, and why the person adapted, rather than stopping at whether the procedure was followed to the letter.

The process map below lays out a usable sequence: state the event, correct the immediate problem, investigate contributing factors, identify the system condition, select and implement an action, then define and review an effectiveness check. Write down what the procedure assumed the technologist would do, and what the technologist actually could see on screen, before you write down what the technologist should have done differently.