Reason for Change

Initial value entry is free — enter and save. But as soon as you change an already-saved value, X7 Insight asks for a reason for change (Reason for Change, RfC). This is part of the data-integrity requirements: the audit trail must answer not only “what and when changed”, but also why.

0:000:00

Editing a saved value: the Reason-for-Change dialog and picking a reason from the catalog

When the dialog appears

The “Reason for Change” dialog opens on any edit of a value that has already been saved:

• changing a field value to a new one;
• clearing a value;
• marking a previously filled field as “Not done” or “Unavailable”.

Initial entry (from the Empty state) does not require a reason.

1. Change a value in a field that already held data.

2. The dialog shows Previous value → New value.

3. Pick a Reason from the catalog. By default these are “Data entry error”, “Correction per source document”, “New information received”, “Correction in response to a query” and “Other (specify)” — the last opens a free-text field. The reason set is an organization- or study-level setting (Admin → Settings), not part of the design version.

4. Click Confirm. Saving is impossible without a chosen reason; cancelling returns the field to the saved value.

Note

The previous value does not disappear anywhere — it stays in the field’s history and in the audit trail together with the new value, the author, the time (UTC) and the given reason. Data in X7 Insight is never silently overwritten.

What happens to the other status axes

A value has several independent status axes. Editing the data synchronously, in the same operation, resets the “derived” marks that no longer match the new value. The order of reactions is fixed:

Axis	Was	Becomes after the edit
SDV (verification)	verified	pending
Medical review	Reviewed	Not reviewed
Form	Complete	In progress
Signature	valid	invalidated

Resetting SDV verification

If a field has already been verified by the monitor against source documents, the dialog warns directly: after saving, the SDV mark is removed and the monitor will have to verify the value again. The value changed — so what needs to be checked against the source changed too.

Editing a verified value removes the verification

SDV verification is tied to a specific value. Any change returns the field from “verified” to “pending” and flags it for re-verification in the SDV Workbench. This cannot be turned off — this is how it is guaranteed that “verified” always means “this exact value was verified”.

Invalidating the electronic signature

If a valid electronic signature covers the form (or its visit, or the whole casebook), the dialog warns: saving invalidates the signature. A signature covers a snapshot of the data at the moment it was applied — by changing the covered data, you make the snapshot invalid.

Changing covered data invalidates the signature

The signature is not deleted — it stays in the history forever, but is marked invalidated, and the form returns to the re-signing queue. There is no such thing as a partial signature: editing a single field invalidates the entire signature that covered the snapshot. More detail — Electronic signatures.

Why it is designed this way

• The reason is part of the flow, not a barrier. RfC is a short step right at the moment of the edit, not a separate screen and not an after-the-fact question. It must not break up the entry.
• Marks do not outlive their data. Verification, medical review and the signature only make sense for a specific value. By resetting them automatically, the system keeps “verified” and “signed” data from silently drifting apart from reality.
• A complete trail. The “before → after” pair + the reason + the author + the time make every edit explainable during monitoring and inspection.

Entering data in a formInitial entry, the 'not done' marks, keyboard entry.

Source Data VerificationHow the monitor verifies data and how an edit resets SDV.

Electronic signaturesSignature coverage and its automatic invalidation.

Status lifecyclesAll the status axes and their mutual reactions to data change.