Roles & Responsibilities in EDC

Why this matters

Electronic Data Capture (EDC) reshapes how study data are created, checked, corrected, and locked. Clear role boundaries prevent unauthorized changes, speed query closure, reduce rework, and avoid inspection findings. A shared mental model—who owns entry and correction vs who governs quality—keeps the audit trail clean and the database lock on schedule.

Core concepts & definitions

EDC (Electronic Data Capture) The system where study data are entered, reviewed, queried, and reported—with an audit trail: a secure, computer‑generated, time‑stamped record of who entered or changed each value, when, the old and new values and the reason, which users cannot edit and which never hides the original entry.

Sponsor, CRO & monitor The sponsor stays ultimately responsible for the quality and integrity of the trial data even when it transfers data management, monitoring or safety work to a CRO (contract research organization) under a written agreement such as a statement of work (SOW), and it must oversee that work. The CRA is the sponsor’s monitor in ICH E6(R3) terms.

Site / Investigator & site staff

• Own subject data entry and correction in EDC.
• Respond to queries and document reasons for change.
• Report serious adverse events (SAEs) to the sponsor immediately (usually within 24 hours of learning of them; the protocol sets the timeline) and record them in EDC.
• Maintain source documents (e.g., medical records).
• The principal investigator (PI) stays responsible for the site’s data and delegates data entry and query responses only to trained staff listed on the delegation log (often the study coordinator).
• The PI electronically signs each subject’s casebook (usually before lock) to confirm the data; in most EDC systems a later change breaks the signature, so the PI signs again.

DM (Data Management)

• Designs/specifies edit checks (system rules) and review listings.
• Runs data quality review, opens/manages queries, tracks currency (how up to date data entry is) and cleanliness (how many issues remain open), reconciles external data (e.g., labs, randomization, safety), and documents traceability.
• Does not “fix” clinical data on behalf of sites.

CRA / ClinOps (Clinical Research Associate / Clinical Operations)

• Performs SDV (Source Data Verification): checks EDC entries against source documents, to the extent the monitoring plan sets (under risk‑based monitoring, often focused on critical data).
• Coaches the site on documentation and compliance.
• Monitors site performance and escalates operational risks.

PV / Medical Monitor (Pharmacovigilance / MM) Two sponsor roles, grouped here as the safety lane: PV (drug safety) processes and reports safety cases, and the Medical Monitor is the sponsor physician who oversees subject safety and reviews the data medically.

• Manages safety case intake, medical assessment, and regulatory reporting (e.g., SAEs).
• Reconciles safety database to EDC safety fields.

Biostatistics

• Defines analysis‑critical variables and consistency checks; partners with DM on review outputs and lock readiness.

EDC roles & access (least privilege) Each EDC role gets only the rights the job needs: site staff enter and correct data and answer queries, and the PI signs; CRAs mark data as source‑verified and raise (and close their own) SDV queries; DM raises and closes data queries, freezes clean data (no edits until unfrozen) and locks the database. No sponsor or CRO user role can edit site‑entered data in the EDC (segregation of duties), and accounts are personal (never shared), granted after training and removed promptly when someone changes role or leaves, as 21 CFR Part 11 and EU computerized‑system guidance expect (see Access, Training & Part 11 Basics).

RACI (Responsible–Accountable–Consulted–Informed) A simple way to document who does what. Use it in the DMP (Data Management Plan) and SOW (Statement of Work) to prevent boundary drift.

Boundary rule of thumb: Sites change data; DM changes rules & opens queries; CRA verifies against source; PV/MM own safety; Biostats own analysis requirements. Vendor‑loaded data (e.g., central lab) are corrected by the vendor and re‑sent, and system‑caused errors (e.g., a faulty migration) are usually fixed by a tested, approved data‑correction script, not by hand edits.

The process, step‑by‑step

1. Before first patient in (FPI): set the lanes

   • Map the data flow: capture → validate → query → correct → reconcile → lock.
   • Approve Edit Check Specs and Review Listings (DM with Biostats/ClinOps input).
   • Validate the EDC build before go‑live: DM leads user acceptance testing (UAT), done by testers other than the people who built it, and later changes to forms or checks are re‑tested under change control.
   • Publish a roles/RACI matrix in the DMP (who enters, who corrects, who queries, who escalates).

2. Capture

   • Site enters data from source documents promptly after each visit, within the timeline the study sets (e.g., in the site agreement or eCRF completion guidelines).
   • Access & training: accounts provisioned by role; retraining for role change; timely offboarding.

3. Validate

   • EDC rules fire on entry or nightly (as designed).
   • DM reviews listings (missing, outliers, illogical sequences, protocol windows).

4. Query

   • DM opens clear, non‑leading queries with rationale and requested action.
   • CRA raises queries on discrepancies found during SDV and closes them once resolved; CRA and DM follow agreed query conventions so they do not raise the same query twice.
   • PV/MM may request medical clarification for safety‑relevant items.

5. Correct

   • Site updates EDC and documents reason for change; audit trail captures who/when/what.
   • DM verifies resolution quality and closes queries.

6. Reconcile external data

   • DM reconciles labs, randomization/IXRS (interactive response system), ePRO/eCOA (electronic patient‑reported and other clinical outcome assessments), imaging, safety.
   • DM and PV reconcile safety ↔ EDC together (who leads varies by organization; the DMP names it). EDC discrepancies go to the site as queries, safety database discrepancies are corrected by PV in the safety case, and anything left unresolved is recorded in the sponsor’s decision log.

7. Review & escalate

   • CRA verifies EDC data against source (SDV) and trends site issues; ClinOps escalates persistent noncompliance.
   • DM escalates aging queries, systemic rule gaps, or vendor issues per the DMP.

8. Lock readiness & lock

   • DM confirms reconciliation gates passed, queries closed, SDV complete as the monitoring plan requires, deviations documented, and PI signatures in place;
   • Biostats sign off on analysis‑critical consistency;
   • DM locks the database once the sponsor’s written lock approval is signed, per SOP and DMP; lock removes all edit rights, and any unlock needs documented approval.

Quick RACI snapshot (sample)

Legend: R = Responsible (does the work); A = Accountable (answers for it; one per task); C = Consulted; I = Informed.

What good looks like

• Ownership clarity: Sites own entry & corrections; DM owns rules, tracking, and the query lifecycle.
• High‑quality queries: Clear, specific, non‑leading; reference form/field/date; ask for action + documentation.
• DMP as the source of truth: Edit‑check ownership, reconciliation gates, closure criteria, and escalation triggers are explicit.
• Safety boundaries respected: PV/MM run safety; DM supports with reconciliation and data fitness.
• Metrics & reviews: Currency (e.g., data entry timeliness), cleanliness (open queries per subject), reconciliation status, and lock KPIs are tracked and trended.
• Access hygiene: Provisioning, retraining on role change, and prompt offboarding—logged and auditable.

Worked examples

Self‑contained definitions used below: MACE = Major Adverse Cardiovascular Event. SDV = Source Data Verification. EMR/EHR = Electronic Medical/Health Record. SAE = Serious Adverse Event.

1) Date logic: MACE before randomization (CV trial)

• Scenario: A MACE date in EDC is 02‑Jan, but randomization is 05‑Jan (a MACE counted as a trial endpoint cannot occur before randomization).
• DM: A date‑sequence rule flags it; DM opens a query: “The MACE date (02‑Jan‑20XX) precedes randomization (05‑Jan‑20XX). Please verify and update the MACE date or document if the event occurred before randomization.”
• Site: Reviews source; either corrects the date or, if the event really occurred before randomization, records it where the protocol says (e.g., medical history if before consent, or an AE if within the protocol’s AE collection period), with explanation.
• CRA: Confirms alignment during next SDV.
• PV/MM: If the event is an SAE, confirms case handling and consistency in safety narratives.

Why this is correct: Site performs the change; DM governs via rule/query; CRA verifies with source; PV/MM handle safety impact.

2) Unit mix‑up: Weight entered in pounds instead of kilograms

• Scenario: EDC expects kilograms; site entered “150” assuming pounds.
• DM: Outlier/listing review spots the issue; DM queries requesting confirmation of units and corrected value in kilograms, with reason for change.
• Site: Updates weight to 68.0 kg (with reason: “original entry in lb”) and confirms any downstream derived fields (e.g., BMI) auto‑recalculated.
• CRA: During SDV, checks that scales and unit conventions are documented at site.

Key boundary: DM does not recalc and overwrite; Site corrects and documents.

3) Safety reconciliation: SAE in PV system not reflected in EDC

• Scenario: PV database shows an SAE on 12‑Mar; EDC adverse event page lacks it.
• PV: Flags during safety↔EDC reconciliation and informs DM.
• DM: Opens a site query to confirm capture of the SAE in EDC with matching onset date and seriousness criteria.
• Site: Enters the AE/SAE details in EDC, links to hospitalization if applicable, and responds to the query.
• PV/MM: Confirms both systems now match and that case processing/reporting timelines were met.

Takeaway: PV owns safety; DM facilitates EDC alignment via queries.

4) Medical record as source: EMR vs EDC discrepancy

• Scenario: The site’s EMR sends lab values to the study through an agreed electronic data transfer. The transfer shows creatinine 1.9, while the EDC lab field shows 1.2 for the same visit.
• DM: Creates a query requesting verification of the value and units against source; includes visit/date/context to avoid ambiguity.
• Site: Checks lab report in the medical record and updates EDC or documents the reason (e.g., two samples; one hemolyzed).
• Boundary guardrail: DM does not log into the EMR to change EDC or transcribe values; the site remains the source‑data owner.

5) “Can DM just fix it?” request

• Scenario: Sponsor team asks DM to correct an obvious typo to keep timelines.
• DM response: “Per DMP/RACI, sites own clinical data corrections. We’ll issue a targeted query now and track for rapid closure.”
• Action: DM opens the query; Site corrects; Audit trail stays intact.

Pitfalls & misconceptions

• Anti‑pattern: DM directly changing clinical data “to help the site.” Fix: DM opens a query; site changes with reason for change.
• Misconception: Query quality is a site‑only problem. Fix: DM designs rules, samples closed queries for quality, and tunes wording/rules.
• Anti‑pattern: Duplicative oversight (CRA and DM asking the same thing separately). Fix: Use shared dashboards and agreed query conventions.
• Boundary blur: Treating SAE reporting as a general team task. Fix: PV/MM own safety case processing; DM supports reconciliation, not reporting.
• Access drift: Leaving accounts active after role changes or offboarding. Fix: Enforce provisioning/retraining/offboarding controls; audit periodically.

Practice in the wild (checklist)

• Add a roles/RACI matrix to the DMP for entry, correction, rules, queries, reconciliations, safety, and lock.
• Define who escalates what to whom (site, vendor, internal) and on what timeline (e.g., aging queries).
• Stand up metrics: data entry timeliness, open‑query aging, reconciliation status, rule hit‑rates.
• Sample closed queries monthly for quality (e.g., 5–10%) and tune templates/rules accordingly.
• Validate access hygiene: onboarding, role changes, retraining, offboarding—all logged.
• Rehearse lock readiness: verify recon gates and closure criteria before interim/final locks.

Key points to remember

• Ownership & boundaries: Sites enter and correct clinical data in EDC; the PI delegates these tasks (delegation log), stays responsible for them and signs the casebooks. DM designs edit checks, tracks quality, and manages the query lifecycle. CRA verifies against source (SDV) and coaches sites. PV/MM own SAE intake, medical assessment and regulatory reporting, and reconcile safety↔EDC with DM. Biostats define analysis‑critical checks and co‑sign lock readiness.
• Audit trail discipline: All corrections to site‑entered data are made by the site with a clear reason for change (the exception is a tested, approved data‑correction script for a system‑caused error such as a faulty migration); avoid any “DM fixed it” entries.
• DM’s levers—not data edits: DM improves quality by refining rules/listings and by opening/closing clear, non‑leading queries—DM does not overwrite source‑derived values.
• Complementary oversight: CRA’s SDV and DM’s programmatic/listing review are coordinated and non‑duplicative.
• Reconciliation gates before lock: Labs, randomization/IXRS, ePRO/eCOA (and imaging if applicable), and safety must match across systems; discrepancies are resolved via site queries and documented decisions prior to lock.
• Defined escalation paths: Aging queries, recurring inconsistencies, and vendor issues follow predefined DMP/SOP routes.
• Access & training hygiene: Provision by role with least privilege (personal accounts, trained before access), retrain on role changes, promptly offboard, and keep evidence auditable.
• RACI visible in the DMP/SOW: Make role boundaries and sign‑offs explicit to prevent drift and avoid audit findings.