How to make a limit custom field as universal as possible?

Empower2018

I have to make a Boolean custom field which calculates a Pass/Fail for USP Tailing, basically any value GT 1.5 is a fail. But the thing is, some of our methods in work vary this limit value in terms of decimals- some methods say GT 1.50, others 2.0, others 2 and still others 1.25! I really don't want to have to make a separate custom field for each product tailored to its specific precision eg GT(ROUND(Tailing,-1),2.0) etc. 

Is it best to throw the spec value into a CConst field and just report the value in a report method to the desired precision value ie 0,1,2 etc?

shaunwat

Yes, sort of.

Instead of something like GTE(Amount,0.06) I would have a custom filed called Reporting_Limit. The Reporting_Limit custom field would be set to use as Value and would contain a value of 0.06.

My custom field above would then become GTE(Amount,Reporting_Limit)

Now, if you want to make that even more universal, create a custom field called Reporting_Parameter. In my example, set Reporting_Parameter to be the Amount (but in realiey you can set this to what ever you want, even other custom fields).

You would then have GTE(Reporting_Parameter,Reporting_Limit) and that custom field never needs to change. All you need to validate is that it initially works and that your Reporting_Parameter and Reporting_Limit custom fields are able to accept your desired inputs and error when given an unepected input (e.g. Reporting_Limit = COW!)

Dan_Ramlose

You can set such limits within the processing method. No need for CFs on this. Between processing methods and field properties within report methods, should be no problem.

Empower2018

Hi Dan. 

Can you set precisions in the Limits tab of processing methods then?

I knew about the report method filed properties, that might be handier to use than a cf for each possibility..

shaunwat

Though I agree with the response above, if for some reason you are not able to use the approach Dan suggested...

Prior to Waters implementing the impurity tab in Empower, I had created a set of custom fields that would determine total known, unknown, and impurities as well of be aware of reporting parameters for impurities such as LOD, LOQ, Etc.

To make my approach generic across several test methods I used custom fields such as LOD_Reporting_Limit where I could hard code the value. Every other field that requried the LOD_Reporting_Limit would simply call that field as opposed to the actual number.

From a GAMP5 validation standpoint, I validated that the Reporting_Limit fileds could accept numerical input and all fields downstream were calculating results properly. This allowed me to be able to change that number to what ever i actually needed without impacting my validation work.

Empower2018

Thanks for the reply shaunwat. 
I'm not 100% sure what you mean when you say "Every other field that required the LOD_Reporting_Limit would simply call that field as opposed to the actual number.".
Are you saying that if you put the LOD_Reporting_Limit down as CConst1, then you could put whatever number is relevant to the method in the CConst1 cell?. Then if someone had one method with a reporting limit of 0.4 that could be input to CConst, another method might use 0.05 etc. 
Is that what you mean?
Regards. 

Empower2018

shaunwat said:

Yes, sort of.

Instead of something like GTE(Amount,0.06) I would have a custom filed called Reporting_Limit. The Reporting_Limit custom field would be set to use as Value and would contain a value of 0.06.

My custom field above would then become GTE(Amount,Reporting_Limit)

Now, if you want to make that even more universal, create a custom field called Reporting_Parameter. In my example, set Reporting_Parameter to be the Amount (but in realiey you can set this to what ever you want, even other custom fields).

You would then have GTE(Reporting_Parameter,Reporting_Limit) and that custom field never needs to change. All you need to validate is that it initially works and that your Reporting_Parameter and Reporting_Limit custom fields are able to accept your desired inputs and error when given an unepected input (e.g. Reporting_Limit = COW!)

Just to come back on this shaunwat, how exactly did you manage to code the Reporting_Paramater to  make it so flexible, did you make a Sample, Enum, Use as Field then type in Amount (fc)? ANd I presume your Reporting_Limit was a sample enum custom field with a list of values that you can pick for each sample? or is it transforming a CConst field into a custom field and called Reporting_Value?

shaunwat

The reporting_parameter and reporting_limit fields are real peak type fields. In a way what I did was transition a CConstX value to something more well defined and, more importantly, not able to be edited by the user.

The use of CConstX may work for reporting value, but it will not work for reporting parameter; you must use a peak type field for reporting parameter.

It's also been my experience that analysts generally confuse what CConst value goes with what. Hence, I try to avoid the use of the CConst variables in processing methods when coding custom fields.