Part 13 · Module 2

Designing Case Report Forms and Data Collection Instruments

Design case report forms and study instruments that capture necessary data accurately, consistently and with minimal avoidable burden or ambiguity.

Learning outcomes

After completing this lecture, you should be able to:

  • Distinguish source documents, case report forms, questionnaires and data-entry interfaces.
  • Design fields and response options that reflect operational definitions and minimise ambiguity.
  • Apply principles of sequencing, skip logic, units, dates and missing-data handling.
  • Explain how form design can prevent or create data-quality problems.
  • Pretest a data collection instrument before production use.

Overview

A case report form (CRF) or data collection instrument translates the protocol’s variables into a usable interface. Its purpose is not to reproduce the entire medical record. It should capture the information required by the study in a form that is unambiguous to the collector, interpretable to the data manager and traceable to an appropriate source. In regulated clinical investigations, electronic source and study records should support reliability, integrity and traceability.[1-3]

A well-designed form makes the correct action easy. A poorly designed form silently creates missing data, coding ambiguity, inconsistent units, accidental duplication and respondent burden. These problems are often attributed later to “data cleaning”, although the origin was the instrument itself.

Why this matters

Forms are where abstract definitions meet real people and real workflows. A field labelled “Smoking: 1/2/3” may be obvious to the person who designed it but uninterpretable months later. A field for “Date of diagnosis” may be impossible for participants to recall precisely. A required numeric field can force staff to invent a value when the measurement was not performed.

Good design therefore combines methodological correctness with human-factors thinking: the collector must understand the question, obtain the information feasibly, and record it without unnecessary transformation.

Flow diagram showing how an operational definition becomes a single clear field, explicit response options, validation rules and a usable exported variable.
Figure 13.2. Good form design translates one operationally defined concept into one interpretable, analysis-ready field.

Distinguish the instrument from the source

A source document is where information is originally recorded or generated. A CRF is a study-specific tool used to capture protocol-required data. A participant questionnaire may itself be source data if the participant enters responses directly. A study database may therefore contain both transcribed source information and data entered directly at source.[1,2]

This distinction matters for corrections and verification. If blood pressure is transcribed from a clinical chart, the form should not obscure which reading was selected. If the measurement is obtained specifically for the study and entered directly into an electronic form, the electronic record may be the source, provided the system and process preserve the required attributes.[2,3]

Start from the data specification

Before arranging fields on a page, prepare a field specification. For each item define:

  • variable name and human-readable label;
  • operational definition;
  • data type;
  • permissible values or response options;
  • unit;
  • source;
  • collection time point;
  • whether the item can be unknown or not applicable;
  • branching or skip conditions; and
  • any validation or calculation rule.

This specification should agree with the data dictionary discussed later in Part 13. The visual form is an interface to the specification, not the only place where definitions live.

Field types and response options

Use structured fields when the possible responses are known and analytically meaningful. Radio buttons or single-choice fields are suitable for mutually exclusive categories. Checkboxes are suitable when more than one option can apply. Numeric fields should enforce plausible data types but should not apply arbitrary ranges that reject clinically possible values.

Free text is valuable for genuinely unstructured information, explanations and “other, specify” responses. It is inefficient for data that will later require consistent categorisation. For example, entering sex, clinic or medication route as free text invites spelling variants that must later be reconciled.

When categories have an order, ensure that the display order is logical. When categories are nominal, avoid numeric codes that imply quantitative distance. Coding is a storage convention, not a measurement scale.

Dates, times and units

Dates should be captured as dates, not ambiguous strings. Use an interface that displays the intended format and, where possible, stores a standard machine-readable value. If only part of a date is known, do not invent the missing day or month; define a separate mechanism for partial dates if they are required.

Measurements need explicit units. “Weight = 68” is incomplete without kilograms or another unit. In multisite studies, either standardise the collection unit or capture the unit alongside the value and convert through a documented transformation. Do not ask staff to perform mental conversion during data entry when the system can handle it reproducibly.

Missingness and response states

A required field is useful only when the information should always exist at that point. Overuse of required fields can encourage fabricated values. Instead, consider explicit statuses such as:

  • performed and value available;
  • performed but result pending;
  • not performed;
  • participant refused;
  • source unavailable;
  • not applicable; or
  • unknown after review.

The status can trigger whether a value field should appear. This preserves the reason for missingness without contaminating the numerical variable.

Order and cognitive flow

For interviewer- or participant-facing instruments, question order affects comprehension and burden. Begin with clear, relevant questions. Group related topics. Place sensitive questions where appropriate after rapport has developed, unless eligibility or safety requires them earlier. Instructions should be visible at the point of use rather than hidden in a distant manual.

For record-abstraction CRFs, order fields to follow the source workflow where practical. If the collector must repeatedly jump between sections of a record, error and fatigue increase. However, do not let the source record structure redefine the study’s conceptual structure.

Branching and repeated events

Skip logic should show only relevant questions. For example, if “No antihypertensive medication” is selected, dose fields should not appear. Branching reduces clutter and prevents impossible combinations, but the logic must be tested in every pathway.

Repeated information should be modelled as repeated information. If a participant can have multiple contact attempts, adverse events or laboratory tests, avoid preallocating arbitrary columns such as visit1, visit2, visit3 unless the study truly has fixed visits. A repeatable record structure is often more scalable and analytically coherent.

Form layout and visual discipline

A form should communicate hierarchy without decorative complexity. Use concise labels, consistent terminology and enough white space. Keep instructions near the relevant field. Avoid excessive abbreviations. For paper forms, provide sufficient writing space and page identifiers. For electronic forms, test on the devices and screen sizes actually used in the field.

Do not use colour as the sole indicator of required status or error because this can reduce accessibility and print usability.

CRF and instrument design checklist

  • Every field maps to a defined study variable or operational need.
  • Labels use the same terminology as the protocol and data dictionary.
  • Response options are mutually exclusive when required and collectively adequate.
  • Units and date formats are explicit.
  • Missing, unknown and not-applicable states are distinguishable when relevant.
  • Branching logic is documented and testable.
  • Repeated events have an appropriate data structure.
  • Derived values are calculated from retained components where feasible.
  • Sensitive or identifying data are minimised and access-controlled.
  • The form has been pretested using realistic scenarios before release.

Worked example

Redesigning a laboratory-result form

The first draft contains one field: Postpartum glucose = ______.

The revised form asks:

  1. Was a postpartum glucose test verified? Yes / No / Unknown
  2. If yes, specimen date: date field
  3. Test type: fasting plasma glucose / oral glucose tolerance test / HbA1c / other specified
  4. Fasting glucose value: numeric, unit fixed to mmol/L where applicable
  5. Two-hour glucose value: numeric, displayed only for the relevant test
  6. Source: local laboratory / external report / other documented source
  7. If no verified test, reason: not performed / source unavailable / participant reports external test without documentation / other / unknown

The revised structure separates completion, timing, test type, result and verification. It can answer more than one research question without asking collectors to compress several concepts into one cell.

Pretesting before production

Instrument testing should occur in stages. First perform technical review against the protocol and data dictionary. Next use scripted cases that include normal, extreme, missing and logically inconsistent values. Then conduct cognitive or operational pretesting with representative users. For participant-facing questionnaires, cognitive interviewing can reveal misunderstanding even when the database behaves perfectly. For CRFs, field staff can identify source information that is difficult to locate or definitions that are not operational.[4]

Electronic instruments should also be tested for branching, calculations, permissions, save/resume behaviour, repeated forms, exports and audit trails where applicable. REDCap is one example of a metadata-driven electronic data-capture platform designed for research workflows, but sound form design is still the responsibility of the study team.[5]

Choose the field that matches the information

  1. Is the response naturally categorical, numeric, date/time or free text?
  2. Can the options be defined prospectively?
  3. Can more than one option apply?
  4. Does the field depend on a previous answer?
  5. Can the information legitimately be missing or unknown?
  6. Will the same event occur more than once?
  7. What will the exported data look like for analysis?

Interface with analysis and data cleaning

Good forms reduce transformation without hard-coding analytical assumptions. Use stable variable names, consistent categories and explicit units. Preserve raw responses before recoding. When a categorical variable is displayed with human-readable labels, the export should still retain clear codes and labels rather than undocumented integers.

Structured data also make validation easier. Spreadsheet guidance recommends one variable per column, one observation per row and consistent representation of missing data; these principles remain useful when evaluating exported research datasets.[6]

Form versioning and controlled changeMMed extension

Once data collection has started, changing a form can alter measurement. A new response category, modified wording or recalculated score may create a discontinuity between participants enrolled before and after the change. Record the effective date and reason for substantive revisions, determine whether existing records require migration, and preserve enough metadata to know which version generated each observation.

In multicentre studies, production changes should be coordinated centrally. A field added at one site but not another can create structural missingness that looks like participant-level missing data during analysis.

Designing for respondent and collector error

Form design should anticipate how mistakes occur. Errors may arise because the question is misunderstood, the source record is difficult to navigate, the response options do not fit the real situation, the user selects the adjacent option, or the interface asks for information that is not yet available. Each error mechanism suggests a different design response.

For participant-facing instruments, distinguish comprehension, retrieval, judgement and response mapping. A participant may understand a question but be unable to recall the exact number of clinic visits; another may remember the event but find no response category that describes it. Cognitive pretesting is valuable because it examines these steps rather than assuming that grammatically correct wording is understood as intended.

For record abstraction, show enough context to prevent transcription of the wrong value. A field labelled “HbA1c” may need the relevant date or episode displayed nearby. If several laboratory measurements exist, the manual should define which one qualifies. The form should support the rule rather than require the abstractor to remember it from another document.

Avoid premature transformation during entry

Capture observations as close as practicable to their source representation, then derive analytical categories reproducibly. If age is available from date of birth and index date, storing only a manually calculated age discards information. If a continuous laboratory value will later be dichotomised, retain the original measurement and derive the threshold variable separately.

This principle also applies to questionnaire items. Store item-level responses even when the primary analysis uses a total score. Item retention supports score verification, missing-item rules and future psychometric checks.

Paper forms still require data architecture

Paper CRFs are not exempt from these principles. Page numbers, participant identifiers, visit labels, version numbers and correction conventions should be visible. Design boxes and response areas so marks are interpretable. If paper is later entered electronically, the paper layout should correspond closely enough to the database to reduce transcription error.

When double data entry is used for selected high-risk data, define how discrepancies are reconciled and which source remains authoritative. Double entry can detect transcription differences, but it does not identify an error already present on the paper source.

Appraise a data collection instrument

  • Does each field have one interpretable purpose?
  • Can users distinguish “No”, “Unknown”, “Not done” and “Not applicable” where needed?
  • Are units, dates and response options explicit?
  • Does the instrument preserve raw information before analytical recoding?
  • Are repeated events represented without arbitrary limits?
  • Do instructions and layout match the workflow in which the form is used?
  • Have both normal and exceptional pathways been tested?
  • Does the exported structure support the planned analysis without undocumented manual reconstruction?

Common mistakes

Knowledge check

Why is 'BP = 140' an inadequate field specification?

Answer and reasoning

It does not state whether the value is systolic or diastolic, the unit, which reading to use when several were taken, the measurement procedure, source or time point. A number without an operational definition is not a reproducible research variable.

Should every electronic field be set as required to prevent missing data?

Answer and reasoning

No. Required fields are appropriate when information must exist at that stage, but they can create false data when the source is legitimately unavailable. Explicit missing states and conditional requirements are often safer.

When is free text preferable to a fixed choice?

Answer and reasoning

When the information is genuinely open-ended, when unanticipated responses are scientifically important, or for a controlled ‘other, specify’ explanation. Stable analytic categories should usually be captured structurally.

Why should the exported dataset be examined during form testing?

Answer and reasoning

A form can look correct on screen while producing confusing codes, duplicated variables or difficult repeated-record structures. Testing the export confirms that capture decisions support cleaning and analysis.

Key take-home messages

Key take-home messages

  • Design forms from the variable specification and operational definitions.
  • Keep one defined concept per field and make units, dates and missing states explicit.
  • Use structured response options and branching where they improve accuracy without forcing false completeness.
  • Model repeated events as repeated data rather than arbitrary extra columns.
  • Pretest both the human workflow and the exported dataset before production.
  • Treat substantive form changes as controlled measurement changes that require versioning.

References

  1. International Council for Harmonisation of Technical Requirements for Pharmaceuticals for Human Use. ICH harmonised guideline: Good Clinical Practice E6(R3). Step 4. 6 January 2025. https://database.ich.org/sites/default/files/ICH_E6%28R3%29_Step4_FinalGuideline_2025_0106.pdf
  2. US Food and Drug Administration. Guidance for industry: Electronic source data in clinical investigations. Silver Spring (MD): FDA; 2013. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/electronic-source-data-clinical-investigations
  3. US Food and Drug Administration. Electronic systems, electronic records, and electronic signatures in clinical investigations: questions and answers. Guidance for industry. Silver Spring (MD): FDA; 2024. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/electronic-systems-electronic-records-and-electronic-signatures-clinical-investigations-questions
  4. World Health Organization. WHO STEPS surveillance manual: the WHO STEPwise approach to noncommunicable disease risk factor surveillance. Geneva: World Health Organization. https://www.who.int/teams/noncommunicable-diseases/surveillance/systems-tools/steps
  5. Harris PA, Taylor R, Thielke R, Payne J, Gonzalez N, Conde JG. Research electronic data capture (REDCap)—a metadata-driven methodology and workflow process for providing translational research informatics support. J Biomed Inform. 2009;42(2):377–381. https://doi.org/10.1016/j.jbi.2008.08.010
  6. Broman KW, Woo KH. Data organization in spreadsheets. Am Stat. 2018;72(1):2–10. https://doi.org/10.1080/00031305.2017.1375989

These materials support learning and research planning. They require adaptation to the study context and do not replace methodological, statistical, ethical, or regulatory consultation.

Report an error in this lecture