A case report form (CRF) should capture the minimum complete dataset required to answer an investigator-initiated trial’s research question—not every variable that might be interesting later. The safest starting point is the protocol: endpoints, eligibility criteria, safety requirements, visit schedule, and prespecified analysis.
In an IIT, the investigator-sponsor often controls both the scientific design and the operational data system. That control creates an opportunity to keep the CRF focused, but it also concentrates responsibility for traceability, field specifications, review, system controls, and change management. A short form is not automatically a good form; the goal is a dataset that is lean and sufficient.
What is a case report form?
A CRF is a paper or electronic data-acquisition tool used to record protocol-required information that will be reported for each trial participant. An electronic CRF (eCRF) is the corresponding auditable electronic record within an electronic data-capture system.
A CRF is not necessarily the source record. The source may be an electronic health record, examination worksheet, imaging device, laboratory system, participant-reported instrument, or a direct-entry eCRF field. For FDA-regulated investigations, the FDA’s Electronic Source Data in Clinical Investigations guidance addresses predefined eCRF fields, source-data originators, audit trails, electronic capture, and investigator review and retention.
The distinction matters. Copying data from a source record into a CRF creates a transcription and reconciliation step. Direct entry into an eCRF can remove that transcription step, but only if the protocol, source definition, user workflow, and system controls support it.
Start with protocol-to-CRF traceability
Do not begin by opening a generic CRF template and adding fields. Begin with the protocol and map each requirement forward into the CRF and analysis dataset.
A practical traceability matrix should connect:
- protocol objective or requirement;
- endpoint, safety, eligibility, or operational rationale;
- visit and timing;
- CRF page and field;
- source or data originator;
- data type, units, coding, and missing-data options;
- edit checks; and
- analysis variable or planned use.
This approach exposes two common problems early: a protocol requirement with no corresponding field, and a CRF field with no defensible purpose. ICH E8(R1) states that protocols and CRFs/data-collection methods should support conduct of the study as designed and avoid unnecessary data collection. The current ICH E8(R1) guideline is therefore a useful foundation for the minimum-complete-dataset principle.
Download the editable CRF design and traceability template
The editable Word template below contains a protocol-to-CRF traceability matrix plus checklists for data minimization, field design, safety, system controls, eye-care variables, user acceptance testing, and approvals.
This educational planning aid must be adapted to the protocol, statistical analysis plan, ethics requirements, institutional procedures, system environment, and applicable jurisdiction. It is not a universal regulatory-compliance template.
Use the minimum-complete-dataset test
For every proposed field, ask:
- Which endpoint, eligibility criterion, safety requirement, operational decision, or prespecified analysis requires this field?
- At which visit is it required?
- Who or what originates the data?
- What coding, units, timing, and missing-data states are required?
- What will happen if the field is incomplete, inconsistent, or out of range?
- Can the field be removed without compromising participant protection or the study’s ability to answer its research question?
This is the practical data-minimization logic used throughout Eye-Dea to Impact. “Nice-to-have” data are not free: they add build effort, site burden, review time, queries, cleaning, and analysis decisions. But indiscriminate deletion is equally poor design. A minimum dataset must still be complete for the protocol and analysis.
Design CRF fields that produce interpretable data
Use explicit labels and completion instructions
Field labels should identify exactly what is being recorded. Define abbreviations, assessment windows, date conventions, and whether a value is observed, calculated, copied, or adjudicated. A separate CRF completion guide is appropriate when the form cannot carry enough instruction without becoming crowded.
Prefer structured values when the allowable responses are known
Checkboxes, radio buttons, coded lists, and constrained numeric fields can reduce ambiguity and support analysis. Free text remains necessary for some clinical descriptions, but it should not replace a variable that has a known, analyzable response set.
Define units, precision, and missingness
Specify permissible units, decimal precision, range, timing, and any conversions. Distinguish “not done,” “unknown,” “not applicable,” and unexpectedly missing data when those states have different meanings. Do not silently convert a blank field into a clinical conclusion.
Do not collect derived variables unnecessarily
When a value can be derived reproducibly during analysis, collect the required components and document the derivation rather than asking sites to calculate it manually—unless the derived value is needed for an immediate clinical or operational decision.
Build safety and eligibility fields from the protocol
Adverse-event design must follow the protocol’s definitions, reporting period, seriousness criteria, causality approach, grading convention, and follow-up requirements. CTCAE may be appropriate for some studies, but it is not a universal grading system for every IIT or every ophthalmic intervention.
Likewise, eligibility should be confirmable without collecting unnecessary narrative. A yes/no eligibility checklist may be adequate operationally, while the protocol-required supporting values are captured elsewhere. The final structure should be agreed before database build by the investigator-sponsor, clinical reviewer, statistician, and data-management lead.
Paper CRF or eCRF?
| Decision factor | Paper CRF | eCRF/EDC |
|---|---|---|
| Setup | Form design, printing, distribution, filing, and controlled revisions | System configuration, field specifications, validation/UAT, roles, and training |
| Data entry | Usually requires later transcription into an analysis database | Can support direct or transcribed entry with edit checks |
| Change history | Corrections require a documented paper convention | Should retain an appropriate audit trail |
| Review | Physical transfer or secure scanning may be needed for remote review | Role-based remote review may be available |
| Risk | Version control, legibility, loss, transcription, and reconciliation | Access, configuration, validation, security, integration, backup, and vendor dependence |
A spreadsheet is not automatically prohibited, but it is not automatically fit for purpose either. Its intended use and risks must be assessed. Access control, change history, auditability, validation, backup, recovery, data review, signatures, retention, and export requirements may exceed what an ordinary spreadsheet configuration provides. For trials in the European regulatory context, the EMA guideline on computerised systems and electronic data in clinical trials provides relevant expectations. ICH E6(R3) also emphasizes fit-for-purpose trial processes and systems.
Eye-care CRF design requires more than adding OD and OS
- Study eye: distinguish study eye, fellow eye, and bilateral assessments consistently.
- Visual acuity: define chart, testing distance, refraction status, lighting, scoring method, permitted conversions, and retest rules.
- Intraocular pressure: specify method/device, eye, timing, repeat measurements, and the rule for selecting or averaging values.
- Imaging: capture modality, device, acquisition protocol, image quality, laterality, reading method, grader, and adjudication where applicable.
- Procedures and devices: structure laterality, technique, device/implant, complications, re-interventions, and relevant procedural timing.
- Participant-reported outcomes: preserve the validated instrument, administration mode, language, timing, and scoring rules.
These details must reflect the actual protocol. A generic ophthalmology CRF cannot define the right measurement conditions for every disease, device, procedure, or endpoint.
Review, test, approve, and version the CRF
Before release, conduct a structured review involving the people who will use and analyze the data. User acceptance testing should cover valid entries, invalid entries, missing values, boundary values, branching, edit checks, role permissions, corrections, and exports. Confirm that the approved CRF specification matches the deployed database.
Document the CRF version, approval, effective date, training, and change-control process. When a protocol amendment changes data requirements, assess the CRF, completion instructions, edit checks, existing records, exports, and analysis mapping together. Retain the approved blank CRF and relevant specifications with the study records.
A practical CRF review checklist
- Every field has a documented protocol, safety, operational, or analysis rationale.
- Every endpoint and critical protocol requirement maps to the required data.
- Source/originator, timing, units, coding, and missing-data states are defined.
- Free text and manually derived values are limited to justified uses.
- Eligibility, safety, deviations, and concomitant treatments follow the protocol.
- Eye, device, method, acquisition conditions, and grader are defined where relevant.
- Electronic-system controls are proportionate to the intended use and risk.
- Clinical, statistical, data-management, site-user, and system review is complete.
- UAT, version approval, training, and change control are documented.
- The analysis team can use the resulting data without guessing what a field means.
Frequently asked questions
What is the difference between a CRF and a source document?
A source record contains the original clinical or research observation—or an authorized certified copy. A CRF records protocol-required information reported for the trial. An eCRF field may itself be the source when data are entered directly and the protocol, source definition, and system support that arrangement.
Can I use a generic CRF template?
Use templates as structure prompts, not as substitutes for protocol-driven design. Every retained field must fit the study’s endpoints, safety needs, visits, population, intervention, and analysis. The downloadable template on this page is a design and traceability tool rather than a universal participant CRF.
Can an IIT use Excel instead of an EDC system?
Possibly, but only after a documented assessment of intended use, study risk, applicable requirements, institutional controls, and the spreadsheet’s limitations. A basic workbook does not inherently provide the controls expected of an auditable clinical data system.
When should CRF design begin?
Begin once the protocol objectives, endpoints, eligibility criteria, safety plan, and visit schedule are sufficiently stable for traceability. CRF development should overlap with statistical and operational review—not wait until after the protocol is finalized and sites are ready to enroll.
Related IIT resources
- Scientific study design for an investigator-initiated trial
- How to write a protocol for clinical research
- How to create the study database for an IIT
- How to perform source data verification
- How to prepare informed consent for an IIT
Sources
- International Council for Harmonisation. ICH E6(R3): Guideline for Good Clinical Practice. Final Step 4 guideline, 2025.
- International Council for Harmonisation. ICH E8(R1): General Considerations for Clinical Studies. 2021.
- U.S. Food and Drug Administration. Electronic Source Data in Clinical Investigations. Guidance for Industry, 2013; FDA page current as of 2018.
- European Medicines Agency. Guideline on computerised systems and electronic data in clinical trials.
- National Institute of Neurological Disorders and Stroke. Common Data Elements CRF Library.
Take the next step
CRF design is only one part of building a study that can produce defensible results. Eye-Dea to Impact connects protocol design, data collection, trial execution, and publication in one practical IIT framework.
