GAMP Traceability

“Good Reprinted from The Official Journal of ISPE

traceability PHARMACEUTICAL ENGINEERING® January/February 2006, Vol. 26 No. 1

yields benefits”

GAMP® Traceability for

– guidance from
the GAMP®
Forum on
achieving the
correct level of
GxP Regulated Applications
traceability
between

T
requirements, he purpose of this document is to pro- Whatever process is used to achieve traceabil-
design, and vide guidance on how to achieve an ity, it should be:
appropriate level of traceability be
testing tween requirements, design, and test- • appropriate to the system size, complexity,
documents for ing documents for regulated GxP applications. impact, and risk
regulated GxP Although the expectation for traceability by
regulatory authorities has been clearly stated,1,2
applications. • documented and approved in the validation
there is little definitive guidance on the planning stage
practicalities of achieving and sustaining trace-
ability.3 • an integrated part of the overall life cycle of
This guidance addresses this gap and should the project and beyond into the support and
be treated as a supplement to GAMP® 4, GAMP® maintenance of the system
Guide for Validation of Automation Systems.4
Benefits of Traceability
Principles Good traceability yields a number of tangible
Processes and supporting documentation and intangible benefits. Examples include:
should be established and maintained to link
requirements, design, and testing. In addition, • Traceability will assist risk management.
it should be possible to trace back from testing Focus should be placed on any critical re-
to both design and requirements - Figure 1. quirements as part of the risk assessment.
This traceability provides a means to ensure Traceability will help to identify critical de-
that all elements of design, as well as all sign elements and necessary testing. There
requirements, have been tested. It also enables should be increased testing rigor applied to
the identification and flow of documentation in the critical aspects of a system, compared to
the event of requests during an audit. the non-critical aspects of the system.
The linkage between requirements, design,
and testing is not necessarily limited to a 1:1:1 • Traceability will improve test coverage.
relationship: Traceability should make it possible to dem-
onstrate which requirements and design el-
• Multiple requirements may be covered by a ements are tested. Therefore, duplicate or
single design specification and tested by a redundant testing may be avoided.
single test.
• Traceability can help demonstrate that vali-
• Multiple design specifications may be linked dation is complete. All requirements should
to a single requirement. be functionally tested, covered by an audit,
handled through a user operating proce-
• Multiple tests may be required to address dure, or accepted as not requiring testing,
one requirement or one design specification. and monitored in the live environment.

Figure 1. Principles of
Traceability.

©Copyright ISPE 2006 JANUARY/FEBRUARY 2006 PHARMACEUTICAL ENGINEERING 1

GAMP Traceability
• Safety

• Identity

• Strength

• Purity

• Quality

This granularity will influence the need

for the traceability matrix and its con-
Figure 2. Example of embedded traceability for simple systems. tents; the greater the granularity the
larger the matrix, and therefore, the
• Traceability will improve change will be dependant upon maintainabil-
greater the need for a tool to maintain
management. When a change con- ity of the deliverable.
the matrix.
trol is raised, traceability enables Traceability for simpler systems
An example Requirements Trace-
an accurate assessment of its im- may be achieved through common or
ability Matrix (RTM) is shown in -
pact by identifying related require- consistent numbering of requirements,
Figure 3. Each reference within the
ments, design elements, and test design statements, and testing - Fig-
traceability matrix, e.g., U1.1.2, F3.1,
scripts. Regression testing can ure 2. The numbering for “temperature
D1.2, T8.2, could be a reference to a
thereby be clearly scoped. recording” in this example is the same
section or subsection within the rel-
in the requirements, design, and test
evant document, or to a totally sepa-
• Traceability will help root cause documentation; thereby enabling trace-
rate document. The method used and
analysis of software malfunctions. ability without creating a separate
the process should have been declared
It should be possible to more easily traceability matrix. This approach
and approved within the validation
track and trace design element in- works well with smaller systems in low
plan.
terdependencies when conducting risk situations.
root cause analysis of incidents at- For purely Commercial Off-the- Level of Detail Practicalities
tributable to software malfunction. Shelf (COTS) software products, the It can be difficult to determine the level
traceability may be reduced to that of of detail required for traceability. The
• Traceability will help audits and requirements to testing (or qualifica- following information is intended to
inspections. It should be relatively tion) only. However, this will depend help pitch the detail at a level which
easy to identify any and all support- upon the user’s knowledge of the sup- satisfies regulatory expectations for
ing documentation for any given plier and their processes, the system traceability, while remaining practical
operation. It should be much easier usage within the company, and the to maintain.
to provide timely responses to re- level of acceptable risk. In most cases, A strategy for traceability should be
quests for information. the design column in Figure 2 could be established during validation planning.
replaced with a link to configuration User requirements should be devel-
Methods of Achieving items, providing traceability between oped with traceability in mind.
Traceability requirements, configuration, and test- The level of traceability could stop
Traceability may be achieved in a num- ing (or qualification). with a reference to vendor documenta-
ber of ways, including: The user of the COTS software prod- tion; if documentation needs are met
ucts will need to be able to demon- by the vendor documentation when
• a Requirements Traceability Ma- strate an intimate knowledge of the supported by in-depth supplier assess-
trix (RTM) supplier’s quality process, as a mitiga- ment and a vendor management plan.
tion of risk to the user processes when The supplier should have their own
• automated software tools using the COTS system. This may ne- traceability for the documentation and
cessitate multiple visits to the supplier testing under their control. This should
• excel spreadsheets during the project phase, as risks are be verified during Supplier Assess-
identified at points throughout the ments, where appropriate.
• embedding references directly project, and during the ongoing contact Requirements need not trace to tech-
within documents of the support and maintenance phases nical controls in all circumstances.
of the system life cycle. Requirements may trace to procedural
If an RTM is chosen, it may be gener- The depth or granularity of the re- controls, in which case cross-references
ated as a separate deliverable or as quirements will be influenced by the to identified SOPs is appropriate.
part of an existing deliverable, such as size and complexity of the system, along
the requirement document: the choice with its potential to impact drug prod- • For simple systems, an RTM is not
uct: recommended, as sufficient trace-

2 PHARMACEUTICAL ENGINEERING JANUARY/FEBRUARY 2006 ©Copyright ISPE 2006

 GAMP Traceability
ability may be incorporated within • The test column may be expanded Documentation and
document cross-references. to indicate at what level the testing Maintenance of Traceability
occurs: unit, integration, acceptance The chosen process and method which
For global systems, planning for trace- (hardware or system) or where and any given system will use for traceabil-
ability in the validation plan is im- when the testing occurs, develop- ity should be documented and under-
perative since the control of local and ment, qualification, production, or stood. It is recommended that this be
global requirements needs to be re- global, local. In this case, the level of achieved within the validation plan for
solved at this point for tracking the effort in testing should relate to the smaller systems, or perhaps proce-
combination of local and global require- criticality of the requirement and duralized for larger and more complex
ments. the level of acceptable risk. For ex- systems. All members of a system de-
ample, a high-risk requirement may velopment team should be acquainted
Extending RTMs be tested many times and at many with the process and method to ensure
There are other features that may be levels, whereas a medium risk re- that it is adopted and maintained
added to a basic traceability matrix quirement may be tested just once, throughout the system development
that can assist with the overall effec- and a low risk may not be tested at life cycle.
tiveness and efficiency of validation all, only verified through system Once a system has been accepted
activities. Examples include: use. into use, the maintenance of traceabil-
ity is required to preserve its useful-
• A column to include a brief written • A column linking a test to a mainte- ness. The method of maintenance will
description of each requirement, nance or calibration record for the always be linked to whatever process is
which may assist in the verification instrument required for a test and used to maintain the requirements,
that matrix contents are referenced requirement. For process automa- design, and test documentation, all of
correctly. tion documents such as installation which must be updated to reflect the
records, loop checks and tuning, current system. In addition, the version
• A column to include change control cable integrity checks may be linked, control may be linked to enable system
numbers to enable tracking the sys- enabling traceability from the cali- configuration controls, e.g., version 1.0
tem history and change impact. bration certification on an instru- of the requirements, design, test, and
Reference also may be made to other ment all the way through to the use traceability are in use at go-live of any
documentation and processes which of that measurement in the busi- system, then all versions may be in-
impact the system, such as devia- ness process and system testing. creased at the same time to maintain
tions or SOP changes. this configuration control periodically
The above additions increase the diffi- throughout the system life cycle.
• A column to indicate the criticality culty of navigating and maintaining Whatever changes are made to the
of the requirements to assist levels the traceability matrix. Therefore there documentation they will be controlled
of testing applied to any given re- needs to be a balance between what is through the control of a change pro-
quirement. High criticality require- expected of the traceability matrix and cess. Within this process, the method
ments may have greater testing the maintainability of the method cho- by which the documents will be up-
applied; therefore, may reference sen. Where large projects are being dated should be documented, for ex-
multiple tests, whereas low critical installed, such as ERP/MRP II, LIMS/ ample:
requirements may have a reference CDS, or large process control systems,
to a single test. There may be a need it may be prudent to seek out a docu- • at every change
to reference the executed tests and ment management system which has
the supporting test result documen- the capability to both maintain the • with a number of changes batched
tation along with any failed tests. links between documents within the together
document management system and
• A column to indicate where a re- references to documents generated and • on a chronological basis
quirement has been met by proce- stored outside.
dural controls, along with the refer-
ence to the procedure and its ver-
sion number. In this case, the re-
quirement and design columns
should be blank, but the testing
column may not, as the use of the
procedure may be tested at the sys-
tem test level.

Figure 3. Example Requirements Traceability Matrix (RTM).

©Copyright ISPE 2006 JANUARY/FEBRUARY 2006 PHARMACEUTICAL ENGINEERING 3

GAMP Traceability
The method should be justified within
the process and based upon documented
and reasoned risk.

Conclusion
Although traceability is a valuable tool
for any system, its scope, depth, granu-
larity, and level of detail should be
commensurate with the criticality and
risk associated with the business pro-
cess being controlled by the system. If
traceability is sized correctly it may be
the one tool which can influence the
success of the project, support and
maintenance, and ‘auditability.’ How-
ever, like any other tool it can achieve
this success only if it is maintained
throughout the system life cycle.

References
1. PIC/S Guidance on Good Practices
for Computerised Systems in Regu-
lated “GxP” Environments (PI011-
2) (available at www.picscheme.org).

2. FDA, ‘General Principles of Soft-

ware Validation: Final Guidance to
Industry and FDA Staff,’ published
in 2002 by the Food and Drug
Administration’s Center for Devices
and Radiological Health (CDRH),
(www.fda.gov)

3. Wingate, G.A.S. (Editor), ‘Computer

Systems Validation: Quality Assur-
ance, Risk Management, and Regu-
latory Compliance for Pharmaceu-
tical and Healthcare Companies,’
published in 2003 by Taylor and
Francis (www.crcpress.com), ISBN
0-8493-1817-8.

4. GAMP® 4, Good Automated Manu-

facturing Practice (GAMP®) Guide
for Validation of Automated Sys-
tems, International Society for Phar-
maceutical Engineering (ISPE),
Fourth Edition, December 2001,
www.ispe.org.

Acknowledgements
The GAMP Forum would like to thank
Scott Lewis (Eli Lilly), Guy Wingate
(GlaxoSmithKline), and Mark Cherry
(AstraZeneca) for leading the develop-
ment of this guidance.

4 PHARMACEUTICAL ENGINEERING JANUARY/FEBRUARY 2006 ©Copyright ISPE 2006