Summarize Amounts

Juwe
edited December 2019 in Software Products
Hi all,

For one of our analysis we have two peaks in the sample solution. The assay should be reported as the sum of these two peaks if the corresponding amount is above the LOQ.
I`ve tried the following Peak, Real Custom Field:
GTE(Amount,0.05)*(Peak1[Amount]+Peak2[Amount])
But if only one peak is above the LOQ, it doesn`t work.
Are there any ideas how to create a costom field which can decide if the sum should be build or not?
For example:
LOQ = 0.05 mg/mL
Amount Peak 1 = 0.16 mg/mL
Amount Peak 2 = 0.03 mg/mL
If only one peak (Peak 1) is above the LOQ, the amount of this peak should appear (0.16 mg/mL).

Thanks in advance!

Answers

  • Is the objective to return the sum of the amount of both peaks regardless of whether one is below the LOQ? You say that if only Peak 1 is above the LOQ then this Peak Amount should appear. That can easily be done by a Peak, Bool, CF with Use as Field. Formula being GTE(Amount,0.05) with 0 set to Below LOQ and 1 set to Amount (fc). Im confused as to if you are looking for the sum of both peaks even if one is below LOQ.

    Example, Peak 1 being 0.01 and Peak 2 being 0.05 then the sum is 0.06. Can you clarify what you are looking for?
  • I'm sorry I didn't make myself clear. :/
    I only want to calculate the sum of both peaks, if both are above the limit.
    I like your suggestion to create a Peak, Bool, CF with Use as Field.
    But then I need a second CF for calculation of the sum of both peaks if they are above the limit, right?
    I'm not sure how I'm going to do this, as the first decision to be made is whether both peaks are over the limit.
    Is it possible to create the following custom field: SAME.%.%.SUM(first CF)

    Thanks!

  • Thanks for the reply. I got this to work using a Bool condition inserted into a summary custom field. So the formula is Peak, Real, Calculated, make sure All or Nothing is set to Yes. Formula: SAME.%..SUM(Amount*(GTE(Amount,0.05)))+LT(Amount,0.05)*-1*60004.

    I don't know how many injections you have per sample or what labels you put on your unknowns, but I will assume single injection and each unknown will have to have a different label, so if you are running 10 samples then label them something like U01 U02 U03 etc, that way you get a unique result for each sample. So Empower will look for any peak amount values that are GTE 0.05 in each chromatogram with the same label and sum them. So in your case if both of your peaks are GTE 0.05, the value returned will be the SUM, and this value will be returned for both peaks.

    Then for any values which are LT 0.05 the value "N/A" will be returned. I checked this using a test project and it worked fine. So in cases where one peak is GTE LOQ then this value will be returned for that peak, and the other peak will have "N/A" against it. I hope this helps.

  • Actually I don't think the above will work for single injections, because the % indicates more than 1 injection and I don't know if you are working with single injections of samples or multiples? If single, another approach may be needed. Its a tricky one. 
  • Just break it down further and try not to do it all in a single custom field.

    1. Peak_Test ENUM(GTE(Amount, 0.05),LT(Amount,0.05), where the translations are 1 and 0, respectively.

    2. Pass_Amount: Amount*Peak_Test

    If you need replicate averaging from there, then SAME.%.%.AVE(Pass_Amount).
  • The only thing with that formula is the Pass_Amount will only return the amount if one of the peaks is GTE 0.05. The OP wants the sum of both peaks returned if both are above the LOQ.

    The only way I could get this to work was create 2 CFs.

    1. Peak, Real, Calculated (Amounts_Added)

    Peak1[Amount]+Peak2[Amount]

    2. Peak, Bool, Calc Use as Field (Final_Reported_Value)

    GTE(Peak1[Amount],0.05)*(GTE(Peak2[Amount],0.05) and the translations are:

    0- N/A

    1 Amounts_Added (fc)

    the only drawback to this is that, when only 1 peak is above the LOQ, the value returned at this peak is still the Sum of the peaks instead of N/A being populated at both peaks. But it works fine for when both peaks are above LOQ, in that case you get the Amounts_Added value at both peaks.

  • The only thing with that formula is the Pass_Amount will only return the amount if one of the peaks is GTE 0.05. The OP wants the sum of both peaks returned if both are above the LOQ.

    Correct.

    You would need a third custom field: Sum: SUM(Pass_Amount).

    I must have gotten distracted by something or other... 
  • Yes, but there seems to be no way around the fact that when only 1 peak is above LOQ and the other not, the reported final result, be that a SUM(Pass_Amount) or my second CF Final_Reported_Value, will still populate the sum of both peaks in the one peak that's above LOQ instead of both peaks being populated with N/A or Arguments etc

    When both peaks are above LOQ its not a problem as both peaks will be populated with the correct Final_Reported_Value but I don't know how to code it such that if only one of the peak satisfies the condition of >LOQ, both peaks should be populated with N/A..no doubt due to the fact that a peak custom field will calculate for each peak and not take into account the entire chromatogram.

  • No, in my example it will not sum the peak below the LOQ because Pass_Amount multiplies the Amount by Peak Test. IF peak test is above 0.05%, then there is a one multiplier; if peak test is below LOQ, there is a zero multiplier. Sure, it will sum both results, but the result(s) below LOQ is 0, which won't impact your sum.
  • I have a field that is very similar in purpose. First, I use the CConst1 field in the PM to define the LOQ value for the peak(s).  Alternately, feel free to just enter a value instead, but using CConst provides for a very robust formula that could be applied to multiple situations rather than having to have multiple custom fields where the only difference is the LOQ value.  I have the following Peak/Real formula to determine what is added or not to a sum with regard to meeting that LOQ criteria:

    (RM_V*ROUND(API[Amount]*GTE(ROUND(API[Amount],-3),CConst1)+Isomer[Amount]*GTE(ROUND(Isomer[Amount],-3),CConst1), -3))+((LT(ROUND(API[Amount], -3), CConst1)&LT(ROUND(Isomer[Amount],-3),CConst1))*NEQ(API[Amount]+Isomer[Amount], 0)*-60009)+(EQ(API[Amount]+Isomer[Amount], 0)*-60000)

    The above example does use a release media volume as a multiplier, imposes some odd rounding rules (old method), and adds some additional functionality with the text strings, so you could probably simplify it a bit for your purpose...

    PEAK1[Amount]*GTE(ROUND(PEAK1[Amount],-2),CConst1)+Peak2[Amount]*GTE(ROUND(Peak2[Amount],-2),CConst1)

    Something this simple should be all you need.  It will compare peak1 to your LOQ, and add it to the total if GTE LOQ, then do the same if peak2 is GTE LOQ.  You could then add in the other conditional text strings for the other scenarios like I did...where both are below LOQ, then report BPQL, and if both peaks are not detected (peak amounts are 0), then report not detected.  That would make it more robust yet.

    PEAK1[Amount]*GTE(ROUND(PEAK1[Amount],-2),CConst1)+Peak2[Amount]*GTE(ROUND(Peak2[Amount],-2),CConst1)+((LT(ROUND(PEAK1[Amount], -2), CConst1)&LT(ROUND(Peak2[Amount],-2),CConst1))*NEQ(PEAK1[Amount]+Peak2[Amount], 0)*-60009)+(EQ(PEAK1[Amount]+Peak2[Amount], 0)*-60000)


  • Many, many thanks for your comments. I`ve learned so much by just reading the comments :D .
    I will try to create it. I`m sure, it should be work!
  • MJS, I can understand your formula up until this point:

    +((LT(ROUND(PEAK1[Amount], -2), CConst1)&LT(ROUND(Peak2[Amount],-2),CConst1))*NEQ(PEAK1[Amount]+Peak2[Amount], 0)*-60009)+(EQ(PEAK1[Amount]+Peak2[Amount], 0)*-60000)

    Would you be able to explain what exactly this does for each peak? From looking at it, I know the first half of your formula will sum the Peak1 and Peak2 amounts only if both peaks are GTE CConst1 when rounded to 2 decimal places. I think the first bracketed condition will return either a 0 or 1 based on the argument that BOTH Peak 1 and Peak 2 are less than CConst1 when considered to 2 decimal place. If 0 then it moves on to the next argument but if 1 then you are multiplying against a condition that evaluates that if the sum of both peak amounts are not 0 then return a BPQL for that peak and if both peak amounts are 0, return a ND. Is that correct?

    What I don't understand here is the 0 part of the last two arguments. Are you saying that if both peaks added together do not equal 0, then at least one of those peaks have some amount and therefore is detected but below LOQ? What happens if no peak amounts are calculated for one or both peaks- then there is no value to add together, so will this automatically kick in the 0 argument? Basically if no amounts are calculated for one or both peaks, what is returned when using that argument?


    Thanks in advance.

  • ::bugged:: Isn't this all (or at least mostly) stuff we should be able to do via the Impurities tab in the PM???
  • Im not sure Dan, I know you can set figures for reporting and id limits etc but I don't think there is a function to combine the amount of two peaks if two out of two peaks are above the LOQ. Ive only used it a few times and I didn't find it particularly user friendly. Especially the end report with lots of red and italic and column like Above Reporting Threshold etc it all seems so clunky and if an auditor picked it up they wouldn't easily be able to find the info they are looking for. 
  • I'd try playing with Named Group (proc. method) in combination with cutoffs for area... It's pretty manual, but should be reliable and simple (if it works). 
    I agree, that tab could be more user friendly. There are also entirely too many default options for component type that make it really tough to use it as a filter in some report methods.
  • @Empower2019
    So, the LT...and so on are to evaluate conditions where at least one of the two components fails to exceed LOQ.  So the +((LT(ROUND(PEAK1[Amount], -2), CConst1)&LT(ROUND(Peak2[Amount],-2),CConst1))*NEQ(PEAK1[Amount]+Peak2[Amount], 0)*-60009) portion is a "is at least one of the two above LOQ? and if so, report BPQL" result (text translation of -60009).  The +(EQ(PEAK1[Amount]+Peak2[Amount], 0)*-60000) portion is the "catch all" that verifies both peaks are NDs (text translation of -60000).  So, portion 1 either returns a reportable value (above LOQ) or 0, the second portion either returns BPQL or 0, the third/final portion either returns ND or 0.  Hopefully that clears it up for you.

    @Dan_Ramlose
    My method/formula predates the impurities tab as a holdover from Emp2 and, since it works for the old method that we don't run often, I've never bothered looking into updating our approach.  I would be hesitant to use an area as the absolute cutoff, however, as the slightest variation in standards can shift the area for the cutoff from one run to the next.  Using the amount is more robust, in my opinion.
  • Thanks for that MJS, I must remember the order as you suggested it could be very helpful for future custom fields at work.
  • Hi all,
    My question is similar, but what if I have to sum those to peaks and then apply the LOQ on that sum?  How can I create a CF to sum those peak?  Not sure how to specify peak name in a CF.  Then I presume I can use a Boolean type of CF.  

    thanks
  • You could use CCompRef1 and CCompRef2 in the processing method and that way you dont need to specify peak names. Then create a peak, real cf with formula CCompRef1(Amount)+CCompRef2(Amount) but use square brackets instead of regular brackets. Then create a peak bool on that cf such as GT(CF,10000) or similar.

  • I've been having some luck using the Impurity tab. You set your Impurity response to the appropriate thing, then set your reporting threshold(s) (carefully - there are some rounding landmines in play here - ie: if your LOQ is 0.05%, include lots of extra zeroes after that 5 because you don't get results until/unless you can round up in the last place entered). 0.05% threshold lowest result: 0.06, 0.050000 threshold's lowest result would be a value >0.0500005.
    The nice thing about doing it this way is that you need never change it once you get it right!