Analytical Test Method Validation for API Raw Material, In Process Control, and Early Intermediate Material Tests
Risk Assessment and Prioritization
Introduction
This procedure provides guidance for the validation of analytical test methods. These analytical test methods include those tests which evaluate API Raw Materials, In Process samples (e.g. reaction monitoring), and early intermediate materials (prior to the introduction of the first critical intermediate).
The need to validate an analytical test method should be based on an impact assessment. Per ICH Q7A, the degree of analytical validation performed should reflect the purpose of the analysis and the stage of the API production process.
Those analytical test methods that should be validated, and are included in the scope of this document, include:
Registered analytical test methods.
Methods used to test a critical attribute.
Methods used to monitor a critical process parameter.
Other methods that may be used to make a decision that affects final API product quality.
Methods that should be developed and evaluated using sound scientific techniques, but that may not require validation include, for example:
Methods performed during a processing step that are redundant with a validated method used to test the isolated intermediate or material. For example: An IPC test (%LOD) used to monitor interim drying before a product is discharged from the drier bed.
Methods used solely for purposes of safety, environmental, yield, efficiency, or operational decisions (with no product quality impact).
Risk Assessment and Prioritization
To ascertain which raw material, in-process control (IPC) and intermediate test methods require
validation, it is suggested that a documented Risk Assessment be carried out on test methods currently utilized at an API site. This risk assessment approach can be used to evaluate legacy or new test methods.
This risk assessment evaluation may be based upon the following suggested principles:
Regulatory expectations at the time of product filing or re-registration
Methods may generally be grouped from low risk to high risk. This risk grouping helps to prioritize those areas that need validation based on a science based evaluation of impact to final API product quality. The following table (Table 1) gives an example grouping strategy for the analytical methods within the scope of this procedure:
Evaluation Process:
Conduct a cross functional and documented analytical test method evaluation based upon an understanding of the test data utilization by the Site Quality Authority and other site functions.
This cross functional review might be conducted by colleagues drawn from the Site Quality Authority, Site Production Operations, development support and other site based or center technical functions as necessary.
Methods may be grouped for this evaluation, such as in the above table to set prioritization for the team.
During this evaluation phase, a number of contributing factors tend to determine impact to quality. Downstream effects may also need to be considered. For example, once the material is isolated, tested, and discharged from the equipment, one may have to reprocess/ rework material because of potentially inaccurate data from the earlier IPC test method.
The use of what-if scenarios can assist in the risk analysis. For example, consider the following:
- Stage in the API Process: Where does this test method’s result lie within the overall quality ‘control’ or ‘assurance’ strategy in producing a quality API?
- Critical Quality Attribute: Can analytical data gleaned from this early stage of the step highlight where an impurity or its precursor is forming?
- Critical Quality Parameter: Could the process step be adjusted within allowable parameters to marginalize or purge unwanted impurities before isolation?
Evaluation Conclusions and Corrective Actions:
For those test methods, which are identified as higher risk (e.g. See Table 1), one can review the existing validation documentation (if any) associated with the method.
Documentation content and accessibility of the raw data should be considered rather than specific validation documents when assessing legacy methods and their existing validation.
Sites should leverage existing documentation through remediation and reference (when possible), to address validation deficiencies.