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).
In this blog post, we will address the following questions:
- What is the Agile approach?
- What is the GAMP 5 V-model?
- What are the main steps within the V-model?
- Why use the V-model?
Enjoy reading!
A complete guide to Computer System Validation
This +100 page guide aims to bring context and define the necessary and appropriate strategies for the validation of computerized systems for Pharmaceutical Industries, Biologics, Biotechnology, Blood Products, Medicinal Products, and Medical Devices, used in activities related to compliance with Good Practices (GxP). Download it now for free:
FREE E-BOOK
Agile approach VS GAMP 5 V-model
What is the agile approach in CSV?
The agile approach is based on a continuous exchange between the customer and the validation team. The phases of the project rely on constant feedback from the client to make progress and is an agile approach to achieve a system that meets end-user expectations. With an agile approach, you have less control over the overall budget and timelines for implementing an automated system.
What is the GAMP 5 V-model in CSV?
Is managing time and budget important to your organization? If so, use the GAMP 5 V-model. 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 name refers to the shape of its common graphical representation: a V.
It is a variant of the Waterfall model of software development, which describes a sequential procedure in which each step must be completed before the next can be started. Since cycles are possible here, the V-shape appears.
Figure 1 – V-model scheme from the GAMP 5 guide
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.
5 main steps of the GAMP 5 V-model
Each of the 5 main steps of the GAMP 5 V-model has different deliverables. Let’s look at their purpose in detail below
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. Finally, 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?
We started by explaining the main differences between the Agile approach and the GAMP 5 V-model. Both approaches have their strengths and pitfalls, but summarized below are the advantages of a V-model approach:
Design that meets end-user expectations of 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.
In conclusion, why would you opt for the GAMP 5 V-model?
Does your software need validation for a specific activity? 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
Do you wish to implement a V-model validation process within your company? Our experts in QbD will be happy to help you! Please do not hesitate to contact us.
