Chapter 5. Determine Validation Activities

Introduction

This chapter looks at the second step in the validation process, determining the validation activities required for the specific system.

Note: When you have determined the validation activities, you should record them, along with approximate timings and responsibilities. This document is called the Validation Plan.

Validation activities

The validation activities are the exact details or activities that will be required for each of the steps in the validation process.

Note: The type and number of validation activities will depend on the nature of the software and the actual computer system that is being validated.

Software categorization

Software can be divided into different categories. The type of software category will determine the validation activities that are required for the software.

Introduction

This topic provides a diagram of an example development life cycle and some associated validation activities.

The example life cycle is broken down into these phases:

·         specification

·         design

·         construction

·         testing

·         installation

·         acceptance testing

·         operation

The validation activities are shown in relation to when they occur in the development life cycle.

Example:  In the installation phase, the validation activity that occurs is the Installation Qualification.

Introduction

To help determine validation activities for software, this guide groups software commonly found in systems into five categories and recommends the validation activities for each category.

Complex systems often have layers of software, and one system could exhibit several or even all of the categories.

Validation activities

The table below outlines the validation activities that should be undertaken for the appropriate software category.

No.

Category Description

Validation Activities

1

Operating systems

Record the version.

2

Standard instruments, Micro controllers, Smart instrumentation

Record the configuration.

3

Standard software packages

Validate the application.

4

Configurable software packages

Audit the supplier.

Validate the application and any bespoke code.

5

Custom built or bespoke systems

Audit the supplier.

Validate the complete system.

Category 1

Category 1 is operating systems.

Established, commercially available operating systems which are used in pharmaceutical operations are considered validated as part of any project in which the application software operating on such platforms are part of the validation process (i.e. the operating systems themselves are not currently subjected to specific validation other than as part of particular applications which run on them). Well known operating systems should be used.

For validation record keeping, record the name and version number in the hardware acceptance tests or equipment IQ.

New versions of operating systems should be reviewed prior to use and consideration given to the impact of new, amended or removed features on the application. This could lead to a formal re-testing of the application, particularly where a major upgrade of the operating system has occurred.

Category 2

Category 2 is Standard Instruments, Micro Controllers and Smart Instrumentation.

These are driven by non user programmable firmware.

Examples: Weigh scales, bar code scanners, 3 term controllers.

This type of software is configurable and the configuration should be recorded in the equipment IQ.

The unintended and undocumented introduction of new versions of firmware during maintenance must be avoided through the application of rigorous change control. The impact of new versions on the validity of the IQ documentation should be reviewed and appropriate action taken.

Category 3

Category 3 is Standard Software Packages. These are called Canned or COTS (Commercial Off-The-Shelf) configurable packages in the USA.

Examples: Lotus 1-2-3, Microsoft Excel and other spreadsheet packages.

There is no requirement to validate the software package, however new versions should be treated with caution.

Validation effort should concentrate on the application written with the package (reference should be made to Category 4), which includes:

·         system requirements and functionality

·         the high level language or macros used to build the application

·         critical algorithms and parameters

·         data integrity, accuracy and reliability

·         operational procedures

As for other categories, change control should be applied stringently, since changing these applications is often very easy, and with limited security. User training should emphasize the importance of change control and the validated integrity of these systems.

Category 4

Category 4 is Configurable Software Packages. These are called custom configurable packages in the USA.

Examples: Distributed Control Systems (DCS), Supervisory Control and Data Acquisition packages (SCADA), manufacturing execution systems and some LIMS and MRP packages, database and document management applications.

(Note: In these examples the system and platform should be well known and mature before being considered in category 4, otherwise category 5 should apply.)

A typical feature of these systems is that they permit users to develop their own applications by configuring/amending predefined software modules and also developing new application software modules. Each application (of the standard product) is therefore specific to the customer process and maintenance becomes a key issue, particularly when new versions of the standard product are produced.

This guide should be used to specify, design, test and maintain the application. Particular attention should be paid to any additional or amended code and to the configuration of the standard modules. A software review of the modified code (including any algorithms in the configuration) should be undertaken.

In addition, an audit of the supplier is required to determine the level of quality and structural testing built into the standard product. The audit needs to consider the development of the standard product which may have followed a prototyping methodology without a customer being involved.

Category 5

Category 5 is Custom built or bespoke systems.

Custom built or bespoke systems should be validated using the full system life cycle approach.

An audit of the supplier is required to examine their existing quality systems and a validation plan should then be prepared to document precisely what activities are necessary, based on the results of the audit and on the complexity of the proposed bespoke system.

Complex systems

It should be noted that complex systems often have layers of software, and one system could exhibit several or even all of the categories.

Determining the category

When categorizing software, choose the category with the most appropriate validation activities and consider any history of usage in similar applications.

Example:

A filter integrity tester is an instrument used in the pharmaceutical industry to test sterile filters. It would fit into category 2. However, users would require much greater assurance of the correct operation and reliability of the instrument and it would therefore be put into category 4 so that validation would be more rigorous.