Computer System Validation

This requirement has naturally expanded to encompass computer systems used both in the
development and production of, and as a part of pharmaceutical products, medical devices, food,
blood establishments, tissue establishments, and clinical trials. In 1983 the FDA published a
guide to the inspection of Computerized Systems in Pharmaceutical Processing, also known as
the 'bluebook'.[6] Recently both the American FDA and the UK Medicines and Healthcare
products Regulatory Agency have added sections to the regulations specifically for the use of
computer systems. In the UK, computer validation is covered in Annex 11 of the EU GMP
regulations (EMEA 2011). The FDA introduced 21 CFR Part 11 for rules on the use of electronic
records, electronic signatures (FDA 1997). The FDA regulation is harmonized with ISO
8402:1994,[7] which treats "verification" and "validation" as separate and distinct terms. On the
other hand, many software engineering journal articles and textbooks use the terms "verification"
and "validation" interchangeably, or in some cases refer to software "verification, validation, and
testing (VV&T)" as if it is a single concept, with no distinction among the three terms. The
General Principles of Software Validation (FDA 2002) defines verification as "Software
verification provides objective evidence that the design outputs of a particular phase of the
software development life cycle meet all of the specified requirements for that phase."[8] It also
defines Validation as "Confirmation by examination and provision of objective evidence that
software specifications conform to user needs and intended uses, and that the particular
requirements implemented through software can be consistently fulfilled". The software
validation guideline states: The software development process should be sufficiently well
planned, controlled, and documented to detect and correct unexpected results from software
changes." Annex 11 states "The validation documentation and reports should cover the relevant
steps of the life cycle."
Weichel (2004) recently found that over twenty warning letters issued by the FDA to
pharmaceutical companies specifically cited problems in Computer System Validation between
1997 and 2001.[9]
Probably the best known industry guidance available is the GAMP Guide, now in its fifth edition
and known as GAMP5 published by ISPE (2008).[10] This guidance gives practical advice on how
to satisfy regulatory requirements.

Scope of Computer Validation

The definition of validation above discusses production of evidence that a system will meet its
specification. This definition does not refer to a computer application or a computer system but
to a process. The main implications in this are that validation should cover all aspects of the
process including the application, any hardware that the application uses, any interfaces to other
systems, the users, training and documentation as well as the management of the system and the
validation itself after the system is put into use. The PIC/S guideline (PIC/S 2004) defines this as
a 'computer related system'.[11] Much effort is expended within the industry upon validation
activities, and several journals are dedicated to both the process and methodology around
validation, and the science behind it.[12][13][14][15]

Risk Based Approach To Computer Validation

In recent years, a risk-based approach has been adopted within the industry, where the testing of
computer systems (emphasis on finding problems) is wide-ranging and documented but not
heavily evidenced (i.e. hundreds of screen prints are not gathered during testing). Annex 11 states
"Risk management should be applied throughout the lifecycle of the computerised system taking
into account patient safety, data integrity and product quality. As part of a risk management
system, decisions on the extent of validation and data integrity controls should be based on a
justified and documented risk assessment of the computerised system."
The subsequent validation or verification of computer systems targets only the "GxP critical"
requirements of computer systems. Evidence (e.g. screen prints) is gathered to document the
validation exercise. In this way it is assured that systems are thoroughly tested, and that
validation and documentation of the "GxP critical" aspects is performed in a risk-based manner,
optimizing effort and ensuring that computer system's fitness for purpose is demonstrated.
The overall risk posed by a computer system is now generally considered to be a function of
system complexity, patient/product impact, and pedigree (Configurable-Off-The-Shelf or
Custom-written for a certain purpose). A lower risk system should merit a less in-depth
specification/testing/validation approach. (e.g. The documentation surrounding a spreadsheet
containing a simple but "GxP" critical calculation should not match that of a Chromatography
Data System with 20 Instruments)
Determination of a "GxP critical" requirement for a computer system is subjective, and the
definition needs to be tailored to the organisation involved. However in general a "GxP"
requirement may be considered to be a requirement which leads to the
development/configuration of a computer function which has a direct impact on patient safety,
the pharmaceutical product being processed, or has been developed/configured to meet a
regulatory requirement. In addition if a function has a direct impact on GxP data (security or
integrity) it may be considered "GxP critical".

Product life cycle approach in validation

Validation process must account for developmental procedures adapted for qualification of a
drug product right from its research and development, reasons for adapting best fit formula, and
procedure for manufacturing, each step is required to be justified and monitored in order to
provide a good quality food and drug product, while applying for prequalification audit US FDA
gives emphasis on product life cycle approach as well