Computerized System Validation in Clinical Trials

ALCOA+: The Guiding Framework for Data Integrity

Clinical data integrity relies on ALCOA+ principles. They make it possible to assess whether data are understandable, reliable, traceable, and usable throughout their lifecycle.

‍

In a digital environment, these principles translate into concrete requirements: individual user accounts, audit trail, timestamping, access control, version management, backups, readable exports, and change documentation.

Which Frameworks Govern Validation?

Computerized system validation sits within several regulatory and methodological frameworks. Their application depends on the type of study, the countries involved, the data collected, and the intended regulatory use.

ICH E6(R3), GCP, and a Risk-Proportionate Approach

Good Clinical Practice requires control over systems, data, access, and associated documentation. ICH E6(R3) reinforces this logic with a quality-by-design approach that is proportionate to risk.

The idea is simple: the validation effort must be adapted to the criticality of the system. A tool that impacts participant safety, the integrity of primary endpoints, or the reliability of results requires a higher level of control than an ancillary internal reporting tool.

Frameworks such as GAMP 5 can help structure this approach, particularly to calibrate the validation effort according to intended use, risk level, and system complexity.

The European Guideline on Computerised Systems

Adopted in 2023, the European guideline Guideline on computerised systems and electronic data in clinical trials clarifies expectations for computerized systems and electronic data in clinical trials.

It covers, in particular, validation, the system lifecycle, user management, roles and permissions, the audit trail, security, backups, restoration, archiving, change management, and the availability of documentation during inspections.

Its principles are particularly structuring for drug trials. They also remain useful as a reference for framing computerized systems in other clinical contexts, according to the applicable requirements.

One point deserves emphasis: using a vendor or a cloud solution does not transfer the sponsor's responsibility. The sponsor must remain able to demonstrate that the system is fit for the study's intended use and that the data remain controlled.

21 CFR Part 11 from the FDA Perspective

In the United States, 21 CFR Part 11 applies to electronic records and electronic signatures used to meet applicable FDA requirements. It therefore becomes central for trials subject to the FDA or likely to support a US regulatory submission.

The regulation covers, in particular, system validation, access controls, the audit trail, protection of electronic records, usable copies of data, and the link between an electronic signature and the signed record.

The FDA also finalized guidance in 2024 dedicated to electronic systems, electronic records, and electronic signatures in clinical investigations. It clarifies expectations regarding the reliability, integrity, and equivalence of electronic records with paper documents when applicable requirements are met.

Convergence Between Europe and the FDA

European and US texts are not identical, but they are based on similar logic: intended use, risk-based approach, data integrity, traceability, access security, and control of the system lifecycle.

For an international trial, it is therefore preferable to design the digital environment coherently from the start, rather than treating each framework in isolation.

How to Validate a Computerized System

A validation approach generally follows a progressive logic. It must remain proportionate to risk, but certain building blocks almost always apply.

The main steps consist of:

• defining the intended use of the system;
• identifying user requirements, or URS;
• performing a risk analysis;
• assessing and qualifying the vendor;
• defining the validation plan;
• testing the system and its configuration;
• documenting the results;
• managing anomalies;
• approving the validation report;
• controlling changes;
• maintaining the validated state over time.

Three concepts often appear in this process:

In a SaaS environment, part of the documentation may be provided by the vendor. This is not always sufficient to cover the specific use of the study. The configuration specific to the protocol, roles, workflows, forms, and expected data must also be controlled.

Sponsor, CRO, Vendor: Who Is Responsible?

Using a SaaS vendor does not transfer the full responsibility to the provider.

The vendor may provide a validated platform, quality procedures, technical documentation, test reports, controlled version management, and audit support. But the sponsor remains responsible for demonstrating that the system is fit for the intended use of the study.

The distribution of responsibilities must be clear between sponsor, CRO, and vendor. It must be documented in contracts, procedures, validation plans, and vendor oversight plans.

In practice, this oversight must cover each party's responsibilities, available validation deliverables, study-specific configuration, user access, training, change management, and export or archiving arrangements.

Maintaining the validated state is just as important as the initial validation. An update, a configuration change, or the addition of a module may change the risk level and require a documented assessment.

The Most Frequent Errors

Some errors often occur in validation projects.

The first is assuming that a SaaS tool is automatically covered because it is marketed for clinical trials. The second is confusing vendor documentation with validation of the sponsor's real-world use.

Other errors are more operational:

• using shared accounts instead of individual accounts;
• failing to document performed tests;
• neglecting study-specific configuration;
• not controlling access rights rigorously;
• not reviewing the audit trail when necessary;
• failing to anticipate exports or archiving;
• not controlling the cloud providers involved;
• not assessing the impact of updates;
• maintaining procedures disconnected from the real use of the system.

These gaps are not always visible at launch. They often appear during an audit, inspection, database freeze, or final export.

What an eClinical Platform Should Facilitate

An eClinical platform designed for clinical trials should facilitate the fundamentals: individual user accounts, roles and permissions, audit trail, version management, usable exports, quality documentation, archiving, and controlled change management.

When the context requires it, it must also make it possible to manage electronic signatures within a controlled framework.

The purpose is not to claim that a tool makes a study “compliant” on its own. The challenge is to provide a secure, validated, traceable, and documented environment that helps sponsors and CROs demonstrate control over their systems according to the intended use.

Computerized system validation is a structuring requirement for digital clinical trials. It makes it possible to demonstrate that the tools used are fit for their intended use, controlled over time, and capable of preserving data integrity.

The challenge is not only technical. It concerns data quality, participant protection, sponsor responsibility, and the ability to respond to an audit or inspection.

A robust validation approach relies on a risk-proportionate strategy, clear documentation, controlled vendor oversight, and continuous maintenance of the validated state.