Clinical Trial Data

“Clinical trial data” is a broad, umbrella term, and confusion about what specifically it refers to at any given point in a trial is a common source of miscommunication between clinical operations, data management, biostatistics, and regulatory staff. It is useful to think of clinical trial data not as one thing but as a chain of representations of the same underlying facts, each with its own integrity requirements, moving from first observation through to a locked, submission-ready dataset.

Source data vs. CRF/EDC-entered data

The first link in that chain is source data: the original recording of a clinical finding, observation, or activity, contained in source documents — a clinic note, a hospital chart, a laboratory printout, an imaging read, an ECG tracing, a pharmacy dispensing record, or a participant diary. ICH E6 (Good Clinical Practice) defines source data and source documents specifically to distinguish them from what gets entered downstream: source data is where a fact about a participant is first captured, by whoever made the original clinical observation, in the ordinary course of care or trial conduct.

The case report form (CRF), whether paper or an electronic CRF (eCRF) inside an Electronic Data Capture (EDC) system, is a structured transcription of that source data into the fields the trial protocol and statistical analysis plan require. It is not itself the original record — it is derived from source documents, which is why source data verification (SDV) exists as a distinct quality-control step: comparing what was entered on the CRF against the source document it was transcribed from, to confirm accuracy and completeness. Current regulatory guidance (ICH E6(R2)’s risk-based-monitoring approach) does not mandate 100% SDV for every field in every trial; sponsors are expected to define a risk-proportionate monitoring plan that concentrates verification effort on data most critical to participant safety and primary endpoints. See CASRAI’s Case Report Form (CRF) term for how CRF design, traceability to the protocol, and SDV mechanics work in detail.

ALCOA+ as applied to clinical trial data specifically

Data-integrity expectations for clinical trial data are commonly summarized with the ALCOA+ framework. The core five attributes — Attributable, Legible, Contemporaneous, Original, Accurate — originated in FDA’s current Good Manufacturing Practice (CGMP) data-integrity guidance, and the UK’s MHRA extended the set with four more attributes — Complete, Consistent, Enduring, Available — in its 2018 GXP Data Integrity Guidance, giving the industry-wide nine-attribute “ALCOA+” acronym. Although ALCOA+ was formalized in a manufacturing (GMP) context, it is applied by convention across GxP domains, including Good Clinical Practice, as the working checklist for whether a given piece of clinical trial data can be trusted: can you tell who recorded it and when (attributable, contemporaneous), is the record legible and unaltered from its original form or a certified true copy (legible, original), does it accurately reflect what happened (accurate), and is the full record complete, internally consistent, durable, and retrievable for as long as retention requirements demand (complete, consistent, enduring, available)? An electronic system’s audit trail — the time-stamped log of who created, modified, or queried a data point, and what the prior value was — is the mechanism that makes most of these attributes verifiable after the fact, which is why audit-trail integrity is itself treated as a proxy for whether clinical trial data as a whole can be relied on.

Database lock: where the chain stops moving

Database lock is the formal, documented point at which a trial’s dataset is frozen: query resolution, medical coding, and external-data reconciliation are complete, and no further changes to the data can be made without a controlled, documented, and typically sponsor-approved unlock process. Before lock, clinical trial data is still being actively cleaned — queries issued to sites, corrections applied, coding finalized against dictionaries like MedDRA for adverse events and medical history. After lock, the dataset is fixed, and it is this locked dataset — not the raw CRF entries, and not the original source documents — that biostatistics analyzes and that gets transformed into the tabulation and analysis formats a regulatory submission requires. Database lock is a single event within the broader discipline of clinical data management, which governs the full workflow (CRF design, database build, edit checks, query management, coding, reconciliation, lock, and submission-dataset preparation) that turns raw entries into a locked, analyzable dataset — see CASRAI’s Clinical Data Management guide for that end-to-end process.

How this relates to the more specific pieces CASRAI covers elsewhere

“Clinical trial data” is the general category; most of the terms a research administrator or data manager actually works with day to day are specific instances or specific containers of that category, not synonyms for it:

• Case Report Form (CRF) — the specific instrument through which CRF-level clinical trial data is captured from source.
• Trial Master File (TMF) — not clinical trial data itself, but the organized collection of essential documents (protocols, approvals, monitoring reports, correspondence) that demonstrates the trial was conducted and the data was generated in compliance with GCP and the protocol. A TMF can contain evidence about how data was handled without containing the participant-level data itself.
• IND-Enabling Studies — preclinical (not clinical trial) data generated before human dosing begins, used to support an Investigational New Drug application; a related but distinct data category that precedes clinical trial data chronologically.
• FDA Adverse Event Reporting System (FAERS) — a specific post-market database that clinical trial adverse-event data (and other real-world sources) can ultimately feed into via regulatory reporting, not a repository of trial data itself.
• MedDRA — the standardized coding dictionary used to make free-text clinical trial data (adverse events, medical history, indications) analyzable and comparable; a tool applied to clinical trial data, not the data itself.

Understood this way, clinical trial data is the substance moving through a trial’s data lifecycle, while the CRF, TMF, IND-enabling package, FAERS, and MedDRA are, respectively, an instrument for capturing it, a compliance-documentation container adjacent to it, a related-but-earlier data category, a downstream database it can feed, and a dictionary used to standardize part of it.

Example

A participant’s blood pressure reading taken at a site visit is first recorded in the clinic’s electronic health record (source data). A site coordinator transcribes that reading into the trial’s eCRF (CRF-level clinical trial data). A monitor later performs SDV, comparing the eCRF entry against the EHR record. After all queries on that field are resolved and the database is locked, the reading becomes part of the fixed analysis dataset a statistician uses to compute a treatment-arm summary, and ultimately part of the dataset submitted to a regulator alongside the trial’s essential documents held in the TMF.

Counter-example

A sponsor’s internal budget forecast for a trial, or a site’s general patient-scheduling calendar, is not clinical trial data even though both exist “around” the trial — neither documents a participant’s protocol-required data or the trial’s conduct in the ALCOA+ sense, and neither is subject to source-data-verification or database-lock controls.