Process Validation

1
Rocky Mountain RAPS

• Process Validation
• Presentation
• 6/7/06
• By Clay Anselmo

2
Learning Objectives

• Understand the purpose of process validation.
• Understand the key components of a good process
  validation (IQ, OQ, PQ).
• Understand how these elements and their
  definitions have changed over the years.
• Be able to categorize processes and determine the
  extent of validation required.
• Understand documentation requirements for
  validation and the process for storage and
  retrieval of these documents.

3
Concepts and Definitions

• Lets be perfectly clear!
• Process Validation (QSR) Establishing by
  objective evidence (documented) that a process
  consistently produces a result or product meeting
  its pre-determined specifications.
• Design (Product) Validation Establishing by
  objective evidence (documented) that device
  specifications conform with user needs and
  intended use(s).

4
Concepts and Definitions

• Verification Confirmation by examination and
  provision of objective evidence that specified
  requirements have been fulfilled.
• Prospective Validation A validation that
  establishes documented evidence that a product or
  process conforms to its specifications prior to
  final release of the product or process.
• Retrospective Validation A validation that
  establishes evidence that a product or process
  performs to its specifications based on a review
  and analysis of historical performance data.

5
Concepts and Definitions

• Installation Qualification (IQ)
• Installation and Installation Conditions
  (electrical, air, water, etc.)
• Calibration and Preventive Maintenance
• Safety Features
• Complete Documentation including equipment and
  software
• Environmental Conditions
• Training
• Does NOT typically require statistically based
  sampling or data analysis

6
Concepts and Definitions

• Operational Qualification (OQ)
• Show equipment functionality over the range of
  specifications
• Show equipment stability and capability in worst
  case conditions (considering all process inputs)
• Equipment settings
• Raw material
• Supply variations (air, water, etc.)
• Establishment of action and alert limits as
  appropriate
• Confirmation of failure modes
• Uses valid statistical methods for analysis of
  data and variation

7
Concepts and Definitions

• Performance Qualification (PQ)
• Demonstrate longer-term stability and capability
  of the process under nominal conditions
• Evaluates acceptability of product against
  specification
• Utilizes valid sampling and statistical
  techniques
• Multiple Lots
• Multiple Operators

8
Concepts and Definitions

• WHEN IS IT NECESSARY TO PERFORM VALIDATION?
• 21 CFR 820.75 Where the results of a process
  cannot be fully verified by subsequent inspection
  and test, the process shall be validated with a
  high degree of assurance
• ISO 134852003 The organization shall validate
  any processes for production and service
  provision where the resulting output cannot be
  verified by subsequent monitoring and
  measurement. This includes any processes where
  deficiencies become apparent only after the
  product is in use or the service has been
  delivered.

9
GHTF Flow Chart
10
Concepts and Definitions

• What/When Processes Should be Validated?
• End product tests that verify device conformance
  to specifications and requirements
• When destructive testing is required to show
  product conformance to specification
• When even state-of-the-art testing methods cannot
  demonstrate conformance to specification
• Process capability is unknown or it is suspected
  that the process is barely capable of meeting
  device specifications

11
Validation Overview

• Define product requirements and specifications
• Define process inputs/outputs and specifications
• Plan the validation process
• Develop Protocols
• Test Method Verification / Validation
• Measuring equipment suitability (i.e. gage RR)
• IQ Installation Qualification
• OQ Operational Qualification
• PQ Performance Qualification
• Execute Protocols

• Compile and Analyze Data
• Corrective Action and Re-execution as Necessary
• Create / Approve Final Report

12
Validation Planning Elements

• Why Create a Validation Plan
• Allows quick overview of validation activities
• Reduced approval cycle iteration
• Pre-Requisites
• Clear Requirements/Specifications
• Basic Test Methods (verified or validated)
• Test Definition/Description
• Plan should include a clear description of each
  set of tests to be performed
• Purpose
• Plan should contain the purpose of each set of
  tests

13
Validation Planning Elements

• Requirements
• Plan should briefly describe the requirements for
  each set of tests and be traceable to product or
  process specifications
• Acceptance Criteria
• Plan should contain the general acceptance
  criteria for each set of tests or cross reference
  the location.
• Analytical Techniques
• Define the method for analyzing data using
  commonly accepted statistical techniques.

14
Protocol Development

• All Validations should be executed per a formal,
  pre-approved protocol
• Pre-approval is not a regulatory requirement,
  just a good practice that prevents delays and
  re-executions.
• Protocol format is OPTIONAL but must include the
  following key sections
• Purpose / Background
• Configuration of product or process
• Material and Equipment (including Calibration
  data)
• Sampling, Data Analysis Methods
• Test Procedure
• Clear Acceptance Criteria

15
Protocol Development

• Key Protocol Sections (cont.)
• Data Sheets
• Conclusions
• Deviations
• Revision History
• Key Points
• Provide background and justification for approach
• Ensure test method is appropriate (verified or
  validated)
• Protocol Review
• Protocol Pre-Execution Approval

16
Validation Completion

• Execution
• Follow the protocol!
• Note any deviations
• Use good documentation practices
• Sign the data sheets
• Collect equipment calibration information
• Make sure training is documented

17
Validation Completion

• Final Report
• May be an addition to protocol or a separate
  document
• Summarize the results specifically related to
  each test or challenge
• Document and justify your deviations
• Deviations are not for changes to acceptance
  criteria
• Document your data analysis
• Reach formal conclusions regarding the overall
  outcome of the validation
• Needs approval

18
Special Considerations

• Deviations
• Document all deviations from pre-approved
  procedure in the Deviations section of the
  protocol.
• Changes to acceptance criteria should be
  documented in the protocol and re-approved prior
  to re-executing the testing.

19
Special Considerations

• Test Method Verification
• Suitability of Test Instrumentation
• Gage Accuracy and Sensitivity
• Operator Variation
• Characterization of Alpha and Beta Errors
• Training and Confirmation of Effectiveness
• Yes, it applies to visual inspection, dimensional
  verification, and automated test methods

20
Software Validation

• Equipment With Embedded Software
• Software must be validated
• Can be done stand-alone (if possible), or as a
  part of verifying equipment function (IQ or OQ)
• Requires an understanding of the software logic
  and the functions to be utilized
• Should include nominal/margin testing and error
  handling

21
Special Considerations

• IQ / OQ / PQ
• Question Does it really matter what goes where?
• Answer Sometimes, if one validation activity
  depends on others. (i.e. training)
• Question I often hear the terms PQ, PPQ, Product
  Performance Qualification, Process Performance
  Qualification. Whats the difference??
• Answer These are often defined differently
  across organizations. However, typically PQ is
  the overarching term that refers to both process
  and product performance qualifications.

22
Common Mistakes

• Poor Organization
• Lack of program structure
• Lack of templates and rules for ensuring program
  consistency
• Poor Planning
• No documentation to tie stand-alone validations
  together (i.e. Master Validation Plan)
• No method to ensure re-validations occur when
  required (i.e. sterilization)
• Poor Documentation
• Little background information
• Story not told
• No links to CO/ECO process to ensure changes do
  not invalidate prior validation activities