introduction to gamp4. 2 eurotherm life sciences group if it’s not documented it’s a rumour!

Introduction to GAMP4

2

Eurotherm Life Sciences Group

IF IT’S NOT DOCUMENTED IT’S A RUMOUR!

3


1994 – UK Pharmaceutical Industry Computer System Validation Forum set up (now known as the GAMP forum)

1994 – First draft issued

1995 – Version 1

1996 – Version 2

1998 – Version 3

2001 – Version 4

GAMP Guide History

With GAMP4, the target audience has been expanded from just pharmaceuticals to the whole healthcare industry including biotechnology and medical devices. The scope has been expanded to cover automated systems within Good Clinical Practice (GCP), Good Laboratory Practice (GLP) and Good Distribution Practice (GDP) in addition to the original Good Manufacturing Practice (GMP) environment.

4


GCPGDPGLPGMPGxP

URSVMP

IQOQPQ

SOP

Lots of Nasty Acronyms

GCP Good Clinical PracticeGDP Good Distribution PracticeGLP Good Laboratory PracticeGMP Good Manufacturing PracticeGxP All of the above!! Sometimes cGxP with ‘c’ for ‘current’

URS User Requirements SpecificationVMP Validation Master Plan

IQ Installation QualificationOQ Operational QualificationPQ Performance Qualification

SOP Standard Operating Procedure

5


GAMP4

Validation

Installation Qualification [IQ]

Operational Qualification [OQ]

Performance Qualification [PQ]

GAMP4 – “Good Automated Manufacturing Practice” as defined in the GAMP4 Guide for Validation of Automated Systems. A set of guidelines for both users and suppliers – MORE LATER!

Validation – “Establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its pre-determined specifications and quality attributes”

Installation Qualification [IQ] – “Documented verification that a system is installed according to written and pre-approved specifications”.

Operational Qualification [OQ] - “Documented verification that a system operates according to written and pre-approved specifications throughout all specified operating ranges”.

Performance Qualification [PQ] – “Documented verification that a system is capable of performing or controlling the activities of the processes it is required to perform or control, according to written and pre-approved specifications, while operating in its specified operating environment.

Jargon for ‘project’ activities

6


Calibration

Change Control

Life Cycle Concept

21 CFR part 11

Calibration – “The set of operations which establish, under specified conditions, the relationships between values indicated by a measuring instrument, or values represented by a material measure or a reference material, and the corresponding values of a quantity realised by a reference standard.”

Change Control – “A formal process by which qualified representatives of appropriate disciplines review proposed or actual changes to a computer system. The main objective is to document the changes and ensure that the system is maintained in a state of control.”

Life Cycle Concept – “An approach to computer system development that begins with identification of the user's requirements, continues through design, integration, qualification, user validation, control and maintenance, and ends only when commercial use of the system is discontinued.”

21 CFR part 11 – FDA regulation covering the use of electronic records and electronic signatures – MORE LATER!

Jargon continued…

7


Validation

What needs to be validated?

Pharmaceutical Process which produce drugs for the human and animal Consumption.

What is validated?• Process• Ensures that the process does what it supposed to do

backed with documentary proof.

Who is responsible for validation?The manufacturer is responsible for obtaining the validation.

What is validation?“Establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its pre-determined specifications and quality attributes”

8


Validation..

What could be our responsibility?

• Provide a system with documentary evidence that satisfies the Users requirement specification.

• The system documentary evidence will be integrated into the overall process documentation which will be submitted for the process validation.

9


Principle of validation

• Document what is to be done

• Document how it is to be done

• Do it

• Produce documented evidence that it was done in accordance with the “how”

• Demonstrate that it remains in a state of control

10


Where Does Process Validation begin?

• Validate the API process beginning at the point where the structure of the active ingredient become evident.

• Secondary Process

• Packaging

• Includes

• Storage

• Utilities

• HVAC

11


GAMP4 Structure

Principles and Framework- objectives of the Guide - overview of validation- validation lifecycle- IT systems- process control systems- benefits of validation- good practice definitions- glossary - source material.

AppendicesManagement activities - validation planning/reporting- risk assessment- project change control, etcDevelopment activities - specification- code production- testingOperating activities -service level agreements- performance monitoring- archive, etc

GAMP principles

and framework

APPENDICESManagement Development

Operation

GOOD PRACTICE GUIDES

TRAINING MATERIALS

12


Risk Assessment + Critical

Parameters

Vendor Preliminary Assessment

Specification Approval

Hardware Test

Specification

Produce Software

Produce Hardware

Hardware Acceptance

Testing

Integration

Software Integration

Testing

Factory Acceptance

Testing

IQ Protocol

Installation Qualification

Operational Qualification

Performance Qualification

Service Level Agreement

PLANNING AND DEFINITION

DESIGN AND DEVELOPMENT

DEVELOPMENT TESTING AND SYSTEM BUILD

DESIGN REVIEW AND ACCEPTANCE

ONGOING OPERATION

User Requirement Specification

OQ Protocol

Acceptance Test

Specification

Functional Design

Specification

Hardware Design

Specification

Change Control

Validation Plan

Supplier Quality

Plan

Supplier Detailed

Assessment

PQ Protocol

Software Module Test

Specifications

Software Module

Specifications

Software Module Testing

COMMISSIONING AND QUALIFICATION

Periodic Review

Performance Monitoring

System Security

Record Retention

Backup and Recovery

Business Continuity Planning

Validation Report

RETIREMENT Retirement

KEY: User Responsibility Joint Responsibility Supplier Responsibility

Desig

n R

ev

iew

an

d c

on

tinu

ed

Risk

Asse

ssmen

t

Pro

ject T

rac

eab

ility M

atrix

Pro

ject C

han

ge C

on

trol

Pro

ject D

ocu

men

t Man

ag

em

en

t

Pro

ject C

on

figu

ratio

n M

an

ag

em

en

t

13


GAMP Lifecycle

UserRequirements

Functional Specification

Hardware Design

Configuration/ coding

ProcessQualification

OperationalQualification

InstallationQualification

IntegratedTesting

Customer responsibility

EurothermresponsibilityHardware

Build

Jointresponsibility

OngoingOperation

Software Design

ModuleTesting

14



Hardware Design

Configuration/ coding

OperationalQualification


IntegratedTesting

HardwareBuild

Software Design

ModuleTesting

FAULT

Update requirements documentation

Update configurationConfiguration

Control

Re-Test

Document Control

Document Control

GAMP and Traceability

15


Risk Assessment +

Critical Parameters

Vendor Preliminary Assessment

Specification Approval

PLANNING AND DEFINITION

UserRequirementSpecification

Validation Plan

Supplier Detailed

Assessment

KEY:User ResponsibilityJoint ResponsibilitySupplier Responsibility

DESIGN AND DEVELOPME

NT

Design

Review

Traceability

Matrix

Change Control

Document

Management

GAMP4 Lifecycle – Planning and Definition

Validation planning (appendix M1)

Hierarchy of Validation Master Plans and individual system Validation Plans including:

•GxP criticality assessment

•validation strategy to cover the revised lifecycle model

•formal list of validation deliverables

•formal acceptance criteria for each lifecycle phase

•formal detail of change control and document management procedures to be followed

•formal list of SOP’s to be created or updated

•Actions and procedures required to maintain the validated state after handover from project to ongoing operation

Supplier Assessment (appendix M2)

Covering both preliminary assessment and detailed supplier audit.

Makes recommendations for audit planning and execution and also contains example checklists for both postal (preliminary assessment) audits and full supplier audits.

User Requirements Specification (Appendix D1)

Has to specify:

•Operational requirements (process control, calculations, etc)

•Data requirements (capacity, access, archive, etc)

•Interfaces (operator, other equipment, plant)

•Environment (layout, physical)

•Constraints (timescales, compatibility with other equipment, etc)

•Life Cycle (development / test requirements, deliverables, etc)

Risk Assessment (Appendix M3)

Covering risk assessment as part of the validation process.

Initial risk assessment during URS generation to identify how much validation effort is required and which areas are critical to GxP product quality, safety, environmental protection, or business continuity.

Review of the risk assessment during the design and development stage (to ensure that choice of supplier / implementation method has not introduced additional risks)

Review of the risk assessment at completion of the design review prior to validation testing (to ensure that any problems identified or work-arounds implemented have not introduced additional risks).

Once the system is in ongoing operation, risk assessment should form part of the ongoing change control strategy.

The appendix also describes an example risk assessment process used to identify risks, categorise according to severity and likelihood and determine appropriate mitigation strategies.

Design Review and Traceability Matrix (Appendix M5)

Covering design review planning and deliverables. Typically, a review is required at the end of each specification stage.

In order for the review process to be meaningful, a formal traceability of user requirements through to design documentation and tests carried out is required. An example traceability matrix format is provided.

Change Control (Appendix M8)

Change request, disposition and authorisation, completion and approval

Document Management (Appendix M10)

Production, approval, issue, change, withdrawal, records and storage

16


DESIGN AND DEVELOPMENT


DEVELOPMENT TESTING AND

SYSTEM BUILD

Design

Review

Traceability

Matrix

Change Control

Document

Management

HardwareTest

Specification

ProduceSoftware

ProduceHardware

Software Integration Test Spec

IQProtocol

OQ Protocol

Acceptance Test

Specification

Functional Design

Specification

HardwareDesign

Specification

SoftwareDesign

Specifications

SupplierQuality

Plan

PQ Protocol

Software Module Test

Specifications

SoftwareModule

Specifications

GAMP4 Lifecycle – Design and Development

Quality and Project Planning (Appendix M6)

Plan needs to include:

•User quality requirements (eg procedure references)

•Supplier quality system (certification details, activities to be undertaken, and procedures controlling these, responsibilities for each activity)

•Project Plan (eg Gantt chart)

•Project organisation (contacts, project team names and titles, interface to QA)

•Deliverable items (format, media)

•Activities (milestones, start/end dates for activities, allocation of personnel)

Functional Specification (Appendix D2)

Specification replies to technical requirements from URS and needs to include:

•Functional requirements (process control, calculations, etc)

•Data requirements (capacity, access, archive, etc)

•Interfaces (operator, other equipment, plant)

•Non-Functional Attributes (availability, maintainability)

Hardware Design Specification (Appendix D3)

Needs to include:

•Computer System (main computer, storage, peripherals, interconnections)

•Inputs and Outputs (instruments used, accuracy, isolation, range, timing)

•Environment (temperature, humidity, EMC, etc)

•Electrical Supplies (filtering, loading, earthing, UPS, etc)

Software Design / Module Design Specifications (Appendix D4)

Need to include:

Software Design Specification

•System Description (split into modules / interaction of modules)

•System Data (files, databases, etc)

•Module Descriptions

Software Module Design Specification

•Module Overview (function, split into sub-programs)

•Module Data (files, databases, etc)

•Sub-Program Descriptions (language, standards, functions, parameters, etc)

•Sub-Program Data (locally declared items)

Test Specifications (Appendix D6)

Need to include:

•Scope of Tests

•Overview and Test Plan (procedure for test execution, ordering of tests, personnel required, etc)

•Test Requirements (hardware, software, test equipment, test software/data, documentation)

•Test Scripts (unique reference, traceability to specification, pre-requisites, test instructions, data to be recorded, acceptance criteria, post test actions)

Software Production (Appendix D5)

Each module needs to address:

•Identification (name, version, controlling specification, history)

•Traceability (commenting of additions / deletions, cross reference to change source)

•Programming Standards

Source code review attempts to ensure that programming standards are applied and that modules are in accordance with specifications.

17




COMMISSIONING AND

QUALIFICATION

Design

Review

Traceability

Matrix

Change Control

Document

Management

HardwareAcceptance

Testing

Integration

Software Integration

Testing

Software ModuleTesting

Factory Acceptance

Testing

DESIGN REVIEW AND ACCEPTANCE

Configuration

Management

GAMP4 Lifecycle – Testing, Build, Acceptance

Testing (Appendix D6)

Test procedure (documented in specification) needs to address:

•Pre-requisites (availability of documentation, test equipment, test data etc)

•Testing Philosophy (witnessing requirements, documentation and retention of results, indelible recording of results, etc)

•Test Script Execution (what happens if acceptance criteria are met / not met?)

•Test Results File (completed tests, documentation of test incidents / faults, etc)

18


COMMISSIONING AND QUALIFICATION


ONGOING OPERATION

Traceability

Matrix

Change Control

Document

Management

Configuration

Management


Operational Qualification

PerformanceQualification

Validation Report

GAMP4 Lifecycle – Commissioning, Qualification

Installation Qualification [IQ] – “Documented verification that a system is installed according to written and pre-approved specifications”.

Operational Qualification [OQ] - “Documented verification that a system operates according to written and pre-approved specifications throughout all specified operating ranges”.

Performance Qualification [PQ] – “Documented verification that a system is capable of performing or controlling the activities of the processes it is required to perform or control, according to written and pre-approved specifications, while operating in its specified operating environment.

Validation Reporting (appendix M7)

New material detailing best practice for validation reporting for both individual lifecycle phases and the final validation report.

19


ONGOING OPERATION


RETIREMENT Retirement

Service Level Agreement

ChangeControl

Periodic Review Performance Monitoring

System Security

Record Retention

Backup and Recovery

Business Continuity Planning

GAMP4 Lifecycle –Ongoing OperationAppendix O1 – Periodic Review

Guideline for establishing whether validated state is being maintained (checking operation of O2 to O8 plus assessing changes in environment, legislation, operating procedures, personnel)

Appendix O2 – Service Level Agreements

Procedure for defining support requirements and agreeing support provisions between user and supplier (including control of fault reporting, workarounds / patches / upgrades, spares / consumables, routine calibration, support for software tools / hardware / infrastructure etc)

Appendix O3 – Automated System Security

Guideline for ensuring control, integrity, availability and confidentiality of data.

Appendix O4 – Operational Change Control

Guideline for review, risk assessment, authorization, documentation and re-test of changes. Allows exclusion of like-for-like replacement and emergency repairs (though emergency repairs must undergo the same review and control ‘after the event’).

Appendix O5 – Performance Monitoring

Guideline for parameters to be monitored (eg disk utilization, response times) and appropriate notification mechanisms.

Appendix O6 – Record Retention, Archiving and Retrieval

Guideline to address retention (security, indexing, availability during full retention period, etc) of all GxP records. Particular requirements for electronic record archival and retrieval.

Appendix O7 – Backup and Recovery

Guideline for data and software backups to guard against physical loss or accidental deletion.

Appendix O8 – Business Continuity Planning

Guideline covering broad issues of business continuity planning including risk assessment; disaster recovery procedures; contingency planning; emergency response planning; training; and rehearsal of the continuity plan.

Appendix O9 – EU Guideline on Computerized Systems

APV Specialist section interpretation of the Annex 11 ‘Computerized Systems’ points.

20


GAMP Hardware and Software Categories

- Risk of failure increases with the progression from standard to bespoke.

- Many systems are built up multiple components of various categories.

- Validation strategy needs to reflect this in order to ensure that effort is correctly focused.

21


GAMP Software Categories (1)

CATEGORY 1 – Operating Systems

VALIDATION APPROACH - Record version (include service pack). The Operating System will be challenged indirectly by the functional testing of the application.

PROCESS CONTROL SYSTEM EXAMPLES

Instrument operating system is usually not separable from firmware – see category 2

Most SCADA or DCS workstation software runs on one of the Microsoft Windows ® operating systems

22



CATEGORY 2 – Firmware

VALIDATION APPROACH - For non-configurable firmware record version. Calibrate instruments as necessary. Verify operation against user requirements.- For configurable firmware record version and configuration. Calibrate instruments as necessary and verify operation against user requirements.- Manage custom (bespoke) firmware as Category 5 software


Instrument firmware including set-up parameters.

3-Term Controllers, Recorders, etc

23



CATEGORY 3 – Standard Software Packages

VALIDATION APPROACH - Record version (and configuration of environment) and verify operation against user requirements. - Consider auditing the supplier for critical and complex applications.

PROCESS CONTROL SYSTEM EXAMPLESProvided that ‘off the shelf’ solutions are purchased rather than creating bespoke toolkits:

Historical data viewersStatistical analysis packagesConfiguration management toolsApplication development toolsDiagnostic tools

24



CATEGORY 4 – Configurable Software Packages

VALIDATION APPROACH - Record version and configuration, and verify operation against user requirements. - Normally audit the supplier for critical and complex applications.- Manage any custom (bespoke) programming as Category 5. PROCESS CONTROL SYSTEM

EXAMPLES

Control schemes configured from library blocksSimple mimicsRecipes

25



CATEGORY 5 – Custom (Bespoke) Software

VALIDATION APPROACH - Audit supplier and validate complete system .


Sequence Function ChartsCustom reporting using SQL queriesComplex mimics running scripts

26


GAMP Software Categories Spreadsheets / Tools

Special Considerations for Spreadsheets

Can fall into category 3, 4 or 5 depending on use.Examples:Category 3 – used purely to generate a paper documentCategory 4 – more complex application involving templatesCategory 5 – spreadsheet application using custom macros

Application Development and Diagnostic Tools

Can be bespoke or off-the-shelfValidation requirements depend on software category and on whether the tool directly supports the business process (eg application builder) or only supports the development or management of applications (eg configuration management tool)

27


GAMP Hardware Categories

CATEGORY 1 – Standard Components

VALIDATION APPROACH - Record model, version, serial number. Verify correct installation / connection. Apply change control.

CATEGORY 2 – Custom Built Components

VALIDATION APPROACH - As for standard components but also require a design specification and acceptance test. Supplier may be audited.

28


AIM – to understand how Eurotherm interprets the GAMP

lifecycle and software / hardware categories

The Eurotherm GAMP Offering

29


Visualsupervisor

2500 I/O

EurothermSuite Server / Viewer

Example Architecture 1 – Control System

Profibus

ALIN

Ethernet

30


2500

T800

Visualsupervisor

2500 I/O

EurothermSuite Viewer

1 – Operating System

5 - Custom Software

3 – Standard Software Package

2 - Firmware

4 - Configurable Software Package

PC

Windows NT

Eurotherm Suite

Continuous Controland mimics

Database, Security, Alarming, Mimics,Trending.

GAMP4 SOFTWARE CATEGORIESY

1 – Standard Components

2 - Custom Built Components

GAMP4 HARDWARE CATEGORIES

PC

2500

T800

HARDWARE SOFTWARE

Sequencing

Example Categorisation 1 – Control System

31


Example Architecture 2 – Graphic Recorders

Ethernet

5180V 5180V

PC viewer running

Bridge 5000

Data PC running Review

32


Example Categorisation 2 – Graphic Recorders

Software Categorisation1 – operating system 5 - coded3 – ‘off the shelf’2 - parameterised firmware 4 - configured

Remote PC PCWindows NT Windows NT

(inc ftp server)ReviewBridge 5000

5180V

5180V 5180V

5180V

Review configuration

ConfigConfig

Recorder configurations shown as category 4

Also available treated as category 2 for simple configurations only (no user screens, no maths channels)

33


Project Deliverables Compared

ProduceSoftware

ModuleFS +TS

Integrated Test

IQSpec


PLANNINGAND

DEFINITION

SPECIFICATION, DESIGN,

CONSTRUCTION


COMMISSIONING AND

QUALIFICATION

COMPLETION OF QUALIFICATION AND ONGOING OPERATION (TO CUSTOMER PROCEDURES)

HardwareDS + TS


ProduceConfiguration

ProduceHardware

Internal Test

Standard IQ Spec


Standard Functional Spec

Category 2 Graphic Recorder Category 4 / 5 Visual Supervisor

SW Module Test

ProduceHardware

Hardware Test

OQSpec

Quality Plan

Factory AcceptanceDESIGN REVIEW & ACCEPTANCE

End Slide

introduction to gamp4. 2 eurotherm life sciences group if it’s not documented it’s a rumour!

Documents