Clinical Quality Assurance is the quality function for clinical trial operations. It ensures that studies are conducted in accordance with the protocol, GCP (Good Clinical Practice), and applicable regulations, and that the data generated is accurate, reliable, and auditable. Clinical data is the foundation of the efficacy and safety package in a regulatory submission. If it can’t be trusted, neither can the submission.
The governing standard is ICH E6(R2) (Good Clinical Practice), adopted by FDA, EMA, PMDA, and most other major regulatory authorities. The 2016 revision significantly updated GCP for the electronic era, introducing risk-based monitoring, explicit electronic system requirements, and stronger expectations for quality management in clinical operations.
What GCP Requires for Data Integrity
ICH E6(R2) Section 6.14.9 requires that systems used to capture clinical data maintain “audit trails that capture all changes to clinical trial data, including the date and time of changes, the name of the person making the change, and the reason for any change.”
This is functionally the same requirement as pharmaceutical manufacturing data integrity, but applied to clinical data:
- Every data point must be attributable to the person who entered it
- Data must be entered contemporaneously (at the time of observation, not reconstructed later)
- All changes must be tracked with prior values, who changed, when, and why
- The original record must be preserved
The “reason for change” requirement in GCP is more explicit than in GMP. In a clinical EDC system, any change to a previously entered value requires a documented reason. This is captured through edit check queries and change justification fields in the EDC system.
The Clinical Data Flow
Understanding where data integrity applies requires understanding how clinical data moves:
Source data: The original record of a clinical observation. This might be a patient’s vital signs recorded in a paper chart at the investigator site, or a direct electronic entry into an EDC eCRF, or laboratory results from a central laboratory. Source data is the original.
Transcription: When source data (a paper chart entry) is transcribed into an EDC system, the transcription must be accurate and verifiable. The source document must be retained alongside the transcribed electronic record. Discrepancies between source and EDC are data integrity problems.
EDC entry: Investigator site staff enter patient data directly into the eCRF. Edit checks in the EDC flag implausible values or missing required fields immediately. Queries are raised for values that need clarification from the site.
Data management: The sponsor’s clinical data management team conducts validation checks against pre-defined data validation specifications. Additional queries are raised. Sites respond. Data is cleaned.
Database lock: Once all queries are resolved and the data management team confirms the database is clean, the database is locked. No further changes without explicit reopening and re-locking.
Statistical analysis: The locked, clean database is transferred to the statistical team for analysis. The analysis population, endpoints, and statistical methods are defined in the SAP (Statistical Analysis Plan) and followed without modification.
Any manipulation of clinical data between collection and analysis is a GCP violation. Any unreported protocol deviation that affects data interpretation is a violation. Any failure to report adverse events that might affect the safety analysis is a serious violation.
Electronic Data Capture (EDC) System Validation
An EDC system is a validated computerized system under both GCP (ICH E6(R2)) and, where applicable, 21 CFR Part 11. The validation requirements are equivalent to GMP computerized systems: documented evidence that the system does what it’s supposed to do, maintains data integrity, and is appropriately controlled.
EDC validation scope:
The sponsor (pharmaceutical company or CRO) is responsible for validating the EDC system used in their studies. Validation includes:
User Requirements Specification: What does the study require from the EDC? This includes: eCRF structure, edit checks and data validation rules, user roles and access permissions, audit trail requirements, data export format for statistical analysis, randomization support, patient registration, and query management.
Configuration testing: The EDC is typically a configured platform (Medidata Rave, Oracle InForm, Veeva Vault EDC). The configuration for each study must be tested: every eCRF page, every edit check, every conditional display rule, every required field. The validation tests that the configured study behaves as specified.
UAT (User Acceptance Testing): Investigator site personnel (the actual users) test the configured EDC for usability and accuracy. They’re the best detectors of workflow problems, confusing form designs, and missing data fields.
Audit trail verification: Verify that the audit trail captures: initial entry (user, timestamp, value), any modification (user, timestamp, old value, new value, reason), and any query (who raised, when, response, resolution).
Access control verification: Verify that user roles enforce appropriate access restrictions. Site staff can only see their own site’s patients. Monitors have read access but not write access. Sponsor personnel cannot edit source data.
Protocol Deviations and Their Data Integrity Implications
A protocol deviation is any departure from the procedures specified in the protocol. Deviations range from minor (a visit was conducted one day late) to major (an excluded patient was enrolled).
From a data integrity perspective: protocol deviations must be reported, documented, and assessed for their impact on study data. A deviation that affects the primary endpoint measurement must be disclosed in the clinical study report and may affect statistical analysis decisions.
The data integrity problem arises when deviations are:
- Not identified because site staff don’t recognize them as deviations
- Identified but not reported to the sponsor
- Identified, reported, but not reflected in the data (data is presented as if the protocol was followed)
Clinical monitoring addresses all three. Monitors review source documents against the EDC to detect deviations. They interview site staff. They assess whether site practice matches protocol requirements.
Trial Master File (TMF) Management
The TMF is the complete collection of documentation that evidences the conduct of a clinical trial. For the sponsor, it includes: protocol and amendments, ICF and amendments, IRB/IEC approvals, regulatory authority correspondence, investigational product information, monitoring reports, training records for trial personnel, and the complete data management audit trail.
21 CFR 312.57 and ICH E6(R2) Section 8 both specify what must be in the TMF. The TMF must be maintained in good order throughout the trial and preserved after trial completion for a defined period (typically 2 years after study discontinuation or 2 years after the marketing application is approved, whichever is longer).
eTMF systems: Electronic TMF systems are now standard. Like EDC systems, they are validated computerized systems. Key validation considerations:
- Document upload and indexing integrity (document in system matches document uploaded)
- Access controls (who can add, modify, archive)
- Audit trail for document changes and version history
- Search and retrieval functionality
- Final archival and long-term readability
An eTMF that stores documents correctly but doesn’t maintain a searchable, retrievable archive is a problem when FDA requests specific documents during a BLA review or inspection.
Clinical Site Audits
Clinical site audits are conducted by the sponsor’s CQA team to verify that the trial is being conducted in compliance with the protocol and GCP. They’re distinct from monitoring visits (which are routine, risk-based oversight) in that audits are independent quality assessments.
When to audit:
- Pre-study: before a site is activated, to confirm it has the infrastructure, qualified personnel, and procedures to conduct the trial
- During the study: typically for sites with high enrollment, significant protocol deviations, data quality concerns, or sites contributing to a pivotal dataset
- For cause: when a specific concern is identified (adverse event pattern, data anomalies, personnel complaint)
- Pre-submission: before a BLA, NDA, or MAA submission, audit the sites contributing the pivotal efficacy data
What a site audit covers:
- Investigator and staff qualifications and training
- Consent process (were patients properly consented before any study procedures?)
- Protocol adherence (were inclusion/exclusion criteria properly applied?)
- Investigational product management (accountability, storage, dispensing records)
- Source document review (completeness, contemporaneity, accuracy)
- EDC accuracy vs. source documents
- Adverse event identification, assessment, and reporting
- Regulatory submission records (IRB correspondence, IND safety reports)
Data Integrity Risks Specific to Clinical Trials
Fabricated data: The most serious clinical data integrity failure. An investigator or site staff member enters data that doesn’t reflect actual patient observations. This can be detected through: source document verification that finds no source document supporting the EDC entry, statistical anomalies in data distributions (too many round numbers, impossibly low variation), and direct observation that patients don’t match their recorded data.
Selective reporting: Results that don’t favor the investigational product being underreported or incorrectly classified. Protocol deviation data being omitted from the final dataset. Adverse events being coded to minimize apparent causality.
Protocol deviations affecting eligibility: Enrolling patients who don’t meet inclusion criteria, then not reporting the deviations. The resulting dataset includes patients who shouldn’t be in the analysis population.
Back-dated entries: Source documents or EDC entries created after the fact, with false dates. Detected by reviewing source documents for contemporaneous signatures, checking EDC audit trails for entry timestamps vs. documented observation dates.
Connecting Clinical Data to Regulatory Submissions
The clinical data package is Module 5 of the Common Technical Document (CTD). It includes the clinical study reports for all pivotal and supportive studies. FDA and EMA reviewers look at the data quality indicators in the submission:
- Protocol deviation rates and their classification
- Data query rates and patterns
- Adverse event reporting completeness
- Consistency between the statistical analysis plan and the reported analysis
- Audit trail availability for EDC data on request
A BLA with clinical data integrity issues, high rates of unresolved queries, protocol deviations not reflected in the analysis, or sites with a history of GCP findings, may receive a Complete Response Letter citing clinical data concerns, or may trigger an FDA clinical site inspection as part of the review.
The clinical QA function is the internal safeguard that catches these problems before they reach the submission. Investing in site auditing and data quality management during the trial is less costly than receiving a Complete Response after submission.