Correct a saved value

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 (RfC): the audit trail has to answer not only “what changed and when”, but also why.

Who and when

Coordinator — the site coordinator. You need the permission to edit a saved value (data.update) — it is separate from the initial-entry permission (data.enter). The task comes up when a transcription error is found, new data arrives from source documents, or the monitor raises a query on the value.

Before you start

• The form is not under a lock.
• You know why you are changing the value: you will pick the reason from a catalog.
• If the field is already verified by the monitor or a signature covers the form, remember that the edit resets those marks (see What happens).

Steps

1. Open the form and change the value in a field that already held data — or clear it, or mark it “not done” / “unavailable”.

2. Save. The Reason for Change dialog opens: it shows the Previous value and the New value, plus warnings if the field is source-verified (SDV) or a signature covers the form.

3. Choose a Reason from the catalog. By default these are “Data entry error”, “Correction per source document”, “New information received”, “Correction per monitor’s query” and “Other (specify)” — the last opens a free-text field.

4. If you will make several edits in a row for the same reason, tick Apply this reason to edits for the rest of this session — further saves then show “Saved · reason: …” with a Change link.

5. Click Confirm. Cancel returns the field to the saved value.

0:000:00

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

What happens

• The previous value does not disappear — it stays in the field history and in the audit trail together with the new value, the author, the time (UTC) and the reason given. The catalog reason code (or your text for “Other”) is what goes to the log, so edits can be grouped by reason regardless of the interface language.
• In the same operation, marks that no longer match the new value are reset:

Axis	Before	After the edit
SDV (verification)	verified	pending
Medical review	Reviewed	Not reviewed
Form	Complete	In progress
Signature	Valid	Invalidated

• The field reappears in the monitor’s SDV queue and in the medical review Inbox; the form returns to the signature queue once you mark it complete again.
• If the edit removed a check violation, the related automatic query closes by itself; if the edit violated another check, a new query opens.

If it doesn’t work

• The save does not go through without a reason (422) — a reason is mandatory for any edit of a saved value. Choose one in the dialog.
• The field cannot be edited — you lack data.update, the form is locked (“The form is locked — data changes are not possible”), or the field is auto-filled (edit its source fields).
• The “Version conflict” dialog opened — someone else has just changed the value. Compare “You entered” with “Now in the database” and decide which value to keep; overwriting also requires a reason.
• No suitable reason in the list — choose “Other (specify)” and describe it in your own words. The reason set is an organisation or study setting (“Administration → Settings”), not part of the design version; an administrator changes it.

Next

Answer a queryAnswer with text or fix the value right from the query thread.

Enter data in a formInitial entry, “not done” marks, keyboard entry.

Verify source data (SDV)How the monitor verifies data and how an edit resets SDV.

Sign dataSignature coverage and its automatic invalidation.

More detail

When the dialog appears

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

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

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

Resetting SDV verification

If the field has already been checked by the monitor against source documents, the dialog warns plainly: “Saving will clear that verification, and the monitor will have to re-verify the value.” The value changed — so what needs checking against the source changed too.

Editing a verified value clears 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 queue. This cannot be switched off — it guarantees 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 whose signature the edit removes and from how many forms (“Saving will remove …’s signature from this form”). A signature covers the data snapshot at the moment it was applied — by changing covered data you make the snapshot invalid.

Changing covered data invalidates the signature

The signature is not deleted — it stays in history forever, but is marked invalidated, and the form returns to the re-signing queue. There is no partial signature: editing one field invalidates the whole signature that covered the snapshot. More in Sign data.

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 editing, not a separate screen or an after-the-fact question. It should not break data entry.
• Marks do not outlive their data. Verification, medical review and the signature make sense only for a specific value. By resetting them automatically, the system keeps “verified” and “signed” data from silently drifting away from reality.
• A complete trail. The “before → after” pair + reason + author + time makes every edit explainable during monitoring and inspection.

A summary of status axes and their mutual reactions is in the Status reference.