The Validation Process

Overview

Introduction

This chapter looks at the validation process. Note: This validation process is used to validate a specific computer system. It may be done on an existing computer system or on a new computer system.

Purpose

The purpose of the validation process is to provide a high degree of assurance that a specific process (or in this case computer system) will consistently produce a product (control information or data) which meets predetermined specifications and quality attributes.

The Validation Facets

The validation effort consists of 5 specific facets or processes, each alone, would not constitute a validation.  However, depending on the specifics of the application, system or process, would depend on which facets would be required.  There following facets are: ·  The Validation Master Plan (VMP) ·  The Project Plan ·  Installation Qualification (IQ) ·  Operational Qualification (OQ) ·  Performance or Process Qualification (PQ)

Types of validation

The two types of validation are: ·         Prospective validation: the validation of a new system as it is developed ·         Retrospective validation: the validation of an existing system

Validation process		The validation process and document references are shown below:
Step	Action
1	Establish Team(s)
2	Determine Validation Activities
3	Write the Validation Protocol
4	Specify the System Development Details
5	Perform Qualification Activities
6	Develop/Review Controls and Procedures
7	Certify the System
8	Review Periodically

Steps 1 to 8

Introduction

This topic provides an overview of the validation process.

Step 1: Establish team(s)

The first step in the validation process is to establish the System Validation Team and if required the System Validation Steering Team. These are the teams that will be responsible for the validation process.

Step 2: Determine validation activities

The second step in the validation process is to determine and record all of the validation activities that will be undertaken in order to validate the computer system. The validation activities are the exact details or activities that will be required for each of the steps in the validation process. The output from this activity will be the Validation Plan. Example: At step six of the validation process (Develop/Review Controls and Procedures) the exact controls and procedures that will be required to keep the computer system validated will be determined and recorded. Note: The type and number of validation activities will depend on the nature of the computer system that is being validated.

Step 3: Write the Validation Protocol

The third step in the validation process is to write the Validation Protocol. The Validation Protocol describes the procedure and the steps within the procedure that will be followed in order to validate the system. The Validation Protocol must also provide a high level description of the overall philosophy, intention and approach.

Step 4: Specify the system development details

The fourth step in the validation process is to specify the system development details. You should specify to the supplier or developer of a system that they must have: ·         a good methodology in order to develop a system ·         a formal quality management system for the development, supply and maintenance of the system You may need to specify to the supplier or developer the types of items you want to see - this could be done in the form of a Quality Plan. These items will help you ensure that the supplier or developer has a good methodology and formal quality management system in place. Examples: Items that will help you ensure a good methodology and formal quality management system include: ·         quality management procedures ·         life cycle definition ·         specifications, for example user requirements specification and functional specification ·         documentation controls and various items of documentation, for example user manuals and administrator documentation ·         testing procedures If the computer system is a new one, then the system development requirements will be identified prior to system selection/development. If the computer system is an existing one, then the system development requirements will still be identified and used as a basis against which to evaluate the system.

Step 5: Perform qualification activities

The fifth step of the validation process is to perform the qualification activities, which are comprised within the validation process. Some examples of these qualification activities include: ·         Supplier audit ·         Specification qualification ·         Design qualification ·         Installation qualification ·         Operational qualification ·        Performance qualification

Step 6: Develop / review controls and procedures

The sixth step of the validation process is to develop/review controls and procedures. If the computer system is a new one, then you will need to develop the controls and procedures, or check the suitability of existing generic procedures applicable to the site or department. If the computer system is an existing one, then you will need to review the controls and procedures and update them if required.

Step 7: Certify the system

The seventh step of the validation process is to certify the system. This step is where you certify that the validation deliverables have met the acceptance criteria that were described in the Validation Protocol. When you certify the system you should prepare a validation report. The validation report should outline the details of the validation process. Examples of details that should be outlined include: ·         what was done and the results that were obtained ·         any special considerations ·         whether the validation procedure (as described in the Validation Protocol) was followed ·         a summary of all documentation that was generated ·         the location of the validation documentation ·         the retention period for the documentation

Step 8: Review periodically

The eighth and final step of the validation process is to review the system validation periodically. The system should be reviewed periodically to provide additional assurance of validation. There should be documentation outlining the details of how the review is to be done and what the review should cover. The end result of a review should be a summary of the review and a recommendation as to what to do next.

Timing and Documentation

Introduction

This topic looks at the timing of the validation process and documentation.

Timing

Ideally, the validation process begins at the inception of the system selection or design process. It then proceeds alongside the system development and is completed prior to implementation of the system. Many aspects of computer systems validation are just "Good Informational Resources (IR) Practice" and as such should occur anyway during the implementation of a system. For many reasons, a system may not have been validated until after it has been in use for some time. The basic validation process is the same as for a new system. The timing of some of the validation activities may, however, differ. Note: Retrospective validation is becoming increasingly unacceptable to regulatory inspectors. New systems should be validated before use.

Timing for a new system

The steps in the validation process, and their associated validation activities are performed in parallel with the system development life cycle and reference the development documentation as it is produced.

Timing for an existing system

For existing systems, the validation activities will still follow the development life cycle but will reference the development documentation retrospectively.

Example

An example of the parallel between system development and validation activities is shown below. * Functional Specification can comprise mechanical, electrical and software functional specification for systems embedded in equipment ** Systems embedded in equipment with significant control and monitoring instrumentation *** Testing carried out by supplier can form part of subsequent qualification activities if adequately controlled. This can help reduce the amount of testing needed later, particularly at operational qualification.

 

Documentation

Every step in the validation process, and the activities within the steps, requires documented evidence that the steps or activities have been completed. The table below shows the documents that must be generated at each step. Note: In some cases some of these documents may not be required.

Step	Action	Documents Generated
1	Establish Validation Team(s)	·         Team Charter ·         Terms of Reference ·         Role Definition ·         Team Organization Chart
2	Determine Validation Activities	·         Validation Plan
3	Write the Validation Protocol	·         Validation Protocol
4	Specify the System Development Details	·         Systems Development Life Cycle documentation
5	Perform qualification activities	·         Supplier Audit Report ·         In-house Audit Report ·         Source Code Review Report ·         Specification Qualification Report ·         Design Qualification Report ·         Installation Qualification (IQ) Protocol ·         IQ Results ·         IQ Summary Report ·         Operational Qualification (OQ) Protocol ·         OQ Results ·         OQ Summary Report ·         Performance Qualification (PQ) Protocol ·         PQ Results ·         PQ Summary Report
6	Develop/Review Controls and Procedures	·         SOPs (Standard Operating Procedures) ·         Training procedures ·         Training records
7	Certify the System	·         Validation Report ·         Validation Certification
8	Review the System Validation Periodically	·         Periodic Review Procedure ·         Periodic Review Audit Report

---