Top Banner

of 80

GAMP 5 Overview

Feb 14, 2018

Download

Documents

fakinreg
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
  • 7/23/2019 GAMP 5 Overview

    1/80

    /

    GAMP 5 Overview

    Paul Fenton

    January 2013

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    4/80

    / Introduction to GAMP5

    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

  • 7/23/2019 GAMP 5 Overview

    5/80

    / Introduction to GAMP5

    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

  • 7/23/2019 GAMP 5 Overview

    6/80

    / Introduction to GAMP5

    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/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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
  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

    Source: ISPE GAMP 5 Guide

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

    Source: ISPE GAMP 5 Guide

  • 7/23/2019 GAMP 5 Overview

    15/80

    / V Model

    15

  • 7/23/2019 GAMP 5 Overview

    16/80

    /

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    22/80

    / Functional Specifications

    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

  • 7/23/2019 GAMP 5 Overview

    23/80

    / Functional Specifications

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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)

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    31/80

    / Testing Documentation Typical Structure

    Test Protocol /Specification

    Test Plan /

    Strategy (VP)

    Test Cases Test Scripts Test Results

    Test Results

    Test Summary

    Report

    Source: ISPE GAMP 5 Guide

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    41/80

    / System Categories

    Source: ISPE GAMP 5 Guide

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    43/80

    / Typical Lifecycle Approach Category 3

    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

  • 7/23/2019 GAMP 5 Overview

    44/80

    / Typical Lifecycle Approach Category 4

    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)

  • 7/23/2019 GAMP 5 Overview

    45/80

    / Typical Lifecycle Approach Category 4

    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 compliance and fitness for intended use

    Ensure procedures are in place for managing data

  • 7/23/2019 GAMP 5 Overview

    46/80

    / Typical Lifecycle Approach Category 5

    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

  • 7/23/2019 GAMP 5 Overview

    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

    ensure compliance and fitness for intended use

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

    /

  • 7/23/2019 GAMP 5 Overview

    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

    /

  • 7/23/2019 GAMP 5 Overview

    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

    /

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

    Source: ISPE GAMP 5 Guide

    / Wh t th l ti

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    65/80

    / Example of a risk based for a category 5

    system

    / Step 1 Initial Risk Assessment

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    69/80

    / Step 3 - Example of Risk and Hazard

    Identification

    / Step 3 Perform a Functional Risk

  • 7/23/2019 GAMP 5 Overview

    70/80

    / Step 3 Perform a Functional Risk

    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

    / Step 3 Perform a Functional Risk

  • 7/23/2019 GAMP 5 Overview

    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

    / Step 3 - Perform a Functional Risk

  • 7/23/2019 GAMP 5 Overview

    72/80

    / Step 3 - Perform a Functional Risk

    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

    / Step 3 - Perform a Functional Risk

  • 7/23/2019 GAMP 5 Overview

    73/80

    / Step 3 - Perform a Functional Risk

    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

  • 7/23/2019 GAMP 5 Overview

    74/80

    / Example: Risk Assessment

    74

    / Step 3 - How to Interpret the Results

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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

  • 7/23/2019 GAMP 5 Overview

    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