What is the GAMP 5 V-model in Computerized System Validation?

The V-model summarizes the key steps to be taken in conjunction with associated deliverables within the context of computerized systems validation or project lifecycle development. The GAMP 5 V-model describes the activities to be performed and the deliverables to be produced during product development.

The V-model is an SDLC model where execution of processes happens in a sequential manner in a V-shape. It is also known as Verification and Validation model. The V-Model is an extension of the waterfall model and is based on the association of a testing phase for each corresponding development stage.

V- model means Verification and Validation model. It is a widely accepted reference model for computer system validation and was introduced by International Society of Pharmaceutical Engineers (ISPE) in 1994 in the first edition of their Good Automated Manufacturing Practices guideline, (GAMP).

Using software for your life sciences operations requires high integrity and security in the data processing. Your computer systems must be designed to operate in a consistent and reproducible manner and comply with applicable GxP regulations to ensure the expected final product quality with certainty. Validating your systems provides documented evidence that they do exactly what they were designed to do.

Want to introduce robustness into your software validation activities? Then you can use the V-model or the Agile approach. Both of these are Computer System Validation (CSV) methods that can be applied according to GAMP 5 (the industry guidance on how to validate automated manufacturing equipment and computerized systems).

The GAMP 5 V-model describes the activities to be performed and the deliverables to be produced during product development.

5 main steps of the GAMP 5 V-model

The GAMP 5 V-model strategy has a descending (planning, specification, configuration) and ascending (configuration, verification, reporting) phase, going back and forth from the customer to the supplier.

• First, in the descending phase, input from the customer helps the validation vendor implement the requirements at the bottom of the V-model.

• Then, in the ascending phase, the resulting development is compared to the original input statement to verify that the customer’s requirements have been met.

1. Planning

The planning phase aims to define the strategy for validating the computerized system. The strategy is essential and will be defined in the validation plan, but there are more deliverables than the validation plan in the planning phase.

• Validation project plan. Boundaries and interfaces are defined with the software scope, leading to a risk analysis to evaluate criticality. To complete the description of the validation strategy, a list of documents and responsibilities and a list of applicable procedures, responsibilities and required documentation are created then tasks and roles are assigned to members of the validation team.

• Description of the system. In accordance with EU GMP Annex 11, clause 4: “An up-to-date description of every GxP regulated computerized system should be available.” Any authorized person, new user, or auditor must have access to this information.

• User Requirements Specifications (URS). Users’ needs are described from their point of view. They guide the development activities and the functional controls that are implemented later. Requirements can be categorized as operational, process, regulatory, quality, performance, etc.

• Risk analysis. Using common risk assessment techniques, risks are identified, qualified, and quantified to provide a response to ultimately control them. Based on statistics, matrices are created to determine risk classes by crossing severity and probability. Priorities are then determined by crossing risk classes and detectability.

2. Specification

The user requirements specifications, which correspond to the end users’ expectations of the computerized system, are translated into functions, system interfaces, and system descriptions.

To ensure traceability between user requirements, functions, configurations, and later test activities, a traceability matrix is required to establish the link between user requirements specifications and functional, design, configuration, and unit specifications.

Such a matrix considers both the hardware and software sides. References are given to procedures (e.g.: SOP and change controls) and the criticality of the requirements.

3. Configuration/coding

This is the step in which the supplier relies on its expertise to implement the customer’s requirements. All functionalities documented in the previous steps are implemented.

4. Verification

According to the test procedure, the results in the test reports are obtained from the previously performed configuration/coding. They are compared with the expected values from the specifications. Verification tests consist of

• unit and integration testing (integration qualification, IQ: the system is built as intended);

• functional testing (operational qualification, OQ: the system works as intended).

• as well as user acceptance testing (process qualification, PQ: the systems meet users’ needs).

5. Reporting

The validation report is a summary of the previous results and activities of the project. It is the final documented evidence that the automated system has been validated.

Furthermore, all types of events that occur during the validation process are documented. This includes scope changes, references to the vendor review, a list of various activities, deliverables, deviations and corrective actions, statements: “Fit for intended use,” training, and others.

Why use the GAMP 5 V-model?

The advantages of a V-model approach:

User Requirement Specifications (URS)

End users clearly define their needs in a URS document approved by the parties involved (users, validation team, quality assurance). There is always an opportunity to modify them, preferably early in development to save costs.

Quality & Compliance

The V-model approach relies on documented steps, either requirements (URS) or development and validation (Unit & Integration Testing, Functional Testing, User Acceptance Testing,). This ensures a high level of data integrity.

Project planning. Manpower and time are easily managed as each step has a predetermined duration.

Reliability

In the descending phase of the V-model, testing is done gradually until development. Together with the control of the ascending phase, any errors can thus be easily detected and corrected.

The V-model of CSV can be an approach, which will help you to ensure:

• Goal, scope, and limitations of software use are defined

• Little to no place is made for mistakes

• Tied budget

• Data integrity related to patient health security