Trevor Schoerie

It seems everything is automated?

Automatic Flush Proxy sensor and lowers the seat In seat heating for extra comfort A t Automated t d environmental i t l controls t l Paperless

GAMP - ISPE
We would like to acknowledge that a significant portion of the material presented today is subject to the copyright of the ISPE. We strongly urge you, or your organisation to purchase copies of this guide.

Presentation structure
We are discussing a book with complex concepts. Attempt Att tt to b bring i t together th th the other th t talks, lk GAMP 5 i is a holistic approach, it cannot be seen in isolation. Recap on GAMP history and GAMP 4 GAMP 5 Risk Based Approach p Business processes Continuous Monitoring = No Validation Expand p on categories g

GAMP History

Recap GAMP 4
GAMP - Good Automated Manufacturing Practice GAMP 4 issued December 2001
No reference to ICH documents Mentioned Risk in Section M3, and hardly mentioned in the main text. Referred R f d to t th the old ld ISO 9001-4 9001 4 system t 5 software categories, increasing risk

GAMP 5 The Guide

Principles and Framework 8 Sections
1. 2. 3. 4. 5. 6. 7. 8. Introduction Key Concepts Life Cycle y Approach pp Life Cycle Phases Quality Q y Risk Management g Regulated Company Activities Supplier Activities Efficiency Improvements

GAMP 5 The Appendices

Appendix in five sections g 1. Management 2. Development 3 Operation 3. 4. Special Interest 5. General

Why is GAMP so important?

GAMP was primarily developed by industry PIC/S Annex 11 on computerised systems only states they Computers Systems have to be validated, validated not how In the PIC/S No Annex on CSV, yet! CSV is a topic to be inspected by specialists

GAMP is endorsed by International Regulators l

Extent of our Validation effort?

Burning Question How much validation is enough?

Continuous Quality Verification

Where Where a computer system is regarded as one component of a wider manufacturing process or system, particularly in an integrated QbD environment, specific and separate computerized system validation may not be necessary. necessary This environment requires both complete product and process understanding and that the critical process parameters can be accurately and reliably predicted and controlled over the design space. In such a case, the fitness for intended use of the computer system within the process may be adequately demonstrated by documented engineering or project activities together with subsequent Process Validation or continuous quality verification of the overall process or system. The same principle applies to the adoption of Process Analytical Technology (PAT). (PAT) For automated manufacturing equipment, separate computer system validation should be avoided. Computer system specification and verification should be part of an integrated engineering approach to ensure compliance and fitness for intended use of the complete automated equipment.

Perhaps a little controversial

GAMP 5 assists us with how we can apply a risk based approach when determining how much validation is required. required So - Risk is Severity of Impact Likelihood of Occurrence Probability of Detection As our Likelihood of Occurrence is 0%, risk = 0, therefore no validation As our probability of detection is 100%, risk = 0, therefore no validation (Continuous Monitoring, Monitoring or PAT)

How do we practically use this risk b d approach? based h?

Dr. H. Gregg Claycamp
Director, Division of Compliance Risk Management and Surveillance, FDA, CDER Office of Compliance.

There is no magic formula, system, methodology! It is a multi disciplinary team applying an agreed methodology, making an educated and experienced judgement and then seeking ways to mitigate the risk. This obviously must be documented.

Four major life cycle phases

Seven+ times, ouch!

1 2 3 4 5 6 7 +

Change Control Risk in Operation

The FDAs analysis of 3140 medical device recalls conducted between 1992 and 1998 reveals that 242 of them (7 (7.7 7 %) are attributable to software failures failures. Of those software related recalls recalls, 192 (79%) were caused by software defects that were introduced when changes were made to the software after its initial production and distribution.

Risk Decision Tree

Project risks
1. 2 2. 3. 4. Is this GxP? Before a validation plan? Risk based decisions during planning. planning Functional risk assessments. Risk-based decisions during test planning. 5. Risk-based decisions during operation.

Design Design Space Space

Critical Quality Attributes (CQAs) Critical Process Parameters (CCPs) Quality by Design Continuous Quality Monitoring PAT Business Process and predict rules Software / Hardware Categories

Software categorisation
GAMP recognises five levels of software increasing in risk with Level 5 ("bespoke") requiring the most attention. Category g y 1 - Infrastructure Software. Software used to manage the operating environment examples are Operating Systems, Database Engines, Networking tools

See the GAMP Good Practice Guide: IT Infrastructure and Compliance Guide
Category 2 - This Category is no longer used in GAMP 5 Category 3 - Non-configured COTS software, ft Instruments I t t Category 4 Configured Software such as LIMS, , SCADA, , ERP, , DCS, , EDMS, , BMS and CRM. Category 5 - Custom applications Software custom designed and coded to suit the specific business process

Hardware categorisation
GAMP recognises two levels of hardware Hardware Category 1 - Standard Hardware Components The majority of the hardware used by regulated companies will fall into this category. Standard hardware components should be documented including manufacturer or supplier details, and version numbers. Correct installation and connection of components should be verified. The model, version number and, where available, serial number, of preassembled hardware should be recorded. Hardware Category 2 - Custom Built Hardware Components These requirements are in addition to those of standard hardware components. Custom items of hardware should have a Design Specification (DS) and be subjected to acceptance testing testing. The approach to supplier assessment should be risk-based and documented. In most cases a Supplier Audit should be performed for custom hardware development. development

The Basic V V Model

User Requirements S ifi i Specification related to
Design Constrains

Performance Qualification Operational Qualification Installation Qualification

Functional Specification

related to
Power On

Design Design Review Specification

related to
Power P Off

Measurable

System Build

The Basic V V Model

User Requirements S ifi i Specification Functional Specification

Initial Risk Assessment

Performance Qualification Operational Qualification Planning

Testing Risk Assessment Design Specification

System Functional Build Risk
.

Risk A t Assessment Installation Qualification

Risk Assessment / V - Model

Practical Advice on designing your d documentation. i

Recommend embedding Risk Assessment into i existing i i documents d

Functional Risk Assessment

Traceability and testing

Requirements Traceability Matrix

Criticality on testing
Table M3.5: Example on use of Risk Assessment Results Function Low Risk Medium Risk Verify normal data is Boundary testing : 1 value Input Function with accepted 10, 1 value above 20 Acceptable Data Range of 10.0 20.0 Null value challenge High Risk Boundary testing: 9.9, 10.0, 10.1, 19.9, 20.0, 20,1 Null value challenge Incorrect decimal precision Alpha character Temperature p Control for an Instrument or Verify y calibration p procedures Verify y accurate calibration throughout operating range 3-Point boundary testing for alarms Verify y accurate calibration throughout operating range 6-point boundary testing for alarms Challenge control precision against defined process Run test case to determine parameters that system can track and trace availability of rescue drug kit for specific subjects

Vessel

Interactive Voice Response System

Verify that the system is connected via a toll-free number

Run test case to verify that an error message is returned if the subject is

Test date value entry and under 18 years old age calculation against local system date

Risk Assessment
As an industry we must develop simple, easy to use Risk Assessment methodologies and where possible, embed these in existing documents, forms and practices. We need to develop tactics to do cost effective risk assessments. We should use GAMP, ISPE C&Q Volume 5 to help.

Risk Assessment

Numerical Scores
It is common to see companies wanting to y can measure the risk so that they demonstrate a risk reduction! Usually the scores are multiplied, multiplied we strongly recommend only using 1,2 and 3. SOD risk method. The highest risk number is 3 x 3 x 3 = 27. 27

Practical tips
1. Prepare, do not waste your experts time. 2 One person, 2. person an SME, SME pencils in their best guess. 3 Get 3. G t an outstanding t t di chairperson, h i err on the side of caution 4. The less probable the risk, the less likely we will predict it. it 5. Use a simple system and scale.

Practical example
Skid Mounted, COTS, Purified Water y , producing p g 1000 litres an hour into a System, 5000 litre tank. Purified water specifications are: Conductivity 1,3S/cm2 Mic obial Limit 100 CFU Microbial TOC 500 ppb pp

PLC in the system

This water system has a PLC which controls the: RO pressures distribution di t ib ti loop l pressure tank levels hot water sanitation loop temperature.

What if you have continuous online monitoring? i i ?

For? Pressures Temperatures Conductivity TOC Microbial

PAT The value?

Why do we measure TOC, continuously online? It is an easily applied Process Analytical Technology (PAT). (PAT)

The End

ICH PIC/S

GAMP