EDC × Data Integrity

Who holds the original when the record is an eCRF

The Original in ALCOA+ presumes you can point at the first durable capture of an observation. An EDC scatters that presumption. In the classic model the eCRF is a transcription — the original sits at the site, in medical records or worksheets, and source data verification checks the copy against it. Under eSource designation, direct entry into the eCRF is the first capture, and there is no site-held original at all. For a central-lab result or an eCOA response, the original was created in another organisation's system and arrived by transfer. Three routes, three different answers to "where is the original" — coexisting within one casebook.

The integrity consequence is that originality stops being a property you can inspect and becomes a decision you must govern. The trial's data-governance documentation has to state, per data element, where source resides — because every downstream control depends on the answer. Source data verification of an eSource field is meaningless; skipping verification of a genuinely transcribed field is a gap. Retention obligations attach to the original, so the site must keep what it holds and the sponsor must ensure connected systems keep theirs. An inspector's first data-integrity question in a trial is not "show me the audit trail"; it is "show me where you decided what source is" — and a trial that cannot produce that decision has already conceded the rest of the argument.

A record that is designed to change

A chromatography data file that has been repeatedly modified is a red flag. An eCRF that has never been modified is a different kind of red flag — it suggests the cleaning process did not run. Clinical data management exists to challenge and correct entered data: edit checks fire, queries are raised, sites answer, values change. The trial's conclusions rest on the corrected record, not the first keystroke. This is the point where practitioners trained on manufacturing data-integrity doctrine misread the clinical database: change is not the enemy here. Untraceable change is.

ICH E6(R3) states the standard precisely for this context: any change or correction to trial data must be traceable, must not obscure the original entry, and must be explained where explanation is needed. The audit trail is therefore not a security afterthought but the instrument that makes legitimate change legitimate — it preserves the superseded value, the actor, the timestamp, and the reason. The integrity failure modes are correspondingly specific: reasons for change that are all the same generic phrase, corrections clustered suspiciously after a monitoring visit, values toggled until an edit check passes, or a site answering every query with immediate agreement. None of these is a modification problem; all of them are pattern problems, visible only to someone who actually reads the trail.

Attribution runs through the delegation log

Attributable, in a single-organisation system, means the account that made the entry belongs to the person who did the work. A trial adds a second requirement: the person must also have been delegated that task by the investigator, in writing, at that site, during that period. The EDC's access model and the delegation log are two representations of the same authority, and integrity requires them to agree. An entry made by a coordinator who joined the study team a week before appearing on the delegation log is attributable in the Part 11 sense and indefensible in the GCP sense — the system knows who typed; the trial cannot show they were authorised to.

The investigator's electronic signature compounds this. It is not a workflow approval; it is an attestation that the casebook data are accurate and complete — data the investigator largely did not enter personally. That is the designed shape of clinical attribution: entry is delegated, accountability is not. It works only if the system enforces its consequences — data changed after signature must invalidate the signature and require re-signing, and the trail must show which version of the data each signature attested to. Access retirement is the quiet failure mode at this junction: a departed coordinator's live account, or sponsor-side write access to site data, collapses attribution for every record it could have touched, which is why user-access history is itself a core integrity record.

One audit trail, two inspectorates

A trail that satisfies the letter of Part 11 — secure, computer-generated, time-stamped, original values preserved — can still fail a GCP inspection, because the two readings interrogate different things. A GMP-shaped review asks whether the record could have been altered without trace. A GCP review asks who was allowed to alter it, and what the alteration did to accountability: could sponsor or CRO staff ever modify site-entered data, even with a trace? Did post-signature changes re-trigger the investigator's attestation? Can the trail reconstruct the casebook as it stood at interim analysis, at signature, at lock? A trail can answer the first family of questions perfectly and the second not at all.

The boundary between organisations is the sharpest edge. In manufacturing, everyone in the audit trail works for the company being inspected. In a trial, the trail records actors from the site, the sponsor, the CRO, and the platform provider — and the integrity claim depends on what each was structurally unable to do. Site data must be changeable only by the site; queries may challenge a value but never replace it; the sponsor's reach must stop at the question. Demonstrating this is a validation activity, not an assertion: the role-permission matrix is tested so that the impossible is evidenced, because a GCP inspector who finds a sponsor role with write access to eCRF data has found a finding no clean audit trail will offset.

Audit-trail review itself also changes character in the overlap. MHRA's data-integrity expectations apply to the clinical database exactly as to a laboratory one, but nobody can eyeball the trail of a hundred-thousand-page casebook. Review becomes a designed, risk-based activity — targeted at high-risk fields, unusual change patterns, and site-level behaviour — with its scope documented and its execution evidenced. An SOP that promises audit-trail review the sponsor never performs is a finding an inspector assembles in minutes.

Data no site ever touched

A growing share of the clinical database is never entered by anyone: central-laboratory results, eCOA responses, randomisation strata, device readings, all arriving by integration. For these, the transcription-checking machinery of the trial has nothing to check — there is no site record to verify the transfer against, and the receiving eCRF field is the first time a human could see the value. Integrity for this data is manufactured upstream or not at all: the sending system's own audit trail and controls, a validated transfer with reconciliation of counts and content, and mapping specifications maintained under change control on both ends.

The characteristic failure is the silent one. An upstream format change — a renamed field, a changed unit, a new code list — that the mapping was never revisited for does not raise an error; it delivers plausible, wrong values for months. This is why integration mappings sit inside the validated scope and why periodic reconciliation is an integrity control rather than a data-management courtesy. The maturity signature of the overlap is visible here: organisations at the low end verify each integration once and trust it for the life of the trial; organisations at the high end treat every upstream release as a change event against their own database, because they have understood that for integrated data, the transfer is the record's entire provenance.