Custom Field Validation

Our site has thousands of test methods for routine testing. We also have a lot of new projects under method development without official method. I wonder how you normally handle the custom field validation in your environment to make it manageable? Thanks in advance for your feedback.


  • I have unfortunately been unable to spend time to validate my custom fields.  Users are therefore stuck performing full review of any fields which directly impact built-in fields (e.g. std amount values, dilution field) as well as any custom fields that perform a calculation.

    Our commercial lab doesn't ultimately have much variety and go through a small validation, scaled like someone might use for validating an Excel spreadsheet, on the project(s).  This approach validates that the instrument method matches the test method requirements, custom fields are correct, etc. so that review of the data/batch is limited to the data entry values and the output is then transcribed into reports accordingly.
  • Most companies have an SOP to follow when they are validating custom fields, usually test the formula against Excel or a calculator and see if they are the same. 
  • I have an SOP and a Form, Lab management submit the Form, I create de CF's, a Superuser verify the calculations, manual vs Empower.  QA approves the Form, then I copy the CF's to a Master Project and locked them.  Any changes after that need to be manage by the same process.  I use a calculator instead of excel.  After disclaimer Waters recommends 3 sets of data but I always use one.  Not sure if this is a new requirement.
  • Thanks everyone for your input. In our environment, 60% of the calculation are standard formula of %w/w or %area. However, we do have a lot of special methods that use unique calculation formula, especially if it's USP/EP impurity method, or GC method. Therefore they are the ones causing headache. My other concern is how user distinguish validated vs. non-validated custom field, since our environment has R&D samples without official method and the formula can be changing dynamically.

    My plan is to focus on our QC methods only and build a master project to store the validated custom fields gradually. Using manual verification (calculator) against representative data  as the proof. It's similar to the Excel template validation process.

    From risk perspective of data life cycle, there are other factors affecting the calculation other than the custom field, such as the sample set and processing method setup. Therefore I think checking the user entry only after custom field validation do not guarantee the calculation is accurate, unless the sample set method and processing method can be locked down. Our impurity processing method had to be adjusted from sequence to sequence to identify the unspecified peaks and match the RT. Th at's one of the continuous concerns we have.
  • Another thing to bear in mind when using a calculator to compare figures is that Empower uses 14 decimal places for real numbers but if the precision for displayed output is low (0-2 decimal places) you can get small differences between Empower and the calculator. The differences are slight (example, 0.218 versus 0.216 etc) but a tricky auditor could ask why they aren't the exact same which is what you are aiming for. 
    Therefore I always validate the calculation at the full precision for whatever data type im creating so a peak, real, field like A.%..AVE(Area), I would bump the precision of the Area up to Max of 14 for the validation and show what all the individual area values are before averaging them using a precision calculator (plenty of them online) set to 14. That way the Empower value and calculator are identical and you can then choose a final reporting lower precision because you have demonstrated that Empower correctly uses all decimal places for all its calculations. 
    I always use a final reporting precision of at least one decimal place higher than the original field which is dependent on the formula do for example a formula like Amount/CConst I would report at precision of 4 because Amount is a precision of 3. Similarly, a formula like SUM(GT(Area,CConst2)*Area) to at least 2 as Area precision of 1, etc etc.

  • Empower uses 14 decimal places for real numbers but if the precision for displayed output is low (0-2 decimal places) any proof document this calculation
  • Have you looked at the ICH impurity processing options to automate impurity calculations?
  • Hi ,

    Original question was CF validation

    Requirements to confirm

    SOP on CF use, rules etc ?

    Create CF and document ? How ?

    Check using Excel with 3 sets of data ?

  • Any further validation points to share ?
Sign In or Register to comment.