ALCOA+ Data Integrity in Clinical Trials: A Practical Checklist for Sponsors, CROs, and Sites

Applying ALCOA+ across real trial data sources (not just EDC)

ALCOA+ is easiest to discuss in theory and hardest to implement across the many systems and data pathways in modern trials. A practical approach is to map ALCOA+ attributes to each major data source and define the controls and evidence you expect.

This section is operational guidance only and not legal advice.

Data-source mapping (examples)

• EDC: audit trails for data entry/changes; user access reviews; query history; role segregation.
• ePRO/eCOA: timestamp integrity; device provisioning logs; missingness handling; export traceability (see DCT Compliance).
• Central lab: chain of custody; reference range versioning; result transmission logs; reconciliation of critical values.
• Imaging/core lab: image acquisition metadata; reader blinding controls; adjudication logs.
• Safety database: case audit trails; submission acknowledgements; reconciliation logs (see PV & Safety Reporting).
• eTMF: document version control; access controls; replacement/deletion audit trails (see TMF/eTMF Excellence).

Where systems are vendor-managed SaaS, ensure your assurance approach includes supplier controls and change management evidence (see CSV vs CSA and Vendor Oversight).

Preventive controls: the “minimum viable” data integrity system

Data integrity is largely a set of preventive controls that reduce the opportunity for error and make detection easier when errors occur.

1) Access controls and periodic review

• Define role-based access aligned to responsibilities
• Document user provisioning and offboarding timelines
• Perform periodic access review for critical systems (EDC, safety DB, eTMF, ePRO portals)
• Investigate shared accounts or anomalous access patterns

2) Audit trail review: when and how

Audit trails exist to make changes transparent. Define when audit trail review is performed and how results are documented. Consider:

• Triggered review for unusual patterns (late bulk edits, repeated back-dating, high change rates)
• Periodic sampling for high-risk sites or high-risk data
• Documented outcomes and escalation to CAPA when needed (see Protocol Deviations and CAPA)

3) Training and behavioral controls

• Train on contemporaneous documentation expectations and why they matter
• Use job aids for complex workflows (e.g., DCT device troubleshooting, consent steps)
• Reinforce escalation for mistakes (encourage correction with audit trail, not concealment)

Data review lifecycle: who reviews what, and how it is evidenced

A common finding pattern is “reviews occurred informally but cannot be evidenced.” Define a review lifecycle and document it with consistent artifacts.

Role-based review model (example)

• Sites: contemporaneous source documentation; timely EDC entry; response to queries.
• Monitors/CRAs: source data review per monitoring plan; verification of consent and eligibility; documentation of findings.
• Central monitors: data trend review; KRI monitoring; issue escalation (see RBM That Works).
• Data management: edit checks, query management, reconciliation with vendors.

Artifacts to retain (examples)

• Central review notes and issue logs
• Monitoring visit reports and follow-up letters
• Reconciliation logs (lab, safety, ePRO)
• CAPA records and effectiveness checks

Common data integrity findings (and preventive countermeasures)

Use the table below as a risk checklist during study startup and periodic quality review.

• Late data entry and back-dated source → countermeasure: workload planning, clear expectations, RBM signals for late entry, targeted training.
• Unexplained bulk edits near database lock → countermeasure: change control discipline, audit trail sampling, documented rationale for corrections.
• Shared accounts or weak authentication → countermeasure: strict user management, periodic access review, vendor enforcement.
• Inconsistent versions of controlled documents (consent, procedures) → countermeasure: document control logs, eTMF governance, site communications.
• Interface failures between systems (EDC ↔ safety DB) → countermeasure: reconciliation cadence, integration testing, incident tracking (see CSV vs CSA).

Data integrity is easiest to defend when it is integrated into routine oversight and inspection readiness practices rather than treated as a separate compliance initiative (see Inspection Readiness).

Source, eSource, and certified copies: make the “O” in ALCOA defendable

The “Original” attribute is one of the most misunderstood. In practice, you need to define what is considered the source record for each data type and ensure that any copies are controlled, legible, and traceable. This is especially important in decentralized workflows where documentation may originate outside a traditional site chart.

1) Source decision points to document

• Where does the first capture occur? (paper note, eSource system, device portal)
• Who is the author? and how is authorship attributed (login, signature, attestation)
• Is transcription expected? If yes, how is it verified (double-check, SDV, targeted sampling)
• How are corrections made? (single line-through for paper, audit trail for electronic)
• What is the retention location? (site chart, vendor portal, sponsor system) and how retrieval is ensured

2) Certified copy process checklist (if scanning is used)

• Define who can certify a copy and what “certification” means at the site
• Scanning quality standards (resolution, color vs grayscale, completeness, legibility)
• Metadata standards (subject ID, visit date, document type) so files are retrievable
• Verification step: confirm the scan matches the original before upload
• Controlled storage: prevent uncontrolled overwrites; retain audit trail of uploads and replacements

Certified copy controls are closely linked to TMF/eTMF discipline and system audit trails (see TMF/eTMF Excellence and CSV vs CSA).

Spreadsheets and manual logs: control the “shadow systems”

Many integrity issues originate in uncontrolled tools: screening logs, temperature logs, delegation trackers, and ad hoc trackers. You do not need to ban spreadsheets, but you should control them when they affect critical trial decisions.

Spreadsheet control checklist (fit-for-purpose)

• Purpose statement: what the log is used for and what it is not used for
• Ownership and access control (no shared generic accounts)
• Versioning: locked template; controlled updates; change history where possible
• Review cadence: periodic review and sign-off (paper or electronic attestation)
• Backup and retention: where the file is stored, how it is backed up, and how it is archived
• Reconciliation with primary systems (e.g., screening log ↔ EDC screening forms; temperature log ↔ excursion reports)

When spreadsheet-derived information feeds deviations or CAPAs, ensure there is a clear path from the log to the documented quality event (see Protocol Deviations and CAPA).

Reconciliation as a data integrity control (not just a data management task)

Reconciliation demonstrates that your systems are consistent and that discrepancies are detected and resolved. Treat reconciliation as an integrity control with defined cadence, ownership, and documentation outputs.

High-yield reconciliation areas

• EDC ↔ Safety database (SAEs, deaths, pregnancies) — see PV & Safety Reporting
• EDC ↔ ePRO (patient-reported symptoms/events and missingness)
• EDC ↔ Central lab (critical values, repeated tests, sample IDs)
• EDC ↔ CTMS (visit dates, monitoring visit documentation where relevant)

Discrepancy log fields (example)

• Discrepancy ID, date detected, and data cut used
• Systems involved and record identifiers
• Description and risk category (safety/right/integrity)
• Owner and due date
• Resolution and evidence (query ID, updated record, rationale)
• Trend tag (root cause category) for periodic review

Feed reconciliation trends into RBM governance as signals of process weakness (see RBM That Works).

Mini data integrity risk assessment (template you can actually use)

Use this as a lightweight way to prioritize integrity controls during startup or when making mid-study changes:

1. List critical data (endpoints, eligibility, key safety).
2. Map where each is captured (system, paper, device, vendor portal).
3. Identify failure modes (late entry, transcription, interface loss, incorrect configuration).
4. Define controls (training, system assurance, audit trail review, reconciliation, central monitoring).
5. Define evidence outputs (what artifacts prove the control occurred).

When this assessment is tied to your inspection readiness evidence map, it becomes a strong, coherent narrative: you knew the risks, implemented proportionate controls, and monitored effectiveness (see Inspection Readiness).

Corrections and late changes: keep the story coherent across systems

Data corrections are expected in clinical trials. Integrity risk arises when corrections are late, undocumented, inconsistent across systems, or appear to “clean up” data without a traceable reason. Define and train a consistent correction approach:

• Correct in the right place: correct the primary record (EDC field, ePRO record, source note) rather than relying on external trackers.
• Preserve history: ensure the original value remains visible in the audit trail and that the reason for change is captured where available.
• Align cross-system changes: if an AE onset date changes in EDC, ensure the safety database reconciliation catches it and documents the follow-up.
• Use targeted audit trail review: sample late changes for critical data fields and document outcomes.

Example: correcting a key date near database lock

If a key endpoint visit date is corrected late, an inspection-ready record shows: what evidence triggered the correction, who approved it (if required), how the change affected protocol windows/analyses, and how you ensured consistency across listings, SDTM/ADaM derivations, and TMF documentation (see CDISC SDTM/ADaM Basics and TMF/eTMF Excellence).

Audit trail review: a lightweight sampling approach

Audit trails are most useful when reviewed with intent. Define a simple sampling plan that focuses on critical data (consent dates, eligibility criteria, primary endpoints, SAE fields) and on high-risk patterns (late entries, mass edits, frequent overwrites). Document what was reviewed, what was found, and what actions were taken. This turns audit trail capability into an operational control rather than an “available if asked” feature.