The Form Is an Instrument, Not a Document
Part of Clinical Data Management and Integrity: Designing the Data Collection Instrument.
About 5 minutes. Free, in your language, no account needed.
Why this matters
A thermometer is an instrument. It has a range, a resolution, a bias and a failure mode, and anyone using its readings needs to know all four.
A case report form is also an instrument, and it has the same properties. Its range is what it can express, its resolution is how finely, its bias is which answers it makes easy, and its failure mode is what a user does when their reality does not fit.
Treating it as a document rather than an instrument is why forms get reviewed for whether they look right instead of for what they will actually produce.
Resolution: what the field can express
Every field imposes a resolution, and the resolution must be at least as fine as the analysis needs.
A date field cannot answer a question about hours. A five-point scale cannot detect a difference smaller than one point. A checkbox cannot express degree. A free-text field has infinite resolution and no structure, which makes it unanalyzable at scale.
The check to run during design is to take each analysis the protocol promises and ask whether the fields feeding it can express the difference that analysis is looking for. Where they cannot, the study will complete and fail to answer its own question, and nothing before analysis will reveal it.
Bias: which answers the form makes easy
Forms push. A default value gets accepted more often than it should. An option at the top of a list gets chosen more than one at the bottom. A field requiring three clicks to say "not done" and one to enter a value gets values.
The most consequential version is the effort asymmetry between reporting and not reporting. If recording an adverse event opens a long cascade of required fields and recording nothing requires no action, the form has made under-reporting the path of least resistance. Nobody intends this and it is a design property, measurable in clicks.
The countermeasure is not exhortation to sites. It is to make the honest answer no harder than the convenient one.
Failure mode: what happens when reality does not fit
Every form eventually meets a situation its designer did not anticipate, and what the form does then determines whether you get a useful record or a fabrication.
A form that accepts an out-of-range value with a flag gets the truth plus a signal. A form that rejects it gets something else entirely, and the something else is untraceable.
The specific rule worth holding: never make it impossible to record what actually happened. A hard block on an implausible value guarantees that when the implausible value is real, the record will be false. Soft warnings that require confirmation and record the confirmation get the truth and the awareness together.
Range: what the form can express at all
A field that cannot express "unknown," "not applicable," "not assessed" or "participant declined" will receive one of those realities encoded as something else.
These are not edge cases. In any study of reasonable size, participants decline assessments, equipment fails, and information is genuinely unknown. A form that cannot say so converts every instance into a false value or a blank of ambiguous meaning.
In practice
A data manager reviews a form for a pain study. The primary endpoint is a pain score on an eleven-point scale, collected at each visit.
She asks three questions.
What if the participant cannot complete it? There is no option, so incapacity will appear as missing, indistinguishable from an oversight.
What if the participant is asleep or sedated at the scheduled time? Same.
What if the assessment happens outside the protocol window? The form collects the date but not the time, and the window for this endpoint is measured in hours.
Three changes: a reason-not-done field with defined options, and a time component on the assessment timestamp.
Cost, one day of build. Without it the primary analysis would have had missing values of unknown cause and no way to establish whether assessments were in window, and both would have been discovered at analysis.
What this looks like when it goes wrong
A study collects tumor response using a dropdown with four options: complete response, partial response, stable disease, progressive disease.
The field is required at every assessment.
Some participants have assessments that are not evaluable: a scan of inadequate quality, a participant who missed the imaging visit, a lesion that cannot be measured because of a technical issue.
There is no option for not evaluable. Sites must choose one of four, and they choose stable disease, because it is the least assertive.
The database records stable disease for assessments where nothing was actually assessed. The frequency is unknown because the records are indistinguishable from real stable disease. The effect on the endpoint is unquantifiable, and the error is not detectable in the data, because the values are valid.
One missing dropdown option, and a primary endpoint that cannot be defended.
Key takeaways
- A form is an instrument with a range, a resolution, a bias and a failure mode, and each must be designed rather than inherited.
- Check every promised analysis against whether its fields can express the difference it looks for.
- Forms push. An effort asymmetry between reporting and not reporting produces under-reporting as a design property, not a site behavior.
- Never make it impossible to record what actually happened. A hard block guarantees a false record when the blocked value is real.
- A missing option does not produce a missing value. It produces a plausible wrong one that is indistinguishable from the truth.