Verify source data (SDV)

Source Data Verification (SDV) is checking entered data against the site’s source documentation. In X7 Insight, SDV is a status axis of a specific value rather than a separate entity, so the mark is always tied precisely to the value you checked.

Who and when

Monitor — the monitor (CRA). You need the “verify against source” permission (data.sdv.verify) on the site; removing a mark takes data.sdv.unverify. The task comes up on a monitoring visit (on site or remote) and whenever a field returns to the queue after its value is edited.

Before you start

• The design version is published, the site is active and you hold a role on that site.
• The field is saved and is in the verification plan — its SDV status is pending. An empty field cannot be verified: there is nothing to check.
• The area is not under a hard lock. A soft lock does not get in the way of verification.
• You have the site’s source document at hand (medical record, lab sheet).

Steps

1. Open SDV in the study menu and the Pending tab. Narrow the queue with the site filter or by searching for a subject, visit, form or field.

2. Pick an item and check the value against the site’s source document.

3. Click Verify — the field moves from pending to verified, and the queue opens the next item. A mistaken mark can be removed right away with Undo in the notification.

4. If the value differs from the source, do not verify — open a query instead. The field stays pending.

0:000:00

SDV queue: the Pending tab, checking a value against the source, and marking it verified — recorded in the audit trail

Verify in the form

You can also verify on the form page itself: each field has a Verify action (“Verify against source data (SDV)”). At the bottom of the form, Verify all pending marks every pending field of that form after you confirm.

Verify a whole form

When several fields of a form await verification, click Verify all in form in that form’s group header in the queue. This is one act: exactly the values and versions you see are verified — all at once or none. If someone changed a field while you were checking, the act is rejected and nothing is marked. You can undo it right from the notification.

Verify a selection

Tick fields from different forms and click Verify selected (N). Each field is verified and audited separately; at the end you see “Verified N of M”. A bulk action covers only the shown and selected items: the queue loads in pages of 100, so check the loaded-rows counter before confirming.

Remove a verification

If a mark was set by mistake, click Unverify in the queue (or Remove SDV on the field in the form) and give a reason. The field returns to pending. This takes the data.sdv.unverify permission.

Export the verification report

Above the queue are Export (XLSX) and Print (PDF). Both build the report on the server for the selected site and the screen’s other filters; the row search is not included in the file. What the report contains is described under Verification report below. The buttons are available to holders of the export permission (export.run).

What happens

• The field’s SDV axis changes: pending → verified. Other axes (entry, medical review, signature) are untouched: verification does not change values.
• The audit trail records “SDV verified” for each field — with the author and time (UTC); a removal is recorded as “SDV verification removed” with its reason.
• The field leaves the Pending tab; site and study progress in reports is recalculated (“X of Y verified, Z pending”).
• If the coordinator later edits the value, the mark is removed automatically (“SDV reset by edit”) and the field returns to the queue.

If it doesn’t work

• No SDV item or Verify button — you do not hold data.sdv.verify on this site (or a deny applies to that specific field). Contact your access administrator.
• No Unverify button — you do not hold data.sdv.unverify.
• Verification rejected, a new value on screen — the value was changed while you were checking (a version conflict). Check the current value and verify again. When verifying a whole form, no field is marked in this case.
• Refused because of a lock — the area is under a hard lock; SDV is forbidden under it.
• The field does not show up in the queue — it is empty or outside the verification plan (status not required): the form’s SDV mode is set by the design author.
• No export buttons — you do not hold export.run (e.g. a sponsor auditor sees SDV statuses on screen but does not export files).

Next

Manage queriesOpen a query when a value differs from the source.

Track monitoring progressPer-site summary: how much is verified and how much is pending.

Correct a saved valueWhy editing a value resets the SDV verification.

Status lifecycles and axesThe SDV axis and how it reacts to data changes.

More detail

The SDV status axis

Mark	Meaning
not required	The field is outside the SDV scope
pending	Requires checking against source
verified	The value was checked against source

1. not requiredfield in SDV scope
2. pendingchecked against source
3. verified
   • value editedpending

The SDV axis of a value. Editing a verified value synchronously resets it back to pending.

The SDV queue

SDV is the monitor’s workspace: a selection of fields awaiting verification, filterable by site, visit and form. Two tabs:

• Pending — the queue of fields with status pending;
• Verified — the values available to you with their current SDV mark. The full history of verifications and removals is in the audit trail and on the form pages.

The table shows the subject, visit, form, field, value and last-update time. The queue loads in pages of 100 items; Load next page adds another. Search by subject, visit, form and field runs across the whole list available to you, not just the loaded page. Data values are not searched. The tab, site and search are kept in the page link.

Automatic reset on a value edit

This is the most important property of SDV: a verification does not survive a change to the data.

Editing a value removes the verification

As soon as the coordinator changes a value previously marked as verified, the system synchronously returns it from verified to pending. The field resurfaces in SDV for re-checking. This cannot be turned off: “verified” always means “this exact value has been verified”.

The coordinator sees this as early as the edit — the reason for change dialog explicitly warns that the SDV mark will be removed and the monitor will have to re-check the value.

Verification checks a value’s version. If the value changed just before your mark, the system shows the new value and the verification is not applied — you only ever verify current data.

SDV is on by default

Every new form joins the verification plan right away: a form’s default SDV mode is All fields. Narrowing it is a deliberate design decision, made in the builder in the form properties (“Source verification (SDV)”):

Form mode	What is verified
All fields (default)	Every saved value of the form awaits verification
Only marked fields	Only fields marked “Subject to SDV” (a risk-based plan)
No verification	The form is outside the SDV plan

The risk-based approach (ICH E6) here is choosing the mode per form: forms critical for safety and the primary endpoint stay on All fields, others are narrowed to marked fields. If no form of a version is in the plan, the design check warns about it in advance.

If an amendment tightens a form’s mode, previously not-required fields move from not required to pending; already-verified fields are left untouched.

Verification report

Both buttons above the queue build a server-side document for the selected site (and the screen’s other filters):

• XLSX — the first sheet “About this export” (filters, who built the report and when, the cut), then the Summary sheet — per site and form: how many fields await verification, how many are verified and the verified share — and the Fields sheet — every field of the plan: site, subject, visit, form, field, value, SDV status, who verified it and when, when the value changed. Printing in Excel is pre-configured: landscape orientation, the table header repeats on every page.
• PDF — a printable PDF/A copy for a monitoring visit.

A file leaving the system is an export: the buttons are available to holders of the export permission (export.run) — the monitor, the data manager and the investigator. The report includes the rows you are allowed to read. The sponsor auditor sees SDV statuses on screen but does not export files. Blinded values are masked in the report; every build lands in the Exports journal with its checksum, and every download is recorded in the audit trail.

SDV and locks

• Under a soft lock, SDV verification is allowed: the lock freezes values, and verification does not change values.
• Under a hard lock, SDV is forbidden, like any change to the data axes — this is the final state before export.

More in Lock the data.