GAMP 5 Overview
Paul Fenton
January 2013
/ 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
/ 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
/ Introduction to GAMP5
GAMP provides practical guidance that:
facilitates the interpretation of regulatory
requirements
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
/ 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
/ 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
/ GAMP Drivers
Focus on Patient
Safety,
Product Quality,
and Data Integrity
Life Cycle
Approach
within QMS
Scalable
Approach to GxP
Compliance
Effective
Supplier
Relationships
Quality by
Design (QbD)
Configurable
Systems
and Development
Models
Source: ISPE GAMP 5 Guide
GAMP 5
Use of Existing
Documentation
and Knowledge
Effective
Governance to
Achieve and
Maintain GxP
Compliance
Continuous
Improvement
within QMS
Improving GxP
Compliance
Efficiency
Science Based
Quality Mgt
of Risks
Critical Quality
Attributes (CQA)
Develop
Medicinal
Products
Produce
Medicinal
Products
Market and
Distribute
Medicinal
Products
Supplier (of
computerized
systems and
services)
Source: ISPE GAMP 5 Guide
Develop
Products and
Services
Deliver Products
and Services
Maintain and
Support
Products and
Services
/ 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
/ Lifecycle Approach
Good Engineering Practice
Product
Knowledge
Process
Knowledge
Requirements
Regulatory
Requirements
Specification
and Design
Verification
Company
Quality Reqs
Risk Management
Design Review
Change Management
Source: ISPE GAMP 5 Guide
Acceptance
and Release
Operation and
Continuous
Improvement
/ V Model
15
/ 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
/ System Description
Identify GxP process which will be governed by the
system
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
/ 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
/ 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 measurable
and link to tests in the traceability matrix
Ensure the programmer understands the FS
Identify when design review needs to occur
/ 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
/ 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 the
system for which they have been written
/ 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)
/ Design Specifications
Database design should include:
Physical and logical database diagram with all
relevant 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
/ 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
/ 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
/ 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
Test Summary
Report
Test Protocol /
Specification
Test Cases
Test Results
Test Scripts
Test Results
White Box
Black Box
Based on the functional
specification, thus often known
as functional testing
Used for Functional Testing
(OQ) and Acceptance Testing
(PQ)
/ 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
/ Configuration Testing
Focuses on verifying the the configuration of the
system 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
/ 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
/ 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
/ System Categories
/ 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 electronic
system (i.e. HP System Center) or manually in a
traceability matrix document
/ Traceability - Example
URS
FS
DS
UT/IT
IV
FV
OV
UR4.10
FS5.6.
DS3.4
UT10.1
IT5, IT6
n/a
UR4.11
FS5.6.
FS5.7.
DS3.4.
UT10.2
IT6
IV1
UR4.12
FS5.8.
DS3.5.
UT10.3
IT6
IV1
UR5.1.
FS5.1.
DS5.1.
UT5.1
IT5
IV1
GxP Relevance
Tested Y/N
Test Run
Change Control Ids
References to SOPs
/ 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 proposed
change
identifying scope of regression testing for
changes
enabling fast and accurate responses during an
inspection or audit
/ Required Procedures
The following procedures are required to manage the
development and maintenance of GxP Systems:
/ 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 supplier
documentation 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
Output
Input
Identify
Risks
Project Approach
Contracts,
Methods,
Timelines
Review
Risks
Analyze and
Evaluate Risks
System
Components and
Architecture
System Functions
Experience from
Use
Source: ISPE GAMP 5 Guide
Achieving Compliance
and fitness for intended
use
Efficient Validation
Control
Risks
Cost Effective
Maintenace and
Operation
Achieving Business
Benefits
/ 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
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 to
an acceptable level through the use of technical or
procedural controls
High
Medium
Low
High
Medium
Low
Risk Class
High
Medium
Low
Severity
Probability of Detection
High
High
Medium
High
Medium
Low
Medium
Low
Low
Risk Priority
74
/ Conclusion
When applied properly, quality risk management
can significantly improve quality whilst reducing the
burden of system testing
Risk management is here to stay and is gradually
being 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