Validation Guidelines 3rd Party

Validation of Pharmaceutical Process Equipment By Donald M.
Rosendale Validation Group Manager Vector Corporation

PREFACE: Welcome to this session - Practical techniques for successful validation of pharmaceutical process equipment. We hope you find this material to be of some assistance during the validation of your particular process equipment. Obviously, one cannot prepare an example for every case and or situation, however, the methods described in this session can be modified to reflect the needs of a particular type of equipment. The thought processes and methodology for validation remain the same. We would like this session to be as helpful as possible. If you have specific questions as we progress, please feel free to ask questions during the session. We encourage participation and will be asking for your input during this session - your comments are appreciated! 1. Introduction Validation, as it is known today, has developed from the need to maintain quality, consistency, and above all, public safety. Validation is a rapidly growing and evolving subject. This evolution stems from technologys astonishing growth rate, especially in terms of what is available in computer hardware and software. Over the past 15 years, machine automation and process control through the use of a computer has caused additional concerns relating the validation of the processing system. Today, the computer is used for everything from controlling the process, to automatically providing batch reports, and providing automated quality control. The foundation of validation, the methodology behind validation, and the need for validation will likely remain a key aspect of the industry we work in. This session reflects the current industry trends and serves as an educational tool in our progressive industry. 2. Definitions and Key Terms These key terms are listed for your use in this session: FDA definitions of Validation 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. FDA Guideline General Principles of Validation, May 1987
__________________________________________________________________________________________________________
Practical techniques for successful validation of pharmaceutical process equipment Page 1 of 40
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. FDA Guideline General Principles of Validation, May 1987 The key idea is to provide a high level of documented evidence that the equipment and the process conform to a written standard. The level (or depth) is dictated by the complexity of the system, process, or equipment. The validation package must provide the necessary information and test procedures required to prove that the system and the process meet the specified requirements. IQ - Installation Qualification - Verification that the equipment/system is installed in a proper manner and that all of the devices are placed in an environment suitable for their intended operations. OQ - Operational Qualification - Verification that the equipment performs as expected throughout the intended range of use. PQ - Process Qualification- Verification that the system is repeatable and consistently producing a quality product. Protocol - A set of instructions that outline the organization of the Qualification Documents. The protocol specifies the type of tests required and the order in which the tests should be conducted.
3. Validation Life-Cycle Questions to consider: What does validation mean to the personnel in your company? What does validation mean to your vendor? Where does the responsibility lie for validation? - FDA , End user, or Vendor? Process Validation vs. Equipment Validation vs. Validation Plan? What is the difference between the three? Validation is a continuing and evolving process. The validation process extends from the very basic specifics (how each item works and interacts with another item) to a very broad theological and methodical investigation of how the system and processes perform. Its scope encompasses documentation, revision control, training, and maintenance of the system and process. Evidence of validation should be seen at the corporate level, and be reflected in the management structure. Validation is not just a set of procedures and rules to satisfy FDA, validation is a method for building and maintaining QUALITY. When Does Validation Begin? During the chemical development stage? When you are currently developing a process? When conducting clinical studies? Ideally, validation starts in the very beginning, in the laboratory. In the lab, scientists discover exactly how the product reacts, as well as the parameters that are required to produce such a product. They learn under what conditions the product fails or becomes unstable, unusable, and when its quality begins to suffer. Once the laboratory has
__________________________________________________________________________________________________________
established the boundary processing criteria, this information can then be used for establishing requirements for validation. When Does Validation End? After installation of the equipment? After the initial validation? After the first successful batch? Validation of a system never truly ends. Once a new system and process have been validated, the system still requires maintenance, periodic calibrations and adjustment. Therefore, the process [and consequently validation] is always under scrutiny and constant evaluation. Session 2 will discuss when revalidation is required and how it fits into a master validation protocol plan. Shown on the follow page is a simplified flowchart of a validation life cycle. This flowchart has been modified to show just one part of a project rather than the entire validation plan. The first step involved in validating a new process is to formulate a good definition of it. This means defining the following: What the process is Why is it needed What will it be used for How the elements of the system link together to perform the final process Once the process has been completely defined, equipment usually will be required to perform the actual processing of the product. This equipment will be collectively called The System. The system and its operations can then be identified and defined. Quality Checks The first check that must occur is to answer the question does the system meet the need of the process? A detailed examination of the system should be conducted. If for some reason the system does not meet the needs of the process, the system may need to be redefined. In some cases, it may become evident that the process should be redefined rather than the system. For instance, it may be more cost effective to execute the process using a different technology or technique. Thus the option does exist for redefining the process, if necessary. Validation begins with good up-front definition of the validation process. Typically, information is structured so that the Functional Requirement (Or User Requirement Specification [URS]) is in a top-level document.
__________________________________________________________________________________________________________
The chart above displays the ideal arrangement of documentation to tests. A good User Requirement Specification (sometimes referred to as a Functional Requirement) creates a clear definition of the job to be performed. Operational tests that encompass the performance of the overall system should be designed to guarantee the end pharmaceutical product meets or exceeds the designed intent of the drug. The Functional Specification describes the detailed operation of the equipment, from which an OQ test plan can be constructed. Ordinarily, the validation engineer uses the Functional Specifications as a guide to creating the necessary test plans for an operational qualification of the equipment. The Design Specification usually consists of the electrical schematics, part descriptions, and the detail required to construct the system. This information usually includes the Installation Qualification criteria required to adequately insure that the machine is being installed in an environment suitable for its use. (i.e. proper voltages, proper location classifications, etc.) Together, they represent the totality of information required to qualify the system and the processes.
__________________________________________________________________________________________________________
The Validation Validation Life Life Cycle Cycle The

START
DEFINE PROCESS
OPTIONAL
DEFINE THE SYSTEM
SYSTEM MEETS NEEDS OF PROCESS ? YES REDESIGN QUALIFY THE SYSTEM
NO
NO
SYSTEM MEETS REQIREMENTS ? YES QUALIFY PROCESS CONTINUED VALIDATION
__________________________________________________________________________________________________________
4. Defining the Validation Process One of the most important parts of the validation life cycle are the definition stages for the process and the system. Definition Phase The definition phase starts while a new product is being produced in a laboratory. As the product development progresses, the identification of critical process parameters become evident. Critical parameters are those process items that must be maintained to fulfill all of the elements required to maintain the quality of the product. To maintain these parameters, the equipment vendors must also be aware of the same critical process parameters for which the quality of the product depends. Critical process parameters must be transferred to the vendor as early as possible, preferably during the quoting stage of the project. This helps guarantee the purchase of a system that can perform the task as defined by the process as well as hold tolerances within the defined specifications. In communicating and identifying the critical parameter information up-front we can help reduce the overall cost of the upscale project. Also, this may help reduce lead times. This insures delivery of a system that will consistently reproduce high quality product. Importance of validated and validatable software One of the next key elements is to be addressed is system software and its validation. To ensure a successful validation, validated software is a must! Any software which is written, configured, installed, or used in any way to develop the operating process system needs to be validated. Software Overview: Software Definitions: Application software Application software is by definition, custom-written software designed to perform a specific function and/or purpose. Typically this software is written in a high level language such as C, Pascal, COBOL, or some other language. Thus, application software is not meant to include off the shelf commercial software. Configurable software Configurable software is off-the-shelf commercially available software that is written to easily customize it to the users process. With configurable software, large sections of code are automatically invoked or created without the need for highly specialized training of the persons performing the configuration. Examples of configurable software: Intellution FIX for Windows Rockwell Software RSView A-B PanelView Wonderware Programmable controller ladder logic
__________________________________________________________________________________________________________
The range of usage of the software will also determine the level of scrutiny required to verify its function. Windows and DOS, being programs with wide user bases and large man-hours of Mean Time Between Failures (MTBF) do not need extremely close scrutiny. However, applications and configured software written on these operating systems require a large amount of inspection prior to placing them into service. Obviously, the person who knows the most about the software is the programmer. Most validation and quality assurance people do not have a strong software background, so therefore there must be some software guidelines to look for in a validation. The key questions to ask are: Is the software development structured? This structure should be published and followed. What is the development cycle of the product? What is the development environment? Is it backed up? Is it secure? Is it maintained? Is there revision control of developed software? Is the development methodology comprehensive? Are there higher level language structures and standards? Are there Database structures and verification methods for those databases? Are there written test plans and evidence of test cycles? Are the testing procedures comprehensive? Are there written test programs (Stubs) to help with pre-testing? How comprehensive is factory testing? Are their tests documented? Change Control Are there software and hardware change control procedures? How long have they been in place? What level of change control is maintained? Do the people seem aware of the change control methods? Documentation Does the vendor have evidence of change control put into use? Do they have evidence of maintenance of the software and hardware? Is there a code management system? Is it followed? Code Review The vendor should be able to give an example of operating code, to show adherence to the change control procedures and documentation protocol outlined above. The vendor should have a written support plan There should be evidence of the support plan in operation Does the vendor have disaster and contingency plans?
__________________________________________________________________________________________________________
In addition to the basic two types of software presented above, special considerations should be made for concerning the source code, and the operating system that the software is going to run under. Arrangements may need to be made for auditing the source code if necessary. Source Code Source code is the uncompiled version of the software in question. For example, a program written in Pascal that a person can read and interpret is source code, whereas the compiled executable is inaccessible and therefore un-readable. Operating systems An operating system is the low level system code that makes the computer or computer system function. Examples are: Microsofts DOS IBMs OS/2 Microsoft Windows Microsoft Windows NT An operating system should be chosen which best meets the needs of the process. Shown below is a flowchart for a typical validation process:
The Validation Process
START
DEFINE FUNCTIONAL REQUIREMENTS OPTIONAL DEFINE FUNCTIONAL SPECIFICATIONS DESIGN FUNCTIONAL TEST PLANS QUALIFY SYSTEM IQ, OQ, PQ
REDESIGN
NO
SYSTEM MEETS SPECS ?
YES CONTINUED VALIDATION
__________________________________________________________________________________________________________
Functional test Plans The functional test plans lay out a plan to verify, test, and prove the system is installed, configured, and operating according to the requirements set forth by the functional specifications and functional requirements. These test plans are compiled into complete IQ, OQ, and PQ documents. These documents are then tested on the system. If the Tests Fail... If for whatever reason, the system did not pass these procedures, an examination is made of the requirements, specifications, and tests. This helps QA evaluate the system and narrows the focus of the troubleshooting exercise. A redesign of the system may become necessary to address the system failures. In the worst case, a change in Functional Specification may become necessary to address the problem. When the Tests Pass If the system performs as expected and all the specifications are met. a signoff of the Requirements, Specifications, Tests, and Test Results indicates to the governing authority that the system has been properly validated. The system then enters a phase of Continuing Validation. Maintaining validated status should be outlined in your companys Master Validation Protocol (MVP). Continued validation includes periodic checks, calibration, and scheduled maintenance. All of the maintenance operations should be documented in order to prove that the system is still performing within the requirements and specifications as outlined in the Functional Requirements and Functional Specifications. Use of the original test is recommended when performing maintenance on the system. Structure of Test Plans IQ and OQ The structure of the test plans has been evolving over the past 5 years. The current industry trend is to have a distinct Installation Qualification (IQ) section and then proceed to the Operational Qualification (OQ) section after the IQ has been completed.
__________________________________________________________________________________________________________
The IQ section handles the obvious installation criteria: Is the machine installed correctly? (plumb and level, in a room suited to the purpose) Are the utilities satisfactory for the equipment? (The utilities should be adequate to operate the equipment reliably, without straining any systems) Information should be available: The validation team should be identified in a validation team document Are the manuals in place and correct? Are the drawings up to date, and do they represent the actual installation? Are all the major pieces of equipment identified in the manual for ease of replacement Configuration of configurable devices should be recorded (switch settings, programming of recorders, etc.) Identification of manufacturer, model number and serial number of critical equipment for any service that may be required Are all the product contact materials identified, and if necessary, verifiable? The IQ should have an approval signoff page indicating that the IQ procedure has been thoroughly reviewed and is ready for execution. There seems to be a push to have a separate IQ sign-off, that everything is in place and ready for the equipment operation. Practically, this has not been achievable in most initial installations. Either the drawings are marked up and not finalized, all utilities are not 100% available (such as chiller systems), or one or another major activity is not completed while the machine is being installed and commissioned (such as the room finishing and room air validation). Reasonable exceptions can be made and documented, the IQ signed off with exceptions, and the validation engineer can proceed with the OQ testing with these deficiencies in mind. The OQ may have its own sign-off to be completed before conducting the OQ plan, as seems to be the growing trend in Europe. However, one protocol approval covering both the IQ and OQ section approvals may also be used. OQ testing may very well find deficiencies in the system, both from a hardware standpoint and from a software view. These deficiencies can be addressed in the failures, and retesting procedures conducted after the fixes have been installed. After successful retesting, the final report can then be written. A single page sign-off is useful after the OQ to indicate that all matters of the system have been found to be operational.
__________________________________________________________________________________________________________
Revalidation Revalidation becomes necessary whenever the equipment requires or is given significant upgrades to its capabilities, or a key piece of the equipment is replaced. By maintaining a good equipment use and maintenance log, the revalidation of a piece of equipment can be compartmentalized to only the system or device to be repaired or replaced. Also, there should be a factory SOP (Standard Operating Procedure) in place to identify maintenance trigger items, in addition to the customary re-calibration scheduling. Maintenance Triggers Several triggers or indicators should be outlined in the MVP to aid in determining the frequency of re-testing. The following triggers are listed as an example: Loss of product quality Replacement of key components of the system Upgrades (software or hardware) Change in personnel Often, the original test plans can act as re-test procedures for the equipment after servicing. In others, a special test designed to challenge the installation is best. In the case of replacing a computer system, care should be taken to document that the system replacement has all the elements of hardware and software necessary and in place to run the system in the same manner as it was prior to the replacement. In other words, an examination of the software load (revision, file names and file sizes), operability, and retest of critical functions should be approved, test conducted, and test results approved prior to placing the equipment back into service. 5. Generating Functional Requirements The Functional Requirements document ( User Requirement Specifications in GAMP terminology URS) is used to define what is to be done. The process should be stated succinctly with little or no reference to actual specific devices. The following structure is a useful guideline: Purpose or Objective - The purpose of the document. To descibe the processes necessary to produce quality, marketable product. Audience - The intended readership of the document. This may specify that a certain level of knowledge is necessary in order to adequately understand the information in the document. Definitions - An abbreviations and definitions section is very helpful. Reference Documents - Provides supporting evidence to the document, if required. This could be lab test results, charts, or other information that may help explain the process. Details - Outlines the functional details of the process and what it does To briefly summarize, the Functional Requirements (or URS) document describes and defines what the system or process must do. It does not describe or define how it is to be accomplished. This shall be accomplished in the Functional Specifications.
__________________________________________________________________________________________________________
An example of a Functional Requirement (URS) technical page is listed below:

The process The Product being produced is an agglomeration of product Super X (50%) with ingredient Alpha Kappa (40%) moulded into the form of droplets of 10 mg. placed on a stainless holding tray. A 10% Alcohol solution serves to hold the product together until it is evaporated in the heat chamber during the crystalization phase that is produced in the Heat Oven system. A heat of 83 to 87 degrees C exposure for 2 minutes will successfully crystalize the material. A continuous process is desired which will produce product during an infinite production run. Ie., provision should be made for change of shifts. It is desired by Marketing to produce 10,000 units per day, with the capability for production of up to 25,000 units per day using 3 shifts. Operational Limitations Heat Time over 2 Minutes 15 Seconds will hyperatrophy the material into a useless structure which does not form the crystalline base combination after cooling. Heat time under 1 Minute 55 Seconds will not produce a thick enough shell, and will prematurely dissolve in the stomach (the combination is designed for dissolution in the small intestine.) Heats below 83 degrees C will not properly congeal the outer layer into a smooth case and will exhibit the same dissolution in Stomach Acid. Heats above 87 Degrees C will create a solid that will not dissolve in the human digestive system. Ideal Conditions A consistently excellent product was produced in clinical studies at a temperature of 85.2 C for 2 Minutes and 7 second exposures. Temperatures around this setpoint within .5 C did not seem to degrade this Ideal product. Hold times within +/- 5 seconds of this time produced consistently good product. Records The resultant process times and temperatures must be recorded and kept on file for 5 years after the product has been released.
6. Generating Functional Specifications Unlike the Functional Requirements, the Functional specifications state how the system is to accomplish the task as described in the Functional Requirements. It gets specific. The Functional Specification document usually contains: An Introduction, or Purpose Intended Audience Definitions Reference Documentation Mechanical Requirements and Specifications Electrical Requirements and Specifications Computer Requirements and Specifications Security Requirements and Specifications Its format should be consistent with the Functional Requirements document. Reference to system drawings, Piping and Instrumentation Drawing (P&ID), and, if necessary, facility layout drawings should also be included. As it is often said, A picture is worth a thousand words!
__________________________________________________________________________________________________________
Shown below is and example of the technical part of a very simple Functional Specifications document:
Functional Specification A processing line consisting of a stainless steel conveyor system with a thin insulating layer (to isolate the tablet temperature effects of a large mass of stainless) is loaded with 10 mg tablets and passed through an oven that is kept at the Ideal 85.2 C temperature required for the reaction. Loop 1 - Temperature Control The oven temperature is kept constant by a Steam valve actuated by a PLC operated PID Loop system. Input to the PID loop is via a 4 Point averaging RTD probe that spans the length of the Oven Bed. This RTD input is transmitted to the PLC via an RTD to 4-20 MA Conversion Module. Control of the Steam Valve is via an I/P actuated by a 4-20 MA signal from the PLC, provided by the PID control Loop. Input Steam specification is 15 PSI Saturated. The oven draws 30#/Hr steam when oven is operational. (There is little load variation in this process) The operator may adjust the oven temperature from 83 to 87 C. The machine shall power up with the setpoint of 85.2 C. Loop 2 - Dwell Control The time in the oven is set by a conveyor system speed servo that drives the conveyor through a gear set. The speed of the Servo motor is monitored by a tachometer and inputted to the PLC by a Tachometer Input Card. Dwell time is converted from the oven length (3 Feet). 1 revolution of the conveyor Servo motor is exactly 1 Foot of travel of the conveyor. The control of the conveyor speed is to read out in dwell time of the product inside the oven. Thus tachometer speed is converted into dwell time using the following formula: 3 Ft (Oven Length) Dwell Time (min) = ---------------------------------Speed of Conveyor (Ft/Min) The operator may adjust the dwell time between 1.916 Minutes and 2.25 Minutes. The control loop shall power up with the setpoint of 2.117 Minutes. Because of the need to log the information onto the LAN network, a computer-driven PLC system Operator interface was chosen for this job that has Automatic Data Acquisition Capabilities. Other Information The system will operate on 230 VAC 50Hz, 3 Phase. The equipment is to be mounted in a non-hazardous electrical classification. All equipment must be able to be operated at an ambient temperature of 25 C. The equipment is designed to run at 100% duty cycle, 24 hours a day. Equipment must conform to local codes and be certified for European CE approval. In additional, all validation support documentation will be written in French.
Based upon process parameters, the ranges and tolerances of the equipment operation shall be defined in the Functional Specification. Specific types of equipment, if required, would be outlined here. For instance, if a 486 66Mhz PC is required, then it should be specified. If it is not specified, an old 8088 machine could be used and the system wouldnt meet the specified requirements because it would be too slow! If a component of the system is critical to the system, or a particular type of component is desired, is must be specified. The Functional Specification document is very useful for describing to your vendor exactly what you want, and what will be required. Often times, if it is not known exactly what should be specified for a given application, the vendor is willing to work with you to develop or finalize the Functional Specifications. The accuracy of the Functional Specifications is critical to other documents or test plans that will be written around this document. It is important it receives proper reviews and acceptance prior to release.
__________________________________________________________________________________________________________
7. Methods of Identifying Process parameters Identifying process parameters for a given process is often not difficult, one can simply state all the physical aspects of the system! For instance, ambient temperature, internal temperature, external temperature, airflow, air pressure, altitude, relative humidity, compression, power absorption, wavelength, density, and particle size could all be valid process parameters. Only a limited few process parameters are normally considered process critical. These items should be identified so that they are monitored, controlled and/or recorded. Typically in the pharmaceutical environment, the issues concerning quality are the chemical and physical aspects of the product. These would include release times, shelf life, chemical stability, temperature stability, and appearance. Therefore, any process variables that effect the above would be identified as critical process parameters. Identifying critical process parameters Critical process parameters are defined as Those parameters that in any way effect the quality of the product. The term Quality may be defined to include the physical aspects of the finished product, such as its smoothness, that may not be part of the medicinal quality. If it can be shown or verified that a given change in a process parameter has no effect on the process or product, then it is not considered a Critical process parameter. Many times the process parameters are interrelated, and a change in one parameter directly effects or inversely effects another. The common practice in use today is to provide proof that the process parameters are not changed during the process or are maintained within a specified range. These parameters are documented in the functional specifications. Typically decision criteria is supported by lab reports and/or historical data on the process. Using the supplied example, we find that:
Ideal Conditions A consistently excellent product was produced in clinical studies at a temperature of 85.2 C for 2 Minutes and 7 second exposures. Temperatures around this setpoint within .5 C did not seem to degrade this Ideal product. Hold times within +/- 5 seconds of this time produced consistently good product. Thus, heat time and heat temperature are the two most important parameters in this process.
__________________________________________________________________________________________________________
For a Tablet coating process Critical process parameters are normally: Process Airflow, Temperature, Spray rate, Humidity, Pan speed, and Time. Airflow, humidity and temperature are interrelated process variables that directly effect the process by dictating the evaporative capacity of the system. The spray rate is also a critical process parameter. The spray rate would dictate what the required evaporative capacity of the system must be. The spray rate effects the finish of a tablet. If the coating of the tablets occur at too high a rate, the finish may exhibit an orange peel finish which is not desirable. Pan speed may not effect the chemical composition of the product but pan speed can effect the physical appearance of a coated tablet. A very fast pan speed could cause chipping, for instance. Identification of the critical process parameters can often be identified by asking the following questions: How do the process parameters relate to the chemistry of the product? Is there a mathematical process model? How do the process parameters effect the physical aspects of the product? What change would cause product degradation? Identifying tolerances Simply identifying the critical process parameters is not sufficient. Each critical process parameter will more than likely have an operating tolerance. Both the hardware and the process will have tolerances that need to be identified. For instance, a Heat exchanger may have a controllable range from 0 to 212F, but the quality of the product is reduced when the temperature falls below 100F or rises above 185F. Thus, from a process standpoint, 100 to 185F becomes the operating range. This operating range can then be considered to be the worst case. Documentation [such as a batch report] should indicate that the process was maintained between 100 and 185F. Alarms and Interlocks may also be specified to help maintain this temperature. When developing and identifying tolerances, keep in mind the following: Develop operating tolerances for the process Determine the operating tolerance for the equipment Determine the process limits that are required to maintain the quality of the product Verify and document this range during the validation process
__________________________________________________________________________________________________________
8. Vendor Audits One area of concern with the purchase of new equipment is vendor selection. One must ask the question Is the vendor prepared to offer systems which have been validated or are validatable. The primary concern of pharmaceutical processors is the ability of the vendor to demonstrate that the software and hardware design has been developed and tested under written guidelines. What to look for in an audit: Organization of business - Separate QC unit Look for vendors that have a separate quality control department or quality inspector. This person or department should have the authority to reject components and have direct control over when a product will or will not ship based on its quality. Evidence of Document Revision Control Evidence of document revision control would include a written procedure for how drawings, software, contracts, test plans, and specifications are updated. Looking at the documented history of a particular item should give clear indication as to the quality of the document revision control system. Evidence of compliance with written software procedures Software is often times the most critical point of an audit. The compliance of written software procedures for how software is written, maintained, and updated are very critical. Documented history of compliance of these procedures should be reviewed. Off site storage of Critical operating software & documentation A backup and storage procedure for software and documentation should exist. Backup is required in case of a natural catastrophe. Evaluate engineering experience and applicability Qualifications of the technical personnel should be reviewed, as well as an evaluation of the experience of the individuals. The credentials for key positions should also be reviewed. Look for and evaluate employee training Consideration should be given to the continuing education of personnel. For example, if a job description states a requirement for special training, such as how to follow a software procedure, the individual should have in their personnel file a record of successfully completing this training.
__________________________________________________________________________________________________________
Conducting an audit of a vendor- Initial Considerations: Publish an agenda - From a vendor standpoint, an audit can be run much more smoothly if the vendor knows your objectives. The agenda can be in an outline form, indicating what the topics of discussion will be.
Make sure vendor agrees to agenda - In order to make sure the required personnel will be available for the audit, it is important that the vendor agrees with the agenda. This is also good business practice. Provide written report after the audit- After the audit is complete, a letter of results should be sent to the vendor. The results should list the items of concern/unacceptable practices. Also, be sure to include those practices that were done especially well. Ask for a company history - In evaluating quality and longevity, often times the companys history and growth can be used as an indication. For future service and support, one must have a certain comfort level that the company will be able to support you for the long-term. Ask for a financial overview - In evaluating the risk of doing business with a particular vendor, a financial statement, yearly report, or other documented evidence should be reviewed. If the company is publicly held, the yearly report can be acquired easily. If the company is privately held, one can look at the history and growth of the company. Project Overview - The customer should be aware of the current or future projects. Many times an audit can be directed towards a specific project, therefore, a project overview can yield an indication as to what specifically needs to be reviewed.
9. Vendor validation support Validation support can come from the vendor in several forms: Vendor Manuals Operator training manuals Operational documents Functional Specifications Receiving validation information from the vendor can present several significant advantages: Familiarity with the equipment - Initially, the vendor is more familiar with the equipment and its limitations. Therefore, the equipment validation process can usually be accelerated be using vendor protocols. Validatable system - Reviewing the vendors validation documentation up-front helps verify that your equipment vendor is prepared to provide a fully documented and validatable system.
__________________________________________________________________________________________________________
Documentation - Documents that are typically available from the vendor are the Installation Qualification, Operational Qualification, Calibration procedures and documents, Cleaning procedures, scheduled maintenance documents, Functional Requirements, and Functional Specifications. These documents help define the longterm maintenance that the machine requires. System qualification - Receiving validation documentation from the vendor provides a mean of qualifying the system with the vendor. For example, when executing the Installation Qualification, both the vendor who may be performing the qualification, and the purchaser of the equipment would sign off or approve each part of the qualification. This duality provides a good method of checking and verifying that the system is installed as stated. Staffing - Pursuing validation documents from the vendor can reduce internal costs by reducing the staffing requirements for creating and writing the validation documents. Additional benefits The equipment can go into production sooner Problems during the startup of the system can be minimized due to the ability to qualify the equipment before shipment The Vendor may be able to provide additional engineering services. Those services provide detailed installation drawings, electrical installation drawings, ductwork drawings, and facility layout drawings. All of these documents and services help reduce installation time and can be used as part of the validation package to help qualify the installed system.
10. The Structure of the Validation Documentation The Validation Plan The Validation Plan is the roadmap of the validation exercise. Its principle function is to identify exactly what is being validated, and how that validation is to take place. It is also the catch-basin of all of the information necessary to define the machine, software, and hardware terminology, schematics, diagrams, etc. One of its goals is to act as the index to point out where to look for information regarding the machine and the validation. The other main goal of the Validation Plan is to identify how the tests have been structured and include an explanation of how the test plans fulfill the FDAs requirement for validation. An example of a Validation Plan will be shown later, after some other topics have been discussed.
__________________________________________________________________________________________________________
Identifying the Validation Team The Validation Team should be comprised of a set of individuals that is capable of verifying that the test protocol and final machine acceptance testing is done in an acceptable manner. In some organizations, this team is comprised totally of in-house personnel, however, this need not always be the case. In-House and Vendor Teams In many instances, the vendor may act as part of the Validation Team insofar as to provide detail information on the machines operation that the end-user might not be immediately aware of. This aspect in itself may save the end-user months of R&D testing and trial and error that would otherwise be spent learning the system operation. In-House and Sub-Contractor Teams The Team may also consist of sub-contractors, and specialists whose job is to do validation on a professional consulting basis. Care should be taken to qualify the subcontractor properly for the machine validation being requested. Does the subcontractor have previous experience in the field? Are there a list of references to call to verify customer satisfaction? Is their pay based on an hourly rate or at least partially based on protocol acceptance? Exclusively In-House Teams The Team may also consist of totally in-house employees. In this scenario, care must be taken to have team membership available throughout many disciplines. Be sure that the technical portion of the machines operation is covered by a knowledgeable person or persons within the group. If several disciplines are involved, identify each area and make sure that all the bases are covered. In-house teams are especially attractive where the machine is of proprietary design or the end product is generated under a cloak of confidentiality.
Team Construction - The Minimum Constraints In any case, the team must consist of enough team members to guarantee impartiality, (usually at e l ast 2 or 3 people). The team should also have enough technical talent to identify all areas that are to be validated. If an area is lacking, such as a production specialist, the team should recruit an operator or production supervisor to be a part of the approval team. If vendors or sub-contractors are part of the team, ask to see the credentials of those individuals on the team. Of course, the credentials of your own organizations people must also be duly recognized and recorded!
__________________________________________________________________________________________________________
The Validation Team Document A necessary conclusion of the creation of the team is a single document which: Clearly identifies the Validation Project Clearly identifies each individual and their role on the team. This should include the persons printed name, Job Title, and role within the validation group if it is not implied within the persons job title. Provides a place for a written signature, initials and date for each member of the team. Attachments may be included or referenced to back up the persons legitimacy for selection by the team (diploma, transcript, record of training, resume, etc.). Credentials may also be referenced as on file within the organization. In any case, it is important to be able to access this information during an audit. 11. IQ/OQ and PQ Installation Qualification (IQ) IQ verifies that the equipment has been installed in accordance with the manufacturers recommendations in a proper manner and that all of the devices are placed in an environment suitable for their intended purpose. Specification Information The IQ should build on the list of specification documents as outlined in the Validation Plan. From this list of specifications and list of critical components, several checklists are generated. There are several reference documents that help define the IQ parameters, they are: An accurate P&ID (Process and Instrumentation Diagram). The process engineer will be able to identify the critical parts of the process necessary for proper operation of the system. An accurate P&ID tag list, sorted both functionally (alphabetically) and numerically A list of critical components. Critical components are those with which the machine would not operate properly without or would pose a problem if that component were to fail. Also included in this list may be special long-lead components that could jeopardize startup and/or production schedules if they were to fail. The recommended spare parts list usually assists in determining most consumable items, as well. Complete specifications on the critical components. A list of limits that the components will endure and are engineered to should be available for most critical equipment. If no specification is available, suitable judgment should be made about that particular part.
__________________________________________________________________________________________________________
Engineering design data on critical parts. Most of the time, this information is available on the specification sheets or is part of the equipment data. If the part is custom engineered, and affects safety or critical operation, ask to see the engineering calculations. Listing of Product Contact areas. The product contact, solution contact, and air contact areas must be identified and the components listed by the manufacturer, as well as all of the materials in contact with any one of these areas. Any area that may come in contact with the product must be identified and approved for use in that manner. List of lubricants. If lubricants are used in a system, there should be a central place to list out those lubricants, where and how often they should be applied.
Computer and Software IQ For software, the IQ data becomes somewhat more vague. A list of software components and their record of installation should be available, complete with serial number (where available) and current revision level of each software package. If several sets of software are to work in concert with one another, make sure that each set of software is compatible with one another. For example, a Windows 3.1 platform working on DOS 2.0 would be immediately suspect! If it were running on an 8088 platform, one might also question the integrity of the specification data or the equipment supplier! Personnel with a working knowledge of computers is helpful when evaluating computer systems in a validation. Often software setup documentation specifies minimum hardware and software requirements. Care should be taken to make this criteria part of the checklist and document the findings of the investigation as part of the software IQ. The software IQ is also a good place to record serial numbers of the computer software and hardware as well. In a nutshell: Software Requirements and Specifications should be clear, written down, and approved by the appropriate personnel prior to creating the software package Any development software should be identified and logged Changes to the Software Specifications and/or Requirements should be documented when they are made, suitable explanation given for the changes, and approvals signed for the change Software Installation should be recorded, when made, so that the proper model numbers, serial numbers, installation date, and other pertinent facts are kept as a part of an overall disaster recovery plan
__________________________________________________________________________________________________________
The record of Software installation should be complete enough to reproduce the software from that document
Development Programming Software The IQ should also record the development software used to program the machine. In the case of Executable Software, the language compiler and its version number should be recorded In the case of Graphic Interface Packages, the Manufacturer and model number of all applicable elements should be recorded In the case of Programmable Logic Controllers (PLCs) the make and version of the programming software should be recorded as well If a package is available on the open market, such as DOS or Windows , simply writing the version number is all that is required If a development package consists of many parts, all should be broken down and identified in order to be able to reproduce any software at any point, if required
Source Code Specialized Source Code written for a specific function by an OEM may be considered proprietary by the OEM and source code may not be available to the end user. The source code must be available for auditing purposes, if so desired, by the end-user, customer, FDA, or independent source for evidence of testing, structure, and reliability. The OEM should allow audits of its proprietary source codes, to insure that the programming conforms to the OEMs written and approved guidelines. Developing IQ Challenges The information gathered above should be used to develop an IQ test protocol. Note that specifications and limitations for all of the critical components should be tested, wherever possible and practical, to insure that the components are installed according to their designed criteria. Considerations include: Voltage, Loads, Noise (RF, Ground, etc.), Operating Temperatures, Humidity, Classified Environments (Class I, Div 1 & 2, Class II, etc.), Pressures, Vibration, Etc. Installation Tests and Startup Protocol Point to Points Using the electrical schematics, make sure that a point-to-point check of all wires is done, and systematically begin power-up sequences, protecting each branch circuit from power until the branch circuit has been deemed safe. Using the information listed, develop specific tests which are designed to examine the limitations outlined for each instrument.
__________________________________________________________________________________________________________
Lets use a Temperature Loop Process Controller, for example: PROCESS CONTROLLER SPECIFICATIONS: Input Voltage: 115 VAC 50/60 HZ, +/- 10 % (Readings from 103.5 VAC to 126.5 VAC acceptable), grounded. Power Requirements: 2 AMPS at 115VAC. Input Signal: 3-wire RTD, 100 Ohm Platinum, DIN STD .00385 Ohms/Ohm/ C Shielded at instrument ground. Output Signal: 4-20mA DC, driving into a maximum of 600 Ohms resistance. Alarm Outputs: High and Low alarm contacts provided, with user setpoint. 2 amps @ 240VAC maximum load on alarm contacts. Ambient Temperature requirements: 10 C to 35 C, 0 to 85% humidity, non-condensing. Unit acceptable for installation in NEMA 4 enclosures, provided sealing gasket is used. Placement should be horizontal for proper heat dissipation.
An example protocol could take the form of:
Test #
Specification Controller Specification
Test
Expected Results
Actual Results
(Pass/Fail)
Initial
Date
Measure the input voltage. Examine the input to the controller.
Examine the calibration certificates. Examine the alarm output connections and loads. Examine the ambient temperatures and humidity and operating environment. Observe the orientation of the instrument.
Input voltage should read between 108 and 123 VAC The input shall be a 100 ohm platinum 3 wire RTD, with DIN STD curve .00385 Ohms/Ohm/ C with ground. The RTD and display calibration shall be documented. Hi and low alarm output loads shall not exceed 2 amps (AC or DC) or 240VAC. Ambient temperature of the inside of the control panel shall be between 10C to 35C, 0 to 85% humidity, noncondensing. Controller should be mounted horizontally to account for heat dissipation.
_________ VAC ____ HZ
________ VAC ________AMP S Temperature of control panel interior during operation:

___C@__%RH
Record orientation:
Test Conducted By:_____________________ On Date:____ Test Reviewed By:____________________________ On Date:______ __________________________________________________________________________________________________________
Software IQ Tests Software installation should be verified against the specific software and hardware requirements of the systems. Both hardware and software should be tested in this phase of the project. In order for the installation qualification to be successful, the information listed in the Functional Requirements must have been documented. Also, the software installer should have created a written record of the software installation information: Software manufacturers name, address and phone number Make of software Model number or version number of software Serial number of software (if serial number is given) Any problems or special instructions should be noted A form may be created to verify this information using the Function Requirements and Functional Specifications as a guideline. Computer Hardware Because of the complexity of todays modern computer systems, adequate computer hardware diagnostics IQ should also be conducted. Using standard system diagnostics, determine the following: Is all RAM installed that is required by the operating software? Is enough hard disk space available for the operating system, and as a buffer for data storage? Does the system power up without any error messages? Does the power up sequence test memory, system integrity, etc.? Are there any special program diagnostics that can be run? If so, run them and record the results. Is there a backup of the entire system in case of equipment failure? Is there a record of any firmware installations? If so, obtain and keep a copy. Are there any special boards installed on the computer? Is there documentation that can verify that they were installed properly?
__________________________________________________________________________________________________________
Operational Qualifications (OQ) Operational Qualifications require that the following information be generated in the Functional Specifications: Display Specifications If CRTs are used, or if discrete instrumentation is used, a description of their purpose and detail should be provided of how the instrumentation relates to the process. Security Specifications All pharmaceutical equipment shall show evidence of security systems, be it passive or active A Fundamental Sequence of Operations Exactly how is this machine or process to function, and interface with the real-world, its inputs and outputs, and how is it to be operated on? How is it cleaned? How is it set up for production? How is it torn down after production is complete? How is it disposed of, should that become necessary? (Note: This last is a European CE requirement!)
Also, the following questions should be asked. The appropriate information should be gathered: Does the machine have several modes of operation? If so, each mode should be discussed in detail by the Functional Specifications. Does the system have any diagnostics? If so, can some of these be used in the OQ process to speed testing? Does the system have Interlocks? If so, a comprehensive interlock list should be provided in the Functional Specifications. Does the system have Alarms? If so, a comprehensive alarm list should be provided in the Functional Specifications. Are there any other specifications unique to this equipment? If so, they should be listed in the Master Validation Protocol and some sort of testing should be included to verify that the machine operates according to the Functional Requirements and Functional Specifications.
Writing the Operational Qualifications OQs should be conducted in two stages; Component Operational Qualifications (of which Calibration can be considered a large part) and System Operational Qualifications (Does the entire system operate as an integrated whole) For some field devices, the calibration exercise may be all that is needed to consider the instrument operationally qualified. Input and output is examined and checked for proper operation. For other devices that are not calibrated or calibratable, such as CRTs,
__________________________________________________________________________________________________________
software, PLCs, computers, etc. special tests must be designed from the Functional Specifications such that the range of interlocks, alarms, displays, and functional operations are tested adequately to assure consistent operations. Use the P&ID! The P&ID is instrumental in verifying system operations. If possible and practical, divide each component of the PLC or System I/O and each critical device out, and conduct tests of each item to verify that it operates according to the designated function on the P&ID diagram. If loop diagrams are provided, these are an excellent way to categorize checklists. References to P&ID loops and/or loop diagrams may be used in the OQ tests. After the P&ID has been run through, it can usually be said that the individual field components have been thoroughly tested for operability. Use of a database program may help the Validation Group conduct an audit. Ask if the manufacturer uses databases to organize the data, and, if practical, obtain a version of that database to help organize all of the components to be tested. Take Advantage of Diagnostics Some manufacturers provide diagnostic programs and systems. PLCs normally have Force Instructions to manually force I/O on and off. Other systems provide maintenance items that allow diagnostic exercises to be run on the various sub-structures of the equipment. Used properly, the diagnostics are invaluable in saving time and providing assurance that the machine and all its parts are operating properly. Thoroughly Examine Interlock and Alarms The interlock and alarms listings are the most comprehensive and organized functional descriptions of the system. Develop tests which exercise these two lists to the specifications. If there are any changes in these lists during startup, make sure that the most current lists are given to the Validation Team prior to conducting testing. Other Operational Tests If the machine has configurable recipes, tests should be conducted to challenge the recipe engine, boundary conditions of the recipes or sequences, and its operability. A Fundamental Sequence of Operations is helpful in providing a test guideline. Also, an MO (Method of Operation) or SOP (Standard Operating Procedure) of various product runs to be used on this machine may help to provide suitable Automatic and Manual tests on the total functional system. Use of a Fundamental Sequence of Operations (FSO) or Standard Operating Procedure (SOP) The Fundamental Sequence of Operations is a detailed writeup or flowchart that explains the operation of the entire system or machine. It includes sequencing operations and detailed explanations of how the equipment is to perform its function. Taken to its most complete form, the Fundamental Sequence of Operations becomes the basis of communication between the equipment designer, programmers and operators. If one does not exist, you may consider constructing one. It provides insight into the details of the equipment operation that might not surface until the startup phase of the project,
__________________________________________________________________________________________________________
where it might be much more difficult and expensive to make modifications to software and/or equipment. An FSO or SOP is designed to convey the proper operating sequences to the programmer, and serves as a double-check of alarms, interlocks, and system functionality. Usually, this step is missed during the OQ testing. Some will argue that it is not to be included in IQ/OQ testing protocol at all, but should be included only in Process Qualification (PQ). In any case, a comprehensive written sequence is invaluable in understanding and conveying the operation of the entire sequence to the Validation Team, Operators, and maintenance personnel. NOTE The purpose of testing to a FSO or SOP is not so much to test the process itself, but to test the equipment to the FSO so that operation to a sequence is guaranteed (or at least there is some hope that real processing will be possible after all this testing has been completed!). IQ/OQ testing alone does not guarantee that an equipment installation will produce marketable product! PQ Testing to an SOP is necessary to provide a completely validated solution! In generating a test, run through a typical operation sequence, preferably using a placebo batch. Several modes may be tested, such as automatic and manual mode. If it is practical, this testing of the FSO may also be a part of the Process Qualification. However, keep in mind that the purpose of testing the equipment operation to the FSO is to test for proper equipment functionality and not necessarily to test the Process. Although testing to the FSO in the Operational Qualification (OQ) stage is optional, it should be useful as a tool to verify proper operation of the entire system prior to the equipment being placed into service. Process/Performance Qualification (PQ) Process up-scale testing Process scale-up testing should be part of the overall Process Qualification. A properly run project should already have upscale considerations taken under advisement. The laboratory runs of the process should also be well documented and reliable before the system has been placed up for bid. From the laboratory data, and scale-up tests, the important items needed to be scrutinized will be evident from the test data. The resultant Process Qualification should exercise the limits of the operational criteria for proper product. In some instances, this may be a multi-dimensional phase array of several criteria. If possible, equations generated from lab testing should be used to evaluate where the limit points should be. Practical real-world knowledge should also help narrow the variables down for testing and criteria. It is crucial during this phase of the test qualification construction to have knowledgeable personnel involved in creating and approving the Process Qualification procedures.
__________________________________________________________________________________________________________
Process Qualifications at a minimum should include the following: Processing at normal (nominal) processing conditions Processing at several boundary conditions that would normally be encountered during yearly production Processing at less than optimal processing conditions to verify boundary criteria. Re-testing within selected boundary criteria to verify that the proper boundary criteria is acceptable to use in normal production runs Testing of alarm and interlock setpoints resulting from the process boundary testing above . The system should be able to protect itself (within reason) from abnormal processing conditions and alarm, modify, or halt the process accordingly. NOTE The FDA requires that several batches would have to be manufactured, using fullscale batch sizes and conditions, to demonstrate that a process meets the consistency test. At least three batches are normally needed to demonstrate this. Sometimes, more batches are required if various products are to be qualified on the machine. If the QC checks on the batches are acceptable, most times (although not always) those batches can be considered as product for sale. The internal QC group of a pharmaceutical firm has the responsibility to fully examine these test batches prior to release of the product. 12. Calibration Calibration should be conducted in a sequenced manner after the Installation Qualification has been completed. Calibrations should at a minimum, cover the measuring instrumentation, transmitters, PLC or other processor input and outputs, Display Readouts, and Recording Devices. Problem Areas Calibration should be performed at the instrument level when possible. Some devices are difficult, if not impossible to fully calibrate on-site, either due to their very nature or due to excessively high costs. Some examples of these are: High Volume Airflow Stations 1000CFM and Higher Infrared Temperature Sensors Dew-point Sensors Vibration Sensors, etc. For the above item classifications, strive to have the vendor obtain the best information possible. In several cases, the sensor supplier may be able to provide a NIST certificate or certificate of compliance. If at all possible, a check should be made on the device by another source. For example, High Volume airflow stations could be checked by an anaerometer for approximate compliance. Since this is a mature technology, a lot is known about Pitot tubes and their properties. Therefore, a consistent and proven design is beneficial.
__________________________________________________________________________________________________________
For mirrored Dew-point sensors, by the laws of physics, are calibration standards. Verification and certification from the factory that the instrument is reading properly may be all that is required. Infrared sensors generally work well when what they are measuring has the same albedo. When several products or products that change properties are used, care must be taken to investigate the properties of the devices and compare them to known standards. In may cases, the manufacturer of the sensor may be able to provide NIST certification to a given product for a fee. Vibration sensors usually have a set method of calibration that relies on imperical field tests. For calibration of these items, it is best to refer to the manufacturers instructions on setup. A NIST traceable vibration source may not be practical to place in the field! Other Devices Some measuring elements are somewhat time consuming to calibrate. In those instances, calibration sheets from the sensor manufacturer may prove useful. It may be more cost effective to have an outside source calibrate them. Calibration Tolerances Calibration tolerances should be governed by the production process and are cumulative. For example, we may have an overall need to be +/-7 C on a particular product before measureable degradation of quality occurs. Therefore, a suitable guideline for calibration could be relaxed from a stiffer standard that may be required in another part of the process. This may save considerable amounts of money and later calibration hassles. If the tolerance is too strict, it will be difficult to maintain conformance in the devices. Cumulative errors The entire sensor loop must be considered to fully evaluate a reading. For example: A temperature element has a .25 C accuracy Its transmitter (range 0-100 C) has a .05 C accuracy The PLC input card has a .25 % accuracy (translating in this case to +/-.25 C). Therefore, if we take the extreme ranges into account, we get a total accuracy of +/- .55 C. (.25 +.05+.25) For the above application, +/- 7 C variation is possible, but quite likely a +/- 3 C variation is possible for the control loop. So, leaving a safety margin of 1 C, we can conclude that +/- 3.0 C overall calibration accuracy is acceptable. That means that an acceptable calibration range for each section would be: +/-1. C for the element +/- .5 C for the Transmitter +/- 1 % for the PLC Input (or +/- 1.0 C) With a .5 C margin for error.
__________________________________________________________________________________________________________
Conduct a total loop test A verification check should be made after unit calibration has been completed to verify that the entire system is functioning properly and measures within limitations. This tolerance should take into account the process tolerance of the product, and should fall within the specifications of those tolerances, if the entire system is functioning properly. Calibration, In Summary: Specify the Product Tolerances to the OEM up front for bid If calibration of a devices is not available, obtain certificates of compliance and devise other methods for checking the instruments accuracy Take the sum of the errors into account when creating calibration tolerance specification Conduct a final instrument loop check of the entire calibrated sensor loop to verify that the entire circuit is operating within specifications 13. Conducting the Tests Proper up-front Protocol Work When the system specifications have been nailed down, the vendor has supplied the equipment, the riggers are finished moving the equipment in place, the electricians, bricklayers, and plumbers work has been completed, it is time to conduct the tests. Reviews The following reviews are recommended throughout the life of the startup project: Initial Audit - Qualify your vendors Initial Review - Discuss Scope of Work, Responsibilities, and Level of Validation required Functional Specification Review - Audit the Functional Specifications for correctness, appropriate information, and considerations for real-world problems and inaccuracies In-Process Review and Company Audit - A review should be conducted of the vendor during construction of the software so that adherence to accepted programming practices are assured. Is the vendor using stubs? Are they correcting mistakes? Are they keeping revision control on the software and other documentation? Factory Acceptance Test (F.A.T.) - An acceptance test of the equipment is recommended whenever possible, so that problem items may be resolved before shipment of the equipment to your facility. This should be part of the original purchase order to conduct an acceptance test prior to shipment. Make sure that suitable testing has been made on all aspects of the equipment, and that some record of the test results is available for inspection. Ask for a copy of the FAT test results. If aspects of the equipment are simulated, ask to see the stub programs or simulation setup. Unpacking Inspection - An in depth, detailed inspection of the equipment should occur prior to acceptance of the equipment on-site. A copy of this report should appear in the project file. IQ Review - Review the installation qualification with the startup crew prior to installation of the site. Explain to the contractors why the IQ is being conducted, and
__________________________________________________________________________________________________________
be aware of any construction timetables and methods employed during the construction phase. This is crucial, as some equipment may be very difficult to access to gain serial number information after the equipment has been installed! The test protocol should be compared with the functional specifications for test accuracy. If any discrepancies are present, they should be discussed immediately and resolved before validation of the system can occur. Consider the real world With few exceptions, startups usually involve adjustments to alarms, interlocks, and operational specifications. Marked up revisions of the changes should be available to the validation test crew. If at all possible, the changes to the specifications should be reviewed and typed prior to execution of the tests. A final test protocol revision should be made prior to conducting the validation tests. This is usually done in the last stages of startup, so allotment should be made up-front to allow for time to conduct a review. This requirement is less important if a machine has been installed before, and the unknowns are minimized. Dont Validate yourself into a corner Sometimes protocol is written such that any change or modification is not allowed, and is grounds for re-validation of the entire equipment set. While this issue is very important, consideration of circumstances needs to be weighed when changes to Functional Specifications occur. Often, a few practical adjustments to test procedures, specifications, or protocol is required to address these changes. NOTE A deviation does not necessarily mean that an entire process is void, just that other considerations had to be made and adjusted to obtain a satisfactory result. Evaluation of accept/reject criteria should be made by an authorized source whos expertise qualifies him/her to make the decision. In the instance where changes to the Functional Requirements are necessary to adjust real-world conditions, an evaluation must be made to the validation protocols so that the full impact of the changes are incorporated into the revised specifications and validation protocols. Documentation should be provided and should remain in the file to explain these deviations when they occur. The Right Tools Validation and calibration require measuring tools. A proper calibration set of instruments should include NIST traceable: RTD Simulator, T/C Simulator, 4-20 MA Simulator and Meter, Multi-meter, Ammeter, Differential Pressure Meters of appropriate ranges, Calipers, Level, etc. The Validation crew should have NIST Traceable: Multi-meter, 4-20 MA Simulator, Stopwatch (NIST Certified), A Black or Blue, non-smearing, medium point pen.
__________________________________________________________________________________________________________
Proper ways to fill out the forms Validation and calibration should be done in a clear and concise manner, neatly, in a patient and orderly fashion. The following rules are useful: Always use a pen, never use a pencil! When signing a test, write Pass, or Fail. Check marks are not considered acceptable and unless properly documented and allowed for on the form, are not sufficient evidence that a device has been checked Note ALL deviations from expected outputs Sign each sheet of the validation test procedure using your full signature You should first print clearly, then sign your name on at least one document, so that any auditor can clearly identify your signature with your proper name Review of the completed test procedure is recommended prior to final acceptance of the final test procedure, to verify that all tests were conducted thoroughly and properly Proper ways to make corrections to the forms As much as we would like to think were perfect, we are all human, and sometimes mistakes and oversights make it through the most thorough examination. Other times, we may just be caught up in Murphys Web, and have to adjust the test procedure to match actual conditions and test results. Making corrections to approved documents is acceptable by the FDA, provided you follow the rules below: Make corrections using one line through the mistake, and writing the correction clearly and legibly near the line. Initial and date the correction on that piece of paper, as close as possible to the correction. Red is appropriate for corrections, although black ink is also OK for correction. Do not black out any section of the validation test plan Attachments are acceptable to the FDA, as long as they are written in pen and permanently attached to the paper in question, by stapling or some other means. What to do when the system does not work exactly to the written specification When the up-scale process, or system, does not work according to planned specification, its time to re-group and formulate a game plan. The validation personnel should act as in a cautious but cooperative manner to make adjustments to the test plans and work with the technical staff to develop upgraded specifications and solutions that match the original Functional Requirement. If the Functional Requirement cannot be met by the equipment or process, there are several questions to ask: Can the system reliably produce quality product using alternative methods of production? If so, a revision of the Functional Requirements and Specifications may save the day. Revisions to the test plans may be made from the newly revised specifications, approvals signed, and re-testing done to verify proper consistency and operation of the equipment.
__________________________________________________________________________________________________________
Can the system be modified to meet the Functional Requirements and Specifications? Again, this may be expensive, but will save the day as well. The Validation Team has but to adjust its tests to the modifications once they have been properly defined by approved revisions to the Functional Requirements and Specifications. Can the Requirements be downgraded to levels the machine currently can produce? Although unattractive, this alternative is sometimes used by companies and is acceptable as long as safety, integrity, and reliability is maintained to the new standards. In any case, these standards must be approved by the appropriate parties prior to writing revised test procedures. The key idea in all three scenarios is to clearly define revised procedures and specifications before re-validation is allowed to occur. The FDA greatly frowns on adjusting validation procedures to match actual data without properly authorized approval of the change in process. NOTE It is part of the function of the Validation Team to act as Patrol officers and report any harmful deviation from abnormal operation. The Validation Team should operate under independent authority, and should not be placed under direct control of the Project Management Team. To do so otherwise would be a conflict of interest. This is not to say that they should have ultimate authority either! They should report to a QA group head or an appropriate level of senior management that is independent of immediate financial or project concerns.
14. Re-Validation and Re-Testing Procedures Re-validation is required when the operating equipment or system has been changed in some way. The following scenarios are good triggers, such as when: System upgrades have been added Major mechanical equipment has been replaced Computer systems have been replaced Additions to the functionality of the system have been made New products have to be run on the system (This requires additional PQ testing) Critical items have been replaced or repaired When major revisions are performed on the system, the re-validation may have to encompass the entire machine. As a rule, only the portions of the machine that have been modified need to be re-validated. When only a transmitter or element has been replaced, usually a record of calibration of that element, plus a record of calibration for the entire readout loop, is required. For software upgrades, and computer system replacements, this effort might be quite a lot more involved.
__________________________________________________________________________________________________________
Software and Computer Hardware Upgrades and Fixes If at all possible, get a comprehensive list of the changes made to the software that is to be added to the system. If this list is available, specific test protocol may be written to address the changes. However, spot checks of critical functions should also be made to ensure that regular operations have not been affected. If the nature of the software or hardware upgrade is profound, or massive, (such as a new operating system upgrade), and entire computer system check should be done to verify that the computer system is operating properly. Follow the common sense plan below when conducting these upgrades: 1. Backup the system before you start. (Its amazing how many people forget this simple step!) 2. Obtain all upgrade specifications prior to installation, and have the responsible parties approve all aspects of the upgrade. 3. Before conducting the upgrade, ask to see test results of module testing or a complete list of upgrades included for your system. 4. Divide and conquer. Concentrate on those items which are the most meaningful to the operation of the system. Divide the tests up into functional segments. 5. Write test plans specific to the items which have been changed. 6. Include some random checks on existing systems that supposedly have not been changed in your re-validation protocol. Especially concentrate on those operations that are mission critical. 7. Have the testers write down anything abnormal that happens, not just the results of the tests. Investigate any anomalies found. Prepare a final report. 8. Make sure the system is backed up daily during the test and debug phases. Repair and Replacement of Components Component repair and replacement is a relatively simple process. A form should exist when doing maintenance or replacement of an item that addresses: a) The nature of the problem b) What has been replaced or repaired (the technician should be specific, using model and serial numbers whenever they are provided), c) A supposition of why the part failed or needed to be replaced (For Total Quality Management [TQM]). If the reason was vague, this should trigger some investigation as to exactly why the part failed. If re-calibration is required, it should not only be done on the component replaced, but also on the entire loop that the component was in, to verify full functionality of the system. Any other systems that the component was connected to that might be affected by incorrect operation of the failed part or addition of the new part should be tested using the same protocol that was used when initially validating the system.
__________________________________________________________________________________________________________
A copy of the maintenance records should be kept for each major repair made. NOTE Routine repair or replacement of items should be included in the regular Standard Operating Procedures (SOP) that personnel follow in the regular operation of the machine. A copy of this SOP should be available. Suitable records should be kept of all maintenance done on machinery, be it routine or on-call. Calibration and Re-Calibration Calibration data often contains pertinent information on the quality of the part being calibrated. If at all possible, calibration data should be in a database so that trends may be made of the devices. Logging device historical information may yield important information that could help troubleshoot trends of failures. Record: The calibration device used, its Manufacturer, Model Number, Serial Number, and Calibration Date and Calibration reference number should be clearly marked on the calibration sheet. The existing measurements made before calibration of the device has been done. The resulting calibration data of the device after it has been calibrated A description of how the calibration was performed Listing of all data points calibrated A place for comments should be made on the form A Pass/Fail criteria (normally tolerances) should appear on the calibration form. A place for the calibrator to put Pass or Fail A place for the Calibrator to sign and date the calibration, and a place for the calibrator to print his/her name. (A copy of a printed name and signature should be on file for comparison inspection at any time, as oftentimes, personal signatures may be illegible). Re-Calibration Frequency Re-calibration should be done on a semi-annual (6 Month) basis, according to FDA guidelines. However, some items may require re-calibration more frequently than others. Those items should be identified and calibrations conducted on a basis suitable to their physical properties.
__________________________________________________________________________________________________________
Retro-Validations Retroactive validation must be done on equipment that records have either been lost or validation was not provided for in the initial life of the machine. Retroactive validations get more difficult the older the machine is. Several questions surface when retroactive validations are planned: What is the level of validation the machine requires? If the machine is used for a tertiary operation, the level of validation required may not need to be extensive, as the machine has a historical record of operation. This should reveal any, if not all, of the problems associated with the machine. What is the past performance history of the machine? Past performance of the machine will yield valuable information when planning a validation strategy. Where are its weak points? Talk to the operators and gather informational data on operation of the machine. Is the manufacturer of the machine available? Are they cooperative with information about the machine? Does the machine have product contact surfaces? If so, are those surfaces kept clean? Do they show any signs of contamination? The manufacturer should be able to provide the design specifications of the materials. Chances are, the manufacturer will not have kept actual material certifications of the parts. Evidence should be gathered from the daily operations. (Basically, if surfaces show no signs of corrosion, they are probably suitable for the purpose.) If a part is in serious doubt, an analysis should be done. Is there a written sequence of operation? Is programming well documented? Is a current copy of the programming available for inspection? If there is software source code, is the manufacturer willing to have an audit conducted on that source code? Did the manufacturer have programming guidelines in place at the time of software programming? If so, was the guideline followed for the programming of that machine? Does the manufacturer have other machines of that type and model operational in other facilities? What is the history regarding the machine? Did the manufacturer keep Factory Test Data on the machine? Did you conduct a Factory Acceptance Test? Is there record of a Factory Acceptance Test? Does the manufacturer have a copy of their quality test procedure that was in place to inspect the machine before shipment? After it was installed? After it was started up? Is the manual up to date? If not, what has changed? Have there been modifications to the machine after it was initially installed? Were there records kept of the modifications? Is there a P&ID of the system? Is it up to date? Schematics? Other?
__________________________________________________________________________________________________________
What to do when faced with Retro-Validation Step 1 - Size up the job, Identify Your Team, Write a Validation Plan, Gather Data Size up the job, and follow a written Validation Plan. Your team should be aware of this plan. Gather all the information on the machine you can. Ask operators, get a copy of the manuals and drawings. The most important aspect of the validation is obtaining a written procedure of how the machine operates and its history. A good manual helps. A P&ID is invaluable. Step 2 - Create a Functional Requirement, if one has not been made for the system A Functional Requirement is the basis for all the testing you are about to do on the machine. While most times the operating manual can serve as a Functional Requirement, it may not be specific enough for your product. The Functional Requirement starts back at the creation of the product. Why was the machine necessary? What does it do? Step 3 - Create a P&ID, if there isnt one. If there is one, make sure its updated The P&ID is your best roadmap of the system. If one does not exist, take the time to make one. Label all of the components, and if possible, place tags on the critical parts. The P&ID is your most useful checklist of functionality and should encompass all aspects of machine functionality. Step 4 - Make a Database Using the P&ID, a database listing will help you organize your plan of attack, and identify what is important and what is not. A database need not be in a computer. It can simply be a list of the items in the system, ordered conveniently for reference. (But a computerized database sure helps!) Step 5 - Gather all information to form the Functional Specification How does the machine perform its function? What I/O does it need to operate? What interlocks does it have? Alarms? What are its displays? Does it have any diagnostics? What are the operational limitations of its individual components? Of its critical components? Hopefully, all of this is provided for you in an organized fashion already. But if it isnt, make sure it becomes available before a test plan is written. The Functional Specifications are the basis of any good test plan. Step 6 - Make a list of all product contact areas, possible contamination sites, and critical equipment items This list should be done with the aid of suitable process expertise. This identifies all important areas. These should be areas that you should concentrate on. Step 7 - Write a Fundamental Sequence of Operations This one is usually tough to accomplish retroactively, but is really useful if done correctly. Again, hopefully, the manufacturer or operations people have written sequences or SOPs, and you can build on those. If one does not exist, generate one and make sure that the appropriate technical personnel sign off on its validity. Step 8 - Prioritize With all the data in front of the team, decide where the most critical areas are, and concentrate on them. Decide where to stop by looking at the priority of the item. When the priorities get trivial, stop. Document the priorities.
__________________________________________________________________________________________________________
Step 9 - Write the Test Plans Using the priorities established above, and all of the information that has been gathered, have the team write the test plans. Step 10 - Review the Test Plans Have the test plans reviewed by at least one other knowledgeable source, and have them approve the final test protocol documentation. Step 11 - Conduct the Tests The reviewed tests may then be run on the equipment. Follow established change procedures and take any corrective action necessary. From here on out, the validation should proceed as if this were a machine that has just been commissioned. 15. Master Validation Protocol Master Validation Protocol - Structure of a Validation Program The Master Validation Protocol (MVP) is the outline of the validation for a facility. Its purpose is to provide the users, coordinators, managers and auditors with a clear guide to validate the equipment and processes in a plant. Simply put, a good MVP will allow an untrained person to work with and understand the entire system, its purpose for being, how it functions, how it is to be tested, who tests it, what the order of the tests are, and the results of those tests. All this should provide a clear path for the FDA to evaluate the machine and/or process in question. All documentation pertinent to validation and/or qualification should be referenced here and clearly explained to eliminate any ambiguity for their purpose and function. It also provides an overview of the procedures and the recommended work-flow for examination of the equipment. It should outline the planning stages of definition, review, tests and final qualification.
__________________________________________________________________________________________________________
Example outline of a Validation Protocol I. Introduction Purpose of plant and scope of validation procedures to be utilized. II. Reference documentation P&ID.s, Laboratory Test Results, I/O Lists, Engineering Definitions, etc. are referenced here. III. Procedures A. Identification of Validation Team B. Reviews and Audits C. Test Plan Creation Methodology D. Installation Qualification E. Calibration F. Operational Qualification G. Security I. Process Qualification J. ERRATTA Provisions for corrections, change control, new procedures, changes. K. Maintenance Re-Validation, how much and how often?
__________________________________________________________________________________________________________
About the Author Don Rosendale has worked in the Dairy, Aseptic, and Pharmaceutical industries for over 18 years as an Application Engineer, Control Engineer, Control Group Manager. and currently holds the position of Validation Group Manager for Vector Corp. Don holds a BSEE from the University of Pittsburgh. About Vector: Vector Corporation provides a full line of computer controlled processing systems to the pharmaceutical, food processing, confectionery, ceramic, chemical, agricultural, and powdered metal industries. Vector has a laboratory facility in Marion, IA , and a GMP laboratory in Cranbury, NJ, to provide testing for a wide variety of processes. Vector also provides scientific support as needed to assist in applying the process machinery it sells. Vector can provide full validation support for the equipment and services it provides.
All of the terms mentioned in this paper that are known to be trademarks or service marks have been appropriately capitalized. Use of a term in this paper should not be regarded as affecting the validity of any trademark or service mark. Microsoft, Microsoft Excel, Access, DOS and Windows are registered trademarks of Microsoft Corporation. PLC is a registered trademark of Allen-Bradley Corporation. DMACS is a registered trademark of Intellution, Inc. OS/2 is a registered trademark of IBM. Bibliography A History of Validation in the United States A paper presented by Kenneth Chapman at the ISPE Annual Meeting, 1994 - Kemper-Masterson, Inc. Computer Systems Validation for the Pharmaceutical and Medical Device Industries, Richard Chamberlain, Alaren Press 1991 Guideline on General Principles of Process Validation - Center for Drugs and Biologics and Center for Devices and Radiological Health, Food and Drug Administration, May 1987 Code of Federal Regulations, CFR 21 - Part 210 and 211 - Food and Drug Administration - April 1990 Revision GAMP 3 Good Automated Manufacturing Practices version 3.0, ISPE
__________________________________________________________________________________________________________

Validation Guidelines 3rd Party

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Validation Guidelines 3rd Party

Uploaded by

Copyright:

Available Formats

Validation of Pharmaceutical Process Equipment By Donald M.

Rosendale Validation Group Manager Vector Corporation

Practical techniques for successful validation of pharmaceutical process equipment Page 1 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 2 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 3 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 4 of 40

The Validation Validation Life Life Cycle Cycle The

DEFINE THE SYSTEM

SYSTEM MEETS NEEDS OF PROCESS ? YES REDESIGN QUALIFY THE SYSTEM

SYSTEM MEETS REQIREMENTS ? YES QUALIFY PROCESS CONTINUED VALIDATION

Practical techniques for successful validation of pharmaceutical process equipment Page 5 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 6 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 7 of 40

SYSTEM MEETS SPECS ?

YES CONTINUED VALIDATION

Practical techniques for successful validation of pharmaceutical process equipment Page 8 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 9 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 10 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 11 of 40

An example of a Functional Requirement (URS) technical page is listed below:

Practical techniques for successful validation of pharmaceutical process equipment Page 12 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 13 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 14 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 15 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 16 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 17 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 18 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 19 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 20 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 21 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 22 of 40

Specification Controller Specification

Measure the input voltage. Examine the input to the controller.

_________ VAC ____ HZ

________ VAC ________AMP S Temperature of control panel interior during operation:

Test Conducted By:_____________________ On Date:____ Test Reviewed By:____________________________ On Date:______ __________________________________________________________________________________________________________

Practical techniques for successful validation of pharmaceutical process equipment Page 23 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 24 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 25 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 26 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 27 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 28 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 29 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 30 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 31 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 32 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 33 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 34 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 35 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 36 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 37 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 38 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 39 of 40

Practical techniques for successful validation of pharmaceutical process equipment Page 40 of 40

You might also like

_____ VAC HZ

VAC AMP S Temperature of control panel interior during operation:

Test Conducted By:_ On Date: Test Reviewed By: On Date: ________________________________________________________________________________________