Updated: Nov 10
We discussed in details how can we establish a well-operating OOT-limit for our products.
But what can you do when you have a result you cannot do anything with but it is obvsious something went wrong and you would really want to repeat the test?
Let's have an extreme example: you have a clarity test to perform. You solve the sample and you perform your test, everything is conform. But the solution is not colorless but blue! Or there is a brand new peak on your chromatogram, but your specification or OOT-limit cannot 'catch' it. You know you have to repeat your test, but how can you avoid the horrible 'Testing-Into-Compliance' scenario?
What can we do? We can define a new term for that: Out of Expectation - OOE. The name is self-explanatory: if you have something in your hands that is not expected, with initiating an OOE-investigation you can repeat your test withing complaince rules.
From procedural point of view, the most convienent and also efficient way to handle OOE-investigation through the same steps and requirement as the OOS-investigations.
And why this is better than just initiating a deviation? There are two simple reasons:
1, you eventually need to check the same topics you need to do in the frames of an OOT-investigation, so you can use your usual checklist.
2, initiating a deviation means classification, RPN - are you sure you want to go down that road? :)