Case Report Form (CRF) Specification Template

Case Report Form Specification: [Trial short title]

Specification for the case report form (CRF or eCRF) of a clinical trial: the forms, fields, formats, codelists, edit checks and completion rules a data manager hands to the eCRF builder and the sites. Field naming follows the CDISC Clinical Data Acquisition Standards Harmonization (CDASH) Implementation Guide, CDASHIG v2.3 (published 28 September 2023, with CDASH Model v1.3), so collected data trace into SDTM. Source and record keeping expectations follow ICH E6(R3) Good Clinical Practice. Replace every [bracketed] value and every row marked Example. This is a documentation format, not clinical, legal or regulatory advice; check the current official texts and consult your sponsor's data management, quality and regulatory staff.

Document control

Approvals

Revision history

Contents

1. Purpose and scope
2. Design principles
3. Visit and form matrix
4. Form specifications
5. Codelists and dictionaries
6. Edit checks
7. Completion guidelines for sites
8. Source data and data integrity
9. Build, testing and change control
10. Traceability matrix
11. Glossary and references
12. Standard and licence note

1. Purpose and scope

This specification defines the case report form for [trial title] (protocol [version], [registry ID]). It covers [number] forms collected at [number] sites across [number] visits. The CRF is the record the sponsor receives for each participant; it is not the source document unless section 8 says a field is entered directly into the eCRF.

2. Design principles

1. Collect what the protocol needs, once. Each data point has one home. Do not ask for the same value on two forms.
2. Use CDASH where a CDASH field exists. Take the variable name, question wording and core designation from the CDASHIG metadata table for the domain. Sponsor-defined fields follow the same naming pattern and are flagged as sponsor-defined in section 4.
3. Collect raw values, derive centrally. Ask for date of birth or age as the protocol allows, height and weight, not body mass index. Derivations belong in the analysis datasets.
4. Prefer coded answers to free text. Use codelists from CDISC Controlled Terminology. Keep free text for verbatim terms that are coded later (adverse events, medications) and for "other, specify".
5. Make missing data explicit. For fields that may legitimately be blank, add a "Not done" flag with a reason, so a blank always means "not yet entered".
6. Protect the blind. No field reveals allocation to blinded site staff. Unblinded pharmacy or dispensing data live in a separate form with restricted access.
7. Design for the site. Order fields as the clinic works, put units on the page, and keep each form to one task.

CDASH groups fields by a core designation: highly recommended fields, recommended or conditional fields, and optional fields. Record the designation for each CDASH field in section 4 and justify any highly recommended field you omit.

3. Visit and form matrix

Every form header carries the same identifiers: study identifier, site identifier, participant identifier, visit name and visit date. In an EDC system these are system fields; on paper they are repeated on every page.

4. Form specifications

Column key: Type is text, integer, decimal, date, time or coded. Core is the CDASH designation (HR highly recommended, R/C recommended or conditional, O optional) or "Sponsor" for a sponsor-defined field.

4.1 Demographics (FRM-DM)

Collect ethnicity and race only where the protocol and local law allow, and use the categories your regulator expects.

4.2 Adverse events (FRM-AE)

A serious adverse event also triggers expedited reporting outside the CRF on the sponsor's SAE form within the protocol timelines. CDISC publishes a CDASH SAE Supplement (v2.0 with CDASHIG v2.3) for those extra fields. Keep the seriousness criteria aligned with ICH E2A and the protocol definition.

4.3 Vital signs (FRM-VS)

4.4 Further forms

Add one table per remaining form in section 3, for example inclusion and exclusion criteria (IE), concomitant medications (CM), study treatment exposure (EX) and disposition (DS). For a sponsor-defined form, write "Sponsor" in the Core column and give a one-line reason in the form notes.

5. Codelists and dictionaries

6. Edit checks

Queries follow one life cycle, shown below. Only site staff change data; data managers and monitors raise and close queries.

7. Completion guidelines for sites

General rules for all forms:

• Enter data within [5] working days of the visit; serious adverse events within the protocol timeline (for example [24] hours of site awareness).
• Use the participant identifier only. Never enter names, initials where local rules forbid them, hospital numbers or contact details.
• Record values as written in the source, in the units shown. Do not round or convert unless the form asks for it.
• For a test not done, tick "Not done" and give the reason. Do not leave the field blank.
• For partial dates, enter the known parts and use the unknown option for the rest, as the form allows.
• Correct data in the eCRF with a reason for change; the audit trail keeps the old value. On paper, strike through once, write the new value, initial and date it.

Form-specific guidance (Example, adverse events): record one event per row using a diagnosis where one is known rather than its symptoms; record a change in severity as [a new row / an update], as the protocol specifies.

8. Source data and data integrity

ICH E6(R3) expects trial data to be attributable, legible, contemporaneous, original, accurate and complete, with an audit trail and controlled access. Record where each data item originates.

For electronic systems used in US-regulated trials, 21 CFR Part 11 covers electronic records and signatures (https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11). EU and UK trials apply ICH E6(R3) and national clinical trial rules; check the current texts with your regulatory team.

9. Build, testing and change control

Test each edit check with at least one value that should fire it and one that should not. A change that alters existing data definitions needs an impact assessment for data already entered.

10. Traceability matrix

Related templates: science/trial-protocol (schedule of assessments and endpoints), science/data-management-plan (data flow, storage and sharing), academic/stats-analysis-plan (analyses each field feeds), science/dsmb-charter (safety data the monitoring committee reviews) and science/clinical-trial-report.

11. Glossary and references

12. Standard and licence note

Structure aligned with the CDISC CDASH Implementation Guide v2.3 (published 28 September 2023, CDASH Model v1.3) and the record keeping expectations of ICH E6(R3). CDISC variable names and codelist names are used as identifiers only; question wording, core designations and metadata tables are not reproduced, so use the CDASHIG metadata tables for the normative content. Official text: CDISC, account sign-in required for download: https://www.cdisc.org/standards/foundational/cdash. All other text is original. Check the current CDISC releases and ICH texts before use, because standards and controlled terminology are updated regularly. This is a documentation format, not clinical, legal or regulatory advice; consult your sponsor's data management and regulatory staff and follow your ethics committee's conditions. Template licence: MIT.