top of page

OOE - an enabler for QC

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? :)




1 view0 comments

Recent Posts

See All

PQR, QMR, CPV, VMP/VMR, Computerized systems' periodic reviews, who knows what else...we manufacture these summaries, but exactly what for? Sometimes we spend so much time compiling these documents th

I just received a question that looked easy at first, but the laws and guidelines are surprisingly vague on this topic. The question is: how to choose between retest period and shelf-life for an API (

bottom of page