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

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?

Best Answer

  • Accepted Answer

    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!)

Answers

  • 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.
  • 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..
  • 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.

  • 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. 
Sign In or Register to comment.