This chapter looks at the second step in the validation
process, determining the validation activities required for the specific
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.
The validation activities are the exact details or
activities that will be required for each of the steps in the validation
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 can be divided into different categories. The
type of software category will determine the validation activities that are
required for the software.
Life Cycle and Validation Activities
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
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.
Categorization and Validation Activities
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.
The table below outlines the validation activities that
should be undertaken for the appropriate software category.
Record the version.
instruments, Micro controllers, Smart instrumentation
Audit the supplier.
application and any bespoke code.
Custom built or
Audit the supplier.
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 is Standard Instruments, Micro Controllers
and Smart Instrumentation.
These are driven by non user programmable firmware.
Examples: Weigh scales, bar code scanners, 3 term
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
Category 3 is Standard Software Packages. These are
called Canned or COTS (Commercial Off-The-Shelf) configurable packages in
Examples: Lotus 1-2-3, Microsoft Excel and other
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
system requirements and
the high level language or
macros used to build the application
critical algorithms and
data integrity, accuracy and
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 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
(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 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.
It should be noted that complex systems often have
layers of software, and one system could exhibit several or even all of the
When categorizing software, choose the category with
the most appropriate validation activities and consider any history of usage
in similar applications.
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.