gamp 5 overview

7/23/2019 GAMP 5 Overview

1/80

/

GAMP 5 Overview

Paul Fenton

January 2013


2/80

/ Overview

Introduction to GAMP5

Differences between GAMP4 and GAMP5 How to use GAMP5 effectively

What the regulations say

High level overview of the key concepts of GAMP5

Quality Management V Model

Lifecycle Phases

System Categories

Documentation Required Procedures

Supplier Management


3/80

/ Introduction to GAMP5

GAMP 5 - A Risk-Based Approach to Compliant GxP

Computerized Systems

Is a framework for developing, qualifying,

validating and maintaining systems used in GxP

Is produced by ISPE Is widely used within the pharmaceutical

industry

Is understood by inspectors Is not a regulatory requirement but rather a

pragmatic guidance


4/80


GAMP provides practical guidance that:

facilitates the interpretation of regulatoryrequirements

establishes a common language and

terminology promotes a system life cycle approach based on

good practice

clarifies roles and responsibility

Focuses on patient safety, product quality and

data integrity


5/80


Aims to be compatible with other methods, models

and schemes including: Quality systems (IEEE, ISO 9000 Series)

Organization Capability and Maturity (CMMI)

Software processing models (ISO 12207) Software development models (RAD, Agile, RUP,

XP)

IT Service Models (ITIL)

Is composed of a main body and multiple appendix

with practical resources


6/80


Rationale for GAMP 5 To align with ICH guidance

Q8 Pharmaceutical Development

Q9 Quality Risk Management Q10 Pharmaceutical Quality System

To align with FDA cGMPs for the 21st Century

To align with updated PIC/S PI-011 guidance

To align with other standards from ISPE


7/80

/

GAMP 5

GAMP Drivers

EffectiveGovernance to

Achieve and

Maintain GxP

Compliance

Configurable

Systems

and Development

Models

Use of Existing

Documentation

and Knowledge

Effective

Supplier

Relationships

Scalable

Approach to GxPCompliance

Life Cycle

Approach

within QMS

Quality by

Design (QbD)

Continuous

Improvement

within QMS

Critical QualityAttributes (CQA)

Improving GxP

Compliance

Efficiency

Science Based

Quality Mgt

of Risks

Focus on Patient

Safety,

Product Quality,and Data Integrity

Source: ISPE GAMP 5 Guide


8/80

/ Differences between GAMP4 and GAMP5

The numbering of the sections of the guide have changed

significantly The system lifecycle approach has been expanded

significantly to encompass the full system lifecycle from

concept through project to operation and retirement

Guidance on risk management significantly enhanced

Increased guidance on system governance

More focus has been put on leveraging supplier

documentation new section on suppliers

Category 2 systems (Firmware) no longer exists

Risk Asssessment has become Quality Risk Management in

line with ICH Q9

www.ispe.org/publications/gamp4togamp5.pdf
http://www.ispe.org/publications/gamp4togamp5.pdfhttp://www.ispe.org/publications/gamp4togamp5.pdfhttp://www.ispe.org/publications/gamp4togamp5.pdfhttp://www.ispe.org/publications/gamp4togamp5.pdfhttp://www.ispe.org/publications/gamp4togamp5.pdfhttp://www.ispe.org/publications/gamp4togamp5.pdf


9/80

/ How to use GAMP effectively

Remember that GAMP is a framework and not a

regulatory requirement

Use the elements of GAMP that make sense for

your company and activities

If you reference GAMP in your procedures, youshould indicate which areas of GAMP you are using

Try and adopt GAMP terminology to facilitate

understanding of your SDLC

Remember the aim of GAMP is to improve the

quality and reliability of GxP systems whilst

reducing the burden of such systems


10/80

/ Principal Regulations and Guidance

21 CFR Part 11 Electronic Records; Electronic

Signatures

Eudralex Volume 4 Annex 11

ICH Q9 Quality Risk Management

General Principles of Software Validation; Final

Guidance for Industry and FDA Staff


11/80

/ What the regulations say

Principle Requirements

We need to have formal system documentation

which is maintained under change control

We need to validate systems to ensure that they

are fit for thier intended use

We need to apply a risk based approach based on

patient safety, product quality and data integrity

We need to have adequate change andconfiguration management procedures


12/80

/ Key concepts of GAMP5

DevelopMedicinalProducts

ProduceMedicinalProducts

Market andDistribute

MedicinalProductsUser

DevelopProducts and

Services

Deliver Productsand Services

Maintain andSupport

Products andServices

Supplier (ofcomputerized

systems and

services)

Product and Process Understanding

Life Cycle Approach within a QMSScaleable Life Cycle Activities

Science Based Quality Risk Management

Leverage Supplier Involvement



13/80

/ Quality Management

A well designed system lifecycle should:

be an intrinsic part of the companys quality system

Allows for continuous system and process

improvements based on:

Periodic review

Operational and performance data

Root cause analysis of failures

Ensure assurance of quality and fitness for intended use

Ensure regulatory compliance

Facilitates a QbD approach


14/80

/ Lifecycle Approach

Good Engineering Practice

ProductKnowledge

Process

Knowledge

Regulatory

Requirements

Company

Quality Reqs

RequirementsSpecification

and DesignVerification

Acceptance

and Release

Risk Management

Design Review

Change Management

Operation and

Continuous

Improvement



15/80

/ V Model

15


16/80

/


17/80

/ System Documentation General

Requirements

System documentation varies based on the category, risk,complexity and novelty of the system

If system documentation is to be produced electronically,

then it should be maintained in a 21 CFR Part 11 / Annex 11

compliant way

Ensure that all documents meet ALCOA

Establish clear versioning and documentation IDs/Names

Keep documents in draft until development is complete to

minimize overhead (ensure adequate control)

Link to the traceability matrix and maintain under version /

change control


18/80

/ System Description

High level document which describes the hardware

and software components of the system

EU GMP Annex 11, Clause 4, requires that there is

an up to date description of every GxP regulated

computerized system It should also describe:

Principles

Objectives

Scope of the system

Security features

Main functions


19/80

/ System Description

Identify GxP process which will be governed by thesystem

Use diagrams to describe the hardware and

software components

Use non technical language where possible

Describe how the system is used

Describe any interactions with other systems

Define any procedures which will be used in

conjunction with the system


20/80

/ User Requirements Specification

Should be a structured document which describes

high level and detailed user requirements TheWhat

Group requirements by functional area

Requirements should be concise and measurable Think about how requirements will be tested

Avoid combining requirements as this complicates

testing

Provide each requirement with a unique identifier

Ensure the document is versioned and aligned with

the traceability matrix


21/80

/ Functional Specifications

Document which describes How the system should meet

the user requirements Establish a formal standard for functional specifications

Define a high level overview of the different

components/functions and thier relationships

Identify the different functions and describe:

The process

The inputs

The process

Critical calculations or algorithms

The outputs

Error handling


22/80


Use screen mockups to help define user interface

specifications

Establish performance and scaleability requirements

Identify each function with a unique identifier

Use process diagrams wherever possible

Establish clear links to user requirements thorough the use

of the traceability matrix

Use consistent naming conventions

Formal testing is done on FS, so ensure that it is measurableand link to tests in the traceability matrix

Ensure the programmer understands the FS

Identify when design review needs to occur


23/80


The FS should also define data characteristics

including:

Data field definition

Data range

Required fields

Data validation checks

Data relationships

Data capacity, retention and archiving

Data integrity and security


24/80

/ Configuration Specification

Specific configuration specifications (CS) may be

required for the system if it is a category 4

CS may be produced for a specific client if a

category 5 system is deployed and configured in the

clients environment CS are typically produced by the vendor and

reviewed by SMEs at the client organization

CS should clearly cross reference the version of thesystem for which they have been written


25/80

/ Design Specifications

Technical document which describes how the system is to

be developped Should allow the reconstruction of the system

Should describe all classes and reference functions in the FS

Establish a class design model

Class descriptions should include: All inputs, outputs and parameters

System flow diagrams

Technical description of algorithms

Error handling and checking

Data mapping

Display screens and Reports (format, when generated,

which data)


26/80

/ Design Specifications

Database design should include:

Physical and logical database diagram with allrelevant keys, indexes and releationships

Data dictionary with table name, field name,

data type, size and required Y/N Description of all stored procedures, views and

triggers

Identify when Design reivew is required

If using an iterative or agile approach, identify

whether several DS will be developed or a

cumulative document will be produced


27/80

/ Coding

All code should be versioned using a source code

management system i.e. SourceSafe, SVN etc. Code should be properly documented through the use of

cartouches and in-code comments

Formal coding conventions should be used to define how

code is structured and code elements are identified Formal, documented and independant code review should

be undertaken for each version/iteration of code

Source file names should be referenced in the DS

Released code should fall under change control


28/80

/ Testing of Computerized Systems

Testing fulfills objectives such as:

identifying defects so they can be corrected or removed

before operational use

preventing failures that might affect patient safety,

product quality or data integrity

providing documented evidence that the system

performs as specified

demonstrating the system meets its requirements

providing confidence that the system is fit for its

intended use

providing a basis for user acceptance

meeting a key regulatory requirement


29/80

/ Test Plan

Also known as Validation Plan

The test plan (TP) should include:

Clear roles and responsibilities

Test strategy based on risk assessment, system

category, complexity and novelty

List of document deliverables

List of governing procedures

System intended use and acceptance criteria

Aim to produce the TP at the same time as the

specifications


30/80

/ Test strategy

The test strategy should include: The types of testing required

The different test protocols/specifications

required and thier purpose

Use of existing documentation (supplier)

Details regarding the different test phases

Test evidence required

Non-conformance procedure

Test metrics


31/80

/ Testing Documentation Typical Structure

Test Protocol /Specification

Test Plan /

Strategy (VP)

Test Cases Test Scripts Test Results

Test Results

Test Summary

Report



32/80

/ Test Scripts / Test Cases

TS/TC should contain the following elements:

unique test reference

cross reference to controlling specification

title of test

desription of the test including test objective

test steps

acceptance criteria

pre-test steps

data to be recorded post-test actions

Seperate test cases may be prepared for some tests


33/80

/ Test Scripts / Test Cases

Test script results should be formally reviewed and

approved Supporting documentary evidence should be

present i.e. screen shots, data listings, log files etc.

Risk assessment may be used to help define testcases and scripts

Risk assessment can be used to focus the scope of

testing


34/80

/ White Box vs Black Box

Also known as code based

testing, or structural testing. Test cases are identified based

on source code knowledge,

knowledge of Detailed Design

Specifications and other

development documents

Used for Module Testing andIntegration Testing

White Box

Based on the functionalspecification, thus often known

as functional testing

Used for Functional Testing

(OQ) and Acceptance Testing

(PQ)

Black Box


35/80

/ Software Module and Integration Testing

Usually performed for category 5 systems

Module (or unit) testing aims to test each module

against the design specification

Intergration testing aims to verify that modules

work together correctly Testing can be automated on manual

Tests should be formally documented and executed

independantly If automated testing is used, there should be

documentation to show that the testing program is

operating correctly


36/80

/ Installation Testing

Also known as Installtion Qualification

Purpose:To verify that the system is installed

properly in accordance to specifications, installation

instructions and local/global requirements

Verifies that adequate documents are in place i.e.SOPs, user/admin guides, SLA and Security

procedures

Ensures that all installation steps are properly

executed (with objective evidence)

Ensures that the system is adequately protected

from power failure and data loss


37/80

/ Configuration Testing

Focuses on verifying the the configuration of thesystem has been done in line with the configuration

specification (CS)

The tests usually take the form of a checklist

The tests should be approved before execution and

produce objective evidence

The configuration testing documentation is usually

provided by the vendor and could be client specific Testing is usually performed on the client installed

environment


38/80

/ Functional Testing

Also known as Operational Qualification (OQ)

Usually governed by its own protocol Positive and negative functional tests on each system

module

Documented using test scripts with predefined test cases

and data Expected results and actual results should be defined

Scope of testing is defined following the risk assessment

Can also be executed as part of system testing before

release to client

Usually executed in clients environment


39/80

/ Requirements Testing

Also known as Perfromance Qualification (PQ) or User

Acceptance Testing (UAT)

Aims to verify that the system meets the user requirements

and that the system is fit for its intended use

Usually positive testing of end to end business process in

the system

Expected and actual results should be defined / captured

Scope of testing is defined following the risk assessment

Usually executed in clients environment and could be

executed by the client


40/80

/ Test Summary Report

Should document each phase of testing and the

results of testing

Should provide a summary of non-conformances

and their status Should describe the different document

deliverables that were produced

Should evaluate if all acceptance criteria were met

and whether the system is fit for its intended use


41/80

/ System Categories



42/80

/ Typical Lifecycle Approach Category 1

Infrastructure Software

Record software in software invetory and / or

system description document

Perform an Installation verification (IQ)

Ensure software falls under proper configurationcontrol and change management procedures


43/80


Non-configured Software

Abreiviated Lifecycle Approach Establish clear user requirement specification (URS)

Risk based approach to supplier assessment

Record software in software invetory and / orsystem description document

Perform risk based tests against URS(Requirements

Testing) - could also be calibration tests for very

simple systems

Ensure software falls under proper configuration

control and change management procedures to

ensure compliance and fitness for intended use


44/80


Configured Software

Lifecycle Approach

Risk based approach to supplier assessment

Demonstrate Supplier has adequate QMS

Verify documentation maintained by supplier i.e.design specifications

Record software in software invetory and / or

system description document Perform risk based tests in test environment to

verify application works as designed (functional

testing)


45/80


Configured Software (Cont)

Perform risk based tests to verify application works

as designed within the business process

(requirements testing)

Ensure software falls under proper configurationcontrol and change management procedures to


Ensure procedures are in place for managing data


46/80


Custom Software

Same as category 4 plus:

More rigourous supplier assessment and possible

supplier audit

Develop full lifecycle documentation (i.e. FS, DS andfull testing)

Perform design and source code reviews


47/80

/ Categories of Hardware Category 1 -

Standard Hardware Components

Document manufacturer or supplier details and

version/model numbers/serial numbers in

hardware inventory and / or system description

Perform and document installation verification Ensure hardware falls under proper configuration

control and change management procedures to



48/80

/ Categories of Hardware Category 2

Custom Built Hardware Components

Same as category 1 plus:

Design specifications should be developed and

perform acceptance testing undertaken

Take a risk based approach to supplier assessmentand perform supplier audit

May need to perform hardware compatibility tests

Document any hardware configuration in designspecs

Apply configuration management and change

control procedures


49/80

/ Design Review and Traceability- Objectives

To detect system defects early in the SLDC process To ensure that all requirements have been met

That functionality is appropriate, consistent and

meets all pre-defined standards

That the system is properly tested

/


50/80

/ Design Review - Characteristics

Design reviews evaluate deliverables against

standards and requirements Issues are identified and corrective actions

proposed

Planned and systematic reviews during key points

in the lifecycle (specifications, design and

development)

Important part of the verification process

performed by SMEs Rigour of design review and level of documentation

should be based on risk, complexity and novelty

/


51/80

/ Design Review aspects to be considered

Aspects that should be considered when planning Design

Reviews include:

the scope and objectives of the review

what method or process will be followed

who will be involved

what the outputs will be

There should be a formal procedure in place for design

review

A design review form could be used to document reviews

Issues and corrective actions should be documented onforms

Design review should be done for system categories 4 and 5

/


52/80

/ Traceability - Characteristics

Traceability establishes the relationship between

two or more products of the development process

Traceability ensures that:

Requirements are met and can be traced to

configuration and design specifications Requirements are verified and can be traced to

test or verification activities

Traceability can be maintained in an electronicsystem (i.e. HP System Center) or manually in a

traceability matrix document

/ b l l


53/80

/ Traceability - Example

URS FS DS UT/IT IV FV OV

UR4.10 FS5.6. DS3.4 UT10.1

IT5, IT6

n/a FV3 Steps 1-10 OV5 Steps 5-7

OV6 All Steps

UR4.11 FS5.6.

FS5.7.

DS3.4. UT10.2

IT6

IV1 FV3 Steps 11-15

FV4 Steps 1-5

OV5 Steps 8-15

UR4.12 FS5.8. DS3.5. UT10.3

IT6

IV1 FV4 Steps 6-18 OV7 All Steps

UR5.1. FS5.1. DS5.1. UT5.1

IT5

IV1 FV5.1. All Steps OV5 All Steps

Could also add columns for:

Iterations

System version System Document Identifier

Design review instance

Risk class

GxP Relevance

Tested Y/N Test Run

Change Control Ids

References to SOPs

/ bili fi


54/80

/ Traceability - Benefits

Accurate traceability can also provide benefit by:

enabling more effective risk management and

design review processes

judging potential impact of a proposed change

facilitating risk assessment for a proposedchange

identifying scope of regression testing for

changes

enabling fast and accurate responses during an

inspection or audit

/ R i d P d


55/80

/ Required Procedures

The following procedures are required to manage the

development and maintenance of GxP Systems:

Software Devlopment LifeCycle (SDLC)

Computer Systems Validation

Change Control for Validated Computerized Systems

Backup and Restoration

Failover management

Disaster Recovery and Business Continuity

Routine IT Maintenance

Incident and Problem Management Configuration Management

Logical and Physical Security

Documentation Management

/ S li M


56/80

/ Supplier Management

There is an expectation that you assess your

suppliers if they are providing any sub-elements of

your system or associated services

This is usually done through the use of audits

You may want to consider integrating supplierdocumentation with your documentation

Your suppliers should have the same quality

standards as you Your clients may also want to audit your suppliers

so make sure you have this in your contracts

/ Q li Ri k M


57/80

/ Quality Risk Management

Quality risk management is a systematic process for

the assessment, control, communication, and

review of risks

It is an iterative process used throughout the entire

computerized system life cycle from concept toretirement

There is now a regulatory requirement to

implement a risk based approach (Annex 11)

GAMP provides a framework for Quality Risk

Management

/ Q lit Ri k M t


58/80

/ Quality Risk Management

Business Process,

User andRegulatory

Requirements

Project Approach

Contracts,

Methods,Timelines

System

Components and

Architecture

System Functions

Experience from

Use

Improved Patient Safety,

Product Quality andData Integrity

Informed Decisions

Achieving Compliance

and fitness for intendeduse

Efficient Validation

Cost Effective

Maintenace andOperation

Achieving Business

Benefits

Identify

Risks

Analyze and

Evaluate Risks

Control

Risks

Review

Risks

Input Output


/ Wh t th l ti


59/80

/ What the regulations say

ICH Q9 Quality Risk Management describes a

systematic approach to risk management that isintended for general application

It defines the following two primary principles:

The evaluation of the risk to quality should be

based on scientific knowledge and ultimately

link to the protection of the patient

The level of effort, formality, and

documentation of the quality risk managementprocess should be commensurate with the level

of risk

/ Wh t th R l ti S


60/80

/ What the Regulations Say

Eudralex Volume 4 Annex 11 indicates:

Risk management should be applied throughout

the lifecycle of the computerised system taking

into account patient safety, data integrity and

product quality. As part of a risk management system, decisions

on the extent of validation and data integrity

controls should be based on a justified and

documented risk assessment of thecomputerised system.

/ O i f i k b d h


61/80

/ Overview of risk based approaches There are many methodologies that can be used to perform

risk assessments including:

Hazard and Operability Analysis (HAZOP)

Computer Hazards and Operability Analysis (CHAZOP)

Failure Mode and Effects Anaiysis (FMEA)

Failure Mode, Effects, and Criticality Analysis (FMECA)

Fault Tree Analysis (FTA)

Hazard Analysis and Critical Control Points (HACCP)

Basic Risk Management Facilitation Methods

Preliminary Hazard Analysis (PHA)

Risk Ranking and Filtering

GAMP 5 provides us with a methodology which is based on

a five step process

Risk management should be integrated into all activites not

just validation

/ Q lit Ri k M t P


62/80

/ Quality Risk Management Process

Perform Initial Risk Assessment and DetermineSystem Impact

Identify Functions which have impact on PatientSafety, Product Quality and Data Integrity

Perform functional risk assessments and identifycontrols

Implement and verify appropriate controls

Review risks and monitor controls

/ Determining risk


63/80

/ Determining risk

Determining the risks posed by a computerized system

requires a common and shared understanding of: impact of the computerized system on patient safety,

product quality, and data integrity

supported business processes

user requirements

regulatory requirements

project approach (contracts, methods, timelines)

system components and architecture

system functions

Risks need to be determined by the SMEs that have the

knowledge to undertand the above

/ Risk Management


64/80

/ Risk Management

Managing Risks can be achieved through:

elimination by design

reduction to an acceptable level

verification to demonstrate that risks are

managed to an acceptable level

Elimination by design is desirable and design

reviews play a key role

Risks that cannot be eliminated must be reduced toan acceptable level through the use of technical or

procedural controls

/ Example of a risk based for a category 5


65/80

/ Example of a risk based for a category 5

system

/ Step 1 Initial Risk Assessment


66/80

/

An initial risk assessment should be performed based on:

an understanding of business processes business risk assessments

user requirements

regulatory requirements

known functional areas

This initial assessment should focus on the GxP impact of the

system

Focus on the processes that the system is to manage

Formally Document the overall system impact

If the impact of the system is minimal then it may not be

necessary to continue the risk assessment exercise

Step 1 Initial Risk Assessment

/ Step 1 Initial Risk Assessement


67/80

/ Step 1 Initial Risk Assessement

Use process diagrams

to assess the impact

of each process step

This approach will

enable you todetermine overall

system impact

This also allows you

to define the type of

functional assessment

required

/ Step 2 Identify functions which have GxP


68/80

/ Step 2 - Identify functions which have GxP

impact

Functions that could have an impact of patient

safety, product quality or data integrity due to

system failure should be identified in the URS, FS

and from the system impact assessment

Functions that do not have GxP impact but have

high business impact could also be included in the

functional risk assessment

/ Step 3 Example of Risk and Hazard


69/80

/ Step 3 - Example of Risk and Hazard

Identification

/ Step 3 Perform a Functional Risk


70/80


Assessment

Step 1: List the system functions Assume each user requirement will be satisfied by a

specific system function.

Step 2: Identify the type of risk

Associate a type of risk (GxP vs. business) to each

function based on the following: Are there applicable predicate rule requirements?

Is there an impact on patient safety?

Is there an impact of product quality?

Is there an impact on data integrity? Is there an important impact on the ability to carry

out the daily business tasks?

70



71/80

/ Step 3 - Perform a Functional Risk

Assessment Step 3: Identify Risk Scenarios and controls

For each function, list the more likely of thepossible risk scenarios based on the type ofanalysis required (generic or specific)

Identify any controls that could be put in place to

mitigate risk. These could be technical orprocedural

Step 4: Assess the likelihood of occurrence

Occurrence = the likelihood that a fault will occur

Step 5: Assess the severity of impact

Severity = Impact on patient safety, productquality or data integrity



72/80


Assessment

Step 6: Assign a risk class Risk Class = Severity x Probability

Step 7: Assess the probability of detection

Detection= Likelihood of detecting the fault Step 8: Determine the Risk Priority

Risk Priority = Risk Class x Detectability



73/80


Assessment

Determination of risk priority is a practical method for decidingwhich functions pose the greatest risks and, in turn, helps focustesting activities on those functions that present the greatestthreat.

M

Risk Priority

Risk Likelihood

Low

Medium

High

Severi

ty

High 2 1 1

Medium 3 2 1

Low 3 3 2

Probability of Detection

Low

Medium

High

RiskClass

1 High High Medium

2 High Medium Low

3 Medium Low Low

/ Example: Risk Assessment


74/80

/ Example: Risk Assessment

74

/ Step 3 - How to Interpret the Results


75/80

/ Step 3 - How to Interpret the Results

Risk class enables the organization to focusattention on the areas where they are most

exposed

The interpretation of High, Medium and Low can

vary from organization to organization and fromsystem to system

This should be defined for each system prior to

performing the risk assessment

This should be based on system impact

/ Step 4 Select and Implement Controls


76/80

/ Step 4 Select and Implement Controls

Controls are measures that are put in place to reduce risk to

an acceptable level. These controls could be technical in nature such as:

Data verification checks

User prompts to verify inputs

Fault tolerance

Specification documents may be updated following the

identification of technical controls

Controls could also be procedural such as:

Introduction of SOPs to control processes

Increased rigour in testing

Increased user training

/ Step 4 - Risk Based Test Scope Definition


77/80

/ Step 4 Risk Based Test Scope Definition

State the acceptable risk levels, with rationale, inthe Test Plan

Restrict the scope of testing based on the outcome

of the risk assessment

Example:

Business-relevant requirements/functions with

High priorities will be tested.

GxP-relevant requirements/functions,regardless of priority, will be tested.

/ Step 5 Review Risks and Monitor Controls


78/80

/ Step 5 Review Risks and Monitor Controls

Ensure that regular risk reviews are undertaken

(especially during change control and designreviews)

Establish a mechanism for monitoring the controls

Establish a formal risk communicate procedure (asrequired by ICH Q9)

The reporting on risks and monitoring of controls

should be communicated to quality assurance,

business owners and suppliers/clients This communication should be done at every stage

of the system lifecycle

/ Recommendations when performing risk


79/80

/ Recommendations when performing risk

assessements

Ensure that the team performing the riskassessment fully understands the system and the

processes that the system is governs

Designate a moderator to keep the risk assessmentmoving

Be careful not to over-analyze with enough

debate, everything becomes high risk

Make sure controls are realistic and manageable

Always carefully outweigh the effort to put controls

in place versus the risk reductions they bring

/ Conclusion


80/80

/ Conclusion

When applied properly, quality risk managementcan significantly improve quality whilst reducing the

burden of system testing

Risk management is here to stay and is graduallybeing applied to all aspects of GxP

Risk Management is a regulatory requirement

You need to build risk management into your

processes, systems and company culture

gamp 5 overview

Documents