Issue link: https://www.e-digitaleditions.com/i/1483907
28 BioPharm International ® Manufacturing and Facilities 2022 eBook www.biopharminternational.com Audits And inspections surate with the probability of the risk occurrence. The frequency may be adjusted based on documented his- torical performance. Intended use of the data. The intended use of the data should also have an impact on the need for and frequency of ATR. The data's potential risk impact on patient safety and product quality should be con- sidered, and GxP-relevant data are determined by regulatory requirements. High risk impact data are defined as data with po- tential for direct impact to product quality and patient safety. Individual companies may identify other activ- ities as high impact but at a minimum would include release, clinical stability, and cleaning verification. While it is acknowledged that companies may as- sign slightly different levels of impact to the same data types, some useful guidance may be obtained from an informal poll conducted of IQ member companies. Data arising from activities such as GLP studies, cleaning ver- ification, clinical product release, and stability were con- sidered greater impact and may trigger ATR. Activities such as method validation may have an indirect effect on product quality and patient safety and may be less impactful and have a medium/low impact dependent on a company's risk considerations. Defining appropriate ATR effort/frequency. To- gether, the assessments of the system characteristics and limitations and the impact of the data's intended use will facilitate identification of records, steps, and changes, and enable risk classification (low to high) and a tiered audit trail review effort. Performing data ATR A decision tree describing the performance of ATR is provided in Figure 1. Additional explanatory comments about the decision tree are given as follows. Where it is possible for changes to be made to the experimental conditions, metadata, or other param- eters that have the potential to affect the results/data, one control strategy to ensure detection is to perform ATR. In these cases, the following should be considered as critical changes (and potentially included in a list of elements to be checked): • changes to test parameters • changes to data processing parameters (analytical method) • deletion of data • repeated analysis or reprocessing without justification • change history of finished product test results • changes to sample sequences • changes to sample identification • changes to critical process parameters. The requirements for ATR (and data verification in general) should be proceduralized and should de- fine requirements on a software-by-software basis dependent on the assessed data risk and impact. The frequency and responsibility for ATR should be de- fined in the procedure. Evidence of audit trail review should be documented, in most cases by defining the meaning of the overall review signature. System level ATR The purpose of a system level ATR is to ensure key configurations and settings have not been changed (either intentionally or unintentionally). It is recom- mended that the system audit trail (which contains, for example, system administrator actions such as deletion of data or changes to system security set- tings) also be reviewed at least periodically. This pe- riodic review will ensure the system has remained configured as it was during validation/qualification. Based on the type of the system and corresponding data, the following items might be considered: • system policies • deactivation of audit trail • changes to data paths or folder structure • changes to reports or calculations • data security management (lifecycle including ar- chival, restoration, etc.) • audit trail review may be used to verify appro- priate access privileges have been used. Other processes may be employed to satisf y this re- quirement such as user access reviews (including admin privileges) • configuration files • library files (where applicable) where the technical controls of the library would drive the need and fre- quency for review. A decision tree has been developed (Figure 3) for sys- tem-level ATR where data types were categorized with examples and the need for audit trail review considered. Figure 2: Determining the rigor of audit trail review (ATR) as a function of data risk and data impact. Data Risk H 2 3 3 M 1 2 3 L 1 1 2 L M H Data Impact LEVEL AUDIT TRAIL REVIEW EFFORT LEVELS 1 No ATR is required, as supported by a documented risk assessment. ATR is performed on a "for cause" basis only. 2 ATR may be performed on an ad-hoc basis or periodically at a pre- defined interval. 3 ATR must be performed as part of the broader data review prior to the release of the data. FIGURE 2. Determining the rigor of audit trail review (ATR) as a function of data risk and data impact.