GAMP Guideline

&
Validation Documentation
Danilo Maruccia
Milano, 21 Marzo 2006

GAMP Guideline &

Validation Documentation
GAMP Guideline
Planning documents
Specification Documents
Testing Documents
Acceptance Documents

GAMP
Good Automated
Means Manufacturing Practice

Is

A Guide for Validation

of Automated Systems
in Pharmaceutical
Manufacture

Purpose of GAMP
9To help USERS understand the requirements for
prospective validation of an automated system and
the level to which the validation should be performed
9To help SUPPLIERS ensure that systems are developed
according to good practice, and to provide
documentary evidence that their systems meet
the agreed specification

History of the GAMP (1)

First Draft

February 1994

Distributed to UK industry for comments.

Second Draft

January 1995

Incorporating comments from 31 companies.

Version 1.0

March 1995

As Second Draft but incorporating EC GMP

Annex 11.

Version 2.0

May 1996

Revision and new content, incorporating

further comments from Europe and the USA.

Version 3.0

March 1998

Revision and new content. Separation into

User and Supplier Guides. Addition of Volume
Two.

History of the GAMP (2)

GAMP4

December 2001 Major revision and new content in line with

regulatory and technological developments.
Broadened scope to include regulated
healthcare industries. Greater coverage of
user responsibilities and detail on operational
activities.

GAMP 4 Objectives

The
Theextent
extentand
andscope
scopeof
ofValidation
Validationneeds
needsto
tobe
be
easily
easilydetermined
determinedusing
usingsimple
simpleand
andwellwellunderstood
understood rules.
rules.The
Theexisting
existingguidance
guidanceon
on
categories
categoriesof
ofsoftware
softwareis
isvery
veryuseful,
useful,but
butshould
should
be
bedeveloped
developedfurther.Validation
further.Validationlife-cycles
life-cyclesand
and
associated
associateddocumentation
documentationneeds
needsto
tobe
bescaleable
scaleable
to
totake
takedue
dueaccount
accountof
ofthe
thesize,
size,complexity,
complexity,and
and
criticality
criticalityof
ofthe
thecomputer
computersystem.
system.

ISPE GAMP 4 Launch Conference 3-6 Dec. 2001, Amsterdam

GAMP 4 Objectives

The
Thebalance
balanceof
ofvalidation
validationwork
workrequired
requiredby
byusers
users
needs
needsto
tobe
beexamined.
examined.More
Moreuse
useshould
shouldbe
bemade
made
of
ofthe
thedevelopment
developmentwork
workperformed
performedby
bysuppliers,
suppliers,
so
sothat
thatless
lesssupplementary
supplementarywork
workis
isrequired
requiredby
by
the
theusers.
users.Greater
Greateremphasis
emphasisis
isrequired
requiredon
onthe
the
benefit,
benefit,use,
use,and
andcontrol
controlof
ofconfiguration
configurationof
of
systems
systemsbased
basedsoftware
softwarepackages.
packages.

ISPE GAMP 4 Launch Conference 3-6 Dec. 2001, Amsterdam

GAMP 4 vs Good Practice Guides

(GPGs)
Risk Assessment
Central to
Validation
Strategy

Risk central to
GPGs

Principles
GAMP4 & Framework

Guide

Procedures &
Guidelines

Good Practice
Guidance
Training and Education
Material

Detailed
Guidance on
Risk
Assessment

Good Practice Guides (GPGs)

A Risk-Based Approach to Compliant
Electronic Records and Signatures
Testing of GxP system
Validation of Process Control System
Global Information Systems Control
and Compliance
Validation of Laboratory Computerized
Systems
IT Infrastructure Control and
Compliance

Principles and Framework

AAstrategic
strategicframework
frameworkfor
forcomputer
computervalidation
validation
drawing
drawingtogether
togetherthe
thekey
keyvalidation
validationprinciples
principles
and
andpractices
practices
How
Howto
toapply
applythese
theseprinciples
principlesto
todetermine
determineextent
extent
and
andscope
scopeof
ofvalidation
validationfor
fordifferent
differenttypes
typesof
of
systems
systems

ISPE GAMP 4 Launch Conference 3-6 Dec. 2001, Amsterdam

Principles and Framework

Introduction
Introductionto
toGAMP
GAMP

9Including
9IncludingPurpose,
Purpose,Scope
Scopeand
andBenefits
Benefits

Validation
ValidationOverview
Overview
Validation
ValidationLife
LifeCycle
Cycle

Including
IncludingUser
UserRequirements
RequirementsSpecification,
Specification,Determining
DeterminingValidation
Validation
Strategy,
Validation
Reporting,
and
Maintaining
the
Validated
Strategy, Validation Reporting, and Maintaining the ValidatedState
State

Management
ManagementSystem
Systemfor
forSuppliers
Suppliersof
ofIT
IT
Systems
Systems
Process
ProcessControl
ControlSystem
SystemValidation
Validation
Benefits
Benefitsof
ofValidation
Validation
Good
GoodPractice
PracticeDefinitions
Definitions
Glossary,
Glossary,Acronyms,
Acronyms,and
andSource
SourceMaterial
Material
ISPE GAMP 4 Launch Conference 3-6 Dec. 2001, Amsterdam

Procedures and Guidelines

AAsupporting
supportingset
setof
ofrationalized
rationalizedand
andrevised
revised
procedures
proceduresand
andguidelines
guidelinesfor
forcomputer
computersystem
system
validation
validationand
andcompliant
compliantoperation,
operation,classified
classified
into:
into:
Management
Management
Development
Development
Operation
Operation
ISPE GAMP 4 Launch Conference 3-6 Dec. 2001, Amsterdam

Management Appendices M1M10

Validation
ValidationPlanning
Planning
Supplier
SupplierAudit
Audit
Risk
RiskAssessment
Assessment
Categories
Categoriesof
ofsoftware
softwareand
andhardware
hardware
Design
DesignReview
Reviewand
andTraceability
TraceabilityMatrix
Matrix
Quality
Qualityand
andProject
ProjectPlanning
Planning
Validation
ValidationReporting
Reporting
Project
ProjectChange
ChangeControl
Control
Configuration
ConfigurationManagement
Management
Document
DocumentManagement
Management
ISPE GAMP 4 Launch Conference 3-6 Dec. 2001, Amsterdam

Development Appendices D1D6

User
UserRequirement
RequirementSpecification
Specification
Functional
FunctionalSpecification
Specification
Hardware
HardwareDesign
DesignSpecification
Specification
Software
SoftwareDesign
Designand
andSoftware
SoftwareModule
ModuleDesign
Design
Specification
Specification
Production,
Production,Control,
Control,and
andReview
Reviewof
ofSoftware
Software
Testing
Testingof
ofan
anAutomated
AutomatedSystem
System
ISPE GAMP 4 Launch Conference 3-6 Dec. 2001, Amsterdam

Operation Appendices O1O9

Periodic
PeriodicReview
Review
Service
ServiceLevel
LevelAgreement
Agreement
Automated
AutomatedSystem
SystemSecurity
Security
Operational
OperationalChange
ChangeControl
Control
Performance
PerformanceMonitoring
Monitoring
Record
RecordRetention,
Retention,Archive
Archiveand
andRetrieval
Retrieval
Backup
Backupand
andRecovery
Recoveryof
ofSoftware
Softwareand
andData
Data
Business
BusinessContinuity
ContinuityPlanning
Planning
EU
EUAnnex
Annex11
11APV
APVInterpretation
Interpretation
ISPE GAMP 4 Launch Conference 3-6 Dec. 2001, Amsterdam

GAMP 4 Themes
Defined
Defined Development
Development Lifecycle
Lifecycle
Planning
Planning
Risk
Risk And
And Impact
Impact Assessment
Assessment
User
User and
and Supplier
Supplier Partnership
Partnership
Specifications
Specifications
Traceability
Traceability
Design
Design Review
Review
Formal
Formal Testing
Testing and
and Verification
Verification
Documented
Documented Evidence
Evidence
ISPE GAMP 4 Launch Conference 3-6 Dec. 2001, Amsterdam

Validation approach through GAMP

Category Name

Description

Operating
Systems

Established, commercially available software

II

Firmware

Software already contained in equipment that

cannot be manipulated by the user

III

Standard
Software
Packages

These are commercial off the shelf COTS

configurable software

IV

Configurable
Software
Packages

These are custom configurable packages. They

permit users to develop their own application by
configuring predefined SW modules and
developing new application SW modules

Custom
(Bespoke)
Systems

Unique application developed to meet specific

needs of a user company

GAMP
categories

Validation Approach

Validation Approach (1)

CATEGORY

VALIDATION APPROACH

1 Operating Systems

Record version (including Service Pack). The

Operating System will be challenged indirectly by
the functional testing of the application

2 Firmware

For non-configurable firmware record version.

Calibrate instrument as necessary. Verify
operation against user requirements.
For configurable firmware record version and
configuration. Calibrate instrument as necessary
and verify operation against user requirements

3 Standard Packages

Record version (and configuration of environment)

and verify operation against user requirements.
Consider auditing the supplier for critical and
complex application

Validation Approach (1)

CATEGORY

VALIDATION APPROACH

4 Configurable Packages Record version and configuration, and verify

operation against user requirements
Normally audit the supplier for critical and
complex application
Manage any custom (bespoke) programming as
Category 5

5 Custom or Bespoke

Audit supplier and validate complete

system

e.g. ERP System components

vs GAMP Categories
Category

Name

Infrastructure

System Component Description

Network

Communication reliability
verified through PQ

Database Server

Document OS version and

configuration and check it in the
IQ phase.

Application Server
Workstations

Document Package version and

check it in the IQ phase.
Verify Package functionality
through the testing of MAX &
MQM systems.

Standard
Software
Packages

Pervasive SQL
database

IV

Configurable
Software
Packages

ERP

Record version and

Configuration, and verify
operation against user
requirements within PQ

Custom
(Bespoke)
Systems

Interface
ERP-MES

Full Validation Life Cycle

III

Crystal Reports
application

Whats new: Hardware Categories

in GAMP 4 Appendix M4
Cat.
Cat.11--Standard
StandardHardware
HardwareComponents
Components
Should
Shouldbe
bedocumented
documentedincluding
includingmanufacturer
manufactureror
orsupplier
supplier
details
detailsand
andversion
versionnumber
number
Verify
Verifyinstallations
installationsand
andconnections
connectionstrough
troughIQ
IQ
Record
RecordModel,
Model,version,
version,serial
serialnumber
numberof
ofpre-assembled
pre-assembled
hardware
hardware
Use
Usehardware
hardwaredata
datasheet
sheetor
orother
otherspecification
specificationififnecessary
necessary
Change
ChangeControl
Controland
andConfiguration
ConfigurationManagement
Managementapply
apply
Cat.
Cat.22--Custom
CustomBuilt
Built(Bespoke)
(Bespoke)Hardware
HardwareComponents
Components
As
Ascategory
category11plus
plus
Design
DesignSpecification
Specificationand
andAcceptance
AcceptanceTesting
Testing
Supplier
SupplierAudit
Auditfor
forbespoke
bespokehardware
hardwarerequired
required
Configuration
Configurationdefined
definedin
inDesign
DesignDocumentation
Documentation
Verify
Verifytrough
troughIQ
IQ
Change
ChangeControl
Controland
andConfiguration
ConfigurationManagement
Managementapply
apply

GAMP Validation Lifecycle

User
Requirements
Specification
rat
gu
nfi
Co

Functional
Specification

Risk
related to
Assessment

Risk
Assessment
related to

Performance
Qualification

Operational
Qualification

ion

Design
Specification

related to

Installation
Qualification
Testing

n
sig
De
w
vie
Re

System
Build

CS Validation Documents
GAMP
Client responsibility

Supplier responsibility

Audit Report
Validation Plans

Planning
Test Plan

Validation
Master Plan

Design Spec.
Functional Spec.

User Requirement
Specifications

Specifications

Quality and Project

Plan

Testing

Factory/Site
Acceptance Test

SOPs
Protocolli
DQ, IQ, OQ, PQ

Master Index
Validation Report.
Report
IQR, OQR, PQR

SOPs

Validation
Summary

On-Going

User Manuals

Validation Deliverables
User
Requirements
Specifications
Decommissioning
Plan/Report

Audit
Report

De
commissioning

Functional
Specifications

SOPs

Design
Specifications

Installation
Operational
Performance
Qualification
Protocol &
Reports

Test Plan

System
Acceptance
Testing

Unit Testing

Validation Process
User Requirements

Validation Plan

Functional Specifications
Design Specifications

Design Qualification
System Configuration &
Customization
Supplier Testing Review

Unit Testing
System Acceptance Test

Installation Qualification
Operational Qualification
Performance Qualification
Validation Report

Nomenclature and type of

Documents according to the
Vendor Quality System

SW Vendor

Pharmaceutical Firm

Supplier Audit

Project & Quality Plan

Responsibilities

Requirements
Maintenance

I VE
L
O
G

Supplier
Evaluation &
System
Selection
Documentation

Operation

CUSTOMER

Specify

SUPPLIER

&
Design

AC
CE
PT
AN
CE

Validation
Testing

Supplier
Testing

Build

CUSTOMER

GAMP Guideline &

Validation Documentation
GAMP Guideline
Planning documents
Specification Documents
Testing Documents
Acceptance Documents

Validation Plan (1.3)

ItItis
isthe
theformal
formaldocumentation
documentationof
ofthe
thecomprehensive
comprehensive
validation
validationactivity
activityplan
plan(according
(accordingto
tosystem
systemlife
life
cycle).
cycle).

ItItdescribes
describesthe
theplanned
plannedvalidation
validationactivities,
activities,
responsibilities
responsibilitiesand
andapproval
approvalauthorities.
authorities.

Validation Plan (2.3)

Each
Eachvalidation
validationeffort
effort must
musthave
haveaaComputer
Computer
Validation
Validationplan
planthat
thatincludes
includesthe
thefollowing:
following:

System name
System
nameand
andversion
version

System description
System
description

System owner/responsible
System
owner/responsible

Scope of
Scope
ofvalidation
validation(System
(SystemBoundaries)
Boundaries)

Reference to
Reference
toSOPs
SOPsor
orstandards
standardsused
usedto
toperform
perform
the
thevalidation
validation

For automated
For
automatedequipment,
equipment,the
theplan
planshould
shouldbe
be
combined
combinedand/or
and/orintegrated
integratedwith
withthe
theequipment
equipment
validation
validationplan
planand
andnot
notperformed
performedseparately
separately

Validation Plan (3.3)

The
The Validation
Validationplan
planshall
shalldefine
definethe
thedeliverables,
deliverables,
responsibilities
responsibilitiesand
andSOPs
SOPsthat
thatdefine
define
the
thequality
qualityand
andvalidation
validationrequirements
requirementsfor
forthe
the
System
Systemin
inorder
orderto
tobe
beagreed
agreedupon
uponamong
amongthe
the
project
projectteam.
team.
AArationale
rationaleshall
shallbe
bedetermined
determinedfor
forany
anydeviation
deviation
from
fromthe
thestandards
standards
The
The Validation
Validationplan
planshall
shalldefine
definethe
theValidation
Validation
approach
approachbased
basedupon
upon

Criticality
Criticality

Complexity
Complexity

SW Category
SW
Category

GAMP Guideline &

Validation Documentation
GAMP Guideline
Planning documents
Specification Documents
Testing Documents
Acceptance Documents

User Requirements Specification (1.5)

Without
Withoutrequirement
requirementspecification
specificationwell
welldefined
defined
and
andtranslated
translatedinto
intomeasurable
measurableparameters,
parameters,no
no
validation
validationis
ispossible.
possible.
Requirements
Requirementsspecification
specificationshall
shalldescribe
describein
in
details
what the
the computer
computer system
system will
will do
do
detailswhat

BUT
BUT NOT
NOT
how
how itit will
will do
do itit

Mo
st of
Most
ofCS
CSdefects
defectsare
aredue
dueto
toincorrect
incorrect
requirements
requirementsspecification
specification

User Requirements Specification (2.5)

URS
:
URSmust
mustaddress
address:

Regulatory Requirements
Regulatory
Requirements

Process Requirements
Process
Requirements

What ee-Records
-Records are
What
aremanaged
managedby
bythe
thesystem
system

Where ee-Signatures
-Signatures are
Where
areemployed
employed

Necessary audits
Necessary
auditstrails
trails(who,
(who,what,
what,when)
when)

Data retention
Data
retention

Security //authorization
Security
authorization

Business continuity
Business
continuityplan
plan

Unused system
Unused
systemfunctions
functions

Operating environment
s role
Operating
environment and
andthe
thecomputer
computers
role

User Requirements Specification (3.5)

Each
EachRequirement
Requirementshall
shallbe:
be:

Uniquely identified
Uniquely
identified

Unambiguous
Unambiguous

Testable
Testable

Not repeated
Not
repeated

Prioritized (if
Prioritized
(ifany)
any)

Quality
Qualityattributes
attributesof
ofRequirement:
Requirement:

Accurate
Accurate

Clear
Clear

Consistent
Consistent

Complete
Complete

User Requirements Specification (4.5)

The fundamental question for Requirement:

Which the adequate level of detail ???

The
Therequirements
requirementsshall
shallbe
bewritten
writtenwith
with
enough
enoughdetails
detailsto
toprovide
provideguidance
guidancefor
forthe
the
design
designspecifications
specificationsand
andfunctional
functionaltesting
testing
and
andmay
mayreference
referenceother
otherdocuments
documents

User Requirements Specification (5.5)

Use
Useof
ofdiagrams
diagramsto
tohelp
helpdescribe
describeinterfaces
interfacesand
and
complex
complexprocesses:
processes:

Business
Businessprocess
process(in
(inRequirements)
Requirements)
showing
showingwork
workflow
flowand
andparts
partsautomated
automatedby
by
system
system

Interfaces
Interfaces(in
(inRequirements)
Requirements)
showing
showinglinks
linksto
toother
othersystems
systems

System
Systemprocess
process(in
(inRequirements)
Requirements)
showing
showingthe
theinternal
internalsystem
systemprocesses
processes

Supplier Selection
RISKS OF UNRELIABLE SYSTEM

LOW GMP RISK SYSTEMS

MEDIUM GMP
RISK SYSTEMS

HIGH GMP RISK SYSTEMS

EVALUATION
THROUGH
REFERENCES
EVALUATION
THROUGH
EXPERIENCES
REQUEST FOR
INFORMATION

3RD PARTY
AUDIT

SPECIFIC FIRM
AUDIT

COSTS
HIGH GMP RISK
SYSTEMS:
1st screening

HIGH GMP RISK

SYSTEMS:
Evaluation

HIGH GMP RISK

SYSTEMS:
Final Selection

Bekers rule
Level of Evidence
required

User Effort

User Effort

Supplier Effort

Supplier Effort

Bad SW Supplier

Good SW Supplier

NUMBER OF SW BUGS

Why should I choose a Good SW

supplier?
NO Supplier
QS

Good
Supplier QS

Functional
Specs

Design
Specs

Source
Code
Review

Unit
Testing

Integration
Testing

Validation

Operation

TIME

Supplier
Release
GoLive

Quality & Project Plan (1.3)

Quality
QualityPlan
Plan
Agreed
Agreedbetween
betweenuser
userand
andsupplier,
supplier,and
anddefining
definingactions,
actions,
deliverables,
deliverables,responsibilities,
responsibilities,and
andprocedures
proceduressatisfying
satisfyingthe
the
user
userquality
qualityand
andvalidation
validationrequirements.
requirements.
Project
ProjectPlan
Plan
Agreed
Agreedbetween
betweenuser
userand
andsupplier
supplierdetailing
detailingproject
projectphases,
phases,
activities,
activities,and
andmilestones
milestones

GOOD DOCS

BAD DOCS

QUALITY
QUALITY
PLAN
PLAN
Customer
docs

+
Customer
docs

Supplier docs
(Reference)

Quality & Project Plan (2.3)

The
TheQuality
QualityPlan
Planshall
shallinclude
include

Who produced
Who
producedthe
thedocument,
document,under
underwhich
whichauthority,
authority,and
andfor
forwhat
what
purpose
purpose

The contractual
The
contractualstatus
statusof
ofthe
thedocument
document

Relationship with,
es,
Relationship
with,and
andreference
referenceto,
to,relevant
relevantpolicies,
policies,procedur
procedures,
standards
standardsand
andguidelines
guidelines(such
(suchas
asGAMP)
GAMP)

Relationship with,
Relationship
with,and
andreference
referenceto,
to,the
theValidation
ValidationPlan
Planifif
appropriate
appropriate
The
TheQuality
QualityPlan
Planshall
shalldescribe
describehow
howthe
theuser
usercompany
companyquality
quality
requirements
requirementsare
areto
tobe
bemet
metby
bythe
thesupplier.
supplier.The
Theactivities
activitiesto
tobe
be
undertaken,
undertaken,the
theprocedures
proceduresto
tobe
befollowed,
followed,and
andresponsibilities
responsibilities
should
shouldbe
bedefined.
defined.
All
r
Alluser
usercompany
companyquality
qualityrequirements
requirementsshould
shouldbe
belisted
listedhere.
here.Use
User
quality
qualityrequirements
requirementstake
takeprecedence
precedenceover
overthe
the
supplier's
supplier'sQuality
QualityManagement
ManagementSystem.
System.

Quality & Project Plan (3.3)

Activities
Activitiesaddressed
addressedby
bythe
theQPP
QPP
Specification
Specification
Design
DesignReviews
Reviews
Programming
Programmingstandards
standardsand
andcode
codereviews
reviews
Testing
Testing
Installation
Installation
Data
Datamigration
migration
Acceptance
Acceptance(both
(bothsupplier
supplierfactory
factoryand
anduser
usersite
siteacceptance
acceptance
testing)
testing)
Document
DocumentManagement
Management
Change
ChangeControl
Control
Configuration
ConfigurationManagement
Management
Issue
Issueand
andrisk
riskmanagement
management
Project
Projecttraining
training
Handover
Handoverto
tosupport
supportorganization
organization

System Specification
Functional
FunctionalSpecifications
Specificationsis
isnormally
normallywritten
writtenby
by
the
thesupplier
supplierand
anddescribes
describesin
indetail
detailthe
thefunctions
functions
of
ofthe
thesystem,
system,i.e.,
i.e.,what
whatthe
thesystem
systemwill
willdo.
do.The
The
user
usershould
shouldreview
reviewand
andapprove
approveFunctional
Functional
Specifications.
Specifications.ItItis
isnormally
normallyconsidered
consideredaa
contractual
contractualdocument.
document.
Design
DesignSpecifications
Specifications should
should contain
containsufficient
sufficient
detail
detailto
toenable
enablesystem
systembuild
buildand
andmaintenance
maintenance

Functional Specification (1.3)

Functional
FunctionalSpecification
Specificationshall
shalldescribe
describehow
howthe
the
system
systemperforms
performsthe
thefunction
functionrequired
required

Quality
Qualityattributes
attributesof
ofFunctional
FunctionalSpecifications:
Specifications:

Traceable to
Traceable
tothe
therequirement
requirement

Uniquely identified
Uniquely
identified

Unambiguous
Unambiguous

Detailed
Detailed

Testable
Testable

Not repeated
Not
repeated

Functional Specification (2.3)

WHO

WHEN

SUPPLIER

ACCORDING TO URS DURING

NEGOTIATION PHASE

SUPPLIER +
USER

AFTER ANALYSIS IN CASE OF

CUSTOMIZZATIONS

Functional Specification (3.3)

must initiate:

Requirements Traceability
User
Requirements

Functional
Specs

Design
Specification

Source Code
Review

Design Specifications
Design Specification shall describe how the system
has been developed in order to perform the functions
required
Design
DesignSpecifications
Specificationsshall
shallinclude:
include:

Standard model
Standard
modelused
usedin
indeveloping
developingthe
theapplication
application

Information flows
Information
flows

Software elements
Software
elementsof
ofthe
thesystem
system

Configuration (in
)
Configuration
(incase
caseof
ofconfigurable
configurablesystems
systems)
Design Specification shall
provide sufficient detail to build or buy a computer system or
components
Be the basis for additional activities such as module and
subsystem development, test planning, subsequent maintenance
and enhancement.

Design Specifications

Design
DesignSpecifications
Specificationsmaintained
maintainedby
bythe
thefirm
firm
shall
shalldocument
documentthe
thepart
partof
ofthe
thesystem
systemunder
under
user
s ((ie
ie firm)
users
firm)control
control

Design Specification maintained by the firm shall include the

following (but not limited to):
HW/SW Specifications (GAMP category 3)
Package Configuration Specifications (GAMP category 4)
SW Design Specifications (GAMP category 5)

Package Configuration Specifications

This
Thisdocument
documentdescribes
describesthe
therequired
requiredconfiguration
configurationof
of
standard
standardcomponents
componentsto
tobe
beprovided
providedas
asall
allor
orpart
partof
ofthe
the
solution.
solution.
ItItshould
shouldaddress:
address:

Required configuration
Required
configurationsettings
settingsor
orparameters
parameters

Reason for
Reason
forsetting,
setting,with
withreference
referenceto
tocontrolling
controlling
specification
specification

Tools or
Tools
ormethods
methodsthat
thatwill
willbe
beused
usedto
toset
setthe
therequired
required
options
options

Dependencies and
Dependencies
andimpacts
impactson
onother
othermodules
modulesor
orsystems
systems

Security of
Security
ofsettings
settings

Design Qualification
Design
DesignQualification
Qualification(also
(alsotermed
termedDesign
DesignReview)
Review)
is
isaaplanned
plannedand
andsystematic
systematicreview
reviewof
of
specifications,
specifications,design,
design,and
anddevelopment
development
throughout
throughoutthe
thelife
lifecycle.
cycle.
Design
DesignReviews
Reviewsevaluate
evaluatedeliverables
deliverables
against
againststandards
standardsand
andrequirements,
requirements,identify
identify
problems,
problems,and
andpropose
proposerequired
requiredcorrective
corrective
actions.
actions.

Risk Analysis Methods

RISK ANALYSIS
User Requirements
Specifications

Functional
Specifications

RISK ANALYSIS MODEL

(Root analysis, Failure Mode And Effect Analysis,
Parametric Model

Scope and focus of

Performance
Qualification phase

Scope and focus of

Operational
Qualification phase

GAMP Guideline &

Validation Documentation
GAMP Guideline
Planning documents
Specification Documents
Testing Documents
Acceptance Documents

Testing

The
The process
processof
ofexercising
exercisingor
orevaluating
evaluatingaa
system
systemor
oraasystem
systemcomponent
componentby
bymanual
manualor
or
automatic
automaticmeans
meansto
toverify
verifythat
thatititsatisfies
satisfies
specified
specifiedrequirements
requirementsor
orto
toidentify
identifydifferences
differences
between

betweenexpected
expectedand
andactual
actualresults
results
IEEE
IEEEStd.
Std.729
729

Testing is the keystone of the

validation process...
TESTING
USR
FSP
VAL
PLAN

SOPs
VAL
REPORT

INDEPENDENCE FROM
DEVELOPMENT

Tests should include not

only
normal or expected
values,
but also stress conditions.
Test conditions should
extend to
boundary values,
unexpected data entries,
error conditions,
reasonable challenges,
branches,
and combinations of inputs.

Testing

Testing based
Protocols)
Testing
basedon
onTest
TestProcedure
Procedure((Protocols)

Testing performed
Testing
performedin
indedicated
dedicatedenvironment
environment

Attention to
Attention
toproduced
produceddocumentation
documentation

Production of
Production
ofthe
thetesting
testingfinal
finalreport
report
Testing
Testingshall
shallbe
bebased
basedupon:
upon:

system documents,
system
documents,which
whichdescribe
describethe
thecharacteristics
characteristicsof
of
systems
systemsthat
thatwill
willbe
bethe
thesubject
subjectof
oftests
tests

test procedures,
test
procedures,which
whichdescribe
describehow
howto
toperform
performthe
thetest
test

test results,
test
results,which
whichreport
reportresults
resultsof
ofsystem
systemtests
tests

anomaly reports,
anomaly
reports,which
whichdescribe
describeerrors
errorsand
and bad
bad
workings
workingsfound
foundby
bytests
tests

Test Procedures
Test Procedure shall describe in details how to
perform test

Uniquely Identified
Uniquely
Identified

Traceable to
Traceable
tothe
thespecification
specification

Unambiguous
Unambiguous

Accurate
Accurate

Specify expected
Specify
expectedresults
results

Testing Focus

Specify expected
Specify
expectedand
andactual
actualresults
results

Evidence of
Evidence
oftest
testresults
resultsgenerated
generatedduring
during
testing
testingmust
mustbe
berecorded
recorded(e.g.,
(e.g.,printouts,
printouts,
screen
screendumps,
dumps,display
displayof
ofalarm
alarmcolor,
color,event
event
observation)
observation)

If evidence
If
evidencecannot
cannotbe
begenerated,
generated,aasecond
second
person
person(verifier)
(verifier)may
mayneed
needto
toverify
verifycritical
critical
events
events(when
(whenspecified
specifiedby
bytest
testplan)
plan)

Deviations and
Deviations
andunexpected
unexpectedresults
resultsare
are
investigated,
investigated,resolved
resolvedand
anddocumented
documented

Supplier Testing Benefits

Validation testing can be greatly decreased or not
executed if the supplier has a reliable set of verified
functional testing.
Vendor documentation for technical support may
reduce or eliminate the need to recreate
such documentation.
GOOD AUDIT

BAD (or NON EXISTING)

AUDIT

+
Customer
docs

Supplier docs
(Reference)

Customer
docs

Supplier Testing
Supplier Testing shall be executed through following
approaches:
White Box: Examining the internal structure of the source
code. Includes low level and high level code review, path
analysis, auditing of programming procedures and standards
actually used, inspection for extraneous dead code,
boundary analysis and other techniques.
Black Box:Testing that ignores the internal mechanism of a
system software or a software component and focuses solely
on the outputs generated in response to selected inputs and
execution conditions.
Independence of Review shall be ensured by the Vendor, i.e. at
least a testing stage shall not be executed by the persons who
developed the code

Supplier Testing
Unit Testing activities will be performed in order to test each
single software object against its Unit Design Specification and
verify the correct implementation of each single process
management functions.
Integration Test Specification Defines those tests that
demonstrate that all software modules communicate with each
other correctly and that the software system meets its design
specification. For solutions based on configurable software it
may be necessary at this point to integrate the configuration
previously tested using Package Configuration Test
Specifications
Site Acceptance Testing is performed by the Supplier in order
to verify:
system correct functionality
system coverage of User Requirements
interface suitability between systems and instruments (if
any)

User Qualification

Criticality and
Criticality
andcomplexity
complexityof
ofthe
thecomputer
computer
system
system will
willimpact
impactthe
theextent
extentand
andfocus
focusof
oftesting
testing

Results of
Results
ofthe
theSoftware
SoftwareSupplier
SupplierEvaluation
Evaluationmay
may
impact
impactthe
thequantity
quantityof
of formal
formaluser
usertesting
testing
required,
required,especially
especiallyOQ
OQ(unit)
(unit)testing
testing

Testing may
Testing
maybe
begreatly
greatlyreduced
reducedififthe
thesupplier
supplier
has
hasaareliable
reliableset
setof
offunctional
functionaltesting
testing

Vendor testing
Vendor
testingweaknesses
weaknessesmay
mayneed
needto
tobe
be
addressed
addressedwith
withadditional
additionaltesting
testing

Installation Qualification (1.4)

Installation
InstallationQualification
Qualificationis
isin
inpractice
practiceperformed
performedto
toassure
assure
that
thatthe
theCS
CShas
hasbeen
beeninstalled
installedas
asspecified
specifiedand
anddocumented
documented
evidence
evidenceexists
existsto
todemonstrate
demonstratethis
this..
IQ
IQshall
shallconfirm
confirmthat:
that:

Software
Softwarehas
hasbeen
beenloaded
loadedcorrectly
correctly

Specific
Specificsite
sitehardware
hardwareitems
itemshave
havebeen
beenassembled
assembledand
and
installed
installedcorrectly
correctly

Power
Powersupplier,
supplier,earth
earthconnections,
connections,data
dataconnections
connectionsand
and
field
fieldconnections
connectionsare
arecorrect
correctand
andenable
enablethe
thesystem
systemto
tobe
be
powered
poweredup
up

Control
Controland
andmonitoring
monitoringinstrumentation
instrumentationhave
havebeen
been
calibrated
calibratedand
andinstalled
installedcorrectly
correctly

Basic
Basicsystem
systemfunctions
functionsoperate
operateon
onpower
powerup
upand
andany
anybuilt
built
in
indiagnostics
diagnosticsare
aresatisfactorily
satisfactorily

Installation Qualification (2.4)

Documented
Documentedverification
verificationthat
thataasystem
systemis
isinstalled
installed
according
according to
towritten
writtenand
andpre-approved
pre-approved
specifications.
specifications.

Characteristics
Characteristicsof
ofPC
PCHW
HWand
andSW
SW

Configuration/parameterization
Configuration/parameterizationfiles
filesprint
print(if
(if
any)
any)

Quality
QualitySW
SWSupplier
SupplierCertification
Certification(if
(ifany)
any)

Software
SoftwareCertification
Certification(if
(if any)
any)

Reference
Referenceto
tospecifications
specifications(Design
(Design
Specification)
Specification)

Base
Basetests
teststo
toverify
verifycorrect
correctinstallation
installation

Installation Qualification (3.4)

Documentation
Documentationmust
mustexist
existfor
forinstallation
installationof
ofthe
the
application
applicationsoftware
softwarein
inthe
theproduction
production
environment,
environment,including:
including:

Name
Nameand
andversion
versionof
ofthe
thesoftware
software

Who
Whoperformed
performedthe
theinstallation
installation

Date/time
Date/timeof
ofinstallation
installation

Installation
Installationinstructions
instructions(listed
(listedor
orreferenced)
referenced)

Special
Specialset-up
set-upparameters
parameters

Verification
Verificationthat
thatthe
theinstallation
installationwas
was
successfully
successfullycompleted
completed

Installation Qualification (4.4)

IfIftesting
testingis
isnot
notperformed
performedin
inthe
theproduction
production

environment,
environment,include
includedocumented
documentedevidence
evidencethat:
that:

Test
Testenvironment
environmentis
isessentially
essentiallythe
thesame
same
as
asproduction
productionenvironment
environment

Test
Testinstallation
installationmeets
meetsthe
thesame
samecriteria
criteria
as
asproduction
productioninstallation
installation

Operational Qualification (1.2)

Assuring
Assuringthat
thatthe
theinstalled
installedsystem
systemworks
worksas
as
specified
specifiedin
inthe
theFunctional
FunctionalSpecification
Specificationand/or
and/or
Requirements
Requirements throughout
throughout the
theintended
intendedoperating
operating
ranges
rangesand
andsufficient
sufficientdocumentary
documentaryevidence
evidenceexists
exists
to
todemonstrate
demonstratethis.
this. The
TheFunctional
Functionaltests
testsshould
should
be
betraceable
traceable through
through the
the OQ
OQ Test
Test Protocols
Protocolsto
tothe
the
Functional
FunctionalSpecification.
Specification.
The
TheOperational
Operationalprocedures,
procedures,Critical
Criticalalgorithms
algorithms
and
andparameters
parametersshould
shouldbe
betested
testedas
aswell
wellas
asData
Data
integrity,
integrity,security,
security,accuracy
accuracyand
andreliability.
reliability.Stress
Stress
test
testwould
wouldnormally
normallybe
beaapart
partof
ofOQ.
OQ.

Operational Qualification (2.2)

Tests
Testsmust
mustchallenge
challengenormal
normaland
andabnormal
abnormal

conditions
conditionsincluding:
including:

Security
Securitycontrols
controls

Range
Rangechecking
checkingfor
fordata
dataentry
entry

Sequences
Sequencesof
ofoperations
operations

Alarm
Alarmconditions
conditions

Additional
Additionaltesting
testingshould
shouldfocus
focuson
onportions
portionsof
ofthe
the

system
systemwhich
whichare
aremost
mostcritical
criticaland
andcomplex
complex

Performance Qualification (1.2)

As
Aspart
partof
ofthe
thePQ
PQititis
isnecessary
necessaryto
toprove
provethat
thatthe
thesystem
system
works
workscorrectly
correctlyand
andconsistently
consistentlyin
inthe
theintended
intendedoperational
operational
environment
environmentat
atthe
theClient
Clientas
aspart
partof
ofthe
theprocess
processfor
forwhich
whichitit
has
hasbeen
beendesigned,
designed,using
usingall
allprocedures,
procedures,equipment,
equipment,
utilities.
utilities.
The
Theequipment
equipmentIQ
IQ&&OQ
OQand
andthe
theAutomation
Automationsystem
systemIQ
IQand
and
OQ
OQmust
mustbe
becompleted
completedand
andapproved
approvedbefore
beforethe
thePQ
PQprotocol
protocol
is
isexecuted.
executed.
The
TheProcess
ProcessSOPs
SOPsneeds
needsto
tobe
betested
testedduring
duringthe
thePQ,
PQ,and
andthe
the
PQ
PQshould
shouldverify
verifythat
thatthe
theCS
CSwill
willwork
workaccordingly
accordinglyto
tothe
the
Requirements.
Requirements.

Performance Qualification (2.2)

Documented
Documentedverification
verificationthat
thataasystem
systemis
iscapable
capableof
of
performing
performingor
orcontrolling
controllingthe
theactivities
activitiesof
ofthe
theprocesses
processesitit
is
isrequired
requiredto
toperform
performor
orcontrol,
control,according
accordingto
towritten
writtenand
and
pre-approved
pre-approvedspecifications,
specifications,while
whileoperating
operatingin
inits
its
specified
specifiedoperating
operatingenvironment.
environment.

Tests must be included which span the underlying business

process

Tests contain most of the challenges of normal operating

conditions

Each test must be traceable back to its requirement or

requirements/specification

Validation Testing Scope

Performance Qualification Test Script
Operational Qualification Test Script 1

Operational Qualification Test Script 2

Functional
Specifications 1

1
2

Unit
Testing
Object
A

Object
B

Design
Specs
A

Design
Specs
B

Unit
Testing
A

Unit
Testing
B

1
2
3= 3
4

Functional
Specifications 2

Unit
Testing
Object
C

Design
Specs
C

Unit
Testing
C

Requirements Traceability
User
Requirements

Functional
Specs

Design
Specification

Source Code
Review

OQ Test Scripts

PQ Test Scripts

GAMP Guideline &

Validation Documentation
GAMP Guideline
Planning documents
Specification Documents
Testing Documents
Acceptance Documents

Validation Report
A list of deliverables generated from the
validation activities, including storage location

Testing documentation with results

A summary of the overall results of the validation
indicating the stability of the system for use

For example: This system is approved

for use in production

Document any limitations or restrictions

on the use of the system

Documentation Archiving
Project
Documentation
User
Requirements

Implementation
Phase

Validation
Documentation
Validation Plan
Validation Protocols
and Records
Validation Report

Maintenance
Documentation
Registration
Support Agreements
for HW and SW
SOPs

Master Index
User
Documentation

OnGoing
Phase

Maintenance
Records

Training
Records

Change
Control
Documents
Backup
Log

Periodic
Review

Validation Fundamental Concepts

Validation is a process, not an event
Planning activity should be performed as
a Team

Computer Validation Life Cycle provides

a road map

A solid Risk Analysis as a safe operating

framework

Keep the validation process under

control

Validation Keystones
To be in Compliance means:
Coordination (Policy & Standards)
Cooperation (sharing knowledge & support)
Capacity (make realistic Plans for big changes)
Competence (get trained to gain competence)
Consistency (use same measurements & tools)