Validation perceptions that may slow PAT development and implementation Steve Hammond Pfizer Global Manufacturing

Objective for this presentation l PAT will take significant resources to develop and implement l Stated intent of FDA u “Enforcement policy does not impede innovation or introduction of new manufacturing technologies” u Process Analytical Technologies l Examples of the sort of things that might impede innovation and development of PAT l Avoid the “Cart before the horse paradigm”

Outline l Activities involved in developing and implementing PAT l Software Validation l Instrument PQ Tests during development l Concerns for the future - on-line analysers and performance compliance

Implementation activities l Hardware development u Identify an instrument u Have an instrument adapted to meet needs u The easy bit, purely science based l Software specification u Science based - but u Validation is an issue - while developing the system u Part 11 compliance a particular issue l System validation - during development u Plan and documentation u Perception is - FDA require full GMP protocol u Variable - plant \ country dependant

Internal regulatory groups l Instrument qualification must be complete l Includes Performance Qualification l PQ is written before the application is fully developed u What should we test? How do you measure performance on the real system l Revised under change control and repeated when the instrument requirements are better understood

Software validation - Pt 11 l Pfizer will only purchase software from audited and approved suppliers. Includes Pt 11 compliance. l Vendors have been forced to put in large amounts of resources to provide “validateble software.” These efforts take time and money. l Part 11 compliance means at least a new version of software, sometimes a complete re-write. u New software is always a pain, if not a nightmare u There will always be bugs u Change control procedures then become a large burden while testing the “fixed” versions l Over time compliance to Pt 11 will be the way of life l In the meantime it is slowing the development of PAT

Internal regulatory groups l Perception is that Pfizer can not use non compliant software in a GMP area l Must be pre-validated including Pt 11 compliance l IQ must be performed, signed off before data collection can begin. ~1 weeks work l Small bug fixes require change control report l Large bug fixes = new version = re-qualification

Internal regulatory groups l Data processing protocols l How will you get the result l Has to specified before and data is collected l “Mission impossible” “cart before the horse”

Implementation activities - time l Example - development of on-line blender system u Cost in terms of man weeks l Hardware development 15 l Software specification 1 l System validation protocols101 l Total117 weeks l 117 weeks arises from constantly repeating change and review cycle, for documentation,as development unfolds

Instrument performance tests l Science Vs tick the box l One “specification fits all” paradigm (USP) is documentation based, lacks scientific logic and represents a risk to the measurements l Vendor specifications based on science should be applied by users to ensure the base performance of the instrument. l Vary significantly with the type of instrument

Performance tests What Pfizer uses What USP says is OK

On-line instruments l Probes in a reactor cannot be removed to perform USP tests. l Alternative “performance” tests can be devised but they would be non-compliant with USP l Again the USP should not be looking for one specification fits all l Instrument performance testing is best prescribed by the vendor on a science base

Conclusions l Proper validation of PAT systems must of course be performed l However during development and information gathering stages, it can drastically slow progress l Lets have the horse before the cart, and be flexible in the approach to validation during development l Base performance qualification tests on science not lowest common denominator and ease of documentation