V Model - Gamp 343h39

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 – 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.