From Validation of Chromatography Data Systems: Meeting Business and Regulatory Requirements
Systems that are operational in regulated environments but are not validated must be brought under control. This is termed as retrospective validation. Retrospective validation costs must be balanced against the cost of a replacement system as this is the most expensive way to validate a system.
25.1 What do the Regulators Want?
25.1.1 PIC/S Guidance
The best regulatory advice for retrospective validation comes from the PIC/S guidance document31 where Chapter 16 is devoted to the subject; selected quotations are presented here, however the reader is strongly advised to read the whole section if faced with a retrospective validation of a CDS.
Section 16.1: Retrospective validation is not equivalent to prospective validation and is not an option for new systems. Firms will be required to justify the continued use of existing computerised systems that have been inadequately documented for validation purposes. Some of this may be based on historical evidence but much will be concerned with re-defining, documenting, re-qualifying, prospectively validating applications and introducing GXP related life-cycle controls
Section 16.2: A significant number of legacy systems may operate satisfactorily and reliably, however, this does not preclude them from a requirement for validation. The approach to be taken is to provide data and information to support the retrospective documentation of the system to provide validation and re-qualification evidence
Section 16.4: Nevertheless, the validation strategy would be consistent with the principles established for classic retrospective validation where the assurances are established, based on compilation and formal review of the history of...
Products & Services
Topics of Interest
1 GAMP Forum, Good Automated Manufacturing Practice (GAMP) Guide Version 4 , International Society for Pharmaceutical Engineering, Tampa, FL, 2001. 2 Institute of Electronic and Electrical...
Following from our initial discussion of risk assessment in Chapter 5, the next stage in the process is to carry out a risk assessment of each function to determine if the function is business and/or...
Risk assessment and risk management are emerging subjects within the context of computer validation. As such, this chapter covers the essence of risk management as applied to the validation of...
The user requirements specification (URS) is the key document in the whole of the system development life cycle that is required for both business (investment protection) and regulatory reasons...
After operational release comes the most difficult part of computerised system validation maintaining the validation status of the system throughout its whole operational life. The key challenge is...