GAMP5 & V Model

GAMP® makes use of a lifecycle ‘V-Model’ that simply aligns specification and design inputs against
verification and testing outputs

GAMP®-5 (published in 2008) fully aligns itself with ASTM standard E2500 ‘Standard Guide for
Specification, Design, and Verification of Pharmaceutical and Biopharmaceutical Manufacturing
Systems and Equipment’ (first published in 2007). One unique aspect of GAMP®-5 is its scalable
approach to GxP compliance. Whereas GAMP®-4 focused on more of a one-size-fits-all lifecycle
model for bespoke and complex configurable systems, GAMP®-5 scales the lifecycle deliverables
based on a computerized system’s impact on product quality and patient safety, and on its relatively
complexity and novelty.

Multiple ‘V-Models’ are illustrated in GAMP®-5 for varying degrees of scalability.

GAMP is an acronym for Good Automated Manufacturing Practice, (which is hopefully quite familiar to
you), for a risk-based approach to computer system validation where a system is evaluated and assigned
to a predefined category based on its intended use and complexity. GAMP 5’s approach can be summed
up by the V model diagram. The V model juxtaposes the specifications produced for a system to the
testing performed as part of the verification process. Specifications and design down the left side of the V
and verification and validation up the right side. Traceability across the V results in tracing test cases to
the design elements, design elements to software requirements, software requirements to product
requirements. The types of specifications associated to a system are tied to its degree of complexity. The
V-model provides a logical sequence that helps to organize the 232 complex activities of defining a project
scope, executing it and qualifying it.
Additionally, because it’s a risk-based approach, it requires you to target and start with the high-risk
areas of the system to scope out your testing approach in a logical manner, (avoid wasting extra time on
low risk areas), and remain focused on revealing critical defects lurking in the code, prior to release. One
great advantage (GAMP 4 vs GAMP 5) is the redefinition of Performance Qualification (PQ) as
“Requirement Testing”, another was emphasis of the importance of Configuration Specification (CS),
describing the system configuration and representing the reference (controlling specification) for the
configuration verification activities (aka IQ)

GAMP recommends an SDLC called the V-model (see graphic) because it is a commonly used design, but
there are others that can be followed. The V-model shows how the three main qualification activities
(installation, operation and performance) are linked back to the design process. These main steps
correspond to deliverables within a computerized validation framework. The left side of the V represents
the specification stream – user requirements, functional specifications, hardware and software design,
and module specifications. The right side of the V represents the system testing stream against the
specifications. The bottom of the V indicates the code modules.
Top Three Challenges
As a voluntary program, GAMP offers both challenges and benefits. The top three challenges in
implementing GAMP are establishing procedural control, handling management and change control, and
finding an acceptable standard among the existing variations.

Establishing procedural control is a challenge in using GAMP guidelines because new frameworks may
be necessary to gauge the validity of systems. Most pharmaceutical companies have already established a
baseline that adheres to standards and regulations that exist today, but they may not have a procedure to
check the processes that are in place. This could cause resistance among software developers who may
prefer not to work within the confines of specifications and procedures developed by others.
Specifications and procedures developed by previous software developers may hinder ways to adjust
computer systems, but varying interpretations of GAMP guidelines allow for multiple solutions.

Another hurdle is change control. In the development or modification of computer systems, companies
with even the highest of standards can suffer setbacks along the SDLC. Sometimes minor tweaks by the
software programmer, whether necessary or not, may cause breakdowns after validation changes have
been implemented. Internal processes and procedures must be established to guard against these
occurrences.

Whether utilizing another company’s specifications and procedures or your own, effective
documentation management is fundamental for compliance. Any inaccuracies or missing information
renders all other efforts moot. Moreover, implementing a formal document management application may
be cost-prohibitive for some organizations. Some companies simply use what’s in the GAMP checklists
to evaluate their systems. Today’s environment demands a thorough process to show validation.