Chapter 2. Before You Perform System Validation

Introduction

This chapter looks at the things you need to do before you perform system validation on a specific computer system.

You need to:

• Set up the Validation Committee

• Under 21 CFR Part 11 Requirements

• Identify systems that require validation

• Conduct appropriate training

Note

The following topics are the four steps involved in identifying systems that require validation:

·         Creating an Inventory

·         Identifying the Systems

·         Assessing Each System for Validation

·         Determining Validation Priority

Introduction

This topic looks at setting up the Validation Committee.

This is one of the first activities that you must do before you can validate a system.

Role of Validation Committee

The Validation Committee oversees all of the computer system validation projects at a site, or within a department.

It should be noted that in some instances this committee would be responsible for all validation projects at a site, not just computer systems validation projects.

These validation projects will be defined in the Validation Master Plan.

Team members

The Validation Committee should be made up of representatives from the following functional areas as appropriate to the site or department:

·         Users

·         Quality Assurance

·         Engineering

·         Validation

·         Information Resources

·         Other relevant parties

The Validation Committee should be sponsored by one of the most senior managers within the site or department.

Responsibilities

The responsibilities of the Validation Committee include, but are not necessarily limited to:

·         identifying components (including computer systems/applications) requiring validation

·         prioritizing and justifying the validations to be performed

·         developing the initial Validation Master Plan and producing subsequent revisions as required

·         establishing a mechanism to include new computer systems in the Validation Master Plan

·         establishing site specific procedures for computer systems validation

·         coordinating validation projects

·         resourcing validation projects, including approving the use of consultants

·         reviewing the progress of individual validation projects to ensure timely execution of the Validation Master Plan

·         resolving issues arising due to conflicting priorities, schedules, or resources

Validation Master Plan

Each site should establish a Validation Master Plan, which describes all the required validation activities at the site together with assigned responsibilities, priorities and timings for actions. The Validation Committee should approve this site plan.

All computer systems validation projects should either be included in this Validation Master Plan or a separate Computer Systems Validation Master Plan established.

The Validation Master Plan should be a dynamic document which at any point in time will represent:

·         which systems exist on site

·         which systems require validation

·         who is responsible for each validation project

·         the status of the individual validation projects

·         the date for completion of each validation project

All upgrades and periodic reviews should also be added to this plan.

Introduction

Before you can validate a system, you need to identify the systems that require validation.   This topic looks at all of the steps involved in identifying systems that require validation.

It also looks at the:

·         scope of the procedure

·         definition of hardware

·         hardware owner

·         system / application owners

Procedure

Identifying systems that require validation consists of the following steps:

Introduction

This topic looks at creating an inventory of all hardware and software in use within a given site or department.   Creating an inventory is the first step in identifying systems that require validation.

Responsibility

The hardware owner and the system/application owner are responsible for step 1.

See, the previous topic to have a look at their responsibilities.

List all details

For each computer or computerized piece of hardware (or, if appropriate, each group or class of hardware), the operating system and all applications residing on the hardware should be listed.

Other key information may also be recorded.

Best practice

It is best practice to have a single repository within the site or department for all data resulting from the inventory.

Inventory format

The exact information and format of the inventory will vary according to the type of hardware and the needs of the business unit.

The following three tables provide examples of information that should be included in the inventory.

Hardware information

The following hardware information should be included in the inventory:

Information

Description

Reference number

A unique identifier for each piece of hardware.

Name

The model name of the main Central Processing Unit (CPU).

Manufacturer

Manufacturer of the main CPU.

Supplier

Supplier name of the main CPU, if different from manufacturer.

Owner

Name of person responsible for the hardware.

Departments served

The departments or Business Unit relying on the hardware.

Location

Physical location of the CPU.

Qualification status

Whether Installation Qualification (IQ) has been performed on the hardware.

Mark "Qualified" if IQ has been done.

Mark "Not Qualified" if IQ has not been done.

System software information

The following system software information should be included in the inventory:

Operating system

Name of the operating system residing on the CPU.

Operating system version

Version of the operating system residing on the CPU.

Application software information

The following application software information should be included in the inventory:

Reference number

A unique identifier for each piece of application software.

Application name

For purchased systems/applications, use the product name.

For in-house systems/applications, use the name by which generally known.

For computer controlled instruments, call the application "Resident Software".

Version number

Version number of the application.

Owner

Name of person responsible for the application software.

Origin

Statement about origin.

Examples: Vendor Supplied - no modifications

Vendor Supplied - with modifications

Bespoke/Custom

Supplier

Name and location of supplier.

Use

General category of use.

Examples: Raw Data Storage

Raw Data Collection

Data Processing

Equipment Control

System Software

Utility

Note: A computer system may fall into multiple categories e.g., a chromatography system provides raw data collection and storage, date processing and, in some cases, equipment control.

System name

The name of the system of which the application software is a component. This may be the same as the application software name.

System component name

The name of the system component by which the application software is known.

Introduction

This topic looks at identifying the systems, the second step in identifying systems that require validation.

System definition

For inventory purposes, a system is defined as:

any programmable device including its software, hardware, peripherals, procedures, users, interconnections and inputs for the electronic processing and output of information to be used for reporting or control.

Responsibility

The system/application owner is responsible for identifying the systems from the inventory.

Procedure

Identifying the systems consists of the following steps:

Introduction

This topic looks at assessing each system for validation, the third step in identifying systems that require validation.

Each system that has been identified must be assessed to see whether it performs quality or business critical functions, whether there are sufficient controls to ensure its performance, and whether it should be validated or not.

Responsibility

The system/application owner is responsible for completing the assessment of each system and updating that assessment whenever there are changes to the system.

Procedure

Assessing each system for validation consists of the following steps:

Step

Action

1

Develop a list of:

·         quality critical criteria

·         business critical criteria.

2

Evaluate each function against the quality critical criteria and record the outcome.

Note: If a function meets the quality critical criteria, it is classed as quality critical.

3

Evaluate each function against the business critical criteria and record the outcome.

Note: If a function meets the business critical criteria, it is classed as business critical.

4

Identify the external controls, if any, for each quality critical and business critical function.

Examples:  External controls include:

·         Parallel manual procedures

·         100% data reconciliation.

5

Determine whether the system requires validation according to the following criteria:

If the system has quality critical functions, validation is mandatory.

If the system has business critical functions, validation is recommended.

6

Prepare the Assessment Report

Mandatory quality critical criteria

Company processes are subject to various regulations listed in the table below.   Any system or function used in these regulated areas is deemed quality critical.

Regulations

Example Authorities

Good Laboratory Practice (GLP)

Good Clinical Practice (GCP)

Good Manufacturing Practice (GMP)

·         US Food and Drug Administration

·         European Union

·         Therapeutic Goods Administration (TGA)

·         Organization for Economic Co-operation & Development (OECD)

* There are many local country regulations. However, the authorities listed above represent the major regulatory authorities with specific regulations associated with computer systems.

Examples of quality critical criteria

Examples of systems or functions that fall under these regulations are:

·         Pre-clinical safety assessment/toxicology studies

·         Clinical safety assessment/efficacy studies

·         System functions which control equipment, and collect, store, and/or process the following types of data:

Data type

Description

Manufacturing

Manufacturing instructions

Lot status

Lot traceability - composition, disposition

Inventory control

Expiry date

Label control

Process

Process control

Quality

Test methods and test specifications

Test results/QC records

Verdicting i.e. the association of a disposition with a lot/batch/sample

Study

Stability trial - scheduling, data processing, sample storage and inventory

Clinical trial - scheduling, data processing, sample storage and inventory

Process studies

Patient and animal records and results

Equipment and facilities

Environmental monitoring

Calibration and maintenance records

Data used to support regulatory submissions

Stability data

Development Summary Reports

Regulatory documents

Management of SOPs and protocols

Regulatory Document Management System

Electronic data archiving

Indexes of archived documents

Data associated with Clinical Laboratory System

Patient Orders

Samples

Analytes

Results

Definition of manufacturing quality critical functions

The quality critical functions for manufacturing may be defined with reference to current Good Manufacturing Practices (CFR 21, Parts 210 and 211) as those functions that relate to:

"methods to be used in, and the facilities or controls to be used for, the manufacture, processing, packing, or holding of a drug to assure that the drug meets the requirements of the Act as to safety, and has the identity and strength and meets the quality and purity characteristics that it purports or is represented to possess."

Note: This definition is used as an example and synonymous definitions may also be found in the European Guide to GMP and the Australian Guide to GMP.

Business critical functions

Business critical functions relate to areas critical to the operation of the business, but are not related to functions, which are directly covered by regulatory requirements.

Any system or function which collects, stores or processes information in the following areas is designated business critical:

·         product costs

·         customer information

·         supplier information

·         payroll activities

·         accounting data

·         personnel information

·         competitor information

·         office automation

Assessment report

The assessment report identifies the quality critical and business critical functions and documents the validation status of the system.

The assessment report should include:

·         whether validation is recommended and, if so, the scope of the validation

·         quality critical functions

·         external controls for quality critical functions

·         business critical functions

·         external controls for business critical functions

·         current validation status of the system

·         details about the validation documentation, if any

Note: The validation documentation details should include, the location and unique reference number, the identity of the person or persons who approved the validation documentation and the date of the approval.

Introduction

This topic looks at determining validation priority, the last step in identifying systems that require validation.

When you have identified those systems that require validation, you need to determine the priority of each system validation (or validation project) within a site or department. To determine the priority of each validation, you need to perform a risk assessment of all the validation projects.

The findings should be documented in a report and include a justification for the validation priority for all of the systems.

Suggested method

The table below outlines the suggested method of conducting a risk assessment.

Step

Action

1

Determine the risk assessment criteria (refer to the list below).

2

Weight or score each of the criteria.

3

Match the system to each criterion.

4

Compare the total system score with other systems and prioritise.

Note: Use the scoring system as a guide only. Professional judgement will still be required.

Suggested criteria

Consider the following when determining the risk assessment criteria:

·         Company/site history and experience with the system

·         complexity of the system

·         industry experience with the system

·         have the regulatory authorities shown interest in this type of system either within or external to Company?

·         stage in system life cycle. e.g. is the system new or has it been installed for some time, or, is the system almost at the end of its use and will shortly be replaced?

·         criticality of system or data contained within the system in terms of patient risk and product quality

·         what products are associated with the system; are those products strategic?

·         Validated status of system

·         which department is the system used by e.g. QA, Production, Packaging, Development

·         the impact on the business if the system was not operational for a period of time