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'. 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, 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." 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. Probably the best known industry guidance available is the GAMP Guide, now in its fifth edition and known as GAMP5 published by ISPE (2008). 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'. 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.
Risk Based Approach To Computer Validation In the 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==