VAL-130 Guideline For The Development of A Computer Validation Project Plan

5.1 The document shall be set out in the following format.  Other sections may be included which are individual requirements for a specific system.

5.2 Each VPP is to be issued with a unique number.

5.3 The first page of the document should provide the name(s), signature, date and position of the personnel involved in the preparation of the document and approval.  The first page will also detail the name and version of the software / system being validated.

5.4 Approval of the VPP is to be given by personnel nominated by the Validation Steering Committee.

5.5 A table of contents should be included.

5.6 The following Sections 5.6.1 to 5.6.23 of this procedure detail the contents for each of the sections as listed in the Table of Contents.  References to existing documents should be made wherever possible to eliminate duplication of information.

5.6.1 Purpose And Scope

This section shall provide a description of the purpose of the VPP, the computer system under validation and its purpose and which areas / modules of the system are (and are not) to be validated and why.  The purpose and scope will make reference to the site at which the project is going to take place and the final location and specific function of the validated system.  The scope should detail the extent of the validation effort including boundaries, exceptions and detailed project scope.  The scope should reference any applicable documentation that is used to justify omissions from the validation exercise.

5.6.2 References

Provide a list of all the codes, policies, procedures and standards the Validation Project Plan is to comply with.  Identify the documents that are pertinent to the development of the VPP and where applicable, identify the version number.

5.6.3 Responsibilities and Authorities

Provide the names of the key personnel involved in the Validation effort stating their responsibilities and position within the company.  Vendor representatives should also be included at this stage if required.  Define the function of the Steering Validation Committee within the project.

5.6.4 Signature List

A list of all personnel involved in the activities of the validation project is recommended.

5.6.5 System Overview

This section will provide a brief description of the System (include if the System was purchased and a description of the Vendor), referencing URS, FRS, DSS, User Manuals or any other related documentation for detailed descriptions.  Extracts from these documents can be included, however duplication of information should be minimized as much as possible.

5.6.5.1 System Block Diagram – if appropriate a diagram or flow chart of the overall System should be included here.

5.6.5.2 Hardware Description – a brief description or list of the hardware, peripherals and interfaces required to operate the System is to be included.

5.6.5.3 Software Description – a brief description of the databases, files, language and development standards used, name and version numbers of the application software, operating system and supporting software.

5.6.6 Validation Strategy

5.6.6.1 Validation Status

Detail the current validation status of the system if applicable.  Should any work be complete or underway, it should be referenced in the VPP.

5.6.6.2 Validation Environment

The validation environment should be defined in the Validation Project Plan and its validation status document.

5.6.6.3 GxP Criticality Assessment

This section should describe or refer to the GxP criticality assessment process.  It may include high-level assessment information, or preferably refer to some other information on this topic, such as a risk assessment.  The following should be covered:

– The procedures for performing the assessment.

– The current status of the process (recognizing that the assessment may be repeated, and the levels of criticality updated).

5.6.6.4 Auditing

Identify the Vendor(s) of the system component(s) that need to be audited.  If the Vendor audit is already performed, then indicate the status of the Vendor audit result and the location of the report.  Any issues as a result of the audit should be reviewed, if pertinent to the validation project identify how they will be addressed.

Document the justification for not performing a Vendor audit; e.g. non-critical component of the system.

The timing of audits or reviews is to be specified and follow-up actions of any deviations or recommendations are to be monitored.  A feedback mechanism to the Validation Steering Committee is to be defined.

5.6.6.5  Validation Category

Document the category and category requirements (hardware and software).

5.6.6.6  Validation Testing

The level of validation testing will depend on the category of hardware and software to be validated and will be defined in the Validation Project Plan.  Validation testing may include acceptance testing (module / integration / site acceptance testing) and/or qualification testing (IQ/OQ/PQ) refer to SOP VAL-110 Computer Validation Guideline, Section 6.

If validation testing is performed in a validation environment, it must be comparable to the live environment.  A validation environment must be validated.

5.6.6.7  Validation Deliverables

This section should describe the deliverable items to be produced, including responsibility for review and approval – refer to SOP VAL-110 Computer Validation Guideline, Section 6.

5.6.6.8  Acceptance Criteria

This section should define the overall acceptance criteria for the system.  Detailed acceptance criteria will be detailed in individual protocols.

5.6.6.9  Deviations

This section should define the policy for reporting and resolving deviations encountered during the specification and testing phases and following implementation.

5.6.6.10  Validation Schedule

This section should contain a brief overview of the schedule of key validation activities including project milestones.

5.6.6.11  Validation Report

This section should specify a Validation Report will be prepared at the conclusion of the Validation effort to summaries all the deliverables and activities against the Validation Plan.  For large scale projects, separate IQ, OQ and PQ reports should be written and approved prior to commencing the next validation step.

The summary will include a list of all the documents, records, data, procedures, etc., to be reviewed and evaluated by the personnel approving the Validation Report.

Where appropriate, address traceability requirements for the documents delivered.  For example, traceability of URS to FRS and Qualification Protocols.  This can be achieved by a traceability matrix, where each URS requirement is referenced to an FRS requirement and a qualification test is referenced to the URS.

5.6.6.12  Maintaining the Validated State

This section should define the actions and procedures required to maintain the system in its validated state.

5.6.6.13  Change Control

Refer to and make reference to the applicable Change Control procedure adopted during the validation project and following implementation.

5.6.6.14  System Standard Operating Procedures

A number of procedures are to be developed (reference to be made to procedures already existing) to ensure the continued operation of the System in a secure environment that is maintained in a validated state throughout its lifecycle.  This will depend on the complexity of the system and the required documents should be listed.

Examples:

– Change Control

– Security

– Backup and archiving

– Disaster Recovery

– Periodic review (Auditing) /on-going monitoring

– Prevention, detection and correction of errors

– Operational Standard Operating Procedures

Typically the procedures would be drafted at the IQ stage, finalized at the OQ stage and executed at PQ stage of the validation program.

5.6.6.15  Training

Identify the training requirements during the validation project.  As a minimum the following should be addressed:

– What training is required? e.g. Maintenance, Operation, etc.

– How will the training be recorded and retained? e.g. Forms to be used

– Who requires training? e.g. Users, MIS, Vendor, etc.

– Who will conduct the training? e.g. Vendor

– At what stage is the training required? e.g. at IQ, OQ, PQ stage, etc.

– How will the training be conducted? e.g. using Manuals, approved procedures, etc.

Refer to and make reference to the applicable training SOP adopted during the validation study.

5.6.6.16 Documentation

This section should list all the documentation which will be retained, archived and updated for the System.  The list should include as applicable:

System Development Documentation:  URS, FRS, DSS, Validation Project Plans, Protocols and Reports, Audit Reports, Source Codes, User Documentation, Standard Operating Procedures, Maintenance records (hardware and software).

Indicate who is responsible for each document, where it will be kept and for what time period.  For large scale projects a document matrix may be generated at the completion of the project, however this document should not be considered necessary for operation of the system.

5.6.6.17   System Decommissioning

If the new system is replacing one currently in use in production, refer to SOP VAL-110 Computer Validation Guideline, Section 6. The VPP should address the requirements of phase-out of the existing system.  A separate decommissioning plan may need to be prepared to address the following as a minimum:

– The data generated, stored and calculated by the retiring system may have to be archived, transferred, or disposed of.  The procedure for this should be documented and the required time the archived data is to be stored.

– Will the archived data need to be retrieved in the future?  The software programs of the retiring system may have to be archived.

– Documentation related to the retiring system may need to be archived for the same period of time as the data.

5.6.6.18 Amendment List

An Amendment List must be included in the document.