Computer System Validation in Clinical Trials - Trust Built on Evidence

Introduction: Digitalization Demands a New Approach to Quality

Technological advancement has completely transformed the clinical trial landscape. Systems such as EDC (Electronic Data Capture), together with electronic case report forms (eCRF), electronic clinical outcome assessment forms (eCOA), electronic patient-reported outcome forms (ePRO), cloud platforms, mobile applications, and AI-powered solutions, are now widely used, and the scale of their adoption continues to grow steadily.

Ongoing digitalization supports the conduct of clinical trials, improving both their quality and efficiency. At the same time, technology ecosystems are becoming increasingly complex, and data sources are becoming more distributed. As a result, regulatory expectations placed on organizations conducting trials continue to grow. This also applies to systems that incorporate AI/ML components, where validation must account for, among other things, model change control and risk management related to the algorithm used.

In such an environment, the key question is not only about the reliability of the data itself, but also about trust in the processes and systems that generate and process that data. Computer system validation is an essential element in addressing these challenges - one of the cornerstones of quality assurance and trust-building in modern clinical trials. While validation does not resolve every quality issue, it serves as a tool confirming that the system supporting the trial performs as intended and remains in a state of control.

What Is Computer System Validation?

Computer System Validation (CSV) is a documented process intended to confirm that a system:

• performs as intended (fit for intended use),
• meets user and regulatory requirements,
• ensures data integrity, security, and availability.

Validation is not limited to testing the software itself. It covers the entire lifecycle of the system supporting the clinical trial - from planning and requirements definition, through implementation, use, and change management, to the controlled retirement of the system.

In regulated environments - that is, environments subject to specific legal or industry requirements concerning security, quality, or data integrity (e.g., clinical trials, pharmaceutical manufacturing) - it is important to distinguish between three concepts:

Verification typically precedes qualification, while qualification is an essential component of the validation process.

From a regulatory authority’s perspective, the use of a system that has not been properly validated and maintained in a state of control (validated state) may mean that the reliability and integrity of the data collected using that system cannot be defended under GCP.

Why Does Validation Matter in a Clinical Trial?

Validation Supports Data Integrity and Quality (ALCOA++)

In accordance with the ALCOA++ principles (see also ALCOA++ in Practice - A New Dimension of Data Quality ), as set out, among others, in ICH E6(R3) GCP and the EMA guidelines (discussed below), data should remain attributable, accurate, complete, and traceable throughout their entire lifecycle, so that they can be reconstructed. In a digital environment, meeting these requirements depends on properly designed and verified processing systems.

The system must provide, among other things, an audit trail, user access control, change management, proper management of electronic signatures (in accordance with FDA 21 CFR Part 11), and the maintenance of data consistency. What matters most, however, is not merely the existence of these mechanisms, but confirmation - through the validation process - that they function correctly and in accordance with requirements in the context of the specific trial.

Validation Is Driven by Regulatory Agency Expectations

Validation is not merely a good practice - it is a direct consequence of regulatory expectations for systems used in clinical trials.

The primary regulatory framework is provided by the ICH E6(R3) GCP guideline, which requires computer systems to be fit for their intended purpose (fit for purpose) - among other things, through the application of risk-based validation proportionate to the impact on participant safety and data reliability. The guideline strengthens risk management, critical-to-quality factors, and oversight of data and systems throughout the trial lifecycle.

In the European Union, expectations for IT systems and electronic data in clinical trials are further detailed in the EMA Guideline on Computerised Systems and Electronic Data in Clinical Trials . In the United States, 21 CFR Part 11 and FDA guidance on data integrity and electronic systems in clinical trials are of key importance (see also Trustworthy technologies - how to ensure the credibility of clinical trials in the digital era? ).

When implementing these expectations, organizations often draw on recognized industry good practices such as GAMP 5. These are not legal requirements, but they help determine the scope and documentation of validation in proportion to risk.

Today, regulatory expectations apply not only to traditional EDC systems, but also to mobile applications, recruitment support tools, CTMS platforms, and analytics modules. Virtually every element of a trial’s digital ecosystem may require validation assessment - in proportion to its impact on data and the trial process.

Validation Supports Data and Patient Safety

Clinical data belongs to one of the most sensitive categories of information - it includes personal data, detailed health information, and sometimes genetic data as well. Systems used in trials must ensure an appropriate level of security: access control, encryption, business continuity, and resilience against cyber threats.

Standards such as ISO/IEC 27001 provide a framework for an organization’s information security management system. ISO 27001 certification confirms an organization’s general competence in the area of security, but it does not replace the validation of a specific system used in a trial. It is validation - combined with risk assessment - that confirms the implemented mechanisms actually function effectively within the operational environment of a given trial (see also ISO/IEC 27001:2022 in Clinical Trials: Turning Data Security into a Quality Standard ).

Validation Is a Risk Management Tool

Risk-based validation allows the scope of activities to be proportionally aligned with the system’s impact on data quality, patient safety, and regulatory compliance. This enables an organization to focus its efforts on elements of genuine significance, rather than generating documentation disconnected from actual risk.

The Scope of Validation in Clinical Trials

The scope of validation extends far beyond confirming that a system “works.” It includes an assessment of how the system affects:

• the quality and integrity of clinical data,
• information security,
• compliance with regulatory requirements, including sponsor-specific requirements,
• critical trial processes and patient safety.

In practice, this means analyzing the system’s entire period of use - from validation planning and requirements definition, through configuration and integration with other tools, use in the operational environment, to the controlled retirement of the system. It is also important to assess the flow of data between systems: its completeness, consistency, and resilience to errors and data loss.

For solutions provided by external vendors, the scope of assessment also covers the shared responsibility model with the vendor, vendor qualification, environments (e.g., test vs. production), data location, and service continuity mechanisms.

The scope of validation includes verification of access control mechanisms, permission management, change logging (audit trail), and safeguards against unauthorized interference. The greater the system’s impact on clinical data or trial-related decisions, the more detailed and rigorous its validation should be.

System Lifecycle vs. the Validation Process

One common mistake when describing validation is conflating the system lifecycle with the validation process. These are two distinct, though closely related, areas.

The lifecycle describes the successive stages of a system’s existence - from planning to retirement. The validation process does not replace this lifecycle: it is a parallel set of activities and documentation that accompanies the system whenever it is used in a clinical trial. This makes it possible, at every significant stage of the system’s life, to demonstrate that it remains in a state of control and continues to meet requirements.

Validation Stages in the System Lifecycle

In the previous section, we distinguished between the system lifecycle and the validation process. In practice, the two are often described together: as the successive stages a system used in a clinical trial goes through, along with the accompanying validation activities. The overview below combines both areas in this way - without treating them as identical.

According to the GAMP 5 approach, a system is never “validated once and for all.” It passes through successive stages, and after each significant change it requires reassessment - and, where justified, requalification or revalidation.

1. Validation Planning and Requirements Definition

The process begins with a Validation Plan (VP), which defines the strategy, scope, roles, responsibilities, risk-based approach, and the expected deliverables of the validation process. The validation plan should be developed before detailed system qualification begins.

This stage also produces the User Requirements Specification (URS), which specifies:

• which functions the system is required to perform in the given trial,
• which regulatory and organizational requirements it must meet,
• what the critical processes and data flows are.

The URS serves as the reference point for the entire validation process and as the basis for the requirements traceability matrix, which links requirements to specifications, test cases, and results.

2. Solution Selection, Development, and Configuration

User requirements are translated into a specific technology solution. Depending on the choice made, the selected solution is assigned an appropriate category in accordance with GAMP 5. Numerous, varied criteria guide the selection of a system, for example:

• choosing an off-the-shelf solution or developing a custom-built system,
• development or implementation of functionality (for bespoke systems),
• configuration, parameterization, and integration with other tools,
• adaptation to the specifics of the given clinical trial.

In practice, the system category determines the scope of validation:

At this stage - particularly for Category 5 systems - verification during development is carried out (e.g., code review, unit testing, integration testing). Using proven vendor solutions (Category 4) can reduce risk and the scope of validation, but it does not relieve the organization using the system of responsibility for its qualification in the context of the trial.

3. System Qualification

This is the stage that confirms the system operates in accordance with its specification and meets regulatory requirements. Qualification is carried out through documented tests, the scope of which is determined by risk analysis. Every critical requirement in the URS should be traceable to a corresponding test case and test result.

The following are most commonly distinguished:

• DQ (Design Qualification) - confirmation that the system design meets user requirements (particularly relevant for custom-built, Category 5 systems),
• IQ (Installation Qualification) - confirmation that the system has been installed correctly (environment, configuration, components),
• OQ (Operational Qualification) - confirmation that the system operates in accordance with its functional specification under controlled conditions,
• PQ (Performance Qualification) - confirmation that the system performs correctly in the real-world operational environment, including in the context of the specific trial protocol (often includes user acceptance testing - UAT).

Not every system requires the full DQ/IQ/OQ/PQ set - the scope depends on risk analysis and the GAMP 5 category. Following successful qualification, an authorized person formally approves the system for use, together with user training.

During qualification, validation documentation is produced - plans, test protocols, reports, deviation logs, and decision rationales. Documentation is not a separate “stage” of the lifecycle; it is an integral part of every step described above and ensures a complete audit trail.

4. Maintenance, Monitoring, and Change Management

Validation does not end with implementation. Ongoing maintenance, monitoring, periodic reviews, and formal change management are equally important.

A periodic review - in line with GAMP 5 - consists of a regular assessment of whether the system continues to meet requirements and remains “fit for intended use” (e.g., an annual review, internal audit, or verification that documentation is up to date).

Every modification - a software update, a configuration change, a new integration - can affect the system’s compliance with validation requirements. It therefore requires an impact assessment and, following the risk analysis, may also require, where justified:

• requalification - a limited-scope set of tests confirming the impact of a specific change,
• revalidation - a broader, renewed validation process, when the change has a significant impact on the system.

This stage also includes incident management (e.g., system failures, security breaches) and ensuring that users have up-to-date training on the changes introduced.

The activities carried out at this stage are cyclical in nature: a system remains in a state of control only when changes are identified, assessed, and properly documented.

5. System Retirement

The final stage of the lifecycle is the controlled retirement of the system. This process should be planned and documented to ensure:

• continued access to clinical data,
• data integrity and readability throughout the retention period,
• migration of data to an archive or another system, if required,
• the ability to reconstruct data in the future (e.g., for audit or inspection purposes),
• safe decommissioning of the system without risk of data loss or breach,
• formal validation closure, with a summary of the system’s history.

Clinical data must be retained for the required period - in accordance with applicable regulations, GCP principles, and the sponsor’s specific requirements.

Division of Responsibilities

Responsibility for validating a system and maintaining it in a state of control rests with the organization that uses it in the clinical trial - regardless of whether that organization is the sponsor, a CRO, or an investigational site. Ultimate responsibility for the trial’s compliance with regulatory requirements rests with the sponsor.

In practice, the allocation of validation responsibilities among the sponsor, CRO, vendors, and sites should be explicitly documented in a quality agreement or the trial’s quality plan - for example, specifying who validates the EDC, who validates the CTMS, and who is responsible for local site-level integrations.

A system vendor may provide validation documentation, certificates, or test reports; however, the organization using the solution in the trial must independently assess whether the product or service meets requirements in the context of the specific protocol and operational environment. Uncritical reliance on a vendor’s declarations - in place of the organization’s own qualification - constitutes a serious regulatory risk.

Common Mistakes in the Validation Process

Treating Validation as a One-Time Project

Validation carried out only at the implementation stage, without mechanisms for maintaining the validated state, does not protect the system from the effects of later changes. Updates, integrations, and configuration modifications require ongoing control - in line with the validation stages described above in the system lifecycle.

Lack of Periodic Review

Organizations often carry out change control but omit periodic reviews - a formal, cyclical assessment of whether the system remains fit for its intended use. As a result, gradual, minor, and unintended changes to configuration and process may go undetected until the time of an audit.

Lack of a Risk-Based Approach

A uniform, one-size-fits-all approach applied to all systems leads to two extremes: excessive documentation that burdens teams at the expense of genuine quality control, or - the riskier alternative - omitting tests critical to data integrity, without documented justification for that decision.

Ineffective Change Management

Introducing modifications without a formal assessment of their impact on the system’s compliance with validation requirements can lead to a loss of control over the system and its compliance with regulatory requirements.

Excessive Reliance on Vendor Declarations

Using ready-made, verified solutions is consistent with the GAMP 5 approach, but a vendor’s declaration that a system is “validated” does not replace the qualification of the product in the context of a specific trial. The organization must independently confirm that the solution meets requirements within the intended operational environment.

Consequences of These Mistakes

The consequence of these mistakes can be a loss of control over the system supporting the trial, which in turn undermines the reliability of the data and, in extreme cases, the results of the entire trial. This can result in delays in registration processes or the need to repeat part of the trial activities.

Conclusion: Validation as Evidence of Trust

In the digital era, computer system validation:

• is a risk management tool for systems supporting clinical trials,
• supports data integrity and quality in accordance with the ALCOA++ principles,
• helps maintain compliance with regulatory requirements,
• builds auditable trust in the processes and systems that generate and process clinical data.

Validation is not about declaring trust in a system - it is about building trust based on documented evidence. An organization must be able to demonstrate, through appropriate actions and documentation, that throughout its entire period of use in the trial, the system remains in a state of control and meets both quality and regulatory requirements.