Case Report Form (CRF)

A case report form (CRF) is the data-collection instrument used to capture each participant’s protocol-required study data in a clinical trial. Historically a paper document (still used in some settings, particularly smaller academic or investigator-initiated studies), most trials today use an electronic case report form (eCRF) built inside an Electronic Data Capture (EDC) system — see CASRAI’s Electronic Data Capture (EDC) term for how the platform layer relates to the form itself. Whether paper or electronic, the CRF’s job is the same: translate the protocol’s data requirements into a structured instrument that site staff complete for every participant, at every required visit.

How CRF content is derived from the protocol

A CRF is not designed independently of the trial’s other controlling documents. Its field-by-field content is built directly from the Clinical Trial Protocol: every visit schedule, inclusion/exclusion check, assessment, and endpoint the protocol specifies should have a corresponding CRF page or field, and conversely a well-designed CRF should not collect data the protocol doesn’t call for. This traceability matters downstream too — fields that feed the primary and secondary endpoints need to align with how the Statistical Analysis Plan (SAP) expects to receive that data, so CRF design is typically reviewed jointly by clinical operations, data management, and biostatistics before a study goes live, not drafted by any one function in isolation.

In a modern eCRF built in an EDC system, this translation is enforced with structural controls a paper form cannot provide: visit-window logic that only opens a form for entry within the protocol-specified timeframe, required-field validation, range checks, and automated edit checks that flag inconsistent or implausible values (e.g., a lab value outside a physiologically plausible range, or a stop date entered before a start date) at the point of entry rather than after the fact.

Source documents and source data verification (SDV)

A CRF is not itself the original record of a clinical observation — it is a structured transcription or reference to data that was first captured somewhere else: a clinic note, a hospital chart, a laboratory report, an imaging read, an ECG tracing, or a participant diary. Those originals are the source documents, and the underlying data they contain is source data.

Source data verification (SDV) is the process of comparing what’s entered on the CRF against the source document to confirm accuracy and completeness. ICH E6(R2) Section 5.18 describes on-site monitoring’s role in this verification; historically, sponsors often targeted 100% SDV as a default practice, but neither ICH E6 nor FDA guidance has ever actually mandated verifying every data point on every CRF. FDA’s 2013 risk-based monitoring guidance (reaffirmed and elaborated in a 2023 Q&A) explicitly encourages sponsors to target monitoring — including SDV — toward the data and processes that most affect participant safety and the reliability of trial results, rather than exhaustively verifying every field by default. ICH E6(R2)’s Section 5.0 (Quality Management) and Section 5.18.3 formalized this shift, permitting centralized (remote, statistical/analytics-based) monitoring alongside or instead of exclusively on-site SDV, with the specific mix documented and justified in a trial’s monitoring plan. ICH E6(R3), finalized in January 2025, extends this further by placing explicit emphasis on risk-based quality management as a governing principle rather than a monitoring-technique afterthought.

When a discrepancy surfaces during SDV — or through an automated edit check — it is documented as a query, routed back to site staff, and must be resolved (corrected, or explained and left as-is with justification) before the affected data is considered clean and locked for analysis. Any change made to a CRF value after its initial entry must preserve a visible audit trail (who changed what, when, and why) rather than silently overwriting the original entry — this is one of the concrete mechanisms by which trial data meets the ALCOA+ data-integrity attributes (attributable, legible, contemporaneous, original, accurate, plus complete, consistent, enduring, available) that regulators and sponsors expect of clinical trial records generally.

Regulatory basis

The CRF’s role sits inside the broader Good Clinical Practice (GCP) framework set out in ICH E6. E6(R2) (the 2016 addendum) defines source data, source documents, and the essential-documents/monitoring expectations that underpin CRF completion and verification. ICH E6(R3) — reaching ICH Step 4 on 6 January 2025, with an EMA effective date of 23 July 2025 for its Principles and Annex 1, and FDA issuing its own final E6(R3) guidance on 8 September 2025 — carries these expectations forward with a stronger explicit focus on data governance and risk-based quality management, reinforcing that CRF design and verification strategy should be proportionate to a trial’s actual risks rather than uniformly maximal by default. See CASRAI’s Clinical Trial Protocol term for how the protocol itself is structured and amended under E6(R3), and the Electronic Data Capture (EDC) term for the software layer that hosts most modern eCRFs.

Paper CRFs vs. eCRFs

Paper CRFs still appear in some investigator-initiated or resource-constrained studies, but the large majority of sponsored trials now use eCRFs inside a validated EDC platform (commercial systems, or academic tools such as REDCap for smaller or investigator-led studies — see CASRAI’s REDCap term). eCRFs bring built-in edit checks, real-time query management, audit trails required under 21 CFR Part 11 for electronic records and signatures, and materially faster data cleaning than a paper-then-transcribe workflow, at the cost of needing system validation, user access controls, and site training before go-live.

CRF design and the CDASH/CDISC data standards

CRF field structure increasingly follows the Clinical Data Interchange Standards Consortium’s (CDISC) CDASH (Clinical Data Acquisition Standards Harmonization) standard, which defines a recommended, domain-by-domain baseline of data-collection fields (demographics, adverse events, vital signs, concomitant medications, and others) with consistent naming and structure. Designing a CRF around CDASH conventions from the start makes it substantially easier to map collected data into SDTM (Study Data Tabulation Model) — the standardized tabulation format FDA and other regulators expect for a trial’s submitted datasets — rather than reformatting collection-stage data after the fact. FDA’s Study Data Technical Conformance Guide expects SDTM-conformant submission datasets for FDA-regulated studies, which is the practical reason CDASH-aligned CRF design has become common well beyond CDISC’s own membership. CDASH is a design convention and interchange standard, not a data-collection tool itself — it shapes how a CRF’s fields are named and structured, while the EDC platform (or, less often now, the paper form) remains the actual collection instrument.

Not to be confused with a published case report

A case report form (CRF) and a case report are unrelated concepts that happen to share similar names. A CRF is the data-collection instrument described on this page — completed per participant, during an active trial, to populate that trial’s own dataset. A case report, by contrast, is a published journal article type: a single-patient or small-case-series account of an unusual clinical presentation, diagnosis, or treatment outcome, written and submitted for publication independently of any trial’s data-collection system. A case report is not built from a CRF and a CRF is never itself published as a case report. See CASRAI’s Case Study vs. Case Report comparison for how that publication-type distinction works; it addresses an entirely different question (what kind of article is this?) than the one this page addresses (what instrument collects a trial’s data?).