Chapter 6. Write the Validation Protocol

Introduction

This topic looks at the third step in the validation process, writing the Validation Protocol.

Introduction

This topic looks at the Validation Protocol.

The Validation Protocol describes the procedure to be followed to validate a specific computer system and how each step in the procedure will be documented to provide a high degree of assurance that the computer system will perform as intended.

The Validation Plan will be used as the basis for creating the Validation Protocol.

For the benefit of site management, the Validation Committee and supplier representatives, the Validation Protocol must also provide a high level description of the overall philosophy, intention and approach.

Responsibilities

The Validation Protocol should be written by the System Validation Team and approved by the System Validation Steering Team (or Validation Committee if a System Validation Steering Team does not exist).

Timing

The Validation Protocol is written after the validation activities have been determined. The Validation Protocol should be written before the system validation activities are conducted and in accordance with the local SOPs.

Amendments

Amendments to the Validation Protocol must be approved by the same process as the original Validation Protocol, and documented in a supplement or as a new version.

Existing system

The Validation Protocol for an existing system is the same as for a new system. It may include extra considerations or requirements based on the fact that the system has been in use for some time.

Recommended sections

The recommended sections for the Validation Protocol are as follows:

Introduction and overview

·         Scope

·         Validation procedures

·         Responsibilities

·         Acceptance criteria

·         Certification and approval

·         Protocol sign-off and acceptance

Note: You should use diagrams and flowcharts where appropriate.

Introduction

This topic looks at the recommended sections and contents of the Validation Protocol.

Introduction and overview section

The introduction and overview section should be a general introduction to the system, its uses and the need for validation. It should describe the organization in which the system will be used and who will be responsible for the system. It should contain a general reference to the quality critical functions and business critical functions that the system performs.

Consider including the following information in the introduction and overview section:

·         type of validation to be undertaken (prospective or retrospective)

·         description of the process, plant or facility, to put the system in context

·         system description

·         purpose and objectives of system

·         major benefits of system (or continued use of system)

·         principle of operation

·         quality critical functions

·         business critical functions

·         major components

·         major interfaces

·         system boundaries (for hardware, instrumentation and information flow)

·         summary of supplier and system history (This may be documented in a separate section e.g. Supplier Selection)

·         summary of similar systems

·         years on market

·         number of sites

·         reference to any other documents which describe the system

·         ownership/responsibilities for system

·         development

·         commissioning

·         operations

Include diagrams and schematics where appropriate.

Scope section

This section should describe the scope of the system to be validated. It should specify the following information:

·         whether system is new or existing

·         how the system should be or is to be used

·         which parts of the system/application will and will not be validated

·         justification for excluding parts of the system

·         limitations and exclusions

·         particular application functions

·         unused package facilities, unused I/O ports

·         components for future use which cannot be tested yet

·         assumptions (e.g. correct operation, but not configuration, of operating systems or networking software)

·         boundaries

·         physical (e.g. area of site covered)

·         logical (e.g. interfaces covered)

·         items to be validated (e.g. control systems, interfaces, peripherals, instrumentation, services, other equipment)

If the system is part of a multi-component system, reference should be made to the Validation Protocols that will cover the remaining components.

Validation procedures section

This section should describe the activities that will be used to validate the system and the list of documents that will be generated for each activity. It should be detailed and cross-reference the standards for the documents to be written.

Responsibilities section

This section defines which parties (by name) will be responsible for each of the activities in the validation process and for generating the associated documentation.

Whilst the supplier or specific information departments may be responsible for performing parts of the validation, the end user department has the final responsibility for completing the validation.

Consider including an organizational structure chart for the validation project team.

Acceptance criteria section

This section describes the high-level acceptance criteria for each activity. It is the basis for the final certification of the system.

Specific acceptance criteria and expected results for each validation activity will be described in the qualification protocols.

Certification and approval section

This section describes how the validation will be certified or approved. This will be the basis for accepting the system for use in a validated state.

The personnel responsible for reviewing and accepting each document and for the validation as a whole should be identified.

Protocol sign-off and acceptance section

The final section of the protocol should contain the sign-off on the Validation Protocol by the validation steering team. This sign-off signifies the team’s agreement to its contents.