The Case Report Form and Its Relationship to Source

Part of Clinical Data Management and Integrity: Source Data and the Case Report Form.

About 6 minutes. Free, in your language, no account needed.

Why this matters

The case report form is the trial's question to the site, and the data is the answer. Understood that way, the form's relationship to the source is straightforward: for every field, either the form asks the site to copy something that exists, or it asks the site to record something for the first time.

Most confusion comes from forms where nobody decided which of those two a given field was.

What the form is for

The form collects what the protocol requires for the analysis, and nothing else.

That second clause is not an efficiency point, it is a data quality one. Every field a site completes consumes attention, and attention is finite. A form with 40 percent of its fields feeding no analysis does not merely waste effort; it degrades the quality of the other 60 percent, because a site completing a long form under time pressure completes all of it with less care.

A useful discipline during design is to ask, for every field, which analysis or which regulatory requirement consumes it. Fields with no answer should be removed, and the exercise reliably removes more than teams expect.

Transcription fields and first-record fields

Transcription fields ask the site to copy a value that already exists somewhere: a laboratory result, a measurement from a device, a date from the medical record. The form is a copy, the source is elsewhere, and the risk is transcription error.

First-record fields ask the site to record something that exists nowhere else: an assessment made specifically for the trial, a judgment, a structured observation. The form is the source, and the risk is a different one entirely.

For first-record fields the system must meet source document expectations. For transcription fields the site must retain the thing being transcribed.

A form where nobody classified the fields will have first-record fields whose systems were never treated as source, and transcription fields whose sources were discarded.

What the form must never do

It must never ask the site to interpret. A field labeled "clinically significant?" against a laboratory value is asking for a judgment, which is legitimate only if the judgment is defined, attributable to a qualified person, and recorded as a judgment rather than as a fact.

It must never make a required answer impossible. A mandatory field with no option covering the real situation forces the site to enter something untrue. A date of birth field with no option for "not known" in a population where some participants do not know it produces fabricated dates, and the fabrication is the form's fault.

It must never lose the distinction between zero, absent and not assessed. These are three different facts and a single blank field conflates them. A blank means the assessment was not done, or the finding was absent, or somebody forgot, and the analysis cannot distinguish. This is among the most consequential design failures because it is invisible until analysis.

Source data verification and its limits

Monitoring verifies case report form entries against source, and a risk-based approach concentrates that effort where it matters rather than checking everything.

What verification can catch: transcription errors, missing entries, values with no source at all.

What it cannot catch, and this is the important part: an error in the source itself. If the source says 138 and the participant's blood pressure was 148, verification confirms the form matches the source and finds nothing. Verification tests the copy, not the measurement.

This is why verification percentage is a poor proxy for data quality. A study with complete verification and a badly designed form is in worse shape than one with targeted verification and a good one.

In practice

A data manager reviews a draft form and asks, for each of its 340 fields, which analysis consumes it.

For 84 fields there is no answer. Some were carried from a previous study's form, some were requested by people no longer on the team, and several collect information that duplicates other fields.

Removing them takes a week of negotiation, because each has someone who wants it "in case."

The form goes to sites with 256 fields. The measurable effect is that entry time per visit falls by roughly a third; the unmeasurable and larger effect is that the fields that remain are completed by people who are not fatigued by the ones that did not matter.

What this looks like when it goes wrong

A form collects concomitant medications with a mandatory stop date.

Some medications are ongoing at the end of the study and have no stop date. The field is mandatory, and sites cannot save the record without it.

Sites do what people do when a system demands an answer that does not exist. Some enter the study end date. Some enter a far-future date. Some enter the start date. Some stop recording ongoing medications at all, because the record cannot be saved.

The database now holds stop dates that are fabrications in four different styles, and no way to identify which are real. The analysis of concomitant medication exposure is not recoverable, and nothing in the data marks which values to distrust.

No site did anything wrong. Every one of them was made to enter something untrue by a form that required an answer that did not exist.

Key takeaways