| Title: Systems Validation | |||||
| Guidance Number: 94 | |||||
| Prepared by: | Date: | Supersedes: | |||
| Checked by: | Date: | Date Issued: | |||
| Approved by: | Date: | Review Date: | |||
Introduction
This document provides guidance in the validation of systems (facilities, utilities, and equipment, including process control systems, and information systems), that support regulatory compliance – practices, validated processes and/or systems used in the production or storage and distribution of Active Pharmaceutical Ingredients (API), intermediates (subsequent to the introduction of the API starting materials), drug products, medical devices or biologics.
1. For Direct Impact Systems, User requirements specifications (URS) should document what the system must do to meet internal specification, product and regulatory requirements. For standard systems, such documentation may be included in other documents (e.g., technical manuals, vendor documentation). The URS should be approved by the Validation Committee(VC). User wants and Business requirements may be included in the URS but should be differentiated from quality requirements and specifications.
2. For Legacy Direct Impact Systems, at a minimum, any documentation approved by the Quality Authority that describes what the system must do, (e.g., test protocol acceptance criteria) can serve as User requirements for all critical components.
3. For New Direct Impact Systems, Specifications should document the critical aspects of the system design, system functionality, hardware and software components and system configuration.
For standard systems, such documentation may be included in other documents (e.g., technical manuals, vendor documentation, SOPs). Specifications for custom systems or configurable systems should be approved by a Subject Matter Expert (SME). Specifications for custom systems that serve as the basis for acceptance criteria should be identified and maintained to accurately reflect the system, in its current state.
4. For Legacy Systems that require validation, any documentation that describes the system on a functional and design level (e.g., vendor manuals, drawings, configuration documents) can serve as specifications for critical components and functions.
5. Criteria to Consider When Conducting System Level Impact Assessments to determine if the system is a direct impact system include, but are not limited to:
- System has direct product contact;
- System produces a material or excipient that has direct product contact;
- System creates or maintains an environmental condition to preserve product quality;
- System is used in cleaning, sanitizing or sterilization;
- System produces data that are used to accept or reject product, or support regulatory compliance – practices; or
- System performs a critical processing step or operation. System level impact assessments, when performed, should be documented and approved by the responsible VC.
6. Component Level Impact Assessments, when performed, should be documented and approved by the responsible VC. For systems using software, the component level impact assessment should include consideration of software functions that may have the potential to impact product quality or regulatory compliance – practices. Component level impact assessments are used to identify non-critical components that do not require validation.
7. Criteria to Consider When Conducting A Component Level Impact Assessment include, but are not limited to:
- Component prevents contamination of product and materials;
- Component performs or controls functions that have a direct impact on product quality;
- Component verifies functions that have a direct impact on product quality, perform acceptably; and
- Component produces, monitors, evaluates, stores, or reports data used to accept or reject product or GMP materials or data used to support regulatory compliance – practices.
8. For Legacy Systems That Require Validation (e.g., direct impact system, GMP-Related system) an assessment against this guidance, should be performed only when one of the following events occurs:
- The system was not maintained under change control;
- Periodic review indicates the need for assessment against the guidance;
- Change control evaluations indicate the need for assessment against the guidance;
- Observations from internal audits indicate the need for assessment against the guidance; or
- Observations from regulatory inspections indicate the need for assessment against the guidance.
The assessment results and corresponding action plan should be documented. The action plan should identify activities required to minimize the impact of any missing or poorly documented validation deliverables required for legacy systems. The VC should approve the assessment results and action plan.
9. For New Direct Impact Systems, the Validation Activities and Deliverables should take into consideration any vendor information obtained through:
- Assessments,
- Audits, or
- Previous experience with the vendor and/or system.
The results should be taken into consideration when developing a test plan.
10. For New Direct Impact Systems, a Design Review should be conducted, to ensure the system meets regulatory requirements and is suitable for its intended purpose. The review should be documented (e.g., DQ or Design Review, validation report) and should be approved by the responsible VC. Documentation of the review should include:
- A reference to the system level document(s) used to perform the review;
- A description of the review process or reference to the procedure followed;
- Personnel performing the review; and
- A final conclusion on whether the system design is compliant with regulatory requirements.
11. Qualification Protocols (e.g., IQ, OQ, PQ) should specify how qualification testing is to be conducted and include acceptance criteria. Protocols can be separate documents or combined.
Protocols should be approved by the Site Quality Authority. Commissioning may be used to reduce the level of qualification testing required.
12. Installation Qualification (IQ) should verify and provide documented evidence that any required commissioning activities are complete, and that critical components have been installed and configured according to specifications.
13. Operational Qualification (OQ) should verify and provide documented evidence that critical components perform according to specifications, throughout defined operating ranges and meet predetermined acceptance criteria.
14. Performance Qualification (PQ) should verify and provide documented evidence that the system performs according to requirements, while integrated with associated systems, operates in the final production and/or validation test environment according to SOPs, and meets predetermined acceptance criteria.
15. SOPs should be available for the use, control, and maintenance of direct impact systems and the associated critical components. SOPs to consider include, but are not limited to, the following:
- System operation, startup, and shutdown;
- System administration, access control, and security;
- Backup, archiving, and restoration;
- Change control and configuration management;
- Error handling;
- Disaster and recovery planning;
- PM; and
- Calibration.
16. Retirement Plans or SOPs should identify the activities and documentation required to fully decommission and remove a validated system from service. The plan should address disposal of the hardware, software, data, and documentation. The plan should be documented and approved by the responsible VC.
17. For Validated Systems Used to Store Electronic Records, the following should be addressed in the system retirement plan:
- The archival and retention time of electronic records, including the application software;
- Identification of records to be archived;
- Procedures to access historic data; and
- The migration of data into another system and the migration testing, if applicable.