Handling Out-of-Spec Results Without Losing Your Weekend

Every QC lab has the same Friday-afternoon nightmare: an analyst enters a final result, the value is just outside spec, and the entire release schedule is now in question. What happens next determines whether you spend the weekend chasing emails or close the investigation cleanly on Monday morning.

Here’s a workflow that works for small and mid-size labs.

Step 1 — Confirm the result is real

Before escalating, verify the obvious:

• Was the correct method, reference standard, and instrument used?
• Are the calculations correct? (Unit conversions are the leading silent killer here.)
• Is the instrument within calibration?
• Was the sample prepared correctly?

A quick checklist run by the analyst, before anyone else is paged, eliminates a meaningful share of false alarms. It also signals to auditors that you don’t reflexively retest your way out of bad data.

Step 2 — Lock the result, don’t overwrite it

This is non-negotiable: the original out-of-spec value must remain in the record, untouched. If your system lets analysts edit a value to “fix” an OOS, you do not have a controlled data system — you have a liability.

A proper LIMS captures the original entry, the timestamp, the user, and any subsequent annotations or re-test results as additions to the record, not replacements.

Step 3 — Open a formal investigation

If the result survives confirmation, open an investigation. At minimum, document:

• The original value and the spec.
• Who detected it and when.
• The hypothesis being investigated (lab error, instrument error, sample integrity, true OOS).
• The plan — re-test, re-prep, re-sample, or release-with-deviation.
• The reviewer responsible for closing the investigation.

This is sometimes called a “Phase 1 / Phase 2” investigation in pharma contexts, but the principle applies anywhere: separate lab-error investigation from manufacturing-cause investigation, and don’t let one contaminate the other.

Step 4 — Re-testing has rules

Re-testing without justification is one of the fastest ways to fail an audit. Before any re-test:

• Document the specific reason re-testing is justified (e.g., confirmed pipette error, instrument fault).
• Pre-define how many re-tests will be performed and how the result will be calculated.
• Have a second analyst witness the prep where possible.

“We re-ran it and it passed” is not a closure statement. “Original result was traced to a calibration drift detected on instrument #3 the same day; instrument was recalibrated and the lot re-tested in duplicate, both within spec” is.

Step 5 — Close the loop

Every OOS investigation should end with:

• A documented root cause (or an honest “indeterminate, lot rejected”).
• A CAPA if a systemic issue was identified.
• A trend review — has this method, this analyst, or this instrument generated similar OOS events recently?

The trend review is the part most labs skip, and it’s the one that prevents the next Friday afternoon nightmare.

How software helps

A LIMS won’t investigate for you. But it will:

• Flag the OOS the moment the result is entered, before it propagates.
• Prevent silent overwrites by enforcing audit trails.
• Surface trend data without you having to assemble a spreadsheet.
• Hold the investigation record alongside the sample, so nothing gets lost in email.

That’s exactly the workflow Aliquora is built around. Take a look.