SDV, data review, coding, and signatures

Review status

Included in the proposed model: Review Plan Version, Review Plan Assignment, Review Requirement, SDV Evidence, Data-Management Review Evidence, Coding Configuration Version, Coding Request, Coding Decision, Coding Review, Signature Plan Version, Signature Requirement, and Investigator Signature.

Settled proposal: these activities share audit needs but not one generic lifecycle or one overwritten status flag.

Open: review granularity, material-change rules, coding approval policy, and exact signature milestones.

Four different clinical questions

Activity	Question answered
Source Data Verification (SDV)	Was the reported value checked against its identified source record?
Data-Management Review (DMR)	Was the data reviewed for completeness, consistency, and clinical/logical quality under the data-management plan?
Medical Coding	Which controlled dictionary term represents the site’s verbatim report?
Investigator Signature	Does the investigator endorse the specified reported data under the stated attestation?

Completion of one never implies completion of another.

Plan ownership and versioning

Review plans, coding configurations, and signature plans belong to the EDC work area that applies them. They can be revised operationally without pretending that the published CRF design changed.

Plan	Responsible work area	Version and assignment rule
SDV/DMR Plan	Data Review	Approved plan versions; effective-dated assignment to study/site/casebook, with exact prior assignment retained
Coding Configuration	Medical Coding	Approved configuration versions; form/item assignment states dictionary release and effective time
Signature Plan	Investigator Endorsement	Approved statement/scope versions; effective-dated assignment creates subject-level Signature Requirements

The initial Design Publication records the intended starting versions. A later plan change creates a new plan version and assignment, then assesses existing requirements/evidence. It never edits the published collection design or silently changes completed work.

Review Plan and Review Requirement

A Review Plan Version defines selection policy and retains plan number, predecessor, effective reason, author, approval, and date. A Review Plan Assignment identifies the study/site/casebooks to which that exact version applies and its effective time.

• review type: SDV or DMR;
• subject/site sampling method;
• critical forms/items requiring 100% review;
• percentage or targeted selection;
• risk-based override rules;
• effective version and assignment; and
• reassessment behavior when the plan changes.

A Review Requirement is the resulting expectation for a particular item, form, event, or subject: required, optional, or not required, with the plan/rule that produced it.

The requirement is not completion evidence. Historical review remains visible if a later plan makes the data not required.

Source Data Verification evidence

Field	Meaning
Subject and clinical scope	Item, row, form, or other approved exact level reviewed
Exact datapoint revision	The reported data actually compared with source
Source type/location	Source described in the study source-data plan
Reviewer	Authorized monitor or other delegated reviewer
Review time	When comparison occurred
Outcome	Verified, discrepancy found, source unavailable, not verified
Related query	Conversation opened to resolve a discrepancy
Supersession	Later value/design change affecting the evidence

SDV should usually bind to exact datapoint revisions even when the user performs it from a form- level action. The form status is a roll-up of item-level evidence and requirements.

Data-Management Review evidence

Field	Meaning
Review scope	Exact form revision set, listing row, subject area, or other approved exact level reviewed
Review objective	Completeness, cross-form consistency, safety review, endpoint review, or other named objective
Reviewer and role	Accountable clinical data-management person
Review time	When review was completed
Outcome	Reviewed, known discrepancy, requires action
Queries/findings	Issues raised or accepted
Current-data indicator	Whether reviewed data later changed
Supersession/dismissal reason	Deliberate disposition of later change

“Reviewed with known discrepancy” is different from “clean.” Any accepted discrepancy retains its rationale and authority.

Review changes

When data change after review, the product records which evidence is affected. Study policy may:

• require complete re-review;
• flag the review as “reviewed data changed” pending assessment;
• retain review when the change is declared immaterial; or
• supersede the prior evidence and require new evidence.

The policy must be explicit by review type and change class. EDC must not simply clear every checkmark.

Medical Coding

Coding Configuration

• source verbatim item;
• related context items, such as indication, route, seriousness, dose form, or country;
• dictionary type and exact release;
• coding hierarchy/levels to retain;
• synonym and autocoding policy;
• approval workflow policy;
• site-query policy; and
• effective study/design version.

Coding Request

Field	Meaning
Source datapoint revision	Exact verbatim being coded
Context revisions	Indication, route, and other values used in the decision
Dictionary release	Exact controlled dictionary searched
Request status	Open, awaiting clarification, ready for coding, completed, cancelled, superseded
Suggestions	Matches offered, source, rank, and time
Assigned result	Complete selected code hierarchy and primary path where applicable
Query status	Clarification requested from site, if any

Separate coding lifecycles

Coding Request
Open → Awaiting clarification → Ready for coding → Completed
Open/Ready → Cancelled
Completed → Superseded when source/context changes

Coding Decision
Proposed by coder/autocoding → Assigned
Assigned → Superseded or Withdrawn; prior decision remains in history

Coding Review, when required
Pending → Approved
Pending → Rejected → new Coding Decision proposed

Dictionary-change assessment
Pending → Confirmed current OR Remapped OR Needs recoding / Noncurrent

The site’s verbatim is never overwritten by the coded term. Both are delivered with their origin and history.

Coding Decision and Review

Each decision is a retained record containing selected term/code hierarchy, dictionary/release, manual or automatic origin, coder, time, rationale/notes, source revisions, and any synonym used or proposed.

If approval is required, Coding Review separately retains reviewer, outcome, time, rejection reason, and the exact decision reviewed.

Investigator Signature

Signature Plan and Signature Requirement

The study decides:

• signable level: form, visit/event, casebook, or study milestone;
• milestone and frequency;
• exact attestation wording and version;
• included forms/data;
• deliberately excluded blinded or administrative data;
• prerequisites; and
• what changes require re-signature.

The Signature Plan is versioned and approved. Applying it creates a Signature Requirement for each subject scope and milestone that must be tracked.

Signature Requirement field	Meaning
Plan version and assignment	Exact rule and attestation governing the requirement
Subject and signable scope	Form, visit/event, casebook, or milestone requiring endorsement
Due condition/time	When signature becomes expected
Readiness	Required forms submitted and other prerequisites satisfied
Current state	Not due, due, ready to sign, signed, needs re-signature, waived by exception
Current signature	Exact Investigator Signature satisfying it
Waiver/exception	Authority, reason, evidence and time when permitted

A Signature Requirement can exist before a signature. The signature is evidence that satisfies one exact requirement; it is not itself the planning record.

Signature evidence

Field	Meaning
Signer	Authenticated investigator and accountable role at the site
Subject and scope	Exact form/event/casebook being endorsed
Covered-data inventory	Exact submitted revisions covered by the signature
Attestation	Text and version presented to the signer
Signature time	Unambiguous date/time
Authentication evidence	Evidence required by applicable electronic-signature controls
Exclusions	Data deliberately not presented or not included
Supersession	Later relevant change and resulting re-signature need

A signature is not a mutable signed flag. It is retained evidence binding signer, statement, scope, and exact reported data.

Actions

• Assign or override an SDV/DMR plan.
• Mark exact data as source verified.
• Record a source discrepancy and open a query.
• Complete data-management review.
• Record or dismiss a changed-after-review indicator with reason.
• Create a coding request from a submitted verbatim.
• Assign, remove, approve, reject, remap, or re-review a code.
• Query the site for coding clarification.
• Sign an eligible form/event/casebook.
• Create or reassess Signature Requirements when a plan, subject milestone, data, or design changes.
• Supersede prior signature evidence after relevant change.
• Re-sign the corrected scope.

Business rules

1. Review selection and review completion are separate records.
2. SDV binds to the reported revision actually compared with source.
3. DMR identifies its objective and exact reviewed scope.
4. A data change never makes historical review disappear.
5. Review roll-ups are calculated views, not authoritative evidence.
6. A coding request records the exact verbatim, context, and dictionary release.
7. Coding does not alter the site-reported verbatim.
8. Source/context change requires coding reassessment.
9. Dictionary change either preserves a traceable remap or produces a noncurrent/needs-review state.
10. A signature requires eligible submitted data and signer authority at the signing time.
11. Signature evidence records exact attestation wording and covered data.
12. A relevant post-signature correction supersedes the prior signature for that scope and may require re-signature.
13. Data deliberately masked from the investigator are declared in the signature plan and evidence.
14. Coding Request, Coding Decision, Coding Review, and dictionary-change assessment keep separate status histories.
15. Every expected investigator signature is represented by a Signature Requirement before or when it becomes due.
16. Plan version changes create new assignments and reassess requirements; they do not rewrite prior completed evidence.

Exceptions

• A serious adverse event triggers 100% SDV despite ordinary sampling.
• A value changes after SDV but the form-level status still appears complete.
• A reviewed listing row changes because one external laboratory value was corrected.
• A known discrepancy is accepted for lock with documented rationale.
• An autocoded term requires approval in one study but not another.
• A coding verbatim stays the same while indication changes.
• A dictionary up-version cannot uniquely remap an approved code.
• A signed form changes because an amendment adds a new required item.
• A blinded result must be excluded from investigator view and signature.
• A subinvestigator entered data, but the PI signs the subject casebook.

Handoffs

• Site/source documents remain controlled by the investigator/institution.
• Monitoring plans inform review selection; EDC owns its review requirements and evidence.
• Dictionary authorities publish terminology releases; EDC owns study coding configuration and decisions.
• Platform supplies authenticated principal and signature-evidence mechanisms; EDC owns what the clinical signature means.