Writing Pharmaceutical Equipment

Qualification Protocols
By
Joe Cagnassola, Paul Copus, and Keith Haynes

Sep 25, 2018 2:11 pm EDT

ABSTRACT

Development and construction of validation protocols is a critical activity in the validation process. Writing protocols is a
comprehensive activity that should involve the entire validation process. This discussion adds important considerations for
protocol writing in addition to activities in the general validation “V” model. These considerations are consistent with the
evolving lifecycle approach to validation. Earlier involvement of site groups in the validation process, post validation
monitoring and maintenance, testing planning, and comprehensive documentation prior to and following qualification
testing are discussed. This discussion also provides practical hands-on suggestions and examples to facilitate the
protocol-writing process for equipment and other applicable qualifications.

INTRODUCTION

Every validation professional has been tasked with writing technical protocols as part of their job. Having the responsibility
to write a protocol for a piece of equipment or process that may never have been seen before is extremely challenging; it
sets an expectation to essentially become a subject matter expert (SME) on the assigned project within a very limited
timeframe. Some organizations provide standard templates for use in writing protocols. A standard template is ideal in
theory, but is not always easy to utilize and is not applicable in all situations. The writer must understand the need for
equipment and operation of equipment so that appropriate protocol tests may be designed. Attention must be given to the
attributes, functions, and parameters that are going to affect the required performance of the qualified equipment. The
protocol must be approved by SMEs, quality assurance, engineering, validation, and other departments; their perspectives
must also be considered in development of protocols.

Protocol Basics

Protocols contain detailed test procedures for collecting information in accordance with protocol objectives. When
executed and all information meets specified acceptance criteria, the equipment is qualified for its intended use. This
should be a simple and straightforward task. Why are we doing the work? What is the output that we seek to
achieve? Testing in the protocol must link back to the objective of the work such as a new facility, new equipment,
upgrade to a system, or other modifications. Bearing this purpose in mind will allow the author, reviewer, and auditor to
understand the reason for the project and that is has been vetted within the scope identified. By providing the background
for the change, the purpose of the protocol becomes clear. Protocols, subsequent results, and associated documentation
must “live forever;” these may be consulted long after they are written and after active participants have moved
on. Protocols will be needed in regulatory audits and in other consultation. Good protocols are critical; the importance of
protocol-writing cannot be underestimated.

Protocols may be prospective, retrospective, or concurrent in their approach. Prospective protocols are
preferred. Prospective protocols will complete validation of a new system before commercialization without releasing any
product to market prior to completion of all validation activities. Retrospective protocols and concurrent protocols may be
utilized under certain circumstances. If retrospective protocols are utilized, it is advised to have an implementation
strategy for upgrading to prospective and concurrent validation protocols. If concurrent protocols are utilized, these are
executed during product commercialization. If prospective protocols are not being executed, a risk assessment rationale
should be provided.

Qualification Principles and “V” Model

The qualification of equipment, facilities, HVAC, utilities and other site technical systems is an accepted principle of
validation. Systems must be qualified for future use in processing. Qualified equipment, HVAC, utilities, or other systems
means that they have been tested and verified to perform as required for their intended purpose. Qualification may be
generally considered to be a three-part activity. Part one comprises the design aspects of the project – user requirements,
functional requirements, and technical design. In part two, the system is built according to the technical
specifications. Finally, part three utilizes appropriate protocols to test the constructed system for official documented
qualification and approval for future use.

The well-known validation “V” model generally illustrates the relationship and sequence of the three phases -- design,
construction, and testing -- of qualification (Figure 1). There are many variations of the “V” model and many associated
terminologies related to its application, but the fundamental structure is the same in all variations. Design activities are
listed on the left side of the “V.” Note the arrows indicating ongoing interactions between users, functional designers, and
technical people to ultimately design the system. Also note the bold blue arrow indicating the sequence of design activities
leading to the technical design specifications needed for system construction. When all design aspects are completed, the
system is built – the base of the “V.” When construction is completed, testing begins including commissioning and
qualification testing – the right side of the “V.” Again note the sequence of testing activities from commissioning (SAT and
FAT) to IQ, OQ, and PQ. Horizontal red dotted-line arrows indicate the relationship between design requirements and
testing activities. IQ demonstrates technical requirements; OQ demonstrates functional requirements; PQ demonstrates
user requirements. Acceptable completion of all (IQ/OQ/PQ) qualification tests renders the system qualified for use in
future processing. Additional considerations (green) addressed in this discussion have been added to supplement
traditional “V’ model activities.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

QUALIFICATION "V" MODEL

 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Figure 1. Qualification “V” Model

Discussion Topics and Objectives

This discussion addresses the overall validation process as described in a new equipment qualification project. The
validation process should compasses the entire lifecycle of a project. FDA introduced the lifecycle approach to process
validation in the 2011 process validation guidance (1). This approach is now being applied to equipment, facilities, utilities
and other validation activities.

Considerations for the eventual work of validation should begin long before protocols are written and executed. Too often
equipment construction is completed when validation problems are noted; for example, difficulties in cleaning demonstrate
deficiencies in equipment design that are discovered too late or impossible to be easily corrected. Thinking about future
validation from the beginning of the project during user interactions, function development, and technical design should
help to develop thorough and complete validation protocols.

The goal of this discussion is to define the process of preparing equipment qualification protocols in a technical-based and
real-world manner. Specific topics discussed will include:

1. Project initiation. This phase includes the project objectives and associated topics. This discussion initiates the
qualification project before “V” model activities.
2. Design and development. This includes user requirements, functional requirements, and technical
requirements required to actually build the system to be qualified – the left side of the “V” and Stage 1 of the
lifecycle approach. These greatly influence the testing prescribed in the protocols.
 3. System construction. The system is built according to design requirements – the base of the “V.”
4. Qualification testing. This includes the specific project testing -- commissioning (SAT and FAT), IQ, OQ, and
PQ testing – the right side of the “V.” These tests qualify the system for future use – Stage 2 of the lifecycle
approach.
5. Post-validation monitoring and maintenance. These include calibration, preventive maintenance, periodic
reviews, and other associated topics inherent in qualification activities – Stage 3 of the lifecycle approach.
6. Documentation. Everything in validation and related to validation must be documented for future retrieval and
use.

This discussion will explore why we do what we do, how to look at each piece of the puzzle, how each one is interrelated,
and how each piece feeds the next. We will go through the steps to discover what is needed, how to find the information,
and what information to record to create a document that will stand the test of time. At minimum, it will get the job
done. When executed strategically, this approach can become a standard approach to qualification performance.

PROJECT INITIATION

The formal documented initiation of the validation project is best started as early as possible. This enables all associated
groups to know about the project and begin considering future work associated with their function responsibilities. These
groups may need to issue documents that will be utilized in protocol-writing and become part of the validation package. A
project initiation document containing the project title, reason for the project, and project requirements should be
issued. Other information in the project initiation document are the risk analysis and the validation plan. These documents
are usually developed during the course of design activities and prior to the start of actual qualification testing. Risk
information and the project plan are especially important for protocol writing.

Project Tile and Basic Information

The title of the qualification project should be a clear and concise statement. The object of the project should be clearly
stated; for example:

Equipment qualification of a new dedicated mineral oil holding tank for commercial product manufacturing in site building
#1;

A more complex project with additional considerations could be the following:

Equipment qualification of a multiuse mixing tank for oil ingredients for commercial product manufacturing in site building
#1.

These simple statements indicate much about the project – materials considerations, equipment design, GMP
requirements, facility design for equipment, cleaning considerations, and other factors. The latter in the above is obviously
more complicated than the former with additional considerations for implementation and validation.

The reason for the project should also be clearly and simply stated; for example:

Additional capacity for oil ingredients and associated processing used in product manufacturing.

Fundamental requirements to complete the qualification project must also be stated. Completion of the required protocols
as stated in the validation plan is an obvious requirement. Other considerations may include compliance to internal
requirements, engineering standards, and community laws; regulatory impact on associated submissions, other systems or
products impacted, procedure changes or other document changes, new SOPs, drawing updates, equipment files in
engineering library, notifications to affected groups (internal, external, labs), and other additional requirements.

Risk Management

Risk assessments describe and identify the risks associated with the product, process, or equipment and the subsequent
control systems to manage the risks. It is advisable to focus on the control of hazards that relate to product safety and
performance to users.

The risk assessment ties in closely with the purpose and scope of the project. It is a tool used to evaluate the risks
involved in the project or a change to an existing system. The risk assessment is linked to the purpose by knowing what is
happening, that the process has been evaluated, understood, and allows a view of the project, and the ability to
understand the risk better. The scope defines the boundaries, which allows the risk assessment to focus on the critical
parts of the change.

The type of risk assessment used is variable and there is no set standard, but it’s important to understand the process and
the totality so that you can figure out the cause and effect of the project, and how the risk is mitigated and controlled. The
type of risk assessment that is performed should be understood by the protocol writer because they will be the one asked
and will have to defend or explain the risk tool.

There are many different types of risk assessments available. The type of risk assessment used depends on the type of
process, equipment, or change. A simple paragraph may be utilized that provides the information. Others include HCAAP,
FMEA, FMECA, Fault Tree Analysis, and other hybrid systems often in connection with flow charts, fishbone diagrams,
and tools.

ICH Q9 identifies areas of interest for equipment, facilities, utilities, and other areas. Some of their items include product
contact materials, surface finish, product flow, risk of cross-contamination, spare parts inventory, pest control, and other
issues.

For example, a tank in Building 1 is 316 SS with a high polish finish. It is dedicated to use with mineral oil and has a
dedicated cleaning skid. The mineral oil will be used as a lubricant for non-product parts. Based on this knowledge, a risk
assessment for the cleaning process could state that the tank may only need to be visually clean based on its use, and
that impact to other cleaning is not impacted.

Validation Plan

The validation plan provides an overview, technical information, validation strategy, and required activities to complete the
validation. The validation plan sets the tone for the validation project It builds on introductory information in the validation
initiation document. It specifies exact requirements for validation be completed. The validation plan is an extremely
important document in the validation project that states the approach to the protocol effort.

Purpose and Scope. Protocols are written, approved detailed test procedures for collecting specific information and
verifying acceptance criteria in accordance with protocol objectives. When executed, protocols produce documented
evidence that the equipment or system has been qualified.

The purpose of the validation becomes clear and meaningful by providing background for the validation. For example:

Tank 1 is being qualified as part of Building #1 expansion for the storage of mineral oil. See change control #___ for
additional information.
A purpose that stands on its own makes the rest of the document easier to understand. This is the handshake to the
reviewers that says “hello, I am here to install a new tank in the new building for storage of this material.” This gives the
reader an understanding if the concept and shape the requirements for the document. The scope allows the reader to
focus on the task at hand. The tank is not part of other systems so you do not have to expand the scope of the project. The
dedication of the tank makes the cleaning process focused. Therefore, the scope is important in determining how much
qualification is required and if it impacts existing systems. The scope is critical in that it shapes the boundaries of the
protocol, such as the depth of the risk and the structure of the testing to be completed. It defines what area of the process
or equipment is to be evaluated, as well as what impacts to inputs and outputs are to be evaluated and tested.

An example scope statement might read:

The scope of this project comprises the new 1800 L storage tank to be installed in Building #1. The tank is dedicated to
store mineral oil only. There is no change to other equipment to the area. The tank will have dedicated pumps and
utilities. See drawing for the facility with future tank placement.

Technical Information / Process/System Description. The process or system description should describe the system
or process to be tested in the validation and provide associated relevant technical information. If possible, include
drawings of the system or processes. A diagram of the whole process with delineation of the area to be qualified and
change to the existing process is helpful to show readers the concept and focus on the scope. It is recommended to
provide a short summary of the system. This includes general functional requirements, performance capabilities, and
other major components. Include Identification of specific locations of systems under test within the site or facility and
identify processes that the system supports.

For processes such as sterilization (SIP) or cleaning (CIP), provide a detailed description of the automated sequence
initiated and controlled by a programmable logic controller (PLC). As appropriate, include such detail as valve sequencing
and enabling of counters and timers. Diagrams detailing the equipment involved in the automated sequence maybe be
used to illustrate the cycle. Description of manual cycles, such as clean-out-of-place (COP) should include details such as
cleaning agents, specific equipment to be used, and length of time required to perform manual steps, and specific
techniques to be followed. Tables may be used to list any applicable cycle parameters. User Manuals are a great way to
gather specific information regarding the description. Also, vendor web sites typically detail the equipment information.

Sampling/Testing Plan. The sampling and testing section describes the general plan for the validation project. Details of
sampling and testing are specified in the protocols. The plan is based on requirements documented in the URS, FRS,
TRS, risk analysis, and other considerations.

Documentation Requirements. Documentation requirements including protocol requirements are stated in the validation
plan. These may include the URS, FRS, TRS, engineering studies, technical summaries, and other requirements to
complete the validation are specified. These documents are the basis for the validation project and the validation
protocols. Hardcopies of these documents should be filed with the validation package or be readily available through an
electronic system. The listing of required documents is helpful to administratively close the validation project.

EQUIPMENT DESIGN AND DEVELOPMENT

Planning and design of equipment, facilities, HVAC, utilities and other site technical functions is the first step in
qualification. These are ultimately documented in User Requirements Specifications (URS), Functional Requirements
Specifications (FRS), Technical Requirements Specifications (TRS), or other equivalent site terminology. The planning of
an engineering validation project is analogous to Stage 1 in the lifecycle approach to process validation. It provides an
understanding of content in the eventual validation protocols

User Requirements
The basis of what we do starts with a need or desire to have equipment or processes that fulfill the need of the end
user. This is the item that gets you to from point A to point B every day. Consider the thought process when purchasing a
household item like a TV. When you are looking to buy, you usually have an idea of what size you want, how much you
can spend, as well as other features. The same is true when buying a piece of equipment for pharmaceutical
processing. For example, if a tank that holds 150 L of water, can mix viscous products, and can control temperature, user
requirements are written with these in mind. Many times we struggle to write the perfect document without realizing what
we need to write is in front of us.

This should be a group exercise with input from the end user, quality input for regulations and engineering, and
maintenance input for perspective on consistency. It is desirable to have similar pieces of equipment if possible. This
listing results in the User Requirements Specification (URS) that is forwarded to the next step.

Functional Requirements

A functional requirement is what you need the system and or equipment to do or perform. This is an important step in the
design and qualification of the system, in that it provides the basis for what the system is intended to do. For example, a
packaging line that requires high speed output to match consumer demand will need cameras and inspection systems that
can match the throughput. Another example: Equipment used for multiple products may require a range of operating
parameters such as a range of temperature, range of mixing rpm, and range of other variables.

This listing results in the Functional Requirements Specification (FRS) that is forwarded to the next step. The creation of
the FRS should be a group effort to ensure that engineering, validation, and production inputs are considered.

Technical Requirements

The URS and FRS requirements are integrated and translated into the engineering design and drawings for the equipment
to be constructed. The final step in this activity is the documented Technical Requirements Specification (TRS) to be used
for equipment construction. The TRS will specify construction materials, equipment design, operating parameters, and
other details for which equipment vendors may bid. If commercially available standard equipment will accomplish user
requirements and functional requirements, e.g., a 400 L stainless steel jacketed tank with multiple impellers operating from
200 to 500 rpm, a detailed TRS will not be needed.

SYSTEM CONSTRUCTION

When technical requirements are completed and an equipment vendor is selected, the equipment, system, or item of
interest is built. The TRS is the key document for system construction. Depending on complexity, involvement of site
technical engineering personnel with the construction vendor may be significant. SAT activities (see below) may occur
during construction to confirm acceptable performance during construction. At the other extreme, if a stock equipment
item is purchased from a designated vendor, a formal TRS may be unnecessary.

TEST PREPARATION

The next series of activities in the validation project involve preparatory work for testing and protocols. Basis for this
activity has already been stated in the validation plan. The tests to be conducted to accomplish qualification should be
known based on the URS, FRS, and TRS. They now must be organized into appropriate pre-validation work and
protocols. Acceptance criteria for tests must be determined within equipment capabilities. All documents must be
approved by the site approval committee and QA. After approval, testing programs may be executed.

Test Functions
Test Functions (or functional tests) are individual testing procedures targeted at verifying the system or equipment
functions as intended. Test Functions describe the purpose/objective of the test, the frequency of testing, as well as the
test method. The acceptance criteria must also be listed for each test function. There must be acceptance criteria for all
tests; “For information only” testing is not done in validation protocols. Test functions may be established in the User
Requirements, Functional Requirements, Technical Requirements, Installation/Operational Qualification, Pre-Validation
studies, or based on historical data for legacy equipment or systems.

Data are collected for each test function and analyzed against the acceptance criteria for acceptability. Testing must meet
all acceptance criteria listed in the test function. Results that do not meet the acceptance criteria must be documented in a
deviation and resolved prior to the approval of the results. A result not meeting acceptance criteria may require retesting,
or may be accepted based on a documented risk assessment, and is dependent on the criticality of the acceptance criteria
in question.

Test Functions are typically comprised of the following:

 Purpose and Scope; for example, running a specific autoclave load

 Frequency. Number of test cycles required
 Test instructions. Detailed list or reference to a common procedure
 Test equipment
 Acceptance criteria
 Documentation required. Test sheets, laboratory notebooks, or electronic system
 Test functions may be numerous based on the complexity of the protocol.

Acceptance Criteria

Acceptance criteria are all of the requirements that must be met for each test function, pre-test requirements, or other tests
where data are collected and analyzed against an expected results. The acceptance criteria are the results expected to be
achieved while performing the testing in the testing document (FAT, IQ, OQ, PQ). The acceptance criteria must be
documented in the testing document prior to approval for execution. Acceptance criteria may be established by sources
such as the company, local regulations, governing bodies, pre-validation work, historical data, or a combination
thereof. Data that do not meet acceptance criteria are classified as deviations, non-conformances, or failures. These
results must then be handled according to the procedures required by the company.

Approvals

All validation documents must be approved by representatives of Quality Assurance, Validation, and the appropriate
functional department. Qualification of a new manufacturing tank, for example, would surely be approved by engineering
and manufacturing operations as well as other related organizations. Try to minimize the number of approvers to speed
facilitate the approval process. Representatives who have the knowledge, expertise, and training in the validation process
and/or the area affected by the validation work should approve the documents. Typically, approval of each stage of the
validation cycle is complete prior to starting work for the next phase; for example, IQ is complete and approved prior to
starting OQ; OQ is complete and approved before starting PQ). Approvals of validation protocols occur prior to execution
(Approval to Proceed) and after the work is completed and summarized in the Technical Report. Approvers of documents
should be in agreement with the data and supporting documentation, and verify that all the data/documentation is present
before approving.

Execution
Execution of validation testing occurs after a protocol has been approved to proceed. Execution data should be organized
and secured in the validation packet and analyzed and presented in a results document or final results report. Depending
on the type of validation, execution can consist of a paper exercise, a periodic review of a system, collecting data from a
computer system, deviations, work orders, maintenance request or it can be a on the flow exercise, running a temperature
mapping study, probing wires in a vessel, gathering samples, testing vision systems. Regardless of the process, people
executing the protocol must be trained before beginning; this includes operators and lab help so they know the
expectations. All training must be documented.

Before beginning execution, read over the protocol one final time. Be familiar with all the steps. Have another person
review the setup. This is your prep before beginning. Safety is paramount -- check pressures, check piping for heat,
wear proper safety gear, and be familiar with the area surroundings.

The executed protocol is a GMP document. All data must be treated in the same manner as a manufacturing batch
record. Good documentation practices are expected -- slow down; make sure you are following site procedures and
protocols. Ask for help as needed; review work as soon as possible; keep all work organized.

When the protocol execution is completed, leave the area clean, organized, and safe for the next use. Return all borrowed
equipment and return the area to its original state. Notify management that your work is complete so that normal
operations can resume as applicable.

PROTOCOLS

The development and preparation of protocols is the key element in the validation process. This activity is based on work
and information from the design stage of the project. Topics addressed in this section include SAT and FAT; Installation
Qualification (IQ), Operation Qualification (OQ), and Performance Qualification (PQ). All of these activities require careful
development, writing, and execution of tests and evaluation of results against acceptance criteria.

SAT and FAT

Site Acceptance Testing (SAT) and Factory Acceptance Testing (FAT) are preliminary inspections and testing conducted
ahead of actual qualification testing. Organizations approach this testing in different ways. The complexity of the project
also impacts the approach – the more complex the project, the more interactions and preliminary testing at the
vendor. Some companies use “SAT” and “FAT” terminology interchangeably to describe work conducted ahead of
validation either at the vendor or in house. We will define SAT as testing conducted at the vendor and FAT as testing
conducted in house on site prior to qualification testing.

SAT testing conducted at the vendor facility verifies acceptable performance before equipment is shipped to the site. SAT
testing at the vendor site provides an opportunity to conduct validation testing and evaluate results. Equipment changes
may then be made – much more easily that if equipment was shipped to the site and was then returned to the vendor for
corrections. SAT is also valuable to learn about other equipment being developed by the vendor. If possible, ask for a
tour to see what other others are building and gain more technical knowledge of the process. If possible, have a team of
people available that have specific job functions (engineering, maintenance, validation, operator) so that everyone can see
and understand the equipment before it shipped. SAT may or may not be needed depending on the complexity of the
equipment.

FAT testing is conducted at the company site to confirm acceptability of equipment prior to starting validation testing. FAT
testing may also comprise very simple testing that would then not be repeated in qualification testing. FAT testing should
be documented for future retrieval as needed. FAT provides an opportunity to spend a few days in a factory to get to see
the new equipment working and get a hands-on approach to the equipment. It’s a good time to talk with the engineers that
have designed the equipment, understand the software, and use their expertise to further your knowledge for protocol
development.

There are several approaches to performing an FAT. You can use a vendor document or create provide your own test
document. A document that can save you time and effort can be developed with some planning and foresight. A
document that captures the work performed in a cGMP compliant manner so that the document can be leveraged during
the IO/OQ/PQ phase. Writing a FAT can be daunting if you are not familiar with the equipment. Utilizing a vendor
document is the easiest way to get started. Combining the vendor content with content that you prepare is useful in
running tests that are specific to your process. If possible, leveraging testing is ideal. Testing with a factory engineer with
the specific software who understand the complexities of the system is very helpful. Reduced testing may then be done in
the IQ/OQ/PQ phase. This approach should be specified upfront so that when it is time for qualification testing, you can
save time and effort while remaining GMP complaint.

Items that may be addressed at SAT or FAT: Power off/on, safety alarms, welding certifications, serial # and model #, leak
tests, drawings, IO checkouts, and other low risk items. The more testing able to be done in FAT, the less testing in
IQ/OQ/PQ – but be sure to have QA agreement.

Installation Qualification (IQ)

Installation qualification confirms that the design, materials, construction, and other “hardware” components of the
equipment being qualified. This represents the technical requirements design of the equipment. These requirements
include preventive maintenance, calibration, and other monitoring activities continually done analogous to Stage 3 of the
lifecycle approach.

Some of the above may be tested and documented in combined activities; for example, IOQ combines installation and
operation testing in one activity and in one document.

IQ is an overlooked phase of validation which is often thought of as checkbox testing -- but is very important. IQ
establishes the foundation for your equipment. It is an opportunity to ensure that equipment gets checked into your facility
systems and is set up for future control It is an opportunity to ensure that procedures, maintenance and calibrations are
completed as expected and identifying equipment numbers are assigned. The utilities checks are fairly routine, ensuring
that the system has the correct voltage and pressures. IQ is also important because future activities related to the
maintenance and operation of the equipment need to be reconciled to ensure that the equipment is maintained, and the
procedures are adequate. In addition, spare parts are detailed that make sure unexpected breakdowns do not cause
unnecessary downtime.

Items typically addressed in the IQ included drawings, ID tags, safety;, utilities, calibration, preventive maintenance,
operating procedures, spare parts, environmental monitoring, and software.

Operation Qualification (OQ)

Operation qualification confirms that the desired operational parameters of the equipment perform as intended. For
example, actual temperature performance of equipment at the temperature extremes is tested. This represents the
functional requirements design of the equipment.

The OQ is often combined with the IQ when the nature of the qualification lends itself to an integrated document. The OQ
is the real world tests to show that when the equipment is connected per the IQ and the equipment operates as
expected. The OQ will test the extremes of future operation such as the temperature ranges, pressure ranges, and mixing
speed ranges. The key for the OQ is evaluating the Functional Requirements Specifications and tailoring the testing to
meet the project objectives. Some items checked in the OQ include IQ complete, motor rotations, display screens, loop
tests, stress tests, alarms, fault conditions, power failure, recovery, speeds, security, and verification of procedures.

Performance Qualification (PQ)

Performance qualification (PQ) establishes documented evidence that provides a high degree of assurance that a specific
process will consistently produce a product or goods that meet its predetermined specifications and quality
characteristics.

PQ demonstrates actual performance with product or representative materials and batch sizes. The PQ relates to the
User Requirements Specification (URS) for the equipment. Placebo materials such as water or inactive powders may be
used to minimize costs; for example, a placebo formulation containing everything except the active drug or with a similar
material to represent the active drug is used to confirm acceptable performance. A full batch or equivalent representation
should be used. The key for the PQ is evaluating the Functional Requirements Specifications and tailoring the testing to
meet the project objectives.

Results / Summary Technical Report

Results from executed validation protocols are handled differently by organizations. Some may prepare a results
document associated with each completed protocol. After approval of results, the next protocol in a sequence of protocols
is initiated and completed. Other organizations may add results to protocol documents and approve the interim
document. Others may favor a final summary technical report (TR) containing all results from all protocols.

The TR summarizes and analyzes all data gathered during the respective qualification testing phase. Generally all work
specified in the protocol should be completed before writing the final TR. All data must be reviewed and approved. All
deviations and investigations associated with a protocol must also be closed. The TR may be a one-page summary or fifty
pages of technical data. Regardless of the size and scope, the content of the protocol and results must accomplish the
objective of the project.

The same people that signed the protocol usually sign the TR. A typical TR format will comprises the following:

 Purpose
 Scope
 Executive summary
 Results
 Deviations (if applicable)
 Follow up actions from the protocol (new SOP, maintenance review, continued verification)
 Final conclusion.

The acceptance criteria for the respective tests are the baseline for the TR. Did you do what you say you were going to
do? For example, are materials of construction as specified in technical specifications, and are functional parameters as
specified in functional specifications? All results should meet acceptance criteria. If they do not, deviations may be
appropriate.

Tables can be an helpful tool in reporting results. A typical table format is the following:
  Test #
 Test script (what you are doing)
 Expected results
 Actual results
 Pass / Fail.

The above order is generally an easy format to follow in that you can look at what was expected and compare it easily to
what was done. A reviewer can easily scan the document to ensure that testing met acceptance criteria.

There is no right or wrong way to write a report. Following a general format helps keep things organized. When it is
needed for review or an audit, the TR is clear, crisp, and concise and looks professional. Any action item generated from
the protocol should have an action tracking associated with it. Utilizing a compliant system is helpful to ensure that actions
that are specified are done as expected.

Protocol Problems

Protocol problems such as deviations, scope changes, amendments, and failures will always occur regardless of the time
and effort expended in planning, preparation, and writing.

Deviations. Deviations are the most frequently occurring protocol problems. Every protocol is written with great attention
to detail and with the purpose of flawless execution. Minor issues such as typos and “cut and paste” errors can
occur. Whatever the root cause, it is imperative that the problem is corrected and appropriately documented. The intent of
the deviation is to ensure that there is clarity and transparency with the work performed. If the validation work performed is
not presented accurately, the entire document becomes subject to greater scrutiny for not being forthright.

Deviation writing is typically structured through site specific procedures. Simple guidelines dictate that the following are
addressed:

 Deviation description -- what happened

 Initial response to the deviation -- containment
 Notification of deviation to affected groups
 Investigation, Depending on the nature of the deviation, this could be a one line item or a multi-page document
 Corrective action
 Preventive action
 Additional testing as required.

The key is transparency with the problem. Never hide the fact there is a problem and ensure that the problem is
addressed and documented.

Previous protocols with deviations are a source of information. These may alert the writer as to the potential for problems
so that deviation may be avoided. They also discuss how a deviation was addressed.

Scope Changes and Amendments. Scope changes may occur in a validation project after the project initiation document
has been written and approved. Scope changes may be legitimate – something unforeseen occurred that has changed
the project. Scope changes may also be the result of insufficient planning – obviously an undesirable occurrence. Scope
changes are addressed by amendments to documents. Validation documents requiring numerous scope changes and
amendments are a disaster. Scope changes and amendments reflect poorly on the project manager, protocol writer, and
the organization.

Failures and Non-Conformances. Authors of validation protocols should initiate validation when they are confident of
performance success; validation is considered to be confirmatory -- acceptable performance within acceptance criteria is
expected by regulatory auditors. Nevertheless, failures and non-conforming results will occur. These must be addressed
and corrected. Failed tests must be repeated with an explanation of corrective action. A failed validation test is a serious
problem that indicates a lack of understanding of the validation process – obvious negatively impacting the project
manager, protocol writer, and the organization.

POST-QUALIFICATION MONITORING AND MAINTENANCE

Post-validation activities are initiated when qualification testing has been completed and approved. Post-validation
activities for equipment maintenance are specified in manufacturer documentation and recommendations. These are
recorded in the IQ document. Equipment inspection, regular maintenance activities, routine lubrication, calibration, and
other routine activities are initiated in site systems. Periodic validation review and associated management review should
be initiated. Review frequency should be based on risk analysis. Post-qualification monitoring and maintenance are
consistent with Stage 3 of the lifecycle approach.

DOCUMENTATION

Everything associated with the validation project must be documented. This includes design activities, protocols and
testing, and post-validation monitoring and maintenance. Site functions associated with design and development are not
accustomed to being part of validation; their work is the basis for validation. Validation protocols and results must stand
alone for the lifetime of the validated system.

Regarding specific validation protocols, all validation documentation must be complete. All data spaces, blank lines, and
signature/date spaces must be filled. Good documentation practices must be followed in all documentation. All
documents must be approved by the site approval committee. The key is ensuring all base documents and data are
accurate and reliable. Data integrity is paramount. Data presentation must be appropriate to facilitate understanding,
analysis, and evaluation. Follow the FDA ALCOA (3) acronym: Attributable, legible, contemporaneous, original,
and accurate.

SUMMARY

This discussion has addressed topics associated with the preparation of equipment qualification protocols with focus on
hands-on practical advice. Significant points are the following:

 Protocols are critical documents. The importance of properly written protocols cannot be underestimated.
 Initiation of the validation project as early as possible is desirable. This enables all affected groups to begin
preparation of their respected input to the validation process.
 Design activities are the first grouping of activities in the equipment qualification process. These include
determination of the user requirements, functional requirements, and technical requirements.
 When design requirements are completed, the desired equipment is built.
 The validation plan including risk analysis is developed during design activities and equipment
construction. These documents provide vital information and direction for the validation protocols.
  Preparation for testing includes organizing future tests in advance and during system validation testing. Testing
must consider design requirements and risk considerations. Protocols required, tests required to be performed in
each protocol, level of testing, and test acceptance criteria are determined.
 System testing is executed in SAT/FAT, IQ, OQ, and PQ. IQ testing reflects technical requirements. OQ testing
reflects functional requirements. PQ testing reflects user requirements.
 A technical summary report is useful to summarize multiple validation protocols and present validation results in a
clear and concise format. A table format is recommended.
 Post validation monitoring and maintenance identified in the IQ ensures ongoing system performance throughout
the system lifecycle.
 Protocol problems include deviations, scope changes and amendments, and validation failures. Each of these
reflect negatively on the protocol writer and site validation program. Thorough and transparent discussion of
problems is required.
 Everything associated with the validation lifecycle -- design through system maintenance – must be
documented. FDA has identified the ALCOA acronym regarding data integrity.

REFERENCES

1. FDA. Guidance for Industry. Process Validation General Principles and Practices. January, 2011.
2. FDA (ICH). Q9, Quality Risk Management. June, 2006.
3. FDA. Guidance for Industry. Electronic Source Data in Clinical Investigations. September, 2013.