CRF Design Fundamentals

Why this matters

A well‑designed Case Report Form (CRF) makes it easy for sites to enter data correctly the first time and makes it easy for data managers and statisticians to use that data later. Clear fields and instructions reduce queries, re‑work, and delays. Consistent structures and controlled lists enable reliable coding, reconciliation, mapping to analysis datasets, and faster database lock.

If you design the CRF with the endpoint in mind, you avoid the “fix it later” trap—where vague questions, missing units, or unclear prompts force heavy cleaning. Good design pays off at every step: site entry, monitoring, medical review, coding, reconciliation, and analysis.

Core concepts & definitions

CRF — The document, paper or electronic, that records the protocol‑required data for each subject. In most studies it is a set of electronic pages (eCRF) in your EDC (Electronic Data Capture) system, where site staff enter study data.

Field specification — A complete description of a data field so anyone can implement or fill it correctly:

• Type (integer, decimal, date, date‑time, text, yes/no, codelist)
• Unit (mmHg, kg, mmol/L) and whether it is fixed or user‑selectable
• Precision (integer; decimal with X places)
• Allowed values and format/pattern (range, codelist items, patterns like YYYY‑MM‑DD)
• Required? (and when—always, or conditionally)
• Prompt wording (the on‑screen question or label, with its context)
• Validation location (at entry vs batch/overnight)

Controlled codelist — Pre‑defined options with unambiguous wording. Use “Other — specify” only when truly needed, and capture the free text in a separate, clearly labeled field.

Prompt wording — The on‑screen question or label for a field, worded to carry the context the user needs to answer correctly (e.g., “Patient seated, after 5‑minute rest,” “Local lab fasting lipid panel”).

Skip/branch logic — Show/hide rules that depend on prior responses. Keep them simple and predictable; document them in the Completion Guidelines.

CRF Completion Guidelines (CCG; also called form completion guidelines, FCG) — The site‑facing “how to fill” manual that explains definitions, examples, and tricky scenarios. When CRFs or protocol text changes, update CCGs and communicate/train before activating changes.

At‑entry (real‑time) vs batch checks —

• At‑entry: Lightweight checks (required, format, simple ranges, same‑page consistency such as start date not after stop date) to catch obvious errors without slowing the system.
• Batch: Complex cross‑form/visit/subject rules, calculations, and performance‑heavy checks run after entry (e.g., nightly). These protect EDC performance and still catch complex issues. Simple cross‑form checks (e.g., AE start date vs informed‑consent date) usually run at entry in modern EDC.

Atomic fields — Each field captures a single idea (e.g., “Systolic BP” separate from “Diastolic BP”). Avoid packing multiple meanings into one field.

Reasons for missing — If the protocol requires explanation when data are missing or Not Done, capture a structured reason (e.g., “Not Done — equipment unavailable”).

The process, step‑by‑step

1. Start from endpoints and analyses. What will clinicians and statisticians need to answer the primary questions? Work backward to define data elements and structure.
2. Draft field specifications. For each field: type, unit, precision, allowed values, required?, format/pattern, prompt, and validation location.
3. Prefer structure over free text. Use codelists, dates, numeric fields, and separate “specify” fields only where needed.
4. Design for user flow. Group related fields, keep consistent order across visits, minimize scrolling, and align labels with how site staff think and work.
5. Write context‑rich prompts. Encode posture, fasting status, timing windows, or device details as needed.
6. Place checks wisely. Use simple at‑entry checks; put complex cross‑page/visit logic and heavy computations into batch checks.
7. Peer review & user acceptance testing (UAT). Review with Clinical Ops, Monitors, Safety, Coding, and Stats using realistic scenarios and sample data.
8. Update CCGs and train sites. Keep CCGs in lockstep with CRF/protocol changes; notify and train sites before activation.
9. Version and document. Track CRF versions, affected fields, and effective dates; make sure audit trails and change notes are clear.

What good looks like

Vitals page (example)

• Systolic blood pressure (mmHg) — Patient seated, after 5‑minute rest. Integer allowed 60–260.
• Diastolic blood pressure (mmHg) — Integer allowed 40–140.
• Position — Codelist: seated / supine / standing (records the position actually used).
• Heart rate (bpm) — Integer allowed 30–220.
• At‑entry checks: required fields, simple ranges, and same‑page consistency (e.g., diastolic < systolic).
• Batch checks: cross‑visit trends (optional).

Why this is good: Units and context are explicit; prompts tell the operator exactly how to measure; the lists prevent ambiguous text.

Worked examples

This section is self‑contained. Each example includes the intent, the field specs, and the validations required to capture clean, analyzable data without external dependencies.

1) Pregnancy test result (point‑of‑care)

Intent: Capture a clinic urine pregnancy test with enough context for safety decisions.

Fields & specs

• Test type — Codelist: urine / serum / other‑specify. (If “other,” show text field “Specify test type”.)
• Result — Codelist: positive / negative / indeterminate.
• Collection date — Date; format YYYY‑MM‑DD; required.
• Performed at — Codelist: site / local lab / central lab.
• If not done — Reason codelist: patient refused / equipment unavailable / not required per protocol / other‑specify.
• Comments (optional) — Short text, for clarifications only.

Validations

• At‑entry: required where applicable; valid date format.
• Batch: For females of child‑bearing potential, ensure a test exists per visit window; if positive, ensure appropriate safety workflow was triggered (e.g., discontinuation rule or confirmatory test recorded).

2) Concomitant medications (repeating log)

Intent: Capture medications in a structure that supports coding and analysis.

Fields & specs (per medication row)

• Generic/brand as recorded — Short text (verbatim for coding).
• Route — Codelist: oral / IV / IM / subcutaneous / inhaled / topical / other‑specify.
• Frequency — Codelist: once daily / twice daily / weekly / PRN / other‑specify.
• Dose — Decimal (precision aligned to common doses).
• Dose unit — Codelist: mg / g / µg / mL / units / other‑specify.
• Start date — Date; allow partial if day unknown (capture separate fields: YYYY, MM, DD [unknown allowed]).
• Stop date — Date; allow ongoing checkbox if still taking.
• Indication (reason) — Codelist keyed to study conditions where feasible; else short text.
• Coding status (system use only) — Populated by coder (e.g., WHO Drug) post‑entry.

Validations

• At‑entry: dose must have a unit; frequency required; start date cannot be after stop date.
• Batch: confirm every verbatim is coded against the specified dictionary version; flag improbable doses by route (e.g., 5,000 mg topical).

3) Adverse event (AE) capture

Intent: Record AEs consistently to support safety review and regulatory reporting.

Fields & specs

• AE term (verbatim) — Short text (verbatim).
• Start date — Date; allow a partial date (day unknown).
• Stop date — Date or ongoing checkbox.
• Severity — Codelist: mild / moderate / severe.
• Serious? — Yes/No. (If Yes, collect seriousness criteria as a codelist and reportability fields.)
• Relationship to study drug — Codelist: not related / unlikely related / possibly related / probably related / definitely related.
• Action taken with study drug — Codelist: none / dose reduced / interrupted / discontinued.
• Outcome — Codelist: recovered / recovering / not recovered / recovered with sequelae / fatal / unknown.
• Concomitant therapy given? — Yes/No; if Yes, link to ConMeds record.

Validations

• At‑entry: required core fields; logical date order.
• Batch: consistency with exposure dates; seriousness criteria completeness; if fatal, ensure death page exists.

4) Multinational lab results with unit conversion

Intent: Sites may enter values in different units; the study needs a single unit for analysis.

• Approach A (preferred): Capture the value + recorded unit exactly as reported on the source (e.g., the local lab report), and convert centrally to one canonical unit (e.g., mmol/L) using a governed algorithm (document conversion factor and version). Store both the original and the converted value. This matches CDISC CDASH practice, and sites never convert values by hand.
• Approach B (only when every source reports in the same unit): Show that fixed unit as a read‑only label on the field. Do not require sites to convert results into a canonical unit themselves; manual conversion adds errors and breaks the match to source documents.

Example field spec (Approach A)

• Glucose value — Decimal.
• Recorded unit — Codelist: mmol/L / mg/dL.
• Converted value (system‑derived) — Decimal; read‑only.
• Reference range status — Codelist: below / within / above.

Validations

• At‑entry: value within biological plausibility for the recorded unit.
• Batch: verify conversion math and reference range tagging; trend checks for outliers.

5) “Not Done” vs missing data

Intent: Distinguish truly missing data (blank, no explanation) from a documented “Not Done” (not performed, with a recorded reason).

Fields & specs

• Performed? — Yes/No.
• If No: Reason — Codelist: contraindicated / equipment unavailable / patient refused / not required / other‑specify.
• Result fields are hidden when No.

Validations

• At‑entry: reason required when No.
• Batch: if protocol requires the procedure at that visit, open a discrepancy when Not Done or missing without reason.

Pitfalls & misconceptions

• “Help text will save us.” It won’t if the field type, unit, and allowed values are vague. Specify fields completely.
• Over‑using free text. Free text hides meaning and breaks coding and analytics. Prefer codelists with “Other — specify” only when needed.
• Heavy real‑time checks. Complex cross‑visit logic at entry can slow EDC and frustrate sites. Put heavyweight checks in batch.
• Assuming page numbers matter. EDC screens are built from field definitions (data type + prompt + response format), not from printed page numbers.
• Changing the CRF without updating CCGs. Sites won’t know how to enter data after changes unless you update guidelines and train them.
• Combining multiple ideas in one field. Avoid fields like “BP 120/80 seated.” Use separate, atomic fields.

Practice in the wild (checklist)

• For every field: type, unit, precision, allowed values, required?, format/pattern, prompt, validation location.
• Replace free text with controlled lists; keep “Other — specify” minimal and separate.
• Encode context in prompts (posture, fasting, timing, device).
• Keep real‑time checks light; push complex cross‑form/visit logic to batch.
• Use atomic fields; avoid multi‑concept text fields.
• Capture structured reasons for missing/Not Done.
• Version CRF and maintain a clear audit trail of changes.
• Update CCGs and train sites before activating changes.

Key points to remember

• Specify every field completely — type, unit, precision, allowed values, required/conditional, format/pattern, prompt wording, and validation location (at‑entry vs batch).
• Prefer structured responses over free text — reserve “Other — specify” only when unavoidable and capture the free text in a separate, clearly labeled field.
• Design for clarity at entry — reducing ambiguity up front prevents queries and downstream re‑work.
• Split checks appropriately — keep light, local checks at entry; put complex cross‑form/visit and heavy logic in batch to protect EDC performance while ensuring completeness.
• Make units and precision explicit — collect the value + recorded unit as reported and convert centrally to a canonical unit using a governed, versioned algorithm (sites never convert by hand); verify biological plausibility.
• Keep CCGs in lockstep with CRF/protocol changes — update guidance and train sites before activation; communicate changes early.
• Structure and labeling matter — EDC screens are built from field definitions (data type + prompt + response format), not printed page numbers; keep wording consistent across visits.