Clinical trial systems operate in a different regulatory frame from GMP systems, but the data integrity and validation obligations are equivalent in weight. The consequences of failure are different, a GMP failure risks product quality; a GCP failure risks the credibility of the evidence base for regulatory approval and, downstream, patient safety decisions.

This article covers the five core clinical computerized systems, EDC, IRT/RTSM, eTMF, CTMS, and safety databases, and what compliant validation and data integrity looks like for each.

The regulatory framework for clinical computerized systems

Three sources govern clinical system requirements in the US context:

21 CFR Part 11, Electronic records and signatures. Applies when electronic records are used under predicate regulations (21 CFR Part 312 for INDs, Part 314 for NDAs). Systems that generate, modify, maintain, archive, retrieve, or transmit electronic records that substitute for paper are subject to Part 11.

FDA Guidance: Electronic Records; Electronic Signatures in Clinical Investigations (2003, supplemented 2013), Clarifies how Part 11 applies to clinical investigations specifically. Covers EDC, electronic source data, certified copies, and the responsibilities of sponsors, CROs, and sites.

ICH E6(R2) and E6(R3), Good Clinical Practice guidelines. R2 added risk-based monitoring and electronic systems guidance. R3 (in finalization) expands proportionate oversight requirements. Both versions require validation of computerized systems and controls for electronic source data.

The EU equivalent is the EMA Reflection Paper on Expectations for Electronic Source Data (2010) and EMA GCP Inspection Findings publications, which describe what MHRA and EMA inspectors observe during clinical inspections.

What “validation” means for clinical systems

The term validation in the clinical context means the same thing as GMP validation: documented evidence that a system consistently produces results meeting its predetermined specifications. The practical difference is:

  • GMP systems: validated by the regulated company that owns them
  • Clinical systems: often validated by vendors (CROs, SaaS EDC providers), but the sponsor retains regulatory responsibility

This is a critical misunderstanding in many clinical development programs. “The vendor validated it” is not a complete answer. The sponsor must verify that:

  1. The vendor’s validation documentation is adequate and available for inspection
  2. The sponsor’s specific study configuration is tested (configuration-level validation)
  3. The system, as configured for the study, meets 21 CFR Part 11 requirements
  4. Audit trails are enabled and capture what they need to capture
  5. Access controls are appropriate

The GAMP 5 framework applies here: vendor-supplied SaaS EDC platforms are Category 4 systems. The vendor provides the platform validation; the sponsor validates the study configuration. Both are required.

Electronic Data Capture (EDC)

EDC is the software used to collect clinical trial data from investigative sites. Common platforms in use: Medidata Rave, Oracle Clinical One, Veeva Vault EDC, OpenClinica, REDCap (academic/non-commercial).

What EDC must do under GCP and Part 11

Audit trail requirements:

  • Every data entry, modification, deletion, and query must be captured in an audit trail
  • The audit trail must record: who made the change, when, what was changed (original and new value), and reason for change
  • Audit trails must not be editable by users who generated the data
  • Audit trail review is part of the sponsor’s monitoring and data management obligations

Electronic source data:

  • When data is entered directly into EDC at the site (no prior paper), the EDC entry is the source record
  • FDA guidance requires that source data entered electronically: is attributable to the person who entered it, has a contemporaneous timestamp, and cannot be altered without documentation
  • The concept of “direct data capture” (DDC) means the EDC audit trail is the only record, there is no paper source to fall back on

Access controls:

  • Site personnel must have individual accounts with role-appropriate access
  • Shared accounts are not acceptable, they break attributability
  • Password and authentication requirements must meet Part 11 §11.300 criteria
  • Account creation and deletion must be tracked (access provisioning audit trail)

Configuration validation for EDC

When a study is built in an EDC platform, the build is a configuration. Configuration validation covers:

  • Edit checks (logic validation rules): each rule must be tested to confirm it fires correctly and doesn’t generate false queries
  • Visit structure and form layout: verified against the protocol
  • Randomization and stratification rules (if applicable): tested for all scenario combinations
  • Data exports: output format verified to match SAP and downstream statistical analysis expectations
  • Regulatory signatures: confirmed to meet Part 11 requirements

A frequent inspection finding: edit checks in production that were never tested, or test records that show edit check testing but with insufficient scenarios (only tested the “pass” path, not the “fail” path).

What BIMO inspectors check in EDC

FDA’s Bioresearch Monitoring (BIMO) program inspects clinical sites, sponsors, and CROs. In EDC reviews, inspectors typically request:

  • Audit trail extracts for selected subjects, looking for unexplained data corrections, date discrepancies, or patterns suggesting data was not captured contemporaneously
  • Access control records, who had access to what, when, and whether access was terminated appropriately when personnel left
  • EDC validation documentation, system qualification records, configuration testing, Part 11 assessment
  • Training records for EDC system use
  • Query resolution documentation, pattern of queries that were resolved without underlying source document updates (a sign of compliance-only corrections)

IRT / RTSM (Interactive Response Technology / Randomization and Trial Supply Management)

IRT is the system that manages randomization, drug dispensing, and supply chain logistics for a clinical trial. Every patient randomization and every drug dispense is a GCP-regulated event.

Why IRT validation is high stakes

IRT drives:

  • Which treatment arm a patient is assigned to (randomization integrity)
  • Whether a patient receives correct study medication (supply accuracy)
  • Drug expiry and resupply decisions (patient safety)

Incorrect IRT logic can cause protocol deviations affecting hundreds of patients across dozens of sites. This happened in real trials when stratification algorithms were misconfigured, patients were not properly balanced across arms, and the randomization had to be unblinded and assessments redone.

IRT validation requirements

IRT platforms are GAMP Category 4 or 5 depending on whether they are configured COTS or custom-built. The validation package must cover:

  • Randomization algorithm testing: every randomization scenario defined in the protocol must be tested with verified expected outcomes
  • Stratification testing: verify that all stratification factors work correctly and in combination
  • Dispensing logic: confirm that the dispensing rules fire correctly for all visit types and subject conditions
  • Drug accountability: verify that the system tracks quantities correctly and generates alerts at the right thresholds
  • Unblinding procedures: the emergency unblinding workflow must be tested and documented
  • UAT by study team: the study pharmacist, project manager, and clinical team must execute user acceptance testing against the study protocol, not just IT acceptance testing

Common IRT data integrity issues

  • Randomization performed on paper backup when IRT was unavailable, paper randomization must have the same attributability controls as the system
  • Site personnel sharing IRT credentials (same problem as EDC, breaks attributability of who dispensed to whom)
  • Protocol amendments not reflected in IRT updates: visit schedules change, drug dosing changes, but IRT isn’t updated via change control

eTMF (Electronic Trial Master File)

The Trial Master File is the collection of essential documents that allow the conduct of the clinical trial to be evaluated retrospectively. The eTMF is the electronic system that stores these documents.

What the TMF must demonstrate

ICH E6 and FDA regulations require the TMF to contain all essential documents that individually and collectively permit evaluation of:

  • The conduct of the trial
  • The quality of the data collected
  • The investigator’s and sponsor’s compliance with GCP

The eTMF must be complete (no missing documents), organized (documents filed per a defined structure), and available for inspection. In practice, inspectors request eTMF access or exports early in a BIMO inspection.

eTMF validation requirements

eTMF platforms are typically GAMP Category 4 (configured COTS). Validation covers:

  • Document upload and metadata capture (filename, document type, date, version, status)
  • Access controls (role-based access, site-level access restrictions)
  • Audit trail for document uploads, revisions, moves, and deletions
  • Completeness tracking: the eTMF should have a mechanism to track expected vs. filed documents
  • Retention and archival: documents must be retained per the retention schedule and remain retrievable

Inspection readiness for eTMF

A complete, inspection-ready eTMF includes:

  • Finalized documents for all completed visits, not just filed at the end of the trial
  • Study-specific TMF plan defining expected documents and responsible parties
  • TMF completeness metric maintained throughout the trial (not just at close-out)
  • Audit trail showing all document actions, an inspector will look for deletions

CTMS (Clinical Trial Management System)

CTMS manages the operational tracking of a clinical trial: site activation, patient enrollment, visit tracking, protocol compliance, monitoring activities, and financial tracking.

CTMS is generally lower GxP risk than EDC, IRT, or eTMF because it typically does not contain the primary clinical data record. However, it is GxP-impacted when it:

  • Generates records used in regulatory submissions (enrollment by site, eligibility screen failures)
  • Drives monitoring visit reports (which are essential GCP documents)
  • Contains adverse event and serious adverse event tracking

CTMS validation requirements depend on intended use. If CTMS outputs are used in regulatory submissions, those outputs must be validated as accurate.

Safety databases and SAE reporting

Pharmacovigilance databases (common platforms: Oracle Argus, Veeva Vault Safety, ArisG) manage safety data including:

  • Adverse event case intake and processing
  • Individual Case Safety Reports (ICSRs), MedWatch reports to FDA, EudraVigilance submissions to EMA
  • Aggregate safety analysis supporting IND Annual Reports, DSUR/PBRER

These systems are high GxP risk because they directly support patient safety reporting to regulators. Validation requirements:

  • Case processing validation: each workflow step from intake to submission must be tested
  • Regulatory submission outputs: the final ICSR format (E2B R3, MedWatch) must be validated for accuracy
  • Duplicate detection: the logic for identifying potential duplicate cases must be tested
  • Audit trail: all case edits must be captured, including who changed a causality assessment and why

Vendor oversight for clinical computerized systems

Clinical systems are almost always vendor-provided. The sponsor’s obligation doesn’t end at contract signature.

What vendor oversight means in practice

Supplier assessment before selection: Review the vendor’s quality system, SOC 2 Type II report or equivalent, validation documentation library (OQ/PQ) for the platform, and reference customer validation support materials.

Contractual requirements: The agreement must specify:

  • Sponsor’s right to audit the system and its validation documentation
  • Notice period for software updates (especially for systems with study-specific configuration)
  • Incident and change notification requirements
  • Data portability and export rights upon contract termination
  • Retention obligations for audit trails and system logs post-trial

Ongoing oversight: System updates, patches, and configuration changes require notification and sponsor change assessment. Cloud systems don’t exempt the sponsor, they require a more responsive change oversight process.

What oversight doesn’t mean

Vendor oversight is not re-doing the vendor’s platform validation. The sponsor tests the study configuration; the vendor maintains the platform qualification. Confusing these two obligations leads to either insufficient oversight (assuming the vendor handles everything) or overvalidation (retesting platform functions the vendor already qualified).

Minimum compliant baseline for a pre-commercial biotech

For a company running Phase 1/2 studies with a small clinical team and vendor-provided systems:

  1. Vendor qualification assessment on file for each system (EDC, IRT, eTMF), at minimum a questionnaire response and review of the vendor’s qualification documentation library
  2. Part 11 assessment for each system documenting how the system meets audit trail, access control, and signature requirements
  3. Study-level configuration UAT for EDC and IRT, tested against the protocol, documented, approved before study start
  4. Training records for all users of each system
  5. Access control procedures, how accounts are provisioned and deprovisioned when study personnel change
  6. Data export validation, at least one test that confirms data exports from EDC match expected format for statistical analysis

Better maturity state

For a company approaching BLA submission or preparing for a BIMO inspection:

  • Full system validation package including IQ/OQ (vendor provided), configuration PQ (sponsor), and UAT per the protocol
  • Ongoing audit trail review program for EDC and IRT (not just at close-out)
  • TMF completeness metrics tracked throughout the trial (target >95% completeness by study close)
  • Formal change control process for system updates during the study
  • Vendor audit on record (may be desk audit for established platforms, on-site for novel systems)
  • Data integrity review at interim analysis points and at database lock, not just at close

What an inspector asks

In a BIMO inspection of a sponsor:

  • “Show me the validation documentation for your EDC system.” Then: “Who performed the UAT and against what protocol version?”
  • “Show me the audit trail for subject [ID]. Why was this field changed after the visit date?”
  • “What is your process when a site user leaves the study?” (Access termination)
  • “When did your EDC vendor last push a software update? How did you assess the impact?”
  • “Where is the TMF? How do you track completeness?” Then: “Show me the filing for sites that closed.”
  • “How are SAEs captured and reported? Walk me through a case from receipt to submission.”

References

  • FDA: Electronic Records; Electronic Signatures in Clinical Investigations, 2003/2013
  • FDA: Bioresearch Monitoring Program (BIMO): Clinical Investigators, Sponsor-Investigators, Monitors, IRBs
  • ICH E6(R2): Guideline for Good Clinical Practice, 2016
  • 21 CFR Part 11: Electronic Records; Electronic Signatures
  • 21 CFR Part 312: Investigational New Drug Application
  • EMA: Reflection Paper on Expectations for Electronic Source Data (2010)
  • GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems, Second Edition (2022)