9.

A Introduction and terminology

Here you will find answers to the following questions:

● What are the advantages of validation?

● What is a sensible interpretation of validation?

The topic of this chapter is the validation of computerised systems. The term computerised systems has already historical
overtones, but is understood to have a broader meaning here in order to reflect today's complexity, the state of the art and
the correlations properly.

With the starting usage of computers in the industry in the 1980s, demands were also initiated to document the quality of
such systems with regulatory requirements. The Blue Book (Guide to Inspection of Computerised Systems) of the FDA from
1983 is a notable example. In this, for example, a central processing unit (CPU) is presented schematically as being
connected to an analogue signal source via two cables, and the option of networks between two different locations (e.g. via
satellites) is discussed. This seems rather amusing nowadays, but nevertheless – or precisely because of this – the basic
principles of validation from the aforementioned Blue Book still apply today.

Modern systems and applications consequently tend to be assigned to the sector of information technology (abbreviated as
IT) and thus represent the current state of the art which can differ very greatly.

Validation of computerised systems is an interdisciplinary task which, among other things, can comprise the following
aspects:

● Process analysis

● Requirements management

● Project management and methods

● Risk management methods

● Specifications/System descriptions

● Software development standards

● Test management and automation

● IT management and services

● Good Documentation Practice/Quality management

It can therefore be necessary to involve proven subject specialists, who are referred to as Subject Matter Experts (SMEs), in
these various tasks.

The text below consciously describes validation without the traditional or classical presentation of a V model or the traditional
phases (DQ, IQ, OQ, PQ). Scalable validation models are presented for this purpose, as well as the associated criteria for
selecting the appropriate model.

These criteria lead to what is known as a risk-based validation approach which takes into account the processes and system
properties. Consequently possible categorisation of systems is presented. There is always a wide range of different validation
objects such as IT systems, applications, spreadsheet programs, process units or laboratory systems for which the
appropriate validation approach must be determined. This is also dependent on the (GMP) criticality of the data which is
specially processed or stored on one of these systems.

Validation is an important component of a quality management system (QMS) into which it must be integrated, for example
for document management of the validation records or regulating responsibilities. IT projects must always be commercially or
contractually bound via a contract giver (e.g. pharmaceutical company; user requirement specification) and a contract
acceptor (supplier, service provider; technical specification). Each party must have a corresponding, demonstrable QMS. This
also applies if the contract acceptor would be responsible for implementation within the company (e.g. IT department).
Depending on the assessment of the complexity of an IT project, a supplier assessment should take place using various
qualification methods (e.g. auditing). In addition to the assessment of contract acceptors with regard to quality, contractual
aspects can also be relevant, and these must be defined in quality agreements (e.g. outsourcing, warranty, response times,
etc.).

One important basis for quality management is risk management, which should also be used for validation in various phases
and ways. From this are derived various comprehensible quality decisions which must also be documented and demonstrable
and contained in the validation approach.

In addition, nowadays many systems are operated in the IT network and not, for instance, as stand-alone solutions, which will
lead to the topic of qualification of the IT infrastructure. Furthermore, as part of process optimisation systems are also
connected to each other via interfaces for (bidirectional) data exchange. Such interfaces and the resultant routine data
transfer must also be incorporated in the considerations relating to validation. Even where exactly the system boundaries
should be drawn is not easy to define, e.g. IT solutions may consist of several individual IT systems and applications (from
different manufacturers).

Validation projects today frequently also include replacing existing, operational systems by new systems. This can also lead
to a requirement for data migration and its validation – or the request for a suitable archiving concept.

In addition to the numerous factors for defining the appropriate initial validation approach during the project implementation
phase, the system must subsequently be maintained in a valid status when productive operation takes place later. Various
methods like change control and periodic reviews must be defined for this purpose. These considerations can be decisive as
early as in the procurement phase, which in turn necessitates early involvement of the persons responsible for validation
before the project phase begins.

If the term “state of the art” and current developments and options in the IT sector are now examined, the validation
methodology must orient itself on this; various topics such as virtualised servers, cloud computing, wireless LAN, Open
Source Software and many more must be processed. Here, too, a precise analysis and risk assessments are required.

When computer validation, which belongs to the field of quality management, is implemented, the costs it entails are always
scrutinised as it results in no direct monetary gain.

The term computer validation is used in the pharmaceutical industry in the context of satisfying regulatory requirements.
Other branches of industry and recognised standards for project and development management use different generic terms,
such as software quality management (QM), which have the same meaning, however. When IT projects are assessed which
today can be subject to time and cost pressure, it frequently transpires that additional costs or losses have resulted from
missing or incorrectly designed QM elements or methods.

The question of costs can consequently also be asked the other way round: In order to be able to cope at all with the great
complexity and, for example, cost control for IT projects, validation is essential; here validation is the result of good project
management practices. Validation is not an artificially created additional cost for IT projects and IT management, but an
integral part of the project and life cycle model. A meaningful interpretation of the requirements and expectations for
validation must be drawn up and put into practice. This is often the actual challenge.

The software pioneer Barry Boehm concerned himself intensively with the cost analysis of IT projects and showed the
importance of software validation. In the chapters below the benefit of validation measures and their elements are therefore
also presented.

On the other hand validation does not mean that a system functions totally without errors (and that is also not its aim), but
that it does what the specification states that it must be able to do with a high level of reliability.

The design and implementation of validation must lead to its objective, and must be risk-based and cost-aware. Validation for
a simple laboratory device, for example, must always be significantly leaner in design than for a globally implemented batch
release system. It should also be pointed out here that the success of validation and its acceptance do not depend merely on
the specialist design, but also on how the topic is presented, implemented and conveyed.

Validating computerised systems (computer validation) means showing in documented form that, with great probability, the
system will function in a reproducible manner as the specification states it should function.

Validation and qualification are two closely related terms. Qualification is understood to be checking that a plant or system is
correctly installed plus a subsequent functional check. Validation covers processes, systems and procedures in which people
are also involved. Qualification could thus be regarded as a subset of validation.

These terms are supplemented by other customary terms such as system qualification, equipment qualification and, observed
separately, process validation. In the case of traditional process system qualifications the approach is often historically
justified, and a combination with computer validation can make sense. In some cases these concepts are (consciously) also
used with different meanings or definitions in different companies. In all cases it is important that terms used internally are
defined unambiguously and a clear distinction is made between system qualification, computer validation and process
validation. This avoids overlaps which lead to duplicated efforts, but also to gaps in the validation strategy. When cooperating
with external suppliers, it is always necessary to coordinate the terms and content for all validation definitions.
For the term validation of computerised systems a definition of the term system would be required: Annex 11 defines this as
a set consisting of hardware and software (Chapter C.6.11 Annex 11 Computerised Systems). Unfortunately the word “set”
has a large number of meanings. The same applies for the terms hardware (material components such as mainboards and
processor) and software (non-physical functional components/programs). The software sector (architecture, programming
languages) is extremely wide and extensive. A simple digital radio clock (embedded software) or a mobile phone is
consequently as much a “system” as a high-performance computer or a space satellite.

The difficult aspect of validation is definitely the precise decision of the system boundaries and system subsets.

By way of example a production plant comprising one PLC system (connected to the corresponding sensors) and one
terminal (separate visualisation software) with a connected printer will be examined here. This plant is also connected via a
network interface to a camera system which performs an optical check.

In this example the aforementioned elements could be regarded as an overall system or the production system and the
camera system as separate systems, and both interpretations would be correct. The terminal and the printer would certainly
be assigned to the production system with the PLC, while it would, however, also not be wrong also to regard these as
separate. But this would not be feasible, as without the main system and PLC the terminal, which consists of hardware and
software and thus complies with the definition “system”, would be far removed from the actual production process and its
planned use. Consequently it would only be possible to qualify the terminal if it was regarded separately (installation and
functional check), and it could only be validated together with the controlling process system. These considerations could be
extended with the option of regarding the printer separately and would lead to the same results.

This example shows that it makes sense to define the system boundaries with regard to the actual applications areas to the
process and final products. A system can also comprise different sub-systems which can be grouped accordingly to form a
so-called application.

In Annex 11 it is required that applications must be validated and the IT infrastructure must be qualified.

The IT infrastructureconsists of the IT network components (hardware and software), and also of the processes for
operating the infrastructure itself and for ensuring IT operations and governance. As the infrastructure is not actually a
relevant application in the pharmaceutical sense but serves as a basis for several applications and systems, it is not validated
but qualified (see system categories). Qualification of the IT infrastructure is a mandatory requirement in Annex 11 of the EU
GMP Guide (Chapter C.6.11 Annex 11 Computerised Systems).

The actual function performed by the computerised system is the controlled process for producing a specified pharmaceutical
product. This is the validation aim and objective. Several systems or applications can thus be involved in a validated process.

9.A Summary
If validation is applied pragmatically, it results in advantages such as improved project control, better availability and
productivity of the equipment, and a reduced maintenance workload. It also ensures that the legal requirements
(compliance) are implemented correctly.