How should I correctly report this?

[JI2002]

vmu, if 100% derivatization efficiency is verified, please provide data to prove it for the problem raised by pear.

[vmu]

vmu, if 100% derivatization efficiency is verified, please provide data to prove it for the problem raised by pear.

I don't know what and how Pear derivatizes. I guess he/she verified 100 % reaction yield in order to use a commercial derivate as the calibration standard in his/her particular method.

The problem he/she raised is not related to the yield problem you started to discuss. I can repeat that the interfering peak on the blank chromatogram is either a result of poor separation or a result of poor sample treatment leading to contamination of the blank and samples. The calculations by difference lead to increased errors (or uncertainties) in results. In the case of non-zero blanks, the actual LOQ for samples is higher than the LOQ estimated with standards.

Any particular result obtained from the difference between a particular sample signal and a particular blank signal can be judged as a reportable result only on the basis of the magnitude of the uncertainty of this result. The acceptance limit for uncertainty must be set. However, it might be easier to modify the method to obtain blanks without interfereces than to deal with the calculations of uncertainties for the current method. The variations and correlations in blank and sample signals have to be carefully accounted for in such calculations.

[Hollow]

I second vmu.


keeping things generic, even if one does derivatise the references, the calibration curve is still just a linear equation:

Code: Select all

y = ax + b

or in laboratory terms:

Code: Select all

Signal = Response * conc + Blank

So the correction of "contaminated" reagents will be contained in the y-intercept, which is the "Blank"; while the (in)-efficiency of the derivatisation (a.k.a more generic "recovery rate") will be contained in the response.

So one can write it like:

Code: Select all

Signal = (recovery * pure-Response) * conc + Blank

(pure-Response = from a molecular point of view; with pure reference substances)

Now refactor for the conc of an unknown:

Code: Select all

conc = (Signal - Blank) / (recovery * pure-Response)

I guess, that's what we all are doing?
In real life, all of those factors will have their uncertainty, of course.

To further simplify, we can also define

Code: Select all

net-Signal = (Signal - Blank)

so the equation will become:

Code: Select all

conc = net-Signal / Response

Now, what pear was asking, was how to report a result, where the net-Signal is < LOQ(*) but Signal and Blank were well above the (instruments)-LOD.

And that will depend on the uncertainty of the Signal and Blank: when will the net-Signal be significant.

*I guess there is also a confusion/mix-up of different types of the terms "LOD"/"LOQ": (physical) instruments-LOD and sample related LOD.

Pear was referring to the instruments-LOD, while his QA also takes this as the sample-LOD.

But these may be different things.

The instruments-LOD defines how big a signal needs to physically be to be recorded and not taken as noise, while the samples-LOD has to deal with the significance of the net-Signal.
If the Blank = 0, then the net-Signal corresponds directly to the S/N and therefore to the instruments-LOD; but like in pear's case, when the blank > 0, this direct approach is no longer valid.


So, in my opinion, it may be possible to report a result that is < the instruments-LOD, as long as the net-Signal is significant.
(and was calculated from two signals that each were > the instruments-LOD; which has to be the case to be significant)

If this will also be significant in means of sample-LOD/LOQ has to be defined separately