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

For example, in an R&D lab or manufacturing facility, there are likely to be several GxP-relevant systems due to their direct connection to the product. On the other hand, if your company is involved in distribution, one only needs to validate applicable systems. Some examples include WMS (Warehouse Management System), QMS (Quality Management System), and temperature monitoring systems, as well as electronic spreadsheets (if applicable).

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.

GAMP5® was developed by ISPE® (International Society for Pharmaceutical Engineering). The first edition of the 5th version of the guide was released in 2008, and in 2022, the second edition of the 5th version of the publication was released, providing information that can be useful for the business.

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.

URS:
Initial Risk Assessment:
Validation Plan:
Configuration/Functional Specification:
Hardware Design:
Functional Risk Assessment:
Design Review:
Configuration Testing Protocol:
Configuration Testing Script:
Configuration Testing Report:

The User Requirements Specification defines clearly and objectively all the requirements that a computerized system must meet and can be used as a document or contractual deliverable. It is typically drafted by the user, but interestingly, it is created by a multidisciplinary team and undergoes review and approval by the relevant users, including Quality Assurance.

An initial risk analysis should be conducted based on an understanding of the processes, evaluations of business risks, user requirements, and regulatory requirements. The results of this Initial Risk Assessment should include the decision on whether the system falls under GxP (GxP assessment). Typically, when there is an impact, this assessment is referenced within the Validation Plan.

The Validation Plan dictates the standards, methods, and personnel involved to ensure quality through the development life cycle of a system and establishes the adequacy of their performance. The validation plan should be initiated as early as possible and updated in subsequent stages of the project. The validation plan size should be proportional to the complexity of the project. All documentation used during the validation work should be mentioned here and be subject to revision history records and approvals. For the adoption of the Agile framework in validation, it is beneficial that the release strategy through sprints and configurations be detailed in the plan.

The Functional Specification is a type of specification deliverable and should define clearly and completely what the computer system does, and what functions and facilities should be provided to meet the needs described in the User Requirements. Furthermore, the functional specification is typically produced by a supplier, whether internal or external to the company, and should be reviewed and approved by the contractor, and may be considered a contractual document.

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.

The Hardware Design is another type of deliverable (also known as Technical Specification) that should detail the design and the related technological infrastructure component requirements in which the computer system needs to be installed for use, whether this infrastructure is in the cloud or not. This document or deliverable shall include the system's planned and appropriate specifications, covering all components, software, and hardware that make up the infrastructure. The Hardware Design is based on the technical requirements for the installation and configuration of a computer system, to ensure its integrity, security, and performance in testing and operational environments.

Risk management is the primary strategy outlined in GAMP5®, in both the first and second editions, which includes an assessment of risks posed by the system in the process it is managing, including potential mitigating actions (or control measures). Higher risks may require a higher level of testing rigor and documentation. The verification of control implementation continues throughout the validation lifecycle, and it is expected that medium (beneficial) and high (mandatory) risks are mitigated and verified during the testing phase to demonstrate compliance, enabling the system to achieve 'validated' status.

The scope of this deliverable is to verify the system's compliance with the requirements and system specifications. It provides documented verification that the proposed design for facilities, systems, and equipment is suitable for its intended use. Applicable for GAMP5® category 4 and 5 systems.

The testing protocol is the document that guides the phase of validating the quality and safety of the computerized system. It may include the scope, test plan, strategy, sampling definition, participants, acceptance criteria, and how any failures or changes will be handled during the testing phase.

The objective is to confirm and document whether the system components have been assembled and installed according to specifications, supplier documentation, and local as well as global requirements. It may also include evidence of the acceptance of supplier documentation, such as specifications, manuals, and drawings. For production or industrial automation systems and equipment, this phase can also be referred to as Installation Qualification (IQ).

This report summarizes the results of the validation studies conducted on the system during the Configuration Testing phase.

Functional Testing Protocol:
Functional Testing Script:
Functional Testing Report:
Requirements Testing Protocol
Requirements Testing Script:
Requirements Testing Report:
Traceability Matrix:
Final Validation Report:

The test protocol is the document that guides the phase of verifying the system's operations according to the written and pre-approved specifications across its entire range of operations. It may include the scope, test plan, strategy, sampling definition, participants, acceptance criteria, and how any failures or changes will be handled during the testing phase.

This document aims to reference, verify, and document the system’s operating conditions and if it complies satisfactorily with the predefined requirements for its operation.

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

This report summarizes the results of the validation activities conducted on the system during the Functional Testing phase. It can be prepared for the entire system or partially, enabling, within the Agile framework, the release of a portion of the system for production use while ensuring compliance (go live).

The test protocol is the document that guides the system verification phase regarding the operations defined in the requirements. The tests conducted in the previous phase are not fully re-executed in this stage.

In this phase, the tests aim to refer, verify and check the proper parametrization. This test script must provide proof of compliance with user requirements and/or functional specifications, confirm the existence of approved procedures for the features with impact on GxP, and allow for verification of compliance with the rules of GxP and other technical standards, enabling security management. For production or industrial automation systems and equipment, this phase can also be referred to as Performance Qualification (PQ).

This report summarizes the results of the validation activities conducted on the system during this testing phase.

The Traceability Matrix establishes the relationship between two or more deliverables that are developed during the validation process. The Matrix ensures that requirements are met and can be traced to their settings and/or design elements of the system and the test that checks that the requirements have been met. A matrix can also enhance the effectiveness of risk management and simplify the evaluation of the potential impact of a planned change. The Traceability Matrix must be approved and integrated into the system life cycle.

The Final Validation Report of a system validation should be prepared considering the results obtained from the tests applied in the different testing phases. It should also include the regulatory requirements as established in the Validation Plan. After obtaining approval from the Validation Report, any modifications to the system should be carried out through the established change control procedure.

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.

The Waterfall model is not necessarily a problem; there have been several successful projects in this format. The issue lies in adaptation and flexibility for changes.ISPE GAMP5® guides best practices for GxP relevant systems has incorporated various concepts from the Agile framework, supporting the use of incremental, iterative, and evolutionary approaches for the development of custom application products.Agile is a controlled process, and, just like the Waterfall approach, if executed poorly and lacking controls, it is unacceptable.

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

Paper documents can be susceptible to inaccuracies and challenging to track, while electronic formats, when managed using document management tools, may present a risk of allowing the testing executor to make unauthorized changes to a previously approved script.

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.