Every field in a case report form creates work.
Someone has to collect the value, enter it, review it, query it, correct it, protect it, and decide what it means. One extra field may seem harmless. Add that field across 100 participants and five visits, however, and you have created 500 new opportunities for missing, inconsistent, or unnecessary data.
This does not mean an investigator-initiated trial should collect the smallest possible dataset. It means the trial should collect the right dataset: information sufficient to protect participants, run the study, and answer the prespecified research question.
That distinction matters more in an IIT because the investigator or investigator institution often controls both the scientific design and sponsor-level systems. In an industry-sponsored trial, a site usually receives an established protocol and CRF. In an IIT, your team may be responsible for deciding what goes into both. The freedom to design the study also creates the responsibility to defend each field.
What Does Data Minimization Mean in an IIT?
Data minimization is the deliberate restriction of trial data to information that has a defined scientific, safety, eligibility, operational, or prespecified exploratory purpose.
It is not the same as collecting too little. A dataset can be small and still be inadequate. It can also be large and still fail to capture the primary endpoint correctly.
ICH E6(R3), adopted at Step 4 in January 2025, emphasizes quality by design, proportionality, and information that is sufficient and fit for purpose. The guideline does not give investigators a universal maximum number of CRF fields. It provides a stronger design principle: trial processes and data should support reliable results and participant protection without unnecessary complexity.[1]
For an IIT team, the practical question is simple:
If this field disappeared, which objective, endpoint, safety decision, eligibility determination, analysis, or required trial operation would become impossible?
If the team cannot answer, the field is not ready for the CRF.
Why “We Might Need It Later” Is a Weak Justification
The strongest argument for collecting extra data is flexibility. An investigator may want variables for future subgroup analyses, an unexpected reviewer question, or a second publication. That concern is legitimate. An overly narrow CRF can remove context that later proves clinically important.
But flexibility has a cost. Every exploratory variable adds participant or staff burden and increases the volume of data that must be governed. It may also encourage analyses that were not planned and cannot be interpreted with the same confidence as prespecified analyses.
The solution is not to ban exploratory fields. It is to name their purpose before collection.
“Future research” is vague. “Prespecified exploratory analysis of whether baseline ocular surface disease modifies the change in patient-reported visual symptoms” is defensible. The second statement identifies the population feature, outcome, and analytical role. It can be reviewed for feasibility and included in the statistical analysis plan.
Use a Protocol-to-CRF Traceability Matrix
A protocol-to-CRF traceability matrix connects each collected field to the reason it exists. Build it before configuring the study database.
Use six columns:
| CRF field | Protocol source | Purpose | Time point | Source | Planned use |
|---|---|---|---|---|---|
| Participant ID | Data-management plan | Link records without using direct identifiers in the analysis dataset | All visits | Assigned study identifier | Record linkage |
| Baseline visual acuity | Secondary endpoint definition | Establish baseline and calculate change | Baseline | Clinical assessment | Secondary endpoint analysis |
| Adverse event term and onset date | Safety section | Evaluate and report safety events as applicable | Event-driven | Source record/participant report | Safety review |
| Lens model | Exploratory objective | Compare prespecified device subgroups | Procedure visit | Operative record | Exploratory subgroup analysis |
The matrix forces the study team to make hidden assumptions visible. It also exposes three common defects:
- An endpoint with no field. The protocol promises an analysis that the CRF cannot support.
- A field with no purpose. The CRF collects information that is absent from the protocol and analysis plan.
- A field at the wrong time. The variable exists, but the visit schedule cannot produce the comparison the endpoint requires.
The existing Sengi guide to preparing a protocol for an IIT describes the major protocol components. The CRF design guide then addresses structure, allowable units, open text, and endpoint alignment. The traceability matrix is the bridge between those two documents.
Apply a Six-Part Test to Every Field
1. Does it support an objective or endpoint?
Start with the primary objective and primary endpoint. Confirm that the CRF captures every component of the endpoint at the correct time point and in the correct unit.
Then repeat the test for secondary and prespecified exploratory objectives. Do not assume that a familiar clinical variable belongs in the study merely because it is routinely measured.
2. Is it needed for participant safety?
Safety data cannot be reduced to a generic checklist. The necessary information depends on the intervention, population, protocol, jurisdiction, and applicable reporting requirements. Use current regulatory and ethics requirements when defining safety fields; do not rely on a prior Sengi post or a generic template as the authority.
3. Does it establish eligibility?
Each inclusion and exclusion criterion should have a documented source and a clear study decision. Avoid copying an entire medical history into the CRF when only specific conditions determine eligibility—unless broader collection has another defined clinical or safety purpose.
4. Does it support trial conduct?
Some information is operational rather than analytical: visit completion, investigational product accountability where applicable, protocol deviation review, or contact attempts. Keep operational data when it is necessary to manage the trial, but separate it logically from outcome data.
5. Is the source and timing defined?
FDA’s electronic source-data guidance addresses how source data are identified, captured, and transferred into electronic systems and CRFs.[2] The EMA guideline on computerized systems and electronic data similarly sets expectations for systems and data integrity in clinical trials within its scope.[3]
For each field, define where the value originates, who records it, when it is recorded, and whether transcription occurs. A field that lacks a reliable source is not improved by adding validation rules later.
6. Will the data be used?
Name the table, figure, endpoint analysis, safety review, eligibility decision, or operational report that will use the value. If no output or decision uses it, remove it or document why retention is necessary.
Treat ALCOA+ as a Review Lens, Not a Slogan
In Eye-Dea to Impact, Brad Hall places data diligence within the “Notice the Insights” stage of the proprietary LENS system. The book uses ALCOA+ to explain that data should be attributable, legible, contemporaneous, original, accurate, complete, consistent, enduring, and available.
The useful point is operational: collecting a value is not enough. The team must be able to understand its origin, timing, meaning, changes, and availability. Current regulatory application should be checked against the authority governing the specific trial.
Use ALCOA+ after the traceability test:
- Traceability asks: Why are we collecting this field?
- ALCOA+ asks: Can we trust and reconstruct the resulting data?
A field can pass one test and fail the other. A necessary endpoint collected through an ambiguous process is still a quality problem. A perfectly traceable value with no scientific or operational purpose is still unnecessary work.
Run the Audit Before Database Build
The best time to remove a field is before database configuration, participant recruitment, and staff training.
Bring the investigator, coordinator, data manager, and statistician into one review. For each field, require a one-line justification and a protocol reference. Resolve missing endpoints, duplicate fields, undefined units, open-text categories, and timing conflicts. Then update the protocol, CRF, data-management documentation, and statistical analysis plan together.
Do not treat this as a cosmetic CRF review. It is a study-design review.
An IIT succeeds when its data are sufficient to answer a worthwhile question and reliable enough to support the conclusion. More data do not automatically create more insight. Deliberate data create defensible insight.
References
- International Council for Harmonisation. Guideline for Good Clinical Practice E6(R3), Step 4 final guideline, 6 January 2025. https://database.ich.org/sites/default/files/ICH_E6%28R3%29_Step4_FinalGuideline_2025_0106.pdf (accessed 2026-07-11).
- U.S. Food and Drug Administration. Electronic Source Data in Clinical Investigations: Guidance for Industry, September 2013. https://www.fda.gov/media/85183/download (accessed 2026-07-11).
- European Medicines Agency. Guideline on computerised systems and electronic data in clinical trials, 2023. https://www.ema.europa.eu/en/documents/regulatory-procedural-guideline/guideline-computerised-systems-and-electronic-data-clinical-trials_en.pdf (accessed 2026-07-11).
Frequently Asked Questions
Should an IIT collect data for future exploratory analyses?
Yes, when the exploratory purpose is defined prospectively, ethically appropriate, feasible, and supported by the protocol and analysis plan. “We might use it” is not enough justification by itself.
Does data minimization mean collecting only primary-endpoint data?
No. Trials may need secondary outcomes, safety data, eligibility evidence, operational records, and justified exploratory variables. The test is defined purpose, not minimum volume.
Take the next step
Data minimization works best when it begins with the research question and continues through the protocol, CRF, analysis, and publication. Eye-Dea to Impact shows how those decisions fit together across the IIT lifecycle.
