Page 1 of 1

Integration type column

Posted: Tue Jul 30, 2013 1:46 pm
by lcrouch
I think it would be extremely useful for a column to be present in the result/summary tables, which indicates the type of integration used for each peak. For example, baseline or valley or skim etc. Also for some indication of whether the integration has been performed automatically or edited manually by the user. The latter is especially important in GLP situations.

You may know that some other chromatography software on the market uses peak codes, eg. BB indicating a 'baseline to baseline' peak or 'BV' baseline to valley and so on. Capital letter can indicate automatic intregration with lower case for manual for example.

I know that the method details can be added to the report, but this is not ideal as it is not always clear.

Internal issue tracking ID: 10379

Re: Integration type column

Posted: Thu Apr 10, 2014 10:59 am
by Daniel Mentlik
Dear Lewis,
thank you for the suggestion, I have entered it into our internal database under the number ISS59697.
In current Clarity, something along these lines will be pretty difficult to achieve, from two major reasons:
  • there is no distinction between manual and automatic integration. The Integration algorithm is a complex mechanism consisting of several steps, which starts with baseline detection and peak detection, continues through interval operations and ends up with peak operations. All of these steps are performed all the time, using the parameters set in the Integration table or, in case there are none, default parameters.
    Unfortunately for this suggestion, the the integration table applied is the one copied from the template method, which may (and probably should) already consist values and functions specific for the current method setup. From the perspective of manual amendments, the table was already manually modified, the basic (untouched) Integration table consists only Global Peak Width of 0.1 and Global Threshold of 0.1 values. These are the default ones and we encourage the users to adapt these values according to their sample rate, signal range etc., therefore every operation would be marked as manual in correctly filled Integration table.
    The second approach would be to store the Integration table copied from the template method as Automatic values and those added by user later in the Chromatogram window as Manual changes, which would need another structure in the Integration table storing the moment when each command was added. The user would still be able to modify the Integration table manually in the Chromatogram window, copy the Integration table into the template method and reprocess the chromatogram according to the template method, getting the result of all-automatic integration.
  • The Valley-to-Valley and Baseline types of integration are interval operations in Clarity. Therefore, in case the peak is in the interval for the Valey-to-valey operation, it would have the VV tag, if it si not there, it would have the BB tag (as baseline separation is the default one in Clarity). Small problem starts with the non-separated cluster of peaks, where the Valey-to-valey operation starts in the middle of the cluster. The applied integration is the combination of Valey-to-valey, Baseline, Forward Horizontal, Backward Horizontal and few other operations and must be set specific to the chromatogram to provide correct results, and it is very difficult if not impossible to describe this just the peak tag, to have the correct impression of whether the integration is correct or not, you would probably need the Integration table and the chromatogram graph anyway. There are no clear rules set on how the integration of the peak with integration type tag of BV should look like in such situation.
For the GLP situations, any manual changes (as well as those changes done automatically) are marked in the Chromatogram Audit Trail, so every operation with the chromatogram is logged. It may not be the best practice to rely on the printed report of the chromatogram for GLP purposes as we cannot ensure (and no software can by itself) that the report was not already modified, if only by editing the pdf file in Adobe Acrobat or similar tool or copying the printed report with changed parts in it and pretend to be the original report. The Integration table, as well as Audit Trail, may be printed as part of the report, but I would leave the evaluation of the manual changes on the examination of the chromatogram file.

Re: Integration type column

Posted: Wed Jul 09, 2014 4:37 pm
by lcrouch
Hi Daniel,

Thanks for the additional information.

I understand your point regarding the peak tags. I have used to the tags a guide when using other software to get an idea of how a peak has been integrated. For example, reviewing a large number of chromatograms it is useful to see if they have all been integrated similarly. So if one chromatogram shows that the peak in question has been integrated BV when all other chromatograms have BB I would investigate that suspect chromatogram further. But yes it can't provide a complete picture of what has occurred.

For the manual vs. automatic issue. My definition of manual integration is, "has the operator selected or forced where the peak should start and end, or have the peak start/ends been determined by an algorithm". Thinking about this a bit more, in clarity, manual integration would be if there are 'peak start' or 'peak end' events in the integration table (or maybe some other event types also). Perhaps there could be a marker if that peak start or end has been determined by operator or by algorithm?

You are right, there is no 100% way to guarantee that data has not been changed in GLP situations. Yes it's best to review every single chromatogram to ensure they haven't been changed but that is often not practical. But we can use a risk based approach. If for example we had a reliable quick way to know if any manual integration changes have occurred we could say that it is acceptable not to review 100% of chromatograms, but just a random few for instance.


Thanks,