
- Published
- Updated
A system can run the correct software version and still behave differently because a setting changed. Checking the version number alone does not demonstrate that the study’s accepted configuration remains in use.
Preserve the meaning of data
Select critical configuration items according to intended use. Calculations, required fields, notification recipients and interface destinations carry different risks. Define how the approved baseline is recognised and how changes are accepted. Provide an understandable comparison with the running state without copying unnecessary secret values into the review evidence or configuration record.
Worked example
For example, an administrator changes a safety-notification list during maintenance while the software version stays unchanged. One expected recipient receives no messages. The team compares settings with the accepted baseline, identifies change authority and the affected period, and reconciles missed notifications separately. Merely restoring the old setting does not resolve every consequence.
Review checks
- Define the approved baseline and owner for critical settings.
- Compare running settings through periodic or event-triggered authorised review.
- Track the effect of differences on data and notifications separately.
Acceptance and boundaries
Acceptance means differences are recognised and each change has an explainable authorised decision. Every setting need not be checked at the same frequency; consider likelihood of change and study impact. If the baseline itself is obsolete, simply returning to the old setting may be inappropriate. Reagree expected behaviour and document the trusted state before closing the issue.
Frequently asked questions
- Does the same version mean the same behaviour?
- No. Configuration changes can alter outputs or recipients without changing the code version.
- Is every difference a defect?
- A difference may be an authorised, assessed change. Its rationale, approval and effect should remain explainable.