Derived Variables and the Rules That Make Them
Part of Clinical Data Management and Integrity: Coding and Data Standards.
About 5 minutes. Free, in your language, no account needed.
Why this matters
Most numbers in a clinical study report were not collected. They were derived: change from baseline, body mass index, time to event, best overall response, treatment-emergent flag, population membership.
Each derivation is a rule, and the rule is a scientific decision that determines the result. A derivation with an ambiguity in it produces a defensible number and a different defensible number depending on who implements it, and neither implementer will know the other existed.
Where the ambiguity hides
What is baseline? The last assessment before first dose sounds unambiguous until a participant has two assessments on the day of first dose, one before and one after, with only dates recorded. Or an assessment on the day before that is out of window. Or no pre-dose assessment at all.
What is treatment emergent? An event starting after first dose is easy. An event present before first dose that worsens after it is a decision. So is an event starting after the last dose, where the window that counts must be stated.
What is a completer? Completed the final visit, or completed the treatment period, or received a defined proportion of planned doses. Each gives a different denominator, and the denominator is the analysis.
How are partial dates handled? An adverse event with onset "March 2026" and a first dose of 15 March is either treatment emergent or not depending on a convention, and the convention must be stated.
What happens with repeated measurements? Where a visit has two assessments, the rule must say which is used, and "the first" and "the last" and "the mean" are all defensible and different.
The rule must be executable
The test of a derivation specification is whether two competent people implementing it independently produce identical results.
Prose descriptions almost never pass this test. "Baseline is the last assessment prior to first dose" leaves every one of the cases above unresolved.
An executable specification states the ordering when timestamps tie, the treatment of missing values, the behavior when no qualifying record exists, and the handling of records outside the expected window. It is longer and it is the difference between a reproducible number and a number.
Who owns them
Derivations are specified by statistics and implemented by programming, with data management responsible for whether the collected data supports them at all.
That third role is the one most often left out and it is where the failures appear. A derivation requiring a timestamp when the form collects a date is unimplementable, and the moment to find out is during specification, not during analysis.
The practical discipline is that every derivation is checked against the collection instrument before the instrument is finalized, and the check asks one question: does every field this rule reads exist, at the grain the rule needs?
In practice
A data manager reviews the draft analysis plan's derivations against the case report form.
Eleven derivations, of which three cannot be implemented as written.
Change from baseline in a vital sign requires a pre-dose measurement, and the form collects vital signs once per visit with no pre-dose or post-dose designation. Fixed with a timepoint field.
Time to response requires the date of the first assessment meeting the response criteria, and the form collects assessment results without assessment dates, only visit dates. Where assessments occur between visits, the derivation cannot resolve. Fixed with an assessment date.
Treatment-emergent flag requires an onset date, and the form permits partial dates with no convention stated. Fixed by stating the convention in the plan and adding a partial-date flag.
Three fixes, three days. Discovered at analysis, the first would have been a protocol deviation from the analysis plan, and the second would have made the endpoint underivable.
What this looks like when it goes wrong
A study derives best overall response from a series of assessments. The rule says the best response achieved, with confirmation required at a subsequent assessment.
For participants who achieved a response at their final assessment before withdrawing, there is no subsequent assessment and therefore no confirmation.
The specification does not say what happens. The programmer implementing it, reasonably, treats unconfirmed responses as non-responses.
The statistician had assumed these participants would be excluded from the denominator rather than counted as failures.
Both readings are defensible. They produce materially different response rates, and the difference is larger than the effect the study was powered to detect.
The discrepancy is found during quality control, which is the system working. It is found three weeks before a database lock, when resolving it means a decision about the primary endpoint's definition made by people who can already see how the numbers move.
That is the worst possible moment to make it, and the specification could have resolved it two years earlier with one sentence.
Key takeaways
- Most reported numbers are derived, and each derivation is a scientific decision that determines the result.
- Ambiguity hides in baseline definitions, treatment-emergent windows, completer definitions, partial dates, and repeated measurements.
- The test of a specification is whether two competent people implementing it independently get identical results. Prose descriptions almost never pass.
- Data management owns whether the collected data supports the derivation at all, and that check belongs before the instrument is finalized.
- An unresolved derivation found near lock forces a definitional decision by people who can already see how the numbers move.