Validation (drug manufacture)

In the pharmaceutical, for medical device, food, blood products, biological products, tissue, establishments, clinical trials conducting institutions, validation is a process of establishing documentary evidence demonstrating that a procedure, process, or activity carried out in production or testing maintains the desired level of compliance at all stages. In Pharma Industry it is very important apart from final testing and compliance of product with standard that the process adapted to produce itself must assure that process will consistently produce the expected results.[1] Here the desired results are established in terms of specifications for out come of the process. Qualification of systems and equipment is therefore a part of process of validation. It is a requirement of food and drug, pharmaceutical regulating agencies like FDA's good manufacturing practices guidelines. Since a wide variety of procedures, processes, and activities need to be validated, the field of validation is divided into a number of subsections including the following:

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

History

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

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

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

Reasons for validation

FDA, or any other food and drugs regulatory agencies around globe not only ask for a product that meets its specification but they do ask for a process, procedures, intermediate stages of inspections, testing, adapted during manufacturing are designed such that when they are adapted they produce consistently similar, reproducible, desired results which meets the quality standard of product being manufactured, such procedures are developed through the process of validation. This is to maintain and assuring higher degree of quality of food and drug products. Validation is "Establishing documented evidence that provides a high degree of assurance that a specific process will consistently produce a product meeting its pre-determined specifications and quality attributes.".[5] A properly designed system will provide a high degree of assurance that every step, process, and change has been properly evaluated before its implementation. Testing a sample of a final product is not considered sufficient evidence that every product within a batch meets the required specification

Validation Master Plan

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

The validation process

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

The validation scope, boundaries and responsibilities for each process or groups of similar processes or similar equipment's must be documented and approved in a validation plan. These documents, terms and references for the protocol authors are for use in setting the scope of their protocols. It must be based on a Validation Risk Assessment (VRA) to ensure that the scope of validation being authorised is appropriate for the complexity and importance of the equipment or process under validation. Within the references given in the VP the protocol authors must ensure that all aspects of the process or equipment under qualification; that may affect the efficacy, quality and or records of the product are properly qualified. Qualification includes the following steps:

There are instances when it is more expedient and efficient to transfer some tests or inspections from the IQ to the OQ, or from the OQ to the PQ. This is allowed for in the regulations, provided that a clear and approved justification is documented in the Validation Plan (VP).

Figure 2: OPQ Validation Process (adapted from the typical V-Model)

This combined testing of OQ and PQ phases is sanctioned by the European Commission Enterprise Directorate-General within ‘Annex 15 to the EU Guide to Good Manufacturing Practice guide’ (2001, p. 6) which states that:

"Although PQ is described as a separate activity, it may in some cases be appropriate to perform it in conjunction with OQ."

Computer System Validation

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

Weichel (2004) recently found that over twenty warning letters issued by the FDA to pharmaceutical companies specifically cited problems in Computer System Validation between 1997 and 2001.[9]

Probably the best known industry guidance available is the GAMP Guide, now in its fifth edition and known as GAMP5 published by ISPE (2008).[10] This guidance gives practical advice on how to satisfy regulatory requirements.

Scope of Computer Validation

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

Risk Based Approach To Computer Validation

In recent years, a risk-based approach has been adopted within the industry, where the testing of computer systems (emphasis on finding problems) is wide-ranging and documented but not heavily evidenced (i.e. hundreds of screen prints are not gathered during testing). Annex 11 states "Risk management should be applied throughout the lifecycle of the computerised system taking into account patient safety, data integrity and product quality. As part of a risk management system, decisions on the extent of validation and data integrity controls should be based on a justified and documented risk assessment of the computerised system."

The subsequent validation or verification of computer systems targets only the "GxP critical" requirements of computer systems. Evidence (e.g. screen prints) is gathered to document the validation exercise. In this way it is assured that systems are thoroughly tested, and that validation and documentation of the "GxP critical" aspects is performed in a risk-based manner, optimizing effort and ensuring that computer system's fitness for purpose is demonstrated.

The overall risk posed by a computer system is now generally considered to be a function of system complexity, patient/product impact, and pedigree (Configurable-Off-The-Shelf or Custom-written for a certain purpose). A lower risk system should merit a less in-depth specification/testing/validation approach. (e.g. The documentation surrounding a spreadsheet containing a simple but "GxP" critical calculation should not match that of a Chromatography Data System with 20 Instruments)

Determination of a "GxP critical" requirement for a computer system is subjective, and the definition needs to be tailored to the organisation involved. However in general a "GxP" requirement may be considered to be a requirement which leads to the development/configuration of a computer function which has a direct impact on patient safety, the pharmaceutical product being processed, or has been developed/configured to meet a regulatory requirement. In addition if a function has a direct impact on GxP data (security or integrity) it may be considered "GxP critical".

Product life cycle approach in validation

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

See also

References

  1. ↑ Validation definition and FDA, Regulatory agencies guidelines requirement Accessed 27 Feb 2014.
  2. ↑ Agalloco, J. (1995). "Validation: an unconventional review and reinvention". Validation: an unconventional review and reinvention 49 (4): 175–179.
  3. ↑ Hoffmann, A., Kahny-Simonius, J., Plattner, M., Schmidli-Vckovski, V., & Kronseder, C. (1998), 'Computer system validation: An overview of official requirements and standards', Pharmaceutica Acta Helvetiae, vol. 72, no. 6, pp. 317–325.
  4. ↑ Leveson, N. G. & Turner, C. S. (1993), 'An investigation of the Therac-25 accidents', Computer, vol. 26, no. 7, pp. 18–41.
  5. ↑ FDA (1987). "Guidelines on General Principles of Process Validation".
  6. ↑ FDA (1983). "Guide to Inspection of Computerised Systems (The Blue Book)". US Food and Drug Administration, Maryland, USA.
  7. ↑ International Organization for Standardization, Geneva, Switzerland (1994). "ISO 8402:1994: Quality management and quality assurance—Vocabulary".
  8. ↑ "General Principles of Software Validation; Final Guidance for Industry and FDA Staff". US FDA. 2002. Retrieved February 27, 2013.
  9. ↑ Weichel, P. (2004). "Survey of Published FDA Warning Letters with Comment on Part 11 (21 CFR Part 11)". Journal of Validation Technology 11 (1): 62–66.
  10. ↑ ISPE (2008). "GAMP5: Risk Based Approach to Computer Compliance". International Society for Pharmaceutical Engineers, Tampa, FL.
  11. ↑ PIC/S (2004). "Good Practices for Computerised Systems in Regulated "GXP" Environments, Report PI 011-2". Pharmaceutical Inspection Convention, Geneva.
  12. ↑ Smith, H. G. (2001). "Considerations for Improving Software Validation, Securing better assurance for less cost". Journal of Validation Technology 7 (2): 150–157.
  13. ↑ Tracy, D. S. & Nash, R. A. (2002). "A Validation Approach for Laboratory Information Management Systems". Journal of Validation Technology 9 (1): 6–14.
  14. ↑ Lucas, I. (2003). "Testing Times in Computer Validation". Journal of Validation Technology 9 (2): 153–161.
  15. ↑ Balogh, M. & Corbin, V. (2005). "Taming the Regulatory Beast: Regulation vs Functionalism". Pharmaceutical Technology Europe 17 (3): 55–58.

Sources