Why this matters
Regulators expect the data used for analysis to faithfully reflect what was recorded on the study CRF or in source records.
- In paper workflows, data‑entry staff at the sponsor or its contract research organization (CRO) transcribe from paper CRFs into a database, and correct their own keying errors. Any mismatch is usually a transcription error and is counted as an audit finding, unless the CRF Completion Guidelines (CCG) say otherwise (for example, if rounding or unit conversion is required).
- In EDC workflows, the EDC screens are the CRF. You must rely on the audit trail (who changed what, when, and why) and field‑level provenance (manual entry, imported, or derived) to explain differences and justify changes. There is no transcription step, so the audit checks what happens after entry: changes, imports, derivations and the export used for analysis.
This audit starts from the CRF. Checking the CRF against the site’s source records is source data verification (SDV), the task of the monitor (clinical research associate, CRA).
Well‑run CRF↔DB audits catch errors early, protect primary/secondary endpoints, and reduce lock stress.
Core concepts & definitions
CRF (Case Report Form): The official form used to collect study data. Paper CRFs are handwritten/typed forms; EDC CRFs are electronic forms in the EDC system.
CCG (CRF Completion Guidelines): The “rulebook” for how each field must be completed (allowed values, rounding, units, date formats, “unknown/NA” conventions, etc.). If the CCG allows a difference, it is not a finding. Judge each entry against the CCG version in force when it was made.
Database of record: The study database that holds the values used for listings, reconciliation, and analysis.
Audit trail: A secure, computer‑generated log that records every entry and change with user (who), action (what: old and new value), timestamp (when), and reason (why). Users cannot edit it, and the original value stays visible. EDC systems and paper‑study databases both keep one.
Field‑level provenance: The source of a value (e.g., manual entry, system‑derived, imported from a lab/eCOA/device).
Severity: The impact classification of a finding:
- Critical: Affects participant safety, primary endpoints, or regulatory compliance.
- Major: Could affect secondary endpoints, key analyses, or data integrity.
- Minor: Cosmetic or low risk to integrity (formatting, display, spelling).
RCA (Root Cause Analysis): A brief, structured explanation of why the error occurred.
CAPA (Corrective and Preventive Actions): Immediate fix (corrective) and the change that prevents recurrence (preventive), with an owner and due date.
Tolerance rules: Explicit allowances from the CCG (e.g., “round temperature to nearest whole number,” “convert pounds to kilograms”). These rules must be cited when you accept differences.
The process, step-by-step
Define scope and risk focus Select domains, sites, time window, and sample size. Prioritize safety variables and endpoint fields. Note whether the study is paper, EDC, or hybrid. A common design checks all critical fields (safety, primary endpoint) and a documented sample of the rest. Record the sampling rationale and the acceptable error rate in the audit plan; the checker should not be the person who entered the data.
Collect governing documents Obtain the protocol, CCG, relevant SOPs, and any amendments affecting entry rules.
Assemble evidence
- Paper: Scanned CRF pages or certified copies (copies verified as exact reproductions of the original).
- EDC: Field values plus audit trail extracts and any import logs (e.g., central lab).
- All: If a value is derived, capture the derivation rule and display vs storage rules from specs.
Build the comparison list Create a checklist or mapping of CRF field → database field for each item under review. Include the CCG clause that governs each field’s behavior.
Compare and classify For each item:
- Decide if there is a discrepancy.
- Check the CCG for an allowed difference (rounding, conversion, display vs storage).
- For EDC, review audit trail and provenance to see if the story is complete (who/what/when/why).
Determine severity and ownership Judge impact (critical/major/minor). Assign the owner, the party whose step caused the difference (site, data‑entry team, Data Management, vendor, EDC build team).
Open actions
- Corrective: The data’s owner makes the fix. Paper: the data‑entry team corrects its own keying error to match the CRF; a wrong or unclear CRF entry is queried to the site. EDC: the site corrects after a query, with a reason for change; Data Management does not edit site data. Vendors correct and re‑send. A mapping or system error is fixed at its cause, with a tested, approved data‑correction script for the values it damaged. An audit trail entry is never edited: a missing reason is supplied in a new, documented entry.
- Preventive: Update CCG text, add a data validation rule (edit check), refine import mapping, or schedule training.
Document the finding Log the evidence (page or screenshot IDs), RCA, severity, owner, CAPA, and due date. Give it a tracking ID.
Trend and verify effectiveness Report the error rate (errors found ÷ fields checked; e.g., 6 errors in 2,400 fields = 0.25%) against the limit in the audit plan; above it, widen the sample and look for the cause. Track recurrence rates by site/field/vendor. After CAPA due dates, re‑sample to confirm the problem resolved.
Close and archive Close findings when evidence shows the corrective fix is applied and the preventive control is in place. Archive the evidence packet.
What good looks like
Paper study
- A side‑by‑side list of CRF fields and DB fields with CCG clause references.
- Clear rule for each tolerance (e.g., “round heart rate to nearest whole number”).
- A findings log that links each discrepancy to its scanned CRF page and assigns severity, owner, RCA, CAPA, and closure date.
EDC study
- Audit trail extracts that show complete who/what/when/why for every corrected value.
- Provenance visible on listings (manual/import/derived) so reviewers know which evidence to pull.
- Effective rules: If a mismatch keeps recurring, a validation rule or workflow change is in place—not just repeated manual queries.
All studies
- Evidence packets attached to each finding (scans, screenshots, import logs, derivation rule).
- Trend views: error rates by site/field and before/after CAPA.
Worked examples
Each example is self‑contained and expands abbreviations on first use.
Example 1 — Paper CRF blood pressure mismatch (safety variable)
Scenario: On the paper Case Report Form (CRF), systolic blood pressure is 162. In the study database it is 126. The CRF Completion Guidelines (CCG) do not allow rounding for blood pressure.
Assessment: This is a discrepancy with potential safety impact (misclassification of hypertension).
Evidence: Scanned CRF page; screenshot of database listing.
Finding: Major (escalate to Critical if linked to eligibility or safety stopping rules).
Actions:
- Corrective: The CRF is legible, so the data‑entry team corrects the database to 162 with an audit trail reason “Correcting transcription error from CRF page X.” Query the site only if the CRF entry itself is illegible or doubtful.
- Preventive: Retrain the data‑entry staff on high‑risk fields; use double data entry for them (two people key the same page independently and the system flags any difference).
Closure: Re‑sample 10 CRFs keyed after the retraining; no repeats found → close.
Example 2 — Paper CRF “unknown” handling vs database blanks
Scenario: The CCG states: “If a value is unknown, leave blank and tick Unknown checkbox.” The database shows entries with the number 999 in the value field and the checkbox not ticked.
Assessment: Process non‑compliance; 999 is not allowed by the CCG.
Evidence: CRF page, data extract showing “999,” CCG clause.
Finding: Major (affects consistency and downstream derivations).
Actions:
- Corrective: Look at the CRF first. If it is blank with Unknown ticked, “999” is a keying error: the data‑entry team corrects the database, with an audit trail reason. If the site wrote “999” on the CRF, query the site: the site corrects the CRF entry, and the database is then updated from that correction. Data Management never changes what the site recorded.
- Preventive: Update the data entry form to block “999”; send a CCG clarification to all sites.
Example 3 — EDC change with weak reason code
Scenario: In the Electronic Data Capture (EDC) system, a lab value was changed from 12.0 to 21.0. The audit trail shows user, date, and reason “data corrected,” with no detail.
Assessment: The EDC is the CRF; a change is allowed only if the audit trail explains why. “Data corrected” is insufficient.
Evidence: Audit trail extract; site email explaining the lab revised the report.
Finding: Minor to Major depending on variable criticality.
Actions:
- Corrective: Query the site. The original audit trail entry cannot be edited, so the site gives the full reason in its query response, which is itself audit‑trailed: “Corrected per updated lab report dated DD‑MMM‑YYYY; corrected report filed with the source documents.”
- Preventive: Update the reason code list and user training to require specific justifications.
Example 4 — Imported central lab value overwriting manual entry
Scenario: Hematology results are imported nightly from a central lab. A site manually entered hemoglobin to 11.5; the next day the import set the same field to 11.2.
Assessment: This is a provenance issue. The CCG says central lab is the preferred source; imported values supersede manual ones if the sample IDs match.
Evidence: Import log showing sample ID match; audit trail indicating overwrite.
Finding: No finding for the overwrite if the specs define the field as central‑lab‑sourced, with the mapping and overwrite rule referenced in the CCG, and the audit trail still shows the site’s 11.5 and marks the change as an import. The import is a specified system step, not a sponsor edit of site data. Still query the site about where 11.5 came from.
Actions:
- Preventive: Ensure the listing clearly displays provenance and the overwrite rule; teach sites to avoid duplicate manual entry for central lab tests.
Example 5 — Derived value rounding mismatch (display vs storage)
Scenario: Body Mass Index (BMI) is a derived field. The screen displays 23.5, while the export shows 23.46. The data specification, which the CCG refers to, states, “Store two decimals; display one decimal.”
Assessment: The behavior matches the written rule (23.46 shown to one decimal is 23.5); this is not a discrepancy.
Evidence: Derivation and display/storage rules in the CCG or data specs.
Actions:
- Preventive: Add a note in the data transfer specification so statisticians expect this difference.
Pitfalls & misconceptions
- Judging an entry difference from the protocol text. The protocol says what is collected; for how it is entered, the CCG governs. The CCG must never contradict the protocol: if the two conflict, escalate and get the CCG corrected instead of picking one. Align protocol changes with prompt CCG updates.
- Accepting “looks plausible.” If the database differs from the source/CRF, you need a rule (CCG) or evidence (audit trail), not intuition.
- Generic audit trail reasons. “Corrected” or “data entry error” without context is weak documentation.
- Ignoring provenance. Treat manual, imported, and derived values differently during review.
- Uncontrolled placeholders. Values like 999/000 or “TBD” spread silently unless blocked by edit checks.
- Mismatch between display and storage. If not written in the CCG/specs, expect findings.
- Recurring issues without CAPA. Repeating the same query is not prevention.
- Late reconciliation. Leaving CRF↔DB checks until lock creates avoidable critical findings.
Practice in the wild (checklist)
- State scope and risk (domains, sites, period, endpoints).
- Pull CCG, SOPs, amendments; highlight the clauses you’ll cite.
- Prepare CRF→DB mapping with the governing CCG text per field.
- Gather evidence: scans (paper), audit trails and import logs (EDC), derivation rules.
- Compare values and decide discrepancy vs allowed (per CCG/specs).
- Record severity, owner, RCA, and open corrective actions.
- Propose preventive controls (rule, training, mapping, CCG update).
- Attach an evidence packet to each finding.
- Trend by site/field and verify CAPA effectiveness with a re‑sample.
- Close and archive with clear linkage to all artifacts.
Key points to remember
- Paper studies: The database must match the CRF exactly unless the CCG explicitly permits a difference (e.g., rounding, unit conversion, display vs storage). Any other mismatch is an audit finding.
- EDC studies: The EDC is the CRF—every change must be supported by a complete audit trail (who/what/when/why). Use field‑level provenance (manual/import/derived) and defined overwrite rules to justify the final value.
- CCG governs decisions: Always cite the CCG clause when accepting a difference. Update the CCG promptly when protocol or process changes affect entry or display behavior.
- Evidence packets are mandatory: For each discrepancy, retain the CRF scan or screenshot, relevant audit trail/import logs, derivation rule, and the CRF→DB mapping that shows the governing text.
- Classify and assign ownership: Determine severity (Critical/Major/Minor), name an owner, document a concise RCA, and define CAPA with a due date. The owner makes the fix (site, data‑entry team or vendor); an audit trail entry is never edited.
- Prevent recurrence systemically: Prefer edit checks, mapping fixes, provenance/overwrite rules, and CCG updates over repeated manual queries.
- Control placeholders and precision: Block unapproved sentinel values (e.g., 999/000). Specify and enforce display vs storage precision so apparent mismatches are expected, not findings.
- Reconcile early and trend: Don’t wait for lock—trend issues by site/field/vendor, monitor recurrence, and re‑sample to verify CAPA effectiveness before closure.
- Close and archive with traceability: Close only when the corrective fix is applied and the preventive control is verified; archive a complete, linkable evidence packet for each closed item.