Nothing Special   »   [go: up one dir, main page]

Validation (Drug Manufacture)

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 6

Validation (drug manufacture)

From Wikipedia, the free encyclopedia

Validation in the pharmaceutical and medical device industry is defined as the documented act
of demonstrating that a procedure, process, and activity will consistently lead to the expected
results. It often includes the qualification of systems and equipment. It is a requirement for Good
Manufacturing Practices and other regulatory requirements. Since a wide variety of procedures,
processes, and activities need to be validated, the field of validation is divided into a number of
subsections including the following:

 Cleaning Validation
 Process Validation
 Analytical Method Validation
 Computer System Validation

Similarly, the activity of qualifying systems and equipment is divided into a number of
subsections including the following:

 Design qualification (DQ)


 Component qualification (CQ)
 Installation qualification (IQ)
 Operational qualification (OQ)
 Performance qualification (PQ)

Contents
[hide]

 1 History
 2 Reasons for Validation
 3 Validation Master Plan
 4 The Validation Process
 5 Computer System Validation
 6 Scope of Computer Validation
 7 Risk Based Approach To Computer Validation
 8 See also
 9 References

[edit] History
The concept of validation was first proposed by two Food and Drug Administration (FDA)
officials, Ted Byers and Bud Loftus, in the mid 1970’s in order to improve the quality of
pharmaceuticals (Agalloco 1995). It was proposed in direct response to several problems in the
sterility of large volume parenteral market. The first validation activities were focused on the
processes involved in making these products, but quickly spread to associated processes
including environmental control, media fill, equipment sanitization and purified water
production.

The concept of validation was first developed for equipment and processes and derived from the
engineering practices used in delivery of large pieces of equipment that would be manufactured,
tested, delivered and accepted according to a contract (Hoffmann et al. 1998). The use of
validation spread to other areas of industry after several large-scale problems highlighted the
potential risks in the design of products. The most notable is the Therac-25 incident, (Leveson &
Turner 1993). Here, the software for a large radiotherapy device was poorly designed and tested.
In use, several interconnected problems led to several devices giving doses of radiation several
thousands of times higher than intended, which resulted in the death of three patients and several
more being permanently injured.

In 2005 an individual wrote a standard by which the transportation process could be validated for
cold chain products.[citation needed] This standard was written for a biological manufacturing company
and was then written into the PDA's Technical Report # 39, thus establishing the industry
standard for cold chain validation. This was critical for the industry due to the sensitivity of drug
substances, biologics and vaccines to various temperature conditions. The FDA has also been
very focused on this final area of distribution and the potential for a drug substances quality to be
impacted by extreme temperature exposure.

[edit] Reasons for Validation


Validation is "Establishing documented evidence that provides a high degree of assurance that a
specific process will consistently produce a product meeting its pre-determined specifications
and quality attributes." (FDA 1987). A properly designed system will provide a high degree of
assurance that every step, process, and change has been properly evaluated before its
implementation. Testing a sample of a final product is not considered sufficient evidence that
every product within a batch meets the required specification .

[edit] Validation Master Plan


The Validation Master Plan is a document that describes how the validation program will be
executed in a facility. Even though it is not mandatory, it is the document that outlines the
principles involved in the qualification of a facility, defines the areas and systems to be validated
and provides a written program for achieving and maintaining a qualified facility with validated
processes. It is the foundation for the validation program and should include process validation,
facility and utility qualification and validation, equipment qualification, cleaning and computer
validation.The regulations also set out an expectation that the different parts of the production
process are well defined and controlled, such that the results of that production will not
substantially change over time.

[edit] The Validation Process

Figure 1: Traditional Qualification Process (adapted from the typical V-Model)

The validation process consists of identifying and testing all aspects of a process that could affect
the final test or product. Prior to the testing of a process, the system must be properly qualified.
Qualification includes the following steps: (These steps are common practice for equipment (IQ,
OQ and PQ).

 Design Qualification (DQ)- Defines the functional and operational specification of the
instrument, program, or equipment and details the rationale for choosing the supplier.
 Installation Qualification (IQ) - Demonstrates that the process or equipment meets all
specifications, is installed correctly, and all required components and documentation
needed for continued operation are installed and in place.
 Operational Qualification (OQ) - Demonstrates that all facets of the process or equipment
are operating correctly.
 Performance Qualification (PQ) - Demonstrates that the process or equipment performs
as intended in a consistent manner over time.

 Component Qualification (CQ) - is a relatively new term developed in 2005. This term
refers to the manufacturing of auxiliary components to ensure that they are manufactured
to the correct design criteria. This could include packaging components such as folding
cartons, shipping cases, labels or even phase change material. All of these components
must have some type of random inspection to ensure that the third party manufacturer's
process is consistently producing components that are used in the world of GMP at drug
or biologic manufacturer.

There is often overlap between Installation, Operational, and Performance Qualification and
sometimes these are performed simultaneously.
Figure 2: OPQ Validation Process (adapted from the typical V-Model)

This combined testing of OQ and PQ phases is sanctioned by the European Commission


Enterprise Directorate-General within ‘Annex 15 to the EU Guide to Good Manufacturing
Practice guide’ (2001, p. 6) which states that:

"Although PQ is described as a separate activity, it may in some cases be appropriate to


perform it in conjunction with OQ."

[edit] 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 and medical devices. In
1983 the FDA published a guide to the inspection of Computerized Systems in Pharmaceutical
Processing, also known as the 'bluebook' (FDA 1983). 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 1998). 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 (ISO 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." 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.

[edit] 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 (Smith 2001; Tracy & Nash 2002; Lucas 2003; Balogh &
Corbin 2005).

[edit] 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). 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, optimising
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 an direct impact on GxP data (security or
integrity) it may be considered "GxP critical".
[edit] See also

You might also like