# 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.

<!--
Guidance: How to use this template
- Start from the protocol schedule of assessments. Every field on the CRF
  must answer a protocol objective, an eligibility check, a safety
  requirement or a regulatory need. If no analysis or check uses a field,
  remove it.
- Fill the visit and form matrix (section 3) first, then the form
  specifications (section 4), then the edit checks (section 6). The
  traceability matrix (section 10) is your final completeness test.
- Use the CDASHIG metadata tables (from cdisc.org) for variable names,
  question text and core designations. This template shows the shape of
  the specification and a few common fields; it does not reproduce the
  CDASHIG tables.
- Version the specification together with the protocol. A protocol
  amendment that adds an assessment needs a CRF change request here.
-->

## Document control

<!-- Guidance: The CRF specification is a controlled trial document. Keep it in the trial master file with the eCRF build it describes. -->

| Field | Value |
|---|---|
| Document ID | [CRF-SPEC-0001] |
| Trial | [Full title, acronym, registry ID] |
| Protocol version | [Protocol version and date this specification implements] |
| Specification version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@lead-data-manager] |
| Reviewers | [Trial statistician, medical monitor, trial manager, site representative] |
| eCRF system | [EDC system name and version, or "paper CRF"] |
| Data standards | CDASHIG v2.3; CDISC Controlled Terminology [package date]; [MedDRA version]; [WHODrug version] |
| Last updated | YYYY-MM-DD |
| Classification | [Confidential] |

### Approvals

| Role | Name | Signature | Date |
|---|---|---|---|
| Lead data manager | [@name] | [Signature] | YYYY-MM-DD |
| Trial statistician | [@name] | [Signature] | YYYY-MM-DD |
| Medical monitor | [@name] | [Signature] | YYYY-MM-DD |
| Chief investigator | [@name] | [Signature] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary | Protocol version |
|---|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft from protocol schedule | [1.0] |
| 1.0 | YYYY-MM-DD | [@name] | Approved for eCRF build | [1.0] |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Added pregnancy test field to Visit 2 after protocol amendment 1 | [2.0] |

## Contents

1. [Purpose and scope](#1-purpose-and-scope)
2. [Design principles](#2-design-principles)
3. [Visit and form matrix](#3-visit-and-form-matrix)
4. [Form specifications](#4-form-specifications)
5. [Codelists and dictionaries](#5-codelists-and-dictionaries)
6. [Edit checks](#6-edit-checks)
7. [Completion guidelines for sites](#7-completion-guidelines-for-sites)
8. [Source data and data integrity](#8-source-data-and-data-integrity)
9. [Build, testing and change control](#9-build-testing-and-change-control)
10. [Traceability matrix](#10-traceability-matrix)
11. [Glossary and references](#11-glossary-and-references)
12. [Standard and licence note](#12-standard-and-licence-note)

## 1. Purpose and scope

<!-- Guidance: State which trial, which protocol version and which data the CRF collects. Name the data that are NOT collected on the CRF (central laboratory transfers, ePRO, imaging reads, wearable data) so nobody builds them twice. -->

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.

| Data stream | Collected on the CRF? | Route if not |
|---|---|---|
| Demographics, eligibility, vital signs, adverse events, concomitant medications, disposition | Yes | Not applicable |
| Central laboratory results | No | Vendor transfer per data transfer agreement [DTA-ID] |
| Patient-reported outcomes | [No] | [ePRO system, specification DOC-ID] |
| Randomisation and treatment allocation | [No] | [IRT system, allocation never visible on the CRF of blinded staff] |

## 2. Design principles

<!-- Guidance: Agree these principles before anyone designs a page. Most CRF problems (ambiguous questions, free text that cannot be analysed, derived values typed by hand) break one of them. -->

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

<!-- Guidance: Copy the visit structure and windows from the protocol schedule of assessments. An X means the form opens at that visit. Unscheduled visits and log forms (adverse events, concomitant medications) are listed separately because they are not tied to one visit. -->

| Form ID | Form | Screening (Day -28 to -1) | Baseline (Day 1) | Week 4 (+/- 3 days) | Week 12 (+/- 7 days) | End of treatment | Unscheduled |
|---|---|---|---|---|---|---|---|
| FRM-DM *(Example)* | Demographics | X | | | | | |
| FRM-IE *(Example)* | Inclusion and exclusion criteria | X | X (confirm) | | | | |
| FRM-VS *(Example)* | Vital signs | X | X | X | X | X | X |
| FRM-EX *(Example)* | Study treatment exposure | | X | X | X | X | |
| FRM-DS *(Example)* | Disposition | X (screen failure) | | | | X | |
| FRM-AE *(Example)* | Adverse events (log) | From informed consent to [end of follow-up] | | | | | |
| FRM-CM *(Example)* | Concomitant medications (log) | From [28 days before screening] to [end of treatment] | | | | | |

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

<!-- Guidance: One table per form. Question text is what the site sees. CDASH variable is the collection variable name. Core is HR, R/C or O for CDASH fields and "Sponsor" for sponsor-defined fields. Keep the edit check column to IDs that are defined in section 6. -->

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)

| Field ID | Question text (site view) | CDASH variable | Type and format | Codelist | Core | Edit checks |
|---|---|---|---|---|---|---|
| DM-01 *(Example)* | What is the participant's date of birth? | BRTHDAT | Date, DD-MMM-YYYY, partial allowed [year only if local rules restrict] | Not applicable | [Per CDASHIG] | EC-001 |
| DM-02 *(Example)* | What is the participant's sex? | SEX | Coded | SEX | [Per CDASHIG] | None |
| DM-03 *(Example)* | Ethnicity | ETHNIC | Coded | ETHNIC | [Per CDASHIG] | None |
| DM-04 *(Example)* | Race (check all that apply) | RACE | Coded, multiple | RACE | [Per CDASHIG] | None |

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)

| Field ID | Question text (site view) | CDASH variable | Type and format | Codelist | Core | Edit checks |
|---|---|---|---|---|---|---|
| AE-01 *(Example)* | Has the participant had any adverse events? | AEYN | Coded | NY | [Per CDASHIG] | None |
| AE-02 *(Example)* | What is the adverse event term? | AETERM | Text, 200 characters | Coded centrally to MedDRA | [Per CDASHIG] | None |
| AE-03 *(Example)* | Start date | AESTDAT | Date, DD-MMM-YYYY | Not applicable | [Per CDASHIG] | EC-002, EC-003 |
| AE-04 *(Example)* | Is the event ongoing? | AEONGO | Coded | NY | [Per CDASHIG] | EC-004 |
| AE-05 *(Example)* | End date | AEENDAT | Date, DD-MMM-YYYY | Not applicable | [Per CDASHIG] | EC-004 |
| AE-06 *(Example)* | Severity | AESEV | Coded | AESEV (mild, moderate, severe) [or toxicity grade AETOXGR] | [Per CDASHIG] | None |
| AE-07 *(Example)* | Is the event serious? | AESER | Coded | NY | [Per CDASHIG] | EC-005 |
| AE-08 *(Example)* | Relationship to study treatment | AEREL | Coded | [Sponsor-defined causality list] | [Per CDASHIG] | None |
| AE-09 *(Example)* | Action taken with study treatment | AEACN | Coded | ACN | [Per CDASHIG] | None |
| AE-10 *(Example)* | Outcome | AEOUT | Coded | OUT | [Per CDASHIG] | None |

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)

| Field ID | Question text (site view) | CDASH variable | Type and format | Codelist | Core | Edit checks |
|---|---|---|---|---|---|---|
| VS-01 *(Example)* | Were vital signs performed? | VSPERF | Coded | NY | [Per CDASHIG] | None |
| VS-02 *(Example)* | Date of measurement | VSDAT | Date, DD-MMM-YYYY | Not applicable | [Per CDASHIG] | EC-006 |
| VS-03 *(Example)* | Systolic blood pressure | VSORRES (VSTESTCD = SYSBP) | Integer, 3 digits | Unit fixed: mmHg | [Per CDASHIG] | EC-007 |
| VS-04 *(Example)* | Diastolic blood pressure | VSORRES (VSTESTCD = DIABP) | Integer, 3 digits | Unit fixed: mmHg | [Per CDASHIG] | EC-007 |
| VS-05 *(Example)* | Weight | VSORRES (VSTESTCD = WEIGHT) | Decimal, 1 place | VSORRESU: kg or lb | [Per CDASHIG] | EC-008 |

### 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

<!-- Guidance: Name the exact version of every codelist and dictionary. A change of dictionary version mid-trial is a planned, documented event, not something the coding vendor does quietly. -->

| Codelist or dictionary | Version | Used for | Owner |
|---|---|---|---|
| CDISC Controlled Terminology | [Package date, for example YYYY-MM-DD] | SEX, ETHNIC, RACE, NY, OUT, ACN and other coded fields | [@data-manager] |
| MedDRA | [Version in use] | Adverse event and medical history coding | [Coding vendor] |
| WHODrug Global | [Version in use] | Concomitant medication coding | [Coding vendor] |
| Sponsor codelists | [Version] | Causality scale, visit names, other sponsor fields | [@data-manager] |

## 6. Edit checks

<!-- Guidance: Each check has an ID, the fields it reads, the condition that fires it, the message the site sees and whether it fires on entry (hard or soft) or in a batch review. Write messages as neutral questions; never suggest the "right" answer to the site. -->

| Check ID | Fields | Condition | Message to site | Type |
|---|---|---|---|---|
| EC-001 *(Example)* | DM-01, informed consent date | Age at consent outside protocol range [18 to 75 years] | Age at consent is outside the eligibility range. Please confirm the date of birth. | Soft, on entry |
| EC-002 *(Example)* | AE-03, informed consent date | AE start date before informed consent date | AE start date is before consent. Should this be medical history? Please review. | Soft, on entry |
| EC-003 *(Example)* | AE-03 | Start date in the future | Start date is later than today. Please correct. | Hard, on entry |
| EC-004 *(Example)* | AE-04, AE-05 | Ongoing = Yes and end date entered, or ongoing = No and end date blank | Ongoing status and end date do not agree. Please review. | Soft, on entry |
| EC-005 *(Example)* | AE-07, SAE report log | Serious = Yes and no SAE report number within [24 hours] | A serious event needs an SAE report. Please confirm it was submitted. | Batch, daily |
| EC-006 *(Example)* | VS-02, visit date | Measurement date outside the visit window | Measurement date is outside the visit window. Please confirm. | Soft, on entry |
| EC-007 *(Example)* | VS-03, VS-04 | Systolic not greater than diastolic, or systolic outside [60 to 260] mmHg | Blood pressure values look unusual. Please confirm. | Soft, on entry |
| EC-008 *(Example)* | VS-05 | Change of more than [10] percent from baseline | Weight changed by more than 10 percent since baseline. Please confirm. | Batch, weekly |

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

```mermaid
stateDiagram-v2
    [*] --> Open: Edit check fires or reviewer raises query
    Open --> Answered: Site responds or corrects data
    Answered --> Closed: Data manager accepts
    Answered --> Open: Data manager re-queries
    Open --> Cancelled: Raised in error
    Closed --> [*]
    Cancelled --> [*]
```

## 7. Completion guidelines for sites

<!-- Guidance: The CRF completion guidelines (CCG) are the site's manual. Write one entry per form plus general rules. Test them by asking a site coordinator who did not see the build to complete a mock participant. -->

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

<!-- Guidance: Say for each data item where the source is. If the eCRF is the source for any field (direct data entry), list it, because monitors verify those fields differently. -->

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.

| Data item | Source | Direct entry in eCRF? |
|---|---|---|
| Vital signs *(Example)* | Clinic vital signs worksheet | No |
| Patient-reported symptom score *(Example)* | ePRO device | Not on the CRF |
| Eligibility checklist *(Example)* | Medical record plus signed checklist | No |
| [Item] | [Source] | [Yes / No] |

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

<!-- Guidance: Treat the eCRF like software. The specification is the requirement, user acceptance testing (UAT) proves the build matches it, and every post-go-live change runs through the same loop. -->

| Step | Output | Responsible |
|---|---|---|
| Specification approved | This document, version [1.0] | Lead data manager |
| eCRF build | Build in [EDC system], build notes | EDC programmer |
| User acceptance testing | Test scripts per form and per edit check, results log | Data manager plus independent tester |
| Go-live approval | Signed UAT summary, site training records | Lead data manager, trial manager |
| Post-go-live change | Change request, impact on existing data, retest, version update | Lead data manager |

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

<!-- Guidance: Check that every protocol endpoint and safety requirement reaches a field, and every field reaches an analysis or check. Gaps in either direction are findings. -->

| Protocol item | Form and field | CDASH variable | SDTM domain | SAP reference |
|---|---|---|---|---|
| Primary endpoint: change in systolic blood pressure at week 12 *(Example)* | FRM-VS, VS-03 | VSORRES | VS | [SAP section 9.1] |
| Safety: adverse events *(Example)* | FRM-AE, AE-01 to AE-10 | AETERM and related | AE | [SAP section 11] |
| Eligibility: age 18 to 75 years *(Example)* | FRM-DM, DM-01 | BRTHDAT | DM | Not analysed, eligibility check EC-001 |
| [Item] | [Form, field] | [Variable] | [Domain] | [Section] |

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

<!-- Guidance: Keep this list to terms and documents used in this specification, with the versions checked. -->

| Term | Meaning |
|---|---|
| CRF, eCRF | Case report form, paper or electronic: the record of protocol data for each participant sent to the sponsor |
| CDASH | Clinical Data Acquisition Standards Harmonization, the CDISC standard for collecting data |
| SDTM | Study Data Tabulation Model, the CDISC standard for tabulated submission data |
| CCG | CRF completion guidelines for sites |
| EDC | Electronic data capture system |
| UAT | User acceptance testing |
| MedDRA, WHODrug | Coding dictionaries for medical terms and medicines |

| Reference | Version or date | Link |
|---|---|---|
| CDISC CDASH Implementation Guide (CDASHIG) | v2.3, published 2023-09-28; CDASH Model v1.3; SAE Supplement v2.0 | https://www.cdisc.org/standards/foundational/cdash |
| ICH E6(R3) Guideline for Good Clinical Practice | Step 4, 6 January 2025 | https://database.ich.org/sites/default/files/ICH_E6%28R3%29_Step4_FinalGuideline_2025_0106.pdf |
| ICH E2A Clinical Safety Data Management: Definitions and Standards for Expedited Reporting | 1994 | https://www.ich.org |
| US 21 CFR Part 11, electronic records and signatures | Current eCFR | https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11 |

## 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.