What is Computerized System Validation?
Computer System Validation consists of a series of documents that ensure that software, equipment, utilities, infrastructure, or spreadsheets comply with the process, aiming to ensure patient or consumer safety, product quality, and data integrity.
In simpler terms, it proves that the system operates according to its intended use, consistently and with quality.
If it's not registered, it's just a rumor.
This statement underscores the crucial importance of validation. When a process, system, or data undergoes the proper validation process, is officially documented, and approved, it gains reliability and the 'validated' status.
The good news is that regulations worldwide are harmonized, so the rules are similar in regulatory bodies such as FDA, EMA, and WHO.
Do I Need to Validate All Systems in a Regulated Industry?
The answer is no! Not all systems require validation, only those that are GxP relevant (impact on product, quality, patient/consumer safety, and data integrity).
How to Validate?
Throughout the world, even though each country may have its own regulatory rules, most Life Sciences industries use GAMP5® as a framework for computer system validation.
The strategy of validating based on risk ("A Risk-Based Approach to Compliant GxP Computerized Systems") remains the central axis of the guide. GxP is a general term for the application of good practices. The 'x' indicates the area in which good practices apply (manufacturing, distribution, clinical research, laboratory, etc.).
Risk-based validation is expected by regulatory bodies. Mitigation actions are expected to be planned for risks classified as 'medium' and 'high.' If mitigation or upgrade is not possible, system replacement should be considered mainly for high risks.
The GAMP5® guide details the exact lifecycle required for each type of system, whether it's category 1 (infrastructure), category 3 (off-the-shelf), category 4 (configured), or category 5 (custom).
Even when an industry chooses to acquire validation or qualification document packages made available by equipment or system vendors, it's important to remember that these packages are partial. In other words, it's the industry's responsibility to review what has been provided and still develop a part of the validation or qualification lifecycle. In these cases, FIVE also stands as a partner for the industry, supporting the technical review of documentation provided by the supplier, as well as completing the validation or qualification lifecycle.
In these cases, FIVE also positions itself as a partner to the industry, offering to assist you in the technical review of documentation provided by the supplier, as well as in the completion of the Validation or Qualification cycle.
Lifecycle for a GAMP5® Category 4 System
The following list of documents (or deliverables) is common in a validation cycle.
However, after the release of the second edition of the GAMP5® guide, it became clear that the document names, mainly during test phases, are not strictly mandatory; the content is the most relevant aspect. In some companies that adopt agile approaches, requirements may be referred to as 'stories.'
Additionally, for certain systems, the Installation, Operational, and Performance Qualification phases may be referred to as Unit Testing Configuration, Functional Testing, UAT (User Acceptance Testing), Acceptance Testing (including FAT/SAT), Module Testing, Integration Testing, System Integration Testing (SIT), Data Migration Testing, or Requirements Testing.
- Initial Risk Assessment:
- Validation Plan:
- Configuration/Functional Specification:
- Hardware Design:
- Functional Risk Assessment:
- Design Review:
- Configuration Testing Protocol:
- Configuration Testing Script:
- Configuration Testing Report:
For off-the-shelf systems, this deliverable can be replaced by the system manual. The main objective of this deliverable is to provide a clear explanation of the development process for system configurations, customizations, and interfaces, as well as any interactions with other systems. The greatest source of uncertainty regarding this deliverable is usually related to the level of depth and detail required. However, it is practical to identify what should be documented in a way that enables a technical professional with the same knowledge to maintain or modify the configurations without the need to consult the experts who were involved in the original implementation of the system.
- Functional Testing Protocol:
- Functional Testing Script:
- Functional Testing Report:
- Requirements Testing Protocol
- Requirements Testing Script:
- Requirements Testing Report:
- Traceability Matrix:
- Final Validation Report:
This testing script must provide proof of compliance with functional specification, assuring the existence of approved procedures for the features with GxP impact, system security, and maintenance, checking the compatibility of its components with the functionality to be qualified, enabling the verification of technological capacity, and permitting compliance verification with GxP and other technical standards. It demonstrates that the system is working and properly documented through challenges based on risk assessment. For production or industrial automation systems and equipment, this phase can also be referred to as Operational Qualification (OQ).
The flowchart below was inspired by figure 11.7 in the GAMP5® second edition guide: risk-based approach for configured systems (category 4).
Agile Framework in Validation
A very common practice, especially due to the excessive workload resulting from paper-based validation or manual digital validation (based on a text editor), is the use of the waterfall model for project delivery.
Tools Instead of Documents
This is a critical point that can impact a business positively. The second edition of the GAMP5® Guide encourages and recommends the use of software tools to support Agile practices that can bring opportunities to improve a traditional documentation approach, which presents barriers and potentially introduces non-compliance risks (with paper, almost any change could be approved and would be harder to track).
A tool that is already adapted to the Agile framework in validation, in compliance with FDA, EMA, and WHO, is GO!FIVE®, making it an excellent choice for agile projects.
• Create/define items for each row of the matrix.
• Create item packages (requirements, risks, specifications, or tests);
• Partial release (by sprint, module, process, product, etc.);
• One Validation Plan and multiple Partial Reports.
Click here to learn more about how we can work together.