A Case Report Form (CRF) is the study form in which the data defined for a clinical trial are documented in a structured manner for each study participant. The CRF thus forms the bridge between the protocol (which data are required?) and the subsequent analysis or clinical study report. In modern studies, the CRF is usually implemented electronically as an eCRF within an Electronic Data Capture system; however, the term CRF continues to be used as the overarching designation.
Objective: Relevant, Analyzable, and Verifiable Study Data
The CRF ensures that data are collected in a standardized manner and are suitable for statistical analyses. It typically includes demographic information, disease and baseline data, visit and examination data, laboratory parameters, study medication, deviations, adverse events, and endpoint variables. For sponsors and CROs, it is critical that each data field has a clear medical or regulatory justification and is collected in defined formats (e.g., units, date logic, coded values).
Development of a CRF: From Protocol to Data Specification
CRF development begins with the protocol and the statistical analysis plan. From these, “critical-to-quality” data are identified that are particularly important for endpoints, safety, and regulatory decisions. Data Management then develops a data specification and often an annotated CRF that maps variables to, for example, CDISC SDTM/ADaM. An iterative review with Medical, Biostatistics, Monitoring, Pharmacovigilance, and, where applicable, the Regulatory team reduces subsequent changes. In EU projects, it is practically relevant to consider early the requirements from CTR 536/2014 as well as national requirements for documentation and data protection.
For sponsors and CROs, it is helpful to align the CRF structure early with operational workflows: visits should be mapped as they actually occur in the clinic, and documentation requirements (e.g., pregnancy tests, concomitant medication, protocol deviations) must be clearly assigned. If topics are “hidden” somewhere in free-text fields, gaps will later emerge in listings and safety reviews.
In addition, the specification should already define how data from external sources are integrated (e.g., central laboratory, imaging, device or wearable data). Without defined interface and reconciliation rules, the CRF may appear formally complete, but in practice a high level of manual reconciliation effort arises—often precisely when timelines for database lock and CSR preparation become tight.
CRF and Data Quality: Edit Checks, Queries, and Monitoring
Data quality is ensured through defined validation rules and processes. In electronic systems, edit checks (plausibility checks) are configured that verify, for example, value ranges and logical consistency. Discrepancies generate queries that the site must resolve. Monitoring verifies concordance with source documents as part of source data verification, with risk-based approaches focusing on critical data. A clear CRF completion guideline helps sites complete fields correctly and consistently.
From the sponsor and CRO perspective, the “query lifecycle” is also a critical time factor: who triages queries, who may close them, and what deadlines apply? Without clear rules, open items accumulate until shortly before database lock. Good CRF designs avoid unnecessary free-text fields, use standardized codelists, and define unambiguous data sources to reduce queries.
Another common pitfall is the distinction between documented correction and protocol deviation: when data are changed retrospectively, it must be evident whether it is a pure documentation correction or an actual deviating clinical situation. This distinction is relevant during audits and inspections and should be addressed in SOPs as well as in site training.
Regulatory Requirements and Inspectability
CRF data must be complete, traceable, and accurate, as they may form the basis for regulatory decisions and inspections. Relevant requirements include data integrity (ALCOA+), audit trail in electronic systems, documented role and permission concepts, and validation of the IT systems used. The principles of ICH GCP (E6(R2)/E6(R3)) are internationally guiding; in the EU, the Clinical Trials Regulation (EU) No. 536/2014 is additionally central, addressing, among other things, transparency and requirements for study documentation.
Distinction from Related Terms
The CRF is the form or the data capture model. The eCRF is the electronic implementation. The EDC is the system that hosts eCRFs and enables functions such as query management and data export. ePRO systems capture patient-reported data, which, depending on the study design, are managed separately or merged with CRF data. For sponsors and CROs, a clear definition of responsibilities is important, e.g., who reviews which data source, how reconciliations are performed, and how data changes are controlled.
FAQ: Must Every Protocol Detail Be Reflected in the CRF?
No. The CRF should only capture data that are required for endpoints, safety, study evaluation, or regulatory requirements. Too many fields increase effort and the risk of missing data without providing additional insight.
FAQ: What Role Does an Annotated CRF Play?
An annotated CRF links CRF fields to standardized datasets (e.g., CDISC SDTM). It facilitates data mapping, programming, consistency checks, and the subsequent creation of analysis datasets. For complex programs, it is an important control instrument between Data Management and Statistics.
FAQ: What Happens If CRF Changes Come Late in the Project?
Late changes require change control, additional testing, and often training. They may necessitate data migrations or re-annotation and delay timelines (e.g., database lock). Therefore, an early, interdisciplinary review is essential.
Regulatory References (Selection): ICH E6(R3) Good Clinical Practice, EU Clinical Trials Regulation (EU) No. 536/2014, General Data Protection Regulation (EU) 2016/679; supplementary: GAMP 5 (computerized systems in the regulated environment) as good practice.