Practical example of a Result, Boolean custom field?

Empower2018

I have used many different combinations of data types and field types in custom fields such as Peak, Real, Peak, Integer, Sample, Enumerated etc but I have yet to come across a practical use for a Result type Boolean custom field or a Result type Enumerated custom field. All I can think of for a result type Bool would be something like GTE(A.%..AVE(Area),100000) and a translation set to use as "Field" such that 0 = Not Applicable and 1 = SUM(Area) (fc).

shaunwat

That's exactly  it...

Say you wanted to develop your own impurity code and wanted to distinguish known (named) from unknown (unnamed) peaks:

Found_Peak: EQ(Peak Type,"Found") translations being 0=-50,000, 1=1

Unknown_Peak: EQ(Peak Type,"Unknown") translations being 0=-50,000, 1=1

You could key off this field to generate, say, a known area % (or what ever) and an unknown area %

Found_Result: Found_Peak*% Area

Found_Sum: sum(Found_Result)

etc

etc.

Enumerated lists? Assume you had founds, but needed to exclude your parent compound, which would also be a found)

ENUM(EQ(Area, CCalREF1[area]), NEQ(Area, CCalRef1[area])),

You could then provide the translation for condition 1 to be -50,000 and the other translation to be 1, thereby giving you a easy way to discard your parent from a subsequent calculation.  

I caution against using these fields as a function. It sounds great in practice, but the result of a nested custom field in these translations generates a whole number result when subsequently used.

MJS

Shaunwat shows some great examples.  Just to add to more examples of where these can be useful:

I have a Result-type boolean custom field for reporting impurities where if the sum of all "reportable peaks" is less than a "per sample" threshold, then the "<X%" is reported rather than the numeric sum.  It helps prevent reporting of <LOQ results as numeric values in my case (this has an added benefit with QA as they don't like it when we get numeric values and "re-interpret" them as things don't match, this avoids them from ever asking why or asking for additional explanation on a report).

LT(ROUND(Area_C_P_C_Sum_01, -2), 0.1) : Returns either the original field's sum result or "<0.1%"

I have a lot of examples of boolean/enum fields for peak LOQ determinations or bracket standard comparisons, but those would be Peak-type fields.

Empower2018

Thanks for the replies, guys. Do you not use the Impurity tab within Empower 3? I don't hear a lot of people talking about it, I wonder is it prone to bugs or crashing and people prefer tried and tested custom fields?

MJS:

I presume for your custom  field LT(ROUND(Area_C_P_C_Sum_01, -2), 0.1) you have the Use as set to "Field" and for the 0 or No position in translation table its Area_C_P_C_Sum_01 (fc) ?

shaunwat

No, I do not use the impurity tab in processing methods that was introduced in Empower 3 FR2. The data on reports generated when using this tab is not presented in what I would consider to be a human readable format.

For example, say you used an area % cutoff of 0.5%. Empower would show you all of the peaks integrated no matter if they are above or below your cutoff. You would then look at your area % column and would quickly realize the area % values don't add up because Empower did what you asked and didn't include anything below 0.5%. You would then need to go back and figure out what was actually done by looking at the processing method and potentially manually verifying that the proper peaks, etc. were used.

MJS

Yes, it would be set to field for the "return a value" scenario with the Area_C_P_C_Sum_01 (fc) translation.  My methods were developed in Empower 2 FR3 which did not have the purity tab.  The methods are written to account for relative response factors, etc. so I have a series of custom fields that complete those along with checks like this for summary functions.

I've played around with the impurity tab to see where we could go on a future method/revision in changing the method calculations, but I'm not sure it will work very well in adapting current methods in my case.  We've historically tried to avoid doing the blank subtraction through the method set/processing and have relied on custom fields to perform a subtraction post-integration of identified peaks.  Using the impurity tab does not appear to allow for blank subtraction unless you utilize the blank subtraction in the method set when processing. 

Empower2018

I read a recent release note pack for Empower 3 and a lot of Impurity tab issues seem to be working better now, but im not 100% confident in using it in its current state until there is more positive feedback associated with it. 

Regarding blank subtraction, I have a PDA gradient method with a sharp rising baseline but I don't use the PDA Blank Subtraction because my retention times are never 100% reproducible and negative peaks get added to my samples and disrupts clean integration. I use the formula (GT(Area-BL.%.(Area),0))*(Area-BL.%.(Area) as a field to remove any diluent related peaks from samples. 

MJS

Absolutely.  In the end, it's that the custom field can't be used effectively with the built-in impurity functionality in E3.

HeatherLongden

Upcoming Webinar will give examples of how Enum and Boolean custom fields can be used to report ‘exceptions’ which could impact how an Exception Focussed Review procedure could be implemented. 

Empower2018

Hi Heather, that sounds like a very interesting webinar. Are the details on the Waters website do you know?