Formal qualification review

Formal qualification review Formal evaluation by top management of the status and adequacy of the quality system in relation to quality policy and objectives. 

Validations fall into two types prospective and retrospective. In prospective validation (see flow chart in Figure 2) the validation is done in a sequential manner, involving installation qualification and operational qualification (IQ/OQ) of equipment (e.g., chromatography instrumentation or column hardware). Appropriate calibrations accompany the IQ/OQ. Process qualification, or PQ, involves formal review and approval of a PQ protocol, execution of this protocol, and issuance of a formal PQ report which includes data analysis and recommendations (i.e., approval/certification of the process). If the process is not approved, the report may recommend a redesign or redoing of the validation protocol and, in some cases, a return of the process to process development for further optimization. 

It should be recognized that qualification activities need to be undertaken to detailed test procedures that provide comprehensive test records, with all documentation formally reviewed and approved by a designated level of management from the pharmaceutical manufacturer. With this in mind, suitably trained qualification test personnel will be required. 

Each qualification must be formally reported to ensure an approved and audit-able transition to subsequent life-cycle phases. Qualification summary reports for the system must be prepared by the pharmaceutical manufacturer and should be kept in the validation file. Each qualification report should confirm the qualification test acceptance and review associated change control records. The report must present a documented record that clearly states the basis for concluding that the qualification is acceptable, particularly if there are any minor conditions or actions outstanding. 

Design qualification—a formalized review of designs at a preliminary point in the project. Its goal is to independently confirm that the design conforms to both user requirements and regulatory, environmental, and safety regulations. 

Operating Mannals need to be formally reviewed as fit for purpose by the supplier as they form the basis of User Procedures and User Qualification. Operating Manuals must be kept up to date with developments to the compnter systems to which they relate, and they mnst refer to specific hardware models and software versions making up the computer system being snpplied. Recommended ways of working defined by the snpplier should be verified as part of the development testing. 

Responsibility for qnalilication of the infrastructure should be jointly shared between the IT group and Quahty Assurance functions. All qualification or requalification plans shonld be snbject to formal review and sign-off prior to implementation by IT. Internal IT organizations are advised to establish their own qnality assurance arrangements to facilitate this sharing of responsibility. 

Once the qualification protocols have been completed, test results and data need to be formally evaluated. Written evaluation needs to be presented clearly in a manner that can be readily understood. The report should also address any non-conformance or deviation to the validation plan encountered during the qualification and resolution. The outline of the report parallels the structure of the associated protocol. The qualification testing should be linked with relevant specification s acceptance criteria, such as PQ vs. system requirements specification deliverable, OQ vs. system specification deliverable, and IQ vs. technical design specification deliverable. If applicable, it is included as part of the summary of the results of inspections and technical review of all technologies that are elements of the systems. 

The approach to DQ may be in the form of a DQ Protocol which is formally completed to record the assessment of the various design activities, or as a process which will produce a set of review reports that are then collated as a record. Which of these two approaches is taken is not important what is essential is that a formally documented approach is followed. A DQ Protocol has been successfully used many times by the author and provides a condensed formal record to support the qualification process, but it does not remove the need for producing reports for software code reviews (SCRs), GLP assessments and so on. It is important to note that the VMP or Validation Plan must clearly document the method to be used and, therefore, the documentation to be produced to support validation. 

Use of development tools (e.g., compilers, linkers, debuggers) Evidence of Source Code Reviews prior to formal testing (checking design, adherence to coding standards, logic, redundant code, critical algorithms) (see Sections 8.1.3, 8.2.1 and Appendix B) Independence and qualifications of reviewers... 

The AEC s rules of practice established the formal procedures for processing the application. After being docketed by the Civilian Application Division, the application received an administrative review for completeness. This process checked the items required by the 1954 act and the implementing regulations. Key information included data on the financial and technical qualifications of the applicant, the earliest and... 

The Safety Programme is applied from project conception to end-of-life. Implementation is formally monitored at defined Project Milestones by Safety Reviews which are held in parallel with the Milestone Reviews. Safety Reviews are chaired by a representative of the Product Assurance and Safety Department. The following milestone reviews are held - Concept (CR) System Requirements (SRR) Preliminary Design (PDR) Critical Design (CDR) Qualification (QR) Acceptance (AR) night Readiness (FRR) Operational Certification (OCR) and End-of-Life (EOLR). The content of the Safety Programme is summarised in Figure 4. 

---