.jpg){kind=link}
- Published
- Updated
The database may continue changing during an interim review. Without a clear definition of included records, the same program can produce a different decision on another day. Distinguish the snapshot used for the decision from information arriving later.
Define the question and assumptions
Define cutoff dates, extraction time and inclusion rules. Event dates differ from entry dates. Link the raw-data snapshot, derivation code and output set so the package remains traceable. Prespecify who evaluates whether late corrections justify reanalysis instead of letting informal table updates determine which evidence the reviewing group sees.
Hypothetical study example
In a hypothetical trial, an earlier event is entered shortly before a committee meeting. The team does not silently mix it into an existing table. It preserves the original snapshot, assesses the record through the defined review route and clearly identifies the package supporting the decision actually taken.
Design review checks
- Record event timing, entry timing and analytical cutoff as separate concepts.
- Link every output package to its data version and program version.
- Test review and escalation rules for corrections arriving after snapshot preparation.
Record the decision and its limits
Acceptance allows an independent reviewer to reproduce the package seen by decision makers. An interim snapshot is not the final database lock. Do not hide new information, but preserve which decision used which evidence. If reanalysis occurs, document its rationale, scope, differences from earlier results and communication date clearly.
Frequently asked questions
- Does a cutoff always mean an event-date boundary?
- No. The applicable inclusion and extraction rules need separate explanation.
- Can new data overwrite the previous package?
- Preserve the decision trail and keep the earlier used package retrievable.