Turning source verification and clinical queries into one traceable review workflow

Overview

Clinical review isn't finished when a monitor verifies a field. During source data verification a monitor may find a discrepancy, raise a query, wait for the site to respond, inspect a corrected value, re-review the field, and only then close the issue. When SDV and clinical queries are built as separate features, users reconstruct the relationship between the participant, visit, form, field, entered value, source review, query, response, and verification status at every step. I worked across the connected set: partial and 100% SDV, manual clinical queries, notifications, field-level anchor linking, state management, reason capture, and failure recovery.

Where review time went

Review slowed down wherever someone had to rebuild the context around a value

Sessions with clinical operations kept landing on the same shape of problem. To act on a single questionable value a monitor would locate the participant, find the visit, open the right eCRF, identify the question, work out whether it had already been verified, check whether a query already existed, work out whether the data had changed since, contact site staff, and come back later to finish the re-review.

None of that is review. It's the work of finding the thing to review — and it repeated for every issue, in a queue that might run to dozens.

The problem was never one bad screen. It was that every transition — verification to query, query to response, response back to review — could drop the relationship between the issue and the field that caused it.

Experience principles

Every review activity should preserve context instead of forcing users to rebuild it

Five principles came out of the workflow mapping and settled most of the arguments that followed. They are deliberately about the transitions between activities rather than the activities themselves, because that is where the original product lost people.

Source data verification

The same review experience had to support both targeted verification and complete review

Registries don't share one SDV strategy. Some require 100% verification; others use partial, targeted, or risk-based review across selected forms, visits, participants, or fields. One interaction model had to serve both — without ever letting partial review look complete.

The harder problem was state. “Verified” cannot stay final once the underlying data changes, so verification state has to reflect both the review action and the current state of the data.

Role distinction

Monitors and site users worked with the same data but needed fundamentally different controls

A monitor needs a review queue, SDV scope, comparison against source, and the ability to flag — read-only by default, so verified data isn't edited by accident. A site user needs to enter and update data, understand what a query is asking, and respond safely — seeing review state without monitor-only controls.

Same patient, same visit, same form, same field. Different job entirely.

Audit trail

Every change to verified data had to explain itself before it was allowed

In a regulated registry, the record of why something changed matters as much as the change. Unchecking a verification and editing a field that was already verified are both consequential, so neither happens silently.

The pattern is the same in both cases: state the consequence, require a reason, then write it to a log that can be read later by someone who wasn't there.

Requiring a reason per affected field rather than one acknowledgement for the whole save is the detail that matters. A single "this will remove SDV status" message tells someone that something is about to happen; itemising it tells them exactly what, and makes the reason they give specific to it.

Query lifecycle

Status had to answer who acts next, not whether a message exists

The state model is where most of the design work went, because the useful question is never "is there a query?" It is "does this need me, and if not, who is it waiting on?"

So the badge in a field's query list carries the responsible role — Monitor or Site-user — rather than an abstract status name, and reads Closed only when nothing is owed by anyone. Ownership is the primary signal; lifecycle position is derived from it.

Site-user response

Answering a query often meant changing data, which made the response a consequential action

A site user can reply in three ways: correct the value, explain why the existing value is right, or do both. The third is the common case and the one that needed care, because a reply that changes previously verified data is two operations wearing one button.

So the response path surfaces the consequence — old value, new value, the verification it invalidates, the reason required — before the answer submits, and then routes the query back to the monitor with the data change attached to it rather than floating separately in the audit log.

Queries at rest

The absence of a query is information too, and it had to be stated rather than implied

Most fields, most of the time, have no query on them. An empty cell in a query column is ambiguous — it could mean no issue, or it could mean the column hasn't loaded, or that this user can't see queries at all. Each of those needs a different response from the reader.

Naming the empty state removes the ambiguity at the cost of a little visual noise, which in a regulated review context is the right trade.

Naming the empty state costs a little visual noise. In a context where a blank cell might mean no issue, no permission, or no data loaded, that is the right trade.

Notifications

A notification had to say enough to be actionable and no more than that

Notifications are the entry point into most review work, which makes them a privacy surface as much as a navigation one. They carry the patient identifier, visit, form, priority, and status — enough for someone to judge urgency and sequence their day — while name, date of birth, and contact details stay out of the payload entirely.

Separating clinical queries from site operational actions in the notification surface matters more than it sounds. They are different jobs on different clocks, and a single merged list means the urgent clinical item competes with routine account housekeeping.

Anchor linking

Field-level anchor links removed the search work between a notification and the affected data

Before: notification → registry → patient → visit → form → section → field → review. Seven steps, six of them clerical, repeated for every item in a queue that might run to dozens.

After: notification → the exact field, highlighted, with the query open beside it. One authenticated click.

That compression is the single largest efficiency change in the project, and it is also why anchor linking was the hardest interaction problem in it. The link sits at the intersection of navigation, permissions, privacy, and state: it has to resolve six levels of hierarchy, check authorization before it reveals that a patient exists, keep PHI out of the URL, and still land somewhere useful when the world has moved on since the notification was sent.

Failure states

A verification that silently fails to save is worse than one that never happened

Per-field verification autosaves, which means the failure modes are per-field too. A monitor working through a form can't be left believing a check landed when it didn't — that is how a record ends up marked verified in someone's memory and unverified in the database.

Each failure names the specific field it affected, distinguishes a recoverable problem from a system-level one, and gives a next action rather than an apology.

Reflection

Outcome