LabWare Results, Calculations & OOS/OOT: CSA Validation Guide

Functional testing confirms a calculation produces a result when you enter inputs — it does not confirm the formula itself is mathematically correct for the intended method. Independent verification means manually calculating expected results outside the LIMS for a range of input values and comparing value by value against the LIMS output. This is necessary because a formula configuration error can produce a result that looks plausible and passes functional testing trivially, while being systematically wrong for the actual analytical method. This is the single most under-tested area in LIMS validation packages — most OQ scripts confirm the calculation runs, not that it is correct.

Boundary testing must include a result exactly at the lower limit, exactly at the upper limit, one significant digit inside each, and one significant digit outside each. This is necessary because the OOS flagging logic depends on whether the limit comparison is inclusive or exclusive — a configuration error here silently passes or fails results at exactly the boundary, the values most likely to occur in real testing of a well-controlled process. Testing only mid-range pass and obviously-fail values misses this entire risk category.

The system-generated OOS flag is necessary but not sufficient — it satisfies detection, but validation must also confirm the flag triggers the procedural consequence your SOP requires: blocking the sample from disposition until investigation is documented, routing notification to QA, and preventing the OOS result from being silently superseded by a later passing result without investigation linkage. A LIMS that flags an OOS but allows the lab to simply re-enter a passing value over it without preserving the original and requiring investigation linkage is a significant data integrity gap.

Result amendment validation must confirm: any change generates a mandatory audit trail entry capturing original value, new value, user, timestamp, and reason; the amendment requires appropriate authorisation, typically a different user than the original entry enforcing a four-eyes principle; and the amended result is visibly distinguishable in any report from a first-pass entry. A common failure mode is testing only that the audit trail captures the change, without testing whether a second analyst's review and approval is actually required before the amendment takes effect.

OOS detection compares a single result against a fixed specification limit — a relatively simple boundary comparison. OOT detection is statistically more complex, typically comparing a new result against a historical trend, meaning validation must confirm the underlying statistical calculation is correct, the historical data set is the correct and complete population, and the OOT flag correctly distinguishes a meaningful trend deviation from normal variability. OOT validation requires someone with statistical expertise to verify the underlying calculation logic — materially different from OOS boundary testing.

Yes — this is one of the highest-value OQ tests in the entire results module. The validation must confirm a batch with any open OOS investigation cannot have a CoA generated or final disposition recorded, the block is enforced at the system level rather than relying on a reviewer noticing, and the block releases only when the investigation is formally closed with a documented disposition. Without this system-level gate, a batch could theoretically be released before the OOS investigation reaches a conclusion.

Rounding rules must be validated against the specific method requirement, not a generic system default. The OQ must test that the displayed result reflects correct significant figures, rounding is applied at the correct calculation step, and the rule is consistently applied between the raw result, calculated result, and the value compared against specification limits. A mismatch between the rounding rule used for OOS comparison and CoA display can result in a value that displays as passing while the underlying comparison actually flagged it as failing.