- Published
- Updated
Two reports created under the same script name may use different code, inputs or settings. Retaining a file name alone is not enough to reconstruct how a particular clinical-data transformation produced its result.
Preserve the meaning of data
An execution record should link the code version, input population, parameters and outputs. A run date does not uniquely identify a software version. Separate code review from confirmation that one execution completed with its intended inputs. Retain enough configuration context to explain the result without copying secret values into logs or evidence packages.
Worked example
For example, a cleaning script processes a new laboratory delivery using an outdated mapping table. The output format appears correct. A manifest containing input identity, code version and mapping version exposes the discrepancy. The corrected run is linked to the earlier output rather than silently replacing the file and concealing the earlier processing history.
Review checks
- Trace a selected output back to its code and input versions.
- Compare execution parameters with the approved intended use.
- Distinguish failed or partially completed jobs from successful results.
Acceptance and boundaries
Acceptance means an authorised reviewer can explain how a selected output was generated and, when needed, reproduce it in a controlled manner. Recording every environmental detail is unnecessary; select context that can affect the result. File fingerprints do not establish scientific correctness by themselves. Review the script logic and expected results through the relevant verification process as a separate activity.
Frequently asked questions
- Is a code version sufficient?
- No. Identical code can generate different results from different inputs and parameters.
- Does rerunning invalidate an earlier output?
- Determine its status with a documented rationale and preserve the relationship between earlier and revised outputs.