Guideline on General Principles of Process Validation

I. PURPOSE

This guideline outlines general principles that FDA considers to be acceptable elements of process validation for the preparation of human and animal drug products and medical devices.

II. SCOPE

This guideline is issued under Section 10.90 (21 CFR 10.90) and is applicable to the manufacture of pharmaceuticals and medical devices. It states principles and practices of general applicability that are not legal requirements but are acceptable to the FDA. A person may rely upon this guideline with the assurance of its acceptability to FDA, or may follow different procedures. When different procedures are used, a person may, but is not required to, discuss the matter in advance with FDA to prevent the expenditure of money and effort on activities that may later be determined to be unacceptable. In short, this guideline lists principles and practices which are acceptable to the FDA for the process validation of drug products and medical devices; it does not list the principles and practices that must, in all instances, be used to comply with law.

This guideline may be amended from time to time. Interested persons are invited to submit comments on this document and any subsequent revisions. Written comments should be submitted to the Dockets Management Branch (HFA-305), Food and Drug Administration, Room 4-62, 5600 Fishers Lane, Rockville, Maryland 20857. Received comments may be seen in that office between 9 a.m. and 4 p.m., Monday through Friday.

III. INTRODUCTION

Process validation is a requirement of the Current Good Manufacturing Practices Regulations for Finished Pharmaceuticals, 21 CFR Parts 210 and 211, and of the Good Manufacturing Practice Regulations for Medical Devices, 21 CFR Part 820, and therefore, is applicable to the manufacture of pharmaceuticals and medical devices. Several firms have asked FDA for specific guidance on what FDA expects firms to do to assure compliance with the requirements for process validation. This guideline discusses process validation elements and concepts that are considered by FDA as acceptable parts of a validation program.The constituents of validation

*************************Original Page 2*********************

presented in this document are not intended to be all-inclusive. FDA recognizes that, because of the great variety of medical products (drug products and medical devices), processes and manufacturing facilities, it is not possible to state in one document all of the specific validation elements that are applicable. Several broad concepts, however, have general applicability which manufacturers can use successfully as a guide in validating a manufacturing process. Although the particular requirements of process validation will vary according to such factors as the nature of the medical product (e.g., sterile vs non-sterile) and the complexity of the process, the broad concepts stated in this document have general applicability and provide an acceptable framework for building a comprehensive approach to process validation.

Definitions

Installation qualification - Establishing confidence that process equipment and ancillary systems are capable of consistently operating within established limits and tolerances.

Process performance qualification - Establishing confidence that the process is effective and reproducible.

Product performance qualification - Establishing confidence through appropriate testing that the finished product produced by a specified process meets all release requirements for functionality and safety.

Prospective validation - Validation conducted prior to the distribution of either a new product, or product made under a revised manufacturing process, where the revisions may affect the product's characteristics.

Retrospective validation - Validation of a process for a product already in distribution based upon accumulated production, testing and control data.

Validation - Establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its pre-determined specifications and quality attributes.

Validation protocol - A written plan stating how validation will be conducted, including test parameters, product characteristics, production equipment, and decision points on what constitutes acceptable test results.

*************************Original Page 3********************

Worst case - A set of conditions encompassing upper and lower processing limits and circumstances, including those within standard operating procedures, which pose the greatest chance of process or product failure when compared to ideal conditions. Such conditions do not necessarily induce product or process failure.

IV. GENERAL CONCEPTS

Assurance of product quality is derived from careful attention to a number of factors including selection of quality parts and materials, adequate product and process design, control of the process, and in-process and end-product testing. Due to the complexity of today's medical products, routine end-product testing alone often is not sufficient to assure product quality for several reasons. Some end-product tests have limited sensitivity.(1) In some cases, destructive testing would be required to show that the manufacturing process was adequate, and in other situations end-product testing does not reveal all variations that may occur in the product that may impact on safety and effectiveness.(2)

The basic principles of quality assurance have as their goal the production of articles that are fit for their intended use. These principles may be stated as follows:

(1) quality, safety, and effectiveness must be designed and built into the product;

(2) quality cannot be inspected or tested into the finished product; and

(3) each step of the manufacturing process must be controlled to maximize the probability that the finished product meets all quality and design specifications.

Process validation is a key element in assuring that these quality assurance goals are met

*************************Original Page 4********************

It is through careful design and validation of both the process and process controls that a manufacturer can establish a high degree of confidence that all manufactured units from successive lots will be acceptable. Successfully validating a process may reduce the dependence upon intensive in-process and finished product testing. It should be noted that in most all cases, end-product testing plays a major role in assuring that quality assurance goals are met; i.e., validation and end-product testing are not mutually exclusive.

The FDA defines process validation as follows:

Process validation is establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its pre-determined specifications and quality characteristics.

It is important that the manufacturer prepare a written validation protocol which specifies the procedures (and tests) to be conducted and the data to be collected. The purpose for which data are collected must be clear, the data must reflect facts and be collected carefully and accurately. The protocol should specify a sufficient number of replicate process runs to demonstrate reproducibility and provide an accurate measure of variability among successive runs. The test conditions for these runs should encompass upper and lower processing limits and circumstances, including those within standard operating procedures, which pose the greatest chance of process or product failure compared to ideal conditions; such conditions have become widely known as "worst case" conditions. (They are sometimes called "most appropriate challenge" conditions.) Validation documentation should include evidence of the suitability of materials and the performance and reliability of equipment and systems.

Key process variables should be monitored and documented. Analysis of the data collected from monitoring will establish the variability of process parameters for individual runs and will establish whether or not the equipment and process controls are adequate to assure that product specifications are met.

Finished product and in-process test data can be of value in process validation, particularly in those situations where quality attributes and variabilities can be readily measured. Where finished (or in-process) testing cannot adequately measure certain attributes, process validation should be derived primarily from qualification of each system used in production and from consideration of the interaction of the various systems.

*************************Original Page 5********************

V. CGMP REGULATIONS FOR FINISHED PHARMACEUTICALS

Process validation is required, in both general and specific terms, by the Current Good Manufacturing Practice Regulations for Finished Pharmaceuticals, 21 CFR Parts 210 and 211. Examples of such requirements are listed below for informational purposes, and are not all-inclusive.

A requirement for process validation is set forth in general terms in Section 211.100 -- Written procedures; deviations -- which states, in part:

"There shall be written procedures for production and process control designed to assure that the drug products have the identity, strength, quality, and purity they purport or are represented to possess."

Several sections of the CGMP regulations state validation requirements in more specific terms. Excerpts from some of these sections are:

Section 211.110, Sampling and testing of in-process materials and drug products.

(a) "....control procedures shall be established to monitor the output and VALIDATE the performance of those manufacturing processes that may be responsible for causing variability in the characteristics of in-process material and the drug product." (emphasis added)

Section 211.113, Control of Microbiological Contamination.

(b) "Appropriate written procedures, designed to prevent microbiological contamination of drug products purporting to be sterile, shall be established and followed. Such procedures shall include VALIDATION of any sterilization process." (emphasis added)

*************************Original Page 6********************

VI. GMP REGULATION FOR MEDICAL DEVICES

Process validation is required by the medical device GMP Regulations, 21 CFR Part 820. Section 820.5 requires every finished device manufacturer to:

"...prepare and implement a quality assurance program that is appropriate to the specific device manufactured..."

Section 820.3(n) defines quality assurance as:

"...all activities necessary to verify confidence in the quality of the process used to manufacture a finished device."

When applicable to a specific process, process validation is an essential element in establishing confidence that a process will consistently produce a product meeting the designed quality characteristics.

A generally stated requirement for process validation is contained in section 820.100:

"Written manufacturing specifications and processing procedures shall be established, implemented, and controlled to assure that the device conforms to its original design or any approved changes in that design."

Validation is an essential element in the establishment and implementation of a process procedure, as well as in determining what process controls are required in order to assure conformance to specifications.

Section 820.100(a) (1) states:

"...control measures shall be established to assure that the design basis for the device, components and packaging is correctly translated into approved specifications."

Validation is an essential control for assuring that the specifications for the device and manufacturing process are adequate to produce a device that will conform to the approved design characteristics

*************************Original Page 7********************

VII. PRELIMINARY CONSIDERATIONS

A manufacturer should evaluate all factors that affect product quality when designing and undertaking a process validation study. These factors may vary considerably among different products and manufacturing technologies and could include, for example, component specifications, air and water handling systems, environmental controls, equipment functions, and process control operations. No single approach to process validation will be appropriate and complete in all cases; however, the following quality activities should be undertaken in most situations.

During the research and development (R& D) phase, the desired product should be carefully defined in terms of its characteristics, such as physical, chemical, electrical and performance characteristics.(3) It is important to translate the product characteristics into specifications as a basis for description and control of the product.

Documentation of changes made during development provide traceability which can later be used to pinpoint solutions to future problems.

The product's end use should be a determining factor in the development of product (and component) characteristics and specifications. All pertinent aspects of the product which impact on safety and effectiveness should be considered. These aspects include performance, reliability and stability. Acceptable ranges or limits should be established for each characteristic to set up allowable variations.(4) These ranges should be expressed in readily measurable terms.

*************************Original Page 8********************

The validity of acceptance specifications should be verified through testing and challenge of the product on a sound scientific basis during the initial development and production phase.

Once a specification is demonstrated as acceptable it is important that any changes to the specification be made in accordance with documented change control procedures.

VIII. ELEMENTS OF PROCESS VALIDATION

A. Prospective Validation

Prospective validation includes those considerations that should be made before an entirely new product is introduced by a firm or when there is a change in the manufacturing process which may affect the product's characteristics, such as uniformity and identity. The following are considered as key elements of prospective validation.

1. Equipment and Process

The equipment and process(es) should be designed and/or selected so that product specifications are consistently achieved. This should be done with the participation of all appropriate groups that are concerned with assuring a quality product, e.g., engineering design, production operations, and quality assurance personnel.

a. Equipment : Installation Qualification

Installation qualification studies establish confidence that the process equipment and ancillary systems are capable of consistently operating within established limits and tolerances. After process equipment is designed or selected, it should be evaluated and tested to verify that it is capable of operating satisfactorily within the operating limits required by the process.(5) This phase of validation includes examination of equipment design; determination of calibration, maintenance, and

*************************Original Page 9********************

adjustment requirements; and identifying critical equipment features that could affect the process and product. Information obtained from these studies should be used to establish written procedures covering equipment calibration, maintenance, monitoring, and control.

In assessing the suitability of a given piece of equipment, it is usually insufficient to rely solely upon the representations of the equipment supplier, or upon experience in producing some other product.(6) Sound theoretical and practical engineering principles and considerations are a first step in the assessment.

It is important that equipment qualification simulate actual production conditions, including those which are "worst case" situations.

Tests and challenges should be repeated a sufficient number of times to assure reliable and meaningful results. All acceptance criteria must be met during the test or challenge. If any test or challenge shows that the equipment does not perform within its specifications, an evaluation should be performed to identify the cause of the failure. Corrections should be made and additional test runs performed, as needed, to verify that the equipment performs within specifications. The observed variability of the equipment between and within runs can be used as a basis for determining the total number of trials selected for the subsequent performance qualification studies of the process.(7)

*************************Original Page 10********************

Once the equipment configuration and performance characteristics are established and qualified, they should be documented. The installation qualification should include a review of pertinent maintenance procedures, repair parts lists, and calibration methods for each piece of equipment. The objective is to assure that all repairs can be performed in such a way that will not affect the characteristics of material processed after the repair. In addition, special post-repair cleaning and calibration requirements should be developed to prevent inadvertent manufacture a of non-conforming product. Planning during the qualification phase can prevent confusion during emergency repairs which could lead to use of the wrong replacement part.

b. Process: Performance Qualification

The purpose of performance qualification is to provide rigorous testing to demonstrate the effectiveness and reproducibility of the process. In entering the performance qualification phase of validation, it is understood that the process specifications have been established and essentially proven acceptable through laboratory or other trial methods and that the equipment has been judged acceptable on the basis of suitable installation studies.

Each process should be defined and described with sufficient specificity so that employees understand what is required. Parts of the process which may vary so as to affect important product quality should be challenged.(8) In challenging a process to assess its adequacy, it is important that challenge conditions simulate those that will be encountered during actual production, including "worst case" conditions. The challenges should be repeated enough times to assure that the results are meaningful and consistent.

*************************Original Page 11********************

Each specific manufacturing process should be appropriately qualified and validated. There is an inherent danger in relying on what are perceived to be similarities between products, processes, and equipment without appropriate challenge.(9)

c. Product: Performance Qualification

For purposes of this guideline, product performance qualification activities apply only to medical devices. These steps should be viewed as pre-production quality assurance activities.

Before reaching the conclusion that a process has been successfully validated, it is necessary to demonstrate that the specified process has not adversely affected the finished product. Where possible, product performance qualification testing should include performance testing under conditions that simulate actual use. Product performance qualification testing should be conducted using product manufactured from the same type of production equipment, methods and procedures that will be used for routine production. Otherwise, the qualified product may not be representative of production units and cannot be used as evidence that the manufacturing process will produce a product that meets the pre-determined specifications and quality attributes.(10)

*************************Original Page 12********************

After actual production units have successfully passed product performance qualification, a formal technical review should be conducted and should include:

• Comparison of the approved product specifications and the actual qualified product.
• Determination of the validity of test methods used to determine compliance with the approved specifications.
• Determination of the adequacy of the specification change control program.

  2. System to Assure Timely Revalidation

There should be a quality assurance system in place which requires revalidation whenever there are changes in packaging, formulation, equipment, or processes which could impact on product effectiveness or product characteristics, and whenever there are changes in product characteristics. Furthermore, when a change is made in raw material supplier, the manufacturer should consider subtle, potentially adverse differences in the raw material characteristics. A determination of adverse differences in raw material indicates a need to revalidate the process.

One way of detecting the kind of changes that should initiate revalidation is the use of tests and methods of analysis which are capable of measuring characteristics which may vary. Such tests and methods usually yield specific results which go beyond the mere pass/fail basis, thereby detecting variations within product and process specifications and allowing determination of whether a process is slipping out of control.

The quality assurance procedures should establish the circumstances under which revalidation is required. These may be based upon equipment, process, and product performance observed during the initial validation challenge studies. It is desirable to designate individuals who have the responsibility to review product, process, equipment and personnel changes to determine if and when evalidation is warranted.

*************************Original Page 13********************

The extent of revalidation will depend upon the nature of the changes and how they impact upon different aspects of production that had previously been validated. It may not be necessary to revalidate a process from scratch merely because a given circumstance has changed. However, it is important to carefully assess the nature of the change to determine potential ripple effects and what needs to be considered as part of revalidation.

3. Documentation

It is essential that the validation program is documented and that the documentation is properly maintained. Approval and release of the process for use in routine manufacturing should be based upon a review of all the validation documentation, including data from the equipment qualification, process performance qualification, and product/package testing to ensure compatibility with the process.

For routine production, it is important to adequately record process details (e.g., time, temperature, equipment used) and to record any changes which have occurred. A maintenance log can be useful in performing failure investigations concerning a specific manufacturing lot. Validation data (along with specific test data) may also determine expected variance in product or equipment characteristics.

B. Retrospective Process Validation

In some cases a product may have been on the market without sufficient premarket process validation. In these cases, it may be possible to validate, in some measure, the adequacy of the process by examination of accumulated test data on the product and records of the manufacturing procedures used.

Retrospective validation can also be useful to augment initial premarket prospective validation for new products or changed processes. In such cases, preliminary prospective validation should have been sufficient to warrant product marketing. As additional data is gathered on production lots, such data can be used to build confidence in the adequacy of the process. Conversely, such data may indicate a declining confidence in the process and a commensurate need for corrective changes.

Test data may be useful only if the methods and results are adequately specific. As with prospective validation, it may be insufficient to assess the process solely on the basis of lot by lot conformance to specifications if test results are merely expressed in terms of pass/fail. Specific results, on the other hand, can be statistically analyzed and a determination can be made of what variance in data can be expected. It is important to maintain records which describe the operating characteristics of the process, e.g., time, temperature, humidity, and equipment settings.(11) Whenever test data are used to demonstrate conformance to specifications, it is important that the test methodology be qualified to assure that test results are objective and accurate.

IX. ACCEPTABILITY OF PRODUCT TESTING

In some cases, a drug product or medical device may be manufactured individually or on a one-time basis. The concept of prospective or retrospective validation as it relates to those situations may have limited applicability, and data obtained during the manufacturing and assembly process may be used in conjunction with product testing to demonstrate that the instant run yielded a finished product meeting all of its specifications and quality characteristics. Such evaluation of data and product testing would be expected to be much more extensive than the usual situation where more reliance would be placed on prospective validation.

(1) For example, USP XXI states: "No sampling plan for applying sterility tests to a specified proportion of discrete units selected from a sterilization load is capable of demonstrating with complete assurance that all of the untested units are in fact sterile."

(2) As an example, in one instance a visual inspection failed to detect a defective structural weld which resulted in the failure of an infant warmer. The defect could only have been detected by using destructive testing or expensive test equipment.

(3) For example, in the case of a compressed tablet, physical characteristics would include size, weight, hardness, and freedom from defects, such as capping and splitting. Chemical characteristics would include quantitative formulation/potency; performance characteristics may include bioavailability (reflected by disintegration and dissolution). In the case of blood tubing, physical attributes would include internal and external diameters, length and color. Chemical characteristics would include raw material formulation. Mechanical properties would include hardness and tensile strength; performance characteristics would include biocompatibility and durability.

(4) For example, in order to assure that an oral, ophthalmic, or parenteral solution has an acceptable pH, a specification may be established by which a lot is released only if it has been shown to have a pH within a narrow established range. For a device, a specification for the electrical resistance of a pacemaker lead would be established so that the lead would be acceptable only if the resistance was within a specified range.

(5) Examples of equipment performance characteristics which may be measured include temperature and pressure of injection molding machines, uniformity of speed for mixers, temperature, speed and pressure for packaging machines, and temperature and pressure of sterilization chambers.

(6) The importance of assessing equipment suitability based upon how it will be used to attain desired product attributes is illustrated in the case of deionizers used to produce Purified Water, USP. In one case, a firm used such water to make a topical drug product solution which, in view of its intended use, should have been free from objectionable microorganisms. However, the product was found to be contaminated with a pathogenic microorganism. The apparent cause of the problem was failure to assess the performance of the deionizer from a microbiological standpoint. It is fairly well recognized that the deionizers are prone to build-up of microorganisms -- especially if the flow rates are low and the deionizers are not recharged and sanitized at suitable intervals. Therefore, these factors should have been considered. In this case, however, the firm relied upon the representations of the equipment itself, namely the "recharge" (i.e., conductivity) indicator, to signal the time for regeneration and cleaning. Considering the desired product characteristics, the firm should have determined the need for such procedures based upon pre-use testing, taking into account such factors as the length of time the equipment could produce deionized water of acceptable quality, flow rate, temperature, raw water quality, frequency of use, and surface area of deionizing resins.

(7) For example, the AAMI Guideline for Industrial Ethylene Oxide Sterilization of Medical Devices approved 2 December 1981, states: "The performance qualification should include a minimum of 3 successful, planned qualification runs, in which all of the acceptance criteria are met.....(5.3.1.2.)

(8) For example, in electroplating the metal case of an implantable pacemaker, the significant process steps to define, describe, and challenge include establishment and control of current density and temperature values for assuring adequate composition of electrolyte and for assuring cleanliness of the metal to be plated. In the production of parenteral solutions by aseptic filling, the significant aseptic filling process steps to define and challenge should include the sterilization and depyrogenation of containers/closures, sterilization of solutions, filling equipment and product contact surfaces, and the filling and closing of containers.

(9) For example, in the production of a compressed tablet, a firm may switch from one type of granulation blender to another with the erroneous assumption that both types have similar performance characteristics, and, therefore, granulation mixing times and procedures need not be altered. However, if the blenders are substantially different, use of the new blender with procedures used for the previous blender may result in a granulation with poor content uniformity. This, in turn, may lead to tablets having significantly differing potencies. This situation may be averted if the quality assurance system detects the equipment change' in the first place, challenges the blender performance, precipitates a revalidation of the process, and initiates appropriate changes. In this example, revalidation comprises installation qualification of the new equipment and performance qualification of the process intended for use in the new blender.

(10) For example, a manufacturer of heart valves received complaints that the valve-support structure was fracturing under use. Investigation by the manufacturer revealed that all material and dimensional specifications had been met but the production machining process created microscopic scratches on the valve supporting wireform. These scratches caused metal fatigue and subsequent fracture. Comprehensive fatigue testing of production units under simulated use conditions could have detected the process deficiency.

In another example, a manufacturer recalled insulin syringes because of complaints that the needles were clogged. Investigation revealed that the needles were clogged by silicone oil which was employed as a lubricant during manufacturing. Investigation further revealed that the method used to extract the silicone oil was only partially effective. Although visual inspection of the syringes seemed to support that the cleaning method was effective, actual use proved otherwise.

(11) For example, sterilizer time and temperature data collected on recording equipment found to be accurate and precise could establish that process parameters had been reliably delivered to previously processed loads. A retrospective qualification of the equipment could be performed to demonstrate that the recorded data represented conditions that were uniform throughout the chamber and that product load configurations, personnel practices, initial temperature, and other variables had been adequately controlled during the earlier runs.

http://www.fda.gov/CDER/GUIDANCE/pv.htm

Qualification, Validation, and Verification

This article considers the distinction among the terms qualification, validation, and verification in the context of pharmacopeial usage.A recommendation for a standardized usage of the terms validation and verification is provided,and general requirements for validation and verification activities are given.The article also emphasizes the importance of knowing when validation or verification is necessary relative to the use of a method to satisfy pharmacopeial article requirements (for which a monograph..
The terms qualification, validation, and verification occur numerous times in US Pharmacopeia 29 (1). Qualification is found in Chapters ‹1035› "Biological Indicators for Sterilization," ‹1043› "Ancillary Materials Cell, Gene, and Tissue-Engineered Products," ‹1046› "Cell and Gene Therapy Products," and ‹1119› "Near-Infrared Spectrophotometry," among others. Validation appears in ‹1225› "Validation of Compendial Procedures," ‹1223› "Validation of Alternative Microbiological Methods," ‹1010› "Analytical Data—Interpretation and Treatment," ‹1043› "Ancillary Materials for Cell-, Gene-, and Tissue-Engineered Products," ‹1117› "Microbiological Best Laboratory Practices," ‹1120› "Raman Spectrophotometry," and many others. Verification appears in ‹1010› "Analytical Data—Interpretation and Treatment," ‹1035› "Biological Indicators for Sterilization," ‹1035› "Biological Indicators for Sterilization," ‹85› "Bacterial Endotoxins Test," and others. The terms also are present in documents from the US Food and Drug Administration, the Environmental Protection Agency (EPA), and the International Conference on Harmonization (ICH). Given the numerous definitions for the three terms, this article in part is intended to provide an approach to fostering more consistency in the usage of the terms.

A recent issue of the Pharmacopeial Forum (2) had a diagram from a proposed General Chapter ‹1058› "Analytical Instrument Qualification" that was intended to show "...four critical components involved in the generation of reliable and consistent data (quality data)." From most to least critical, the components were quality-control check samples, system suitability tests, analytical methods validation, and analytical instrument qualification. In this article, consider system-suitability tests to be the same as verification. Why this usage should be acceptable will be explained. This article will consider validation and verification in detail. Reference to analytical instrument qualification is made. For further discussion of the top tier, "Quality Control Check Samples," refer to Chapter ‹1058› "Analytical Instrument Qualification" (1).

Qualification

Qualification of analytical instrumentation is essential for accurate and precise measurement of analytical data. If the instrumentation is not qualified, ensuring that the results indicated are trustworthy, all other work based upon the use of that instrumentation is suspect. For the purposes of this article, the assumption will be made that the foundation of validation and verification work to follow is based solidly upon well-qualified instrumentation.

Validation

Definitions. Numerous documents provide definitions of validation. A dictionary definition (3) of validation includes "...the process of determining the degree of validity of a measuring device," and for validate: "to make legally valid," with synonyms "verify, substantiate." Clearly, the synonyms do not distinguish between validation and verification, so let us now turn to definitions provided by other sources. USP chapter ‹1225› "Validation of Compendial Procedures" provides the following:

"Validation of an analytical procedure is the process by which it is established, by laboratory studies, that the performance characteristics of the procedure meet the requirements for the intended analytical applications."

From the ICH document Validation of Analytical Procedures: Text and Methodology:

However, it is important to remember that the main objective of validation of an analytical procedure is to demonstrate that the procedure is suitable for its intended purpose (4).

FDA provides a definition of validation in numerous documents. One such document, Guidance for Industry: Analytical Procedures and Methods Validation Chemistry, Manufacturing, and Controls Documentation says "methods validation is the process of demonstrating that analytical procedures are suitable for their intended use" (5). There also are numerous documents defining validation within the context of processes. From FDA's Guideline on General Principles of Process Validation:

"Validation—Establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its predetermined specifications and quality attributes (6)."

The same definition is provided in other FDA documents, such as Guideline on Sterile Drug Products Produced by Aseptic Processing. FDA document Guidance for Industry: Quality Systems Approach to Pharmaceutical Current Good Manufacturing Practice Regulations provides this definition:

"With proper design (see section IV.C.1), and reliable mechanisms to transfer process knowledge from development to commercial production, a manufacturer should be able to validate the manufacturing process. In a quality system, process validation provides initial proof, through commercial batch manufacture, that the design of the process produces the intended product quality (7). "

The remainder of the discussion about validation in this article will be restricted to a discussion of method validation.

Does it suit its purpose? The foregoing is clearly not an exhaustive list of the manners in which validation has been defined. It does appear that a recurring theme among the various definitions pertains to demonstrating that the method or process is suitable for its intended use. In this article, consider validation to be the demonstration that a method or process is suitable for its intended purpose. Accepting that, it is imperative that the intended purpose of a method or process is clearly stated at the outset of the validation. An example of the importance of such a statement can be found in Chapter ‹71› "Sterility Tests" (1). It states that "the following procedures are applicable for determining whether a Pharmacopeial article purporting to be sterile complies with the requirements set forth in the individual monograph with respect to the test for sterility." The next paragraph states

"These Pharmacopeial procedures are not by themselves designed to ensure that a batch of product is sterile or has been sterilized. This is accomplished primarily by validation of the sterilization process or of the aseptic processing procedures."

During the years there has been concern that the tests for sterility as provided in Chapter ‹71› are not adequate to prove that a batch of product is sterile. As stated previously, the tests in Chapter ‹71› were intended only to show that a Pharmacopeial article is sterile. Such a demonstration constitutes a necessary but not sufficient condition for sterile pharmacopeial articles. If one were to validate an alternative procedure for that in Chapter ‹71›, it would not be necessary to develop one that is intended to demonstrate sterility of an entire lot of product.

In addition, it is appropriate that the conditions are provided under which the validation was performed. Given that there are essentially countless variations on experimental conditions, product matrix effects, and so forth, a validation cannot reasonably expect to address all such permutations. For example, Method 3 in the section of Chapter ‹1047› "Biotechnology-Derived Articles—Tests", which addresses assays for total protein, indicates in a note:

"[Do not use quartz (silica) spectrophotometer cells: the dye binds to this material. Because different protein species may give different color response intensities, the standard protein and test protein should be the same.] There are relatively few interfering substances, but detergents and ampholytes in the test specimen should be avoided. Highly alkaline specimens may interfere with the acidic reagent (1)."

Therefore, given the following from FDA's Guide to Inspections of Pharmaceutical Quality Control Laboratories: "Methods appearing in the USP are considered validated and they are considered validated if part of an approved ANDA" (8), the use of Method 3 would be valid if the conditions stated are met in testing the material of interest. The same FDA document states "For compendial methods, firms must demonstrate that the method works under the actual conditions of use," which, for the sake of this article, will be considered verification. Chapter ‹1047› provides several other procedures, all also validated, that could be considered given test material that does not satisfy the conditions for Method 3.

Remember the purpose. It is important to bear in mind the purpose of the method to be validated. If the method is intended to serve as an alternative to a pharmacopeial method, then one must establish its equivalence to the pharmacopeial method in terms of the end result. Remember that the purpose of a method in the pharmacopeia is to determine whether the pharmacopeial article (for which a monograph exists in the pharmacopeia) satisfies the requirements in the monograph. If instead the purpose behind the use of a pharmacopeial method is for a purpose other than demonstrating that the article complies with monograph requirements (for example, imagine that total organic carbon is to be determined using Chapter ‹643› "Total Organic Carbon"), it is not necessary to perform the validation relative to the pharmacopeial results. This means that the validation should be conducted relative to the specific purpose for which it is intended. Also implicit in this is the use of a nonpharmacopeial method to determine something for which a pharmacopeial method exists, but again for purposes unrelated to satisfying a monograph requirement. In such a case, it is unnecessary to consider validating the method relative to that in the pharmacopeia.

Verification

If the use of the term validation is restricted to mean the demonstration of suitability of a method or process for its intended purpose, and the term verification for the demonstration that the previously validated method is suitable for use given specific experimental conditions that may or may not be appropriate given the conditions present during the validation, the terminological situation may be clarified.

Figure 1

These actual conditions include specific ingredients or products, specific laboratory personnel, equipment, and reagents. There are, however, instances in the literature where this distinction is not maintained. Consider the dictionary definition given previously for validation and its use of verification as a synonym for validation. Further muddying of the waters occurs when phrases such as "system suitability tests" (see Figure 1 and the system-suitability section in Chapter ‹621› "Chromatography"). The phrase also appears in the "Suitability of the Counting Method in the Presence of Product" section of Chapter ‹61› "Microbiological Examination of Nonsterile Products: Microbial Enumeration Tests", the "Suitability of the Test Method" section of Chapter ‹62› "Microbiological Examination of Nonsterile Products: Tests for Specified Microorganisms", and the "Validation Test" section of Chapter ‹71› "Sterility Tests." (1). In all cases, the intention is to ensure that the validated method will work under the specific conditions the analyst plans to use.

This means that a chromatographic system can deliver resolution and reproducibility on par with the system used during validation. For the two microbiology test chapters for nonsterile products, one must show that microbial growth in the presence of the article to be tested is not hindered. This is because the method depends on unencumbered microbial growth for it to work. In other words, a condition established in validating the method initially was unhindered microbial growth. The use of "validation test" in Chapter ‹71› is unfortunate because the intention was again to demonstrate that microbial growth is not hindered, as indicated in the following text:

"If clearly visible growth of microorganisms is obtained after the incubation, visually comparable to that in the control vessel without product, either the product possesses no antimicrobial activity under the conditions of the test or such activity has been satisfactorily eliminated. The test for sterility may then be carried out without further modification."

It may be advantageous, and more consistent, for the text in Chapter ‹71› to be changed to "Suitability of the Test Method," if not to "Verification of the Test Method." The latter change also may be appropriate for Chapters ‹61› and ‹62›, given that what is being assessed is the verification that the actual test conditions relative to those established during the validation permits the proper functioning of the method. Given the harmonized status of these three chapters, such changes, although possible, would certainly take longer to become official.

The same cautions provided at the end of the section on validation are applicable here. If a method in use previously was derived from a pharmacopeial method but used for a purpose other than satisfying monograph requirements, it is not necessary to adopt a revised method in the pharmacopeia when it becomes official. It is therefore not necessary to reverify the suitability of your test article to the revised method. Likewise, the use of a nonpharmacopeial method for purposes other than satisfying a monograph requirement when a pharmacopeial method exists of potential relevance does not necessitate reverification.

General requirements for validation

There are numerous documents that describe the general approach to a validation process. They describe several characteristics (data elements in Chapter ‹1225›) that may be examined during validation, with specific sets selected based upon the nature of the test method. A brief description of these characteristics is provided herein using the characteristics as outlined in the IC Harmonization Harmonized Tripartite Guideline, Validation of Analytical Procedures: Text and Methodology.

Accuracy is a determination of how close the measured value is (in the case of an analytical method) to the true value. As such, one might define accuracy of method as equal to true value plus error. Error may contain both the systematic error (bias) and imprecision of measurement. With the potential error possible, it is important to include a means of reflecting the "true value" as closely as possible. For many compendial tests, this involves the use of a reference standard. Because a method is expected to be useful over a range of true values, the accuracy should be assessed over the expected range of values to which the method is to be applied. As stated previously, the validation should also state the conditions under which the accuracy was determined. Because it is not possible to determine all possible sets of conditions for which a compendial assay might be applicable, accuracy may need to be verified before use of a validated method. The concept of accuracy is more problematic for microbiological assays.

The precision of a method determined during validation should be representative of the repeatability (reproducibility) of the method. As was the case for the determination of accuracy, it should be determined over the expected range of articles to be measured, and the conditions used during the validation should be clearly stated. As for accuracy, the use of reference standards is common because the goal of the assessment of precision is to determe method repeatability without introducing unknown variance as a result of different test articles or test articles drawn from a heterogeneous source. The latter point also complicates the validation of microbiological assays.

Specificity refers to the ratio of false positives to false negatives. A highly specific method would have a very low ratio, given that it should be able to detect the article of interest present in very low quantities in the presence of much higher quantities of similar but not identical articles. As stated previously, specificity should be determined over the expected range of usage for the method, and conditions used during the validation should be clearly stated.

Linearity, in essence, refers to the existence of a direct relationship between the quantity of article contained in the sample being analyzed and the measured value resulting from the analysis. It is not the purpose of this article to delve into statistical intricacies pertaining to data transformation, the use of linear or nonlinear regression techniques, residual analysis, and so forth. Currently, it is sufficient that an assay purporting to be quantitative in nature must have a demonstrable quantitative relationship between the quantity of material of interest contained in the sample and the measured response.

Range is directly related to linearity, and ties in accuracy and precision as well. It represents the lowest and highest quantities of material of interest contained within the samples under analysis that provide data with acceptable accuracy, precision, and linearity.

Detection limit represents the least amount of material of interest contained within the sample under analysis that produces a signal exceeding the underlying noise. No assertions pertaining to accuracy, precision, and linearity are necessary at this level of material of interest. For example, if a method is validated to have a detection limit of 3 ng of total protein using Method 3 (1), then a sample containing 3 ng would elicit a signal discernible from underlying noise. It would not be possible to state from such data alone whether there was in fact an exact quantity ng of protein in the sample, only that there were at least 3 ng.

Quantitation-limit determination is more demanding in that currently it is necessary to establish the minimum quantity of material of interest contained within the sample that produces a signal that lies within the linear range of data. That is to say, the quantitation limit represents the lowest end of the range.

Intermediate precision (ruggedness in USP Chapter ‹1225› [1]) pertains to the establishment of "...the effects of random events on the precision of the analytical procedure" (4). Referring to the previous discussion under accuracy pertaining to error components, intermediate precision considers random error introduced by such factors as specific equipment, analysts, laboratories, days, and so forth. It is not meant to include systematic error (bias).

Robustness is probably most directly related to the consideration of conditions under which a validated method is shown to be suitable. This text is very useful in considering robustness:

"If measurements are susceptible to variations in analytical conditions, the analytical conditions should be suitably controlled or a precautionary statement should be included in the procedure. One consequence of the evaluation of robustness should be that a series of system suitability parameters (e.g., resolution test) is established to ensure that the validity of the analytical procedure is maintained whenever used (4)."

General requirements for verification

One question that may be asked of the compendia is whether a method provided as official (in the compendia or supplements) requires validation. USP Chapter ‹1225› states:

"...users of analytical methods described in the USP-NF are not required to validate accuracy and reliability of these methods, but merely verify their suitability under actual conditions of use (1)."

This text is consistent with the proposal in this article that the term validation be reserved for the process whereby one determines if a given method is suitable for its intended purpose (which must be clearly defined), and that the term verification be reserved for the demonstration that the conditions under which the method is to be performed will be appropriate for the method.

Another question may be given that verification involves demonstrating that the conditions to be evaluated are suitable for use with the validated method, how does one go about assessing that? It should be evident that a subset of the determinations performed during the validation would be appropriate. Important conditions to consider include equipment, possible matrix effects (components included in the article to be tested that were not evaluated during the validation), and other conditions for which there is no clear indication provided in the method as to their suitability. A proposed new General Chapter ‹1226› "Verification of Compendial Procedures" (see reference 9 for a discussion of this chapter) provides some guidance as to how the verification process may be executed, but ultimately the user is responsible for selecting which of the characteristics (data elements) evaluated during the validation should be examined as part of the verification. The user should establish which of those validation characteristics are critical to the successful use of the validated method.

Summary

There has been some confusion about when an analytical method should be validated and when it should be verified. In fact, there have been occasions when the terms have been used interchangeably. It is suggested that the term validation be reserved for the process necessary to demonstrate that a method is suitable for its intended purpose. Effective validation begins with a proper statement of the purpose of the method. This statement should accompany the method validation report, and in some circumstances, such as with Chapter ‹71› "Sterility Tests" (1), the statement should appear in the text accompanying the method. Depending upon the degree to which robustness is assessed during the validation process, there may be a set of conditions determined that may be suitable for the use of the method, and conditions that are contraindicated. If such conditions have been established, it is helpful for them to accompany the text describing the method (for example, Method 3 in [9]).

The term verification should be reserved for the process whereby it is established that the conditions under which an article is to be tested by a validated method are indeed suitable for that method. The verification process might be considered to include a subset of the validation process, as suggested by Figure 1. The characteristics (data elements) of a validation process are contained in several documents, and which of these are incorporated in the validation should be appropriate to the method's intended purpose (and spelled out in the validation protocol.) The characteristics from the validation that are assessed during the verification should be representative of the critical aspects of the method. An example of the verification of the range for Method 3 was provided. Given that verification, as described in this article, is intended to address the suitability of a particular set of conditions for use with a validated method, robustness is not likely to be important for the verification process.

For both validation and verification, one must remember the underlying purpose of the method. If the method is from the pharmacopeia and is intended to be used in demonstrating that a pharmacopeial article meets requirements (for which there is a monograph), the method is considered to be validated, and it would be necessary to verify that the test article is suitable for use with the method. If the method is from the pharmacopeia but is not intended for use in satisfying monograph requirements, it may need to be validated relative to the specific nonpharmacopeial purpose. If instead the method is not from the pharmacopeia but is intended to satisfy monograph requirements, it must be validated as providing equivalent results to the pharmacopeial method. Finally, if the nonpharmacopeial method is not intended to satisfy monograph requirements, it must be validated according to its specific purpose, and this would not require comparison to any pharmacopeial method.

David A. Porter is a pharmaceutical consultant with Vectech Pharmaceutical Consultants, Inc. (Farmington, MI), dporter@vectech.com

Submitted: Oct. 26, 2006. Accepted: Dec. 11, 2006.

Keywords: qualification, USP, validation, verification

References

1. United States Pharmacopeia 29—National Formulary 24, United States Pharmacopeial Convention, (2006).

1. Pharmacopeial Forum 32 (2), 595–604 (Mar.–Apr. 2006).

3. Webster's Seventh New Collegiate Dictionary. (G. & C. Merriam Co., Springfield, MA, 1965).

4. International Conference on Harmonization Harmonized Tripartite Guideline, Validation of Analytical Procedures: Text and Methodology, (ICH, Geneva, Switzerland, 2005).

5. FDA, Center for Drug Evaluation and Research, Guidance for Industry: Analytical Procedures and Methods Validation Chemistry, Manufacturing, and Controls Documentation, (Rockville, MD, Aug. 2000).

6. FDA, Center for Drug Evaluation and Research, Guideline on General Principles of Process Validation, (Rockville, MD, May 1987).

7. FDA, Center for Biologics Evaluation and Research, Guidance for Industry Quality Systems Approach to Pharmaceutical Current Good Manufacturing Practice Regulations, (Rockville, MD, Sept. 2006).

8. FDA, Office of Regulatory Affairs, Guide to Inspections of Pharmaceutical Quality Control Laboratories, (Rockville, MD, July 1993).

9. Pappa et al., "Development of a New USP General Information Chapter: Verification of Compendial Procedures." Pharm. Technol. 30 (3), 164–169 (2006).

An unusual reclaim process

Q: Filled product is recovered from dose checks or improperly stoppered vials, is dumped into a holding tank, in a class 100,000 area, and once in the tank, it is pumped back to the main product holding tank. It is mixed with the product in the holding tank, refiltered and filled again during the course of the filling operations. Wouldn't this "reclaim process" be considered a reworking of the product? Unless this process was submitted along with the ANDA originally, and validated, it seems that this would not be following good cGMP practice for sterile filling operations. I don't think FDA or any other regulatory agency would find this to be an acceptable practice. What are your thoughts?

A:

Jim Agalloco replies:

I fully agree—that’s a most unusual process. I've seen re-claims of this type before, but they typically aren't a part of every batch. They are used to recover an entire lot that may be off-spec. Unless it is filed that way (along with supportive data), I think the practice described is non-compliant.

Validating the Validators

By Magaly Vega, Professor, Puerto Rico Polytechnic University; José Correa, Taratec Development Corp.; and Ivan Lugo, Executive Director, INDUNIV Research Consortium

PharmaManufacturing.com

Puerto Rico’s Validation Academy and Certification Program bridges the gap between knowledge and experience.

The pharmaceutical industry today is challenged by the need to keep up with advances in science and technology, as well as changing regulatory and compliance issues. Success demands highly skilled validation professionals who not only understand the interdependence of multiple technologies, but the complex integration practices required, and their impact on validation. Such skills are especially important with computer systems validation (CSV; see COMPUTER VALIDATION sidebar below).

To address the need for ongoing training in validation, many scientific and engineering professional associations, such as ISPE, have developed programs designed to ensure competence in key areas of practice. Within Puerto Rico, industry leaders have gone one step further, by establishing a “Validation Academy” within the Polytechnic University of Puerto Rico’s Continuing Education Department. After pilots, the program was officially launched on January 1.

Faculty within the University, concerned consultants and professionals within the industry believe that this program will be essential to fostering the professional growth of validation professionals. The program should also help validation specialists document their specific areas of expertise and sharpen their skills through additional education and training.

Certification as a Validation Professional is voluntary. However, as validation activities become more critical, we believe that more pharmaceutical companies will encourage their validation professionals to pursue certification.

The program will recognize professionals who meet basic eligibility requirements and demonstrate a minimal level of job-related knowledge and skills, based on performance in a standardized examination. To be eligible, one must have a bachelor’s degree in science and three years of experience in pharmaceutical industry validation. For individuals with a significant amount of validation experience, a “grandfather clause” applies, allowing them to receive certification simply by passing a formal examination. (Editor's Note: What's your validation IQ? Test yourself by answering the four sample questions (provided at the end of this article) from a test developed as part of Puerto Rico Polytechnic’s new certification program. The answers may be found by clicking here.)

Faculty members — expert consultants and industry professionals — have identified areas of competency and the knowledge and skills required for each one, and have written test questions targeting these areas. Certification candidates might be asked to:

• Develop a list of User Requirements for a given scenario;
  
  
• Develop test scripts for a given source code;
  
  
• Use data provided to develop a Traceability Matrix.

Each test gives professionals an opportunity to demonstrate their understanding of the variety of industry standards, protocols and technologies, and how to apply them to specific situations (see table below).

Validation Academy Curriculum Modules	General Concepts Module Topics
1. General Concepts	1. Basic Validation Concepts and Documentation
2. Computer Systems	2. Qualification Studies: Facilities, Utilities & Equipment
3. Pharmaceutical Process Technology: Solids	3. Regulatory Trends
4. Pharmaceutical Process Technology: Parenterals	4. Supplier Certification
5. Validation of Analytical Methods	5. Risk Management
6. Biotechnology	6. Cleaning Validation
7. Medical Devices	7. Statistical and Validation Matrix Approach Topics
8. Packaging

After completing a General Concepts module, applicants must complete a specialized module of their choice, and their associated examinations for certification as a validation specialist. Once an individual has completed all eight modules within the course, and their associated exams, they will receive a Validation Professional certificate.

The University will issue certification for a three-year period, and those receiving certification will need to keep up to date on new developments within the field, and build competency through continuing education. Every three years, certified professionals will have to take courses adding up to 14 “Recertification Units” in order to be recertified.


COMPUTER VALIDATION

One of the specialized programs within the Validation Academy will cover computer validation, where there is a great need for certification today. In the past, IT professionals received training while in college on the formal methodologies used to test software. Later, some of these techniques would find their way into a field now officially known as “Computer Systems Validation” (CSV). As technology replaced manual processes, the pharmaceutical industry realized that it needed to take a different approach to demonstrate regulatory compliance and the formal title “CSV Professional” was born.

Today, most, if not all, manufacturing, testing and business systems are controlled by computerized equipment. These Controlling Systems manage pharmaceutical controlled processes or functions.

Validation is required for controlling systems that contain records that are “created, modified, maintained, archived, retrieved, or transmitted, under any records requirements set forth in FDA regulations.” This requirement originated the need for a professional who could establish evidence and associated documentation to prove that a computerized system:

• Has been developed according to quality software engineering principles;
  
  
• Provides the functional capability required by its users and the regulations, and that it will continue to do so over time.

For example, a LIMS (Laboratory Information Management System) is a complex tool used by laboratories within the pharmaceutical, biotechnology and medical device industries. A CSV Professional using the life-cycle approach starts by asking:

• What do we want the LIMS system to do?
  
  
• Are we using the system to receive product?
  
  
• Are we connecting the system to other analytical equipment?
  
  
• What reports or certificates of analysis will the system generate?

By developing User Requirements, the CSV Professional provides the company the information needed to understand and specify the system that best suits the operation, and any and all emotion is removed from the decisionmaking process.

Software testing also requires someone capable of understanding the business, the application and computer validation. Testing (as defined by IEEE and adopted by FDA) is the process of analyzing a software item to detect the differences between existing and required conditions, i.e. bugs, and to evaluate the features of the software.

Today’s computer systems control the precise dispensing of a liquid ingredient, the air flow to a sterile area, the administration of samples in a lab and the highly sophisticated supply management handled by an ERP system. An undetected malfunction in a critical system could lead to loss of product, compliance issues, poor quality and damaging consequences to the business.

The CSV Professional should be proficient enough to create a Test Plan that captures the strategy, requirements, testing environment, acceptance criteria, responsibilities and schedule. The individual should have competencies to assess testing performed at the software development stage. These tests should be traced back to user requirements and specifications. A few questions to ask are: Has the logic flow of the software been tested? Has the software been challenged for dead code? Does the software coding follow a structured approach? Did the developers perform a source code testing (White Box) or a functionality test of the executable run code (Black Box)?

A critical mistake is to assume that computer system validation is an on-off event, when in reality it is an ongoing life cycle. A certification program has the benefits of providing a continuous flow of up-to-date information covering best practices in computer system validation. As technology evolves, we can ensure a workforce that keeps pace with advances.

System Validation Requirements

Kevin Lloyd is vice president, chief technology officer of State College, PA-based Centre Analytical Laboratories.

In 1997 the U.S. Food and Drug Administration, in response to requests from industry, issued a regulation specifying criteria for the acceptance of electronic records and electronic signatures as the legal equivalent to manual, paper- based systems. The citation for this regulation can be found in the federal register as 21CFR11.

Citation 21CFR11, also known as Part 11, offers many advantages to industry, including a shortened period for agency review, nearly instantaneous reconstruction of studies, and enhanced confidentiality through limited authorized system access.

In order for an organization to reap the benefits of Part 11, there are many requirements that must be met. Due to the wide scope of Part 11 this article will focus only on the validation requirement. In future articles we will cover the full scope of the regulation.

For an organization to be compliant with Part 11, a number of requirements must be met. See Table 1 (in the print version) for a list of these requirements.

Due to the wide scope of Part 11, this article will focus on system validation requirements only. According to information posted on the FDA’s web site, validation is the establishment of documented evidence that provides a high degree of assurance that a specific process will consistently yield a product meeting its predetermined specifications and quality attributes. Implied by this statement: “If you didn’t document it, you didn’t do it.”

At some point in time, the FDA will inspect every company operating within an FDA-regulated environment. Although the FDA has made it clear that inspections will not be conducted solely for Part 11 compliance, it is well within its purview to inspect for Part 11 compliance within the context of a general audit.

A review of www.fda.gov reveals some common FDA-483 citation letters that have been recorded at previously inspected sites. These citations pertain to absent or incomplete records and/or practices. From the 483s, the following assumptions can be made regarding what the FDA may be looking for when they audit a facility:

• High-level hardware/software documentation, including diagrams and narratives detailing all computer programs and their relationships to each other

• Comprehensive inventories, including operating systems software, terminal emulators and client PC configurations

• Change control and error reporting SOPs

• IT personnel training records

• Software versions and installation dates

• Error reporting logs

• Evidence of proper handling of raw data files and metadata

• Archiving/backup procedures and responsibilities

• Hardware maintenance records

• Software requirements/design/testing documents

• Problem tracking

• Environmental monitoring specifications

• Disaster recovery procedures

It is clear from these requirements that a comprehensive, systematic plan is necessary to address the general expectations listed above, the Part 11 regulations and any applicable predicate rules. This plan can be divided into four phases.

Phase 1: Management Buy-In
Management buy-in is essential to any significant project in any company. The role of management in the validation program is to foster company-wide support for compliance, to make personnel available for appropriate responsibilities and to approve the expenditures necessary for implementation. It is essential to the success of a validation project to not underestimate the commitment required. Our 80-person company has invested 2 FTEs (1.5 man-years) since Jan 1, 1999 to this effort. The project also required the creation of a new position, CSVS (computer software validation specialist), whose full-time job is to ensure Part 11 compliance.

It is also essential to identify an internal “champion” to ensure the success of the computer validation effort. This person should be management-level within the company and have the authority to make key decisions and commit resources to the project. This person should also have the authority to set and enforce policy.

Another requirement for a successful validation is input from disparate functional areas of the company, usually accomplished by the formation of a validation committee. Within this committee, all affected departments must be represented, including IT and quality assurance. All participants must be clearly identified and held accountable to the objectives of the group.

Finally, hire a consultant! This may be costly; however, the project is large, complex and dynamic. It is my opinion that the best way to get started is with the help of an experienced consultant. Our project was nearly 100% dependent on external help at the beginning. However, we have gained experience and confidence and expect to be completely self-sufficient by mid-2001.

Phase 2: Develop SOPs To Address Operation and Maintenance of the Data Servers and Network
Even before the advent of Part 11, most companies understood the need for reliable information backup strategies, the value of a disaster recovery plan and the need for system security. It is the first task of the validation committee to identify all SOPs currently in place that relate to a company’s computer systems. Specifically, the following areas must be addressed:

• Computer System Network Backup and Recovery

• Computer System Data Archive

• Computer System Disaster Recovery

• Computer System Security

• Computer System User Administration

• Computer System Server/Network Monitoring

• Computer System Media Lifecycle

• Computer System Maintenance

As stated, some of these SOPs may already exist. If so, they should be reviewed by the committee and re-evaluated as to their relevance to current and expected practices. If any SOP is out of date or absent, it must be revised or retired and replaced. Computer system SOPs must not only be written, they must also be followed. Regulatory compliance is not satisfied by a well-written SOP; it is the job of the computer software validation specialist to ensure that day-to-day activities are consistent with the SOPs once they are implemented.

Phase 3: Validation System Development
At this point, a validation program must be formally established through a series of SOPs. It would be unusual for pre-existing SOPs to adequately address all aspects of validation system development, although some current SOPs (change control, inventories, etc.) may already be in use. A consultant can be a valuable resource for this phase, providing sample industry standard validation practices that can serve as baseline documents. It is then the task of the validation committee to modify these baseline procedures into detailed practices and procedures that are functional for their specific company. The following SOPs must be written for a successful validation system.

• Computer System Validation Policy

• Computer System Validation Program

• Computer System Change Control Policy

• Development of Computer System Requirements Documentation

• Development of Computer System Design Documentation

• Development of Computer System Test Documentation

• Computer System Configuration Management Plan

• Computer System Software and Hardware Inventory

• Computer System Environments

• Computer System Vendor Evaluation

Phase 4: Conduct a “Gap” Analysis
Once all the policy statements and SOPs are in place, it is necessary to conduct a “gap” analysis. The purpose of this exercise is to represent visually all system validation requirements. Draw a grid with the developed requirements along the ordinate and the individual computer systems along the abscissa. Physically test each system according to the requirements. Any computer system that does not meet one or more of the requirements of the validation program must be considered a “gap.” Gaps require remediation. Compliance only exists when there are no gaps.

Before we look at specific required SOP elements, it is necessary to define the software life cycle and categories of software. These definitions are fundamental to the validation effort.

Software Life Cycle
The graphical representation below is a waterfall model. (There are other acceptable models, but this one, in my opinion, is the simplest and most effective.) The software life cycle is based on the concept that software moves through a series of steps: it is born, it is tested against specs, it is maintained and it is finally retired. The waterfall model depicts this as a series of successive events. At every step, there is documentation to verify compliance.

Categories of Software
According to information presented at the Good Automated Manufacturing Practices (GAMP) ’96 conference, there are five categories of software. Each category has its own validation requirements. Table 2 (in the print version) provides an example of each category.

Computer Validation Policy
The computer validation policy is a high-level SOP that spells out in very general terms the goals of the validation program. An analogy is the corporate mission statement. Most companies have a statement that identifies broad goals and a level of commitment required of each employee of the company. The computer validation policy is similar except that its scope is limited to computer validation.

The following is an example of a computer validation policy for an analytical testing laboratory. It is important to note that the system life cycle features prominently in this policy. This is a foundation concept, around which the rest of the validation program is built.

“To support our goal of establishing ourselves as a premier supplier of analytical laboratory services, XXX shall develop and maintain standards and procedures whereby all computer systems in the company shall be implemented and maintained in a validated state according to FDA computer systems validation guidelines. It shall be the policy of XXX that validation of computer systems used to generate, manipulate, store or transmit data related to all regulated products or services shall follow a System Life Cycle (SLC) approach. This approach shall include documentation of computer system requirements and design specifications, thorough and documented testing of the computer system for compliance, and documented procedures to ensure consistent operation and maintenance of the system in a validated state until it is retired.”

The computer system validation program is another core SOP. This document also has a high-level mission statement. An example is given below:

“At its most basic level, validation is the demonstration of control through documented evidence during development and routine operation of a computer system. This control provides a high degree of assurance that a computer system will consistently yield a product or result meeting its predetermined specification and quality attributes. The process by which computer systems are brought into a validated state and then maintained in that validated state is the facilities validation program.”

Following this general statement, the computer system validation program SOP should detail specific actions to be taken to bring the facility into compliance. The first step, the procedure development phase, sets in stone all the elements necessary for the validation program. There are two distinct types of supporting SOPs required: (1) procedures for the operation and maintenance of the data servers and network, and (2) computer validation procedures. Development can be a time- and resource-consuming task, as it typically requires the efforts of the validation committee as well as help from an external consultant, over multiple iterations of each SOP, until the SOPs reflect the needs of each department.

Once policy SOPs have been developed, it is necessary to conduct a system inventory of all new and legacy systems. Assign a unique number to identify each computer system. Inventory each system and enter the records into a database. All information about the system will be recorded, including hardware configuration such as hard drive size, CPU clock speed and amount of random access memory, as well as a detailed inventory of the software on the system, including operating system version and build number. All new systems records should also include the installation dates of each component.

Once the inventory is complete, a gap analysis can be conducted to identify discrepancies between requirements (the validation program) and what has actually been done for each computer system. Once the gap analysis is completed, the remediation can begin, based upon the remaining elements in the validation program.

Requirements Phase: A requirements definition must be written for each system to identify specific operating and use requirements for the computer system. Requirements are documented and approved by management. The level of detail should be sufficient to support the design phase, commensurate with the GAMP ’96 complexity model. In other words, once the requirements are defined, they will be used as the basis of the design phase. The testing phase will assure that all requirements elements have been accounted for in the design phase.

During the requirements phase, stakeholders from each department that may ultimately use the system meet to discuss features of importance to their respective groups. For example, consider a custom temperature-logging application: QA may be interested in the calibration features of the application; operations may be interested in the ease of use while management may be interested in the initial cost and cost of operation. Once again, it is imperative that all groups are represented and all requirements are defined in this phase.

Design Phase: The design phase follows the requirements phase. The purpose is to assure that each element defined in the requirements phase is addressed. Level of detail is commensurate with the GAMP ’96 complexity model, which states, for example, that there is a difference between commercial off-the-shelf (COTS) software and a fully customized system: the former requires much less validation than the latter.

Implementation Phase: During the implementation phase all elements of the system, as defined in the design phase, are brought together. Elements may include COTS or custom code, or both. The product is a fully functioning piece of software that meets the original requirements.

Testing Phase: During this phase, the computer system is tested against specifications in the requirements definition phase. Tests are structured to provide traceability to both design and requirements documentation. Testing has three elements:

• Installation Testing – e.g., environment, power, plumbing

• Operational Testing – e.g., each individual function

• Performance Testing – e.g., maximum users, maximum data flow

Once testing is complete (successful) and the system is put into production, it enters a new phase: routine operation and maintenance. During this phase, the IT department must provide support and consultation to end-users. A possible outcome of this interaction may be maintenance. If so, all maintenance must be performed in a very controlled manner, under the conditions of the change control SOP. Any changes to the system inventory would also be updated at that time.

Finally, there is a decommissioning phase. At some point, it becomes easier to replace rather than maintain the current system. Starting over can be as simple as a new version/upgrade of currently used software or it can be as radical as replacement of the current system with that of a competing vendor. In any case, all data is archived and/or migrated to the new system. The old system is then removed from operation and a full audit trail of the dates and reasons for decommissioning is kept.

Change Control: The final SOP in the validation program defines how changes to a validated computer system are managed and documented. Changes are tested on a non-production system before they are implemented on the target system. The computer systems validation specialist must evaluate the impact of the change on the validation system. If it is significant change, revalidation may be required. Minor changes may require only documentation.

It is my opinion that a custom database application is the best way to implement change control. This system would include the following steps, each designed to demonstrate authorization and provide a documentation trail:

• Initiation – Anyone within the company can identify, recommend or initiate a possible change

• Acknowledgement – IT acknowledges receipt of the initiation (by e-mail, for convenience)

• Pre-approval – IT reviews the request, evaluates initial feasibility

• Implementation – IT executes the change

• Resolution – IT documents resolution of the problem/ change

• Testing – Demonstration of compliance and documentation of results

• Final approval – Acknowledgement of the action/resolution by the initiator, network administrator and the computer software validation specialist

• Update – Manual entry to system inventories reflecting the changes

• Audit – Performed by the computer software validation specialist

This article has focused on the validation requirement of Part 11, specifically, the high-level procedural SOPs that make up an effective validation program. Future articles will address specific objectives of the requirements, design and testing SOPs, as well as specific requirements of the operation and maintenance of the data servers and network.

Validation Requirements

This article is the third in a series of articles on compliance with the electronic signatures/electronic records rule found in 21CFR11. The previous articles summarized the requirements of Part 11 and specifically looked at the high-level, policy SOPs necessary to satisfy the validation requirement as well as requirements and design documentation.

This article will also focus on the validation requirement of Part 11. Here we will look at the specific elements necessary to meet the validation requirements for each computer system for test documentation.


Test Documentation
Following a System Life Cycle model, test documentation is developed based on the requirements and system functionality as defined in the system requirements documentation. The test documentation is used to verify that each requirement and function defined in the requirements documentation has been implemented in the design of the system.

Test documentation covers both hardware and software. The testing of the system is generally divided into three sections: Installation testing verifies that the physical installation of the system meets the defined requirements; Operations testing verifies that the system performs the defined system functionality; Performance testing verifies that the system will operate at the extreme boundaries of limits of the requirements and functionality, i.e., maximum volume and system stress. Installation testing and some form of operational testing are performed on all systems, while Performance testing is used for scalable systems and custom (categories 4 and 5) systems.

First, we must discuss the guidelines for the development of test documentation, defining how to write test cases and what tests are required for each complexity category model. Then, we will define how to document the execution of the test cases.

The guidelines presented in this section for the development of testing documentation shall follow the complexity model presented in Table 1 (p. 54).

Regardless of the complexity of the system, the following sections are required in any testing document.

Header and Footer: The header and footer should follow the format generally used in company SOP documents. For example, headers usually contain standard elements (company name), document type ("Requirements Document," for example), and title of the document ( "Requirements Documentation for LIMS version 2.5.") The footer usually contains at a minimum the page number ("Page 5 of 35.")

Approvals: All requirements documents shall have an approvals section where responsible persons will sign. I would suggest the following persons: the author of the document, the computer systems validation specialist and a member from IT.

Introduction: The introduction is a brief statement of what the system is, what the system does and where it is to be located.

Ownership: The ownership section is a statement identifying the owner of the system. The statement of ownership is written in a generic sense, identifying the department that owns the system and the department manager as the responsible person.

Overview: The overview is a detailed description of the system, indicating what the system is expected to do and how it fits into the operation of the department. If the system described in the requirements document is a replacement for an existing system, a brief description of the current system should be included. Enough detail should be included in this overview to give the reader an understanding of the system and what it does without going into discrete functions.


General Instructions to Testers
This section defines the procedures and documentation practices to be followed when executing the test cases. A further explanation of these procedures and practices are presented later in this document.

Discrepancy Reports: This section defines the procedures to be followed when the actual results of the test do not match the expected results.

Signature Log: This section is used to identify all personnel participating in the execution of the test cases. The person’s printed name, full signature and initials are recorded at the beginning of the execution of the test cases.

References: This section identifies the appropriate reference documents pertinent to the execution of the test cases. These documents shall include the SOP, the appropriate requirements documentation, and the appropriate design documentation.

Prerequisite Documentation: This section lists the validation documentation such as the requirements documentation and the design documentation that is to be in place before the execution of the test cases. The first test case shall be verification that these prerequisites have been met.

Test Equipment Log: This section is a log in which all calibrated test and measuring equipment used during the execution of the test cases is logged.

Test Cases: This section presents the test cases used to verify that the requirements and functions defined in the requirements documentation have been met. Each test case shall test one requirement or function of the system. In some cases, several closely related requirements or functions might be verified in one test case. Test cases shall be written in a landscape page setup using a table format and include the following elements:

• Objective – This is a brief statement indicating what requirement, function or module of the system the test case is intended to verify.

• System Prerequisite – This section describes any previously inputted data or other system status that must be in place to properly execute the test case. For example, when testing system security, users of various security levels may need to be in the system in order to test security levels at login.

• Input Specifications – This section defines any specific input data required to execute the test other than keystroke entries. This may include instrument test data files, barcode files, etc. A specific data file may be identified or the file identified may be generic.

• Output Specifications – This section defines the expected output of the test case other than output to the monitor. The output may be identified as reports, data files, etc.

• Special Procedural Requirements – This section details any special considerations that may be required to successfully execute the test case.

• Test Procedure – The test procedure is setup in a table format with the following column headings:


Procedural Steps – This is a systematic series of instructions to be followed in the execution of the test. These steps should be sufficiently detailed as to allow the test to be duplicated by any qualified personnel without changing the outcome of the test.

Expected Result – For each procedural step, the expected outcome of that step should be defined. The defined outcome should be detailed enough to allow an unequivocal determination of the pass/fail status of the step.

Actual Result – This column is to be left blank and completed by the person executing the test when the step is executed. The actual result of the step is recorded at the time the test is executed.

Pass/Fail – This column is used to record the Pass/Fail status of the test by comparing the actual result to the expected result.

Tester Initials and Date

• Comments – This section is complete following execution of the test case and is used to record any discrepancies or details not captured elsewhere in the test script.

• Test Conclusion – This is an indication of the Pass/Fail status of the test case.

• Tester’s Signature – This section records the signature of the person executing the test case and date.

• Verification Signature – This section re-cords the signature of the person verify ing the test results and date.


Requirements Traceability
Each requirement and function defined or described in the requirements documentation shall be reflected by one or more test cases. Following completion of the test documentation, the requirements documentation shall be reviewed to ensure that each requirement is reflected in the test documentation. The section number of the test case that fulfils the requirement shall be recorded in the second cell of the table in the right margin of the page. This provides a cross-reference between the requirement and the test case and ensures that the requirements are being completely verified.

As requirements of the system change, test cases that no longer have an active requirement shall be voided, not deleted. To void a test case, delete the test but not the section number, then enter "VOID" in place of the text. This prevents sections from being renumbered after a deletion and invalidating the references in the requirements document. This also eliminates the potential for confusion caused by re-assigning a section number previously used for an unrelated design element.


Considerations for Developing Test Cases
Installation Testing
Hardware Installation Testing – Hardware installation test documentation provides a high degree of assurance that the hardware has been installed according to the vendor’s specifications and configured in accordance with the requirements and design documentation for the system. This may include access space, power supply/UPS, network communications, interconnecting wiring/ cabling, ambient temperature, ambient relative humidity and peripheral systems connections.

Software Installation Testing – Software installation test documentation also provides a high degree of assurance that the software has been installed according to the vendor’s specifications and configured in accordance with the requirements and design documentation for the system. Hardware installation testing must be performed before installation and testing software. Software installation testing applies to all software components that are a part of the system including operating system software, network and communications software, OEM software and custom software. It should also include virus checking, verification of required drive space, RAM space and drive configuration, software version numbers, security access for installation and operation, directory configuration, path modifications and any system parameter configuration.


Operational Testing
Operational test documentation provides documented evidence that the system fulfils the requirements and functions as defined on the requirements documentation. Each function described in the requirements documentation shall be tested independently.

When a function is defined with a specified range of inputs or range for a data field, that function shall be tested at each end of the range. For example, if the range of acceptable inputs is 1 to 5, the test case shall challenge the functions using inputs of 0, 1, 5 and 6, with 0 and 6 expected to fail.

Test cases shall also test to verify that illogical inputs are not accepted. For example, test cases shall challenge a date function with non-date inputs, or a numeric field with non-numeric characters.

For COTS applications, many times the vendor will supply the test cases. These may be used in lieu of test cases developed in-house. There shall be a documented review of the test cases provided by the vendor relative to the functional documentation to ensure that the vendor test cases are sufficient. For applications where vendor-supplied test cases are used, requirements for the various functions of the application shall not be required, provided there is documented evidence that the vendor has followed a validation methodology.


Performance Testing
Performance testing ensures that the system shall stand up to daily use. Test cases during performance testing shall verify that the system can function properly during times of high user input and high data throughput.

Performance testing is not always applicable. For systems with only a single user, stress on the system is inherently limited. Performance testing is usually executed on complex systems with multiple inputs and outputs as well as network-based systems.


Test Execution
Before the start of testing, all personnel participating in the execution shall enter their names, signatures and initials in the signature log of the test documentation.

Once execution of a test case is started, that test case must be completed before moving to the next test case. An exception to this would be if the test case fails, the failure is noted and the next test case is started. Execution of the entire set of test cases does not have to be completed in one sitting, though once testing begins, the systems may not be altered. Any failed tests shall be recorded and testing shall continue unless the failure prevents continuation. If testing must be discontinued in order to correct any issues in the system, then all tests must be re-executed.

As test cases are executed, information shall be recorded neatly and legibly in black ink. Sign-off and dating of the test case shall occur on the day that the test case was executed. Mistakes made during execution of the test cases shall be corrected using a single strikethrough, so as not to obscure the original data. Any corrections made in this manner shall be initialed and dated by the person making the correction.

Errors in the test script shall be corrected using a single strikethrough so as not to obscure the original data. Any corrections made in this manner shall be initialed and dated by the person making the correction. Any corrections made to the test case during execution shall be justified in the comments section of the test case.

Completed test forms shall not contain any blank spots where information might be entered. If an item does not apply to the current test, the tester should fill in a ‘N/A’ followed by an initial and date. Completed tests are reviewed and approved by the Computer Systems Validation Specialist, or designee, who signs and dates the bottom of each approved test page.

Test Failures and Discrepancy Reports
Results of tests that do not match the expected results shall be considered failures. The failure of a single step of the test case shall force the failure of the test case. However, if a step in the test case fails, execution of the test case shall continue unless the failure prevents completion of the test case.

Errors in the test case that would result in test case failure if left alone may be corrected as noted above. This correction must be justified in the comments section of the test case. Steps in the test case where the expected result is in error shall not be considered test failures if corrected. Test failures shall be noted in the test case and documented on a test discrepancy form. The form is then logged to facilitate tracking of errors during system testing.

Upon resolution of the failure, the cause of the failure is examined with respect to the failed test case and any similar test cases. All test cases associated with, or similar to, the resolved failed test case shall be reviewed to determine the extent of re-testing required. This re-testing, commonly referred to as regression testing, shall verify that the resolution of the failed test has not created adverse effects on areas of the system already tested. The analysis of the testing shall be documented to justify the extent of the regression testing.

Regression testing shall be executed using new copies of the original test script to ensure that the requirement of the system is still being met. In some instances, resolution of the failed test requires extensive redevelopment of the system. In these cases, a new test case must be developed. In either case, the failed test shall be annotated to indicate the tests executed to demonstrate resolution. The additional tests shall be attached to the discrepancy report. This provides a paper trail from the failed test case, to the discrepancy report and finally to the repeated test cases.

Test Documentation by Complexity Model

Test documentation varies with complexity category. Com-plexity categories are defined in Table 1 above.

Category 1 – Operating Systems: Category 1 systems are local operating systems and network systems. These systems provide the backbone needed by all other systems to operate. Due to widespread use of these applications, they do not need to be tested directly. As these systems are the base of other applications, they are indirectly tested during the testing of other applications.

Category 2 – Smart Instruments: Category 2 systems shall be tested following the requirements and functions listed in the requirements documentation. All sections of the testing document as defined in the section "General Consideration for Developing Test Cases" listed above shall be included in the test document for Category 2 systems. Installation and Operational Testing shall be executed. The complexity of the test cases should be commensurate with the complexity of the system. Performance Testing is not required.

Category 3 – COTS Applications: All functions and operations embedded by the manufacturer of the COTS do not need to be tested. Only those functions and operations used by the applications developed in-house require testing.

Category 3 systems shall be tested following the requirements and functions listed in the requirements documentation. All sections of the testing document as defined in the section "General Consideration for Developing Test Cases" listed above shall be included in the test document for Category 3 systems. Installation and Operational Testing shall be executed. The complexity of the test cases should be commensurate with the complexity of the system. Performance Testing is not required.

Category 4 – Configurable Software Systems: Category 4 systems shall be tested following the requirements and functions listed in the requirements documentation. All sections of the testing document as defined in the section "General Consideration for Developing Test Cases" listed above shall be included in the test document for Category 2 systems. Installation and Operational Testing shall be executed. The complexity of the test cases should be commensurate with the complexity of the system. Performance Testing should be considered if the system shares data on a network.

Category 5 – Fully Custom Systems: Category 5 systems shall be tested following the requirements and functions listed in the requirements documentation. All sections of the testing document as defined in the section "General Consideration for Developing Test Cases" listed above shall be included in the test document for Category 5 systems. Installation, Opera-tional Testing and Performance Testing shall be executed. The complexity of the test cases should be commensurate with the complexity of the system.


Following a System Life Cycle model, test documentation verifies that all requirements have been properly met in the design phase of software development. Future articles will follow the SLC model into the next phase of software validation: change control.