EDC, eCRF, eCOA and IWRS as One Regulated Data Flow: Who Owns the Source Record and Where ALCOA Breaks at the Seams

At a glance

• Stop treating EDC, eCRF, eCOA and IWRS as five separate glossary entries. They are layers in one regulated data flow, and the GCP exposure lives in the seams between them, not inside any single box.
• The auditor’s first questions are not “what does this tool do” but “who is the data originator, which system holds the source record, and where does the audit trail live.” Those three answers change from system to system.
• For directly entered data, FDA’s eSource guidance is explicit: the eCRF is the source. For a patient-reported outcome, the patient is the originator and the eCRF is the source. Get the originator wrong and you have mislabeled your source record.
• ICH E6(R3) treats CRFs, interactive response technologies and clinical outcome assessments alike as data acquisition tools that collect data from an originator, and it requires validated, reconciled processes for any data moving between computerised systems.
• The recurring failure modes are reconciliation gaps between IWRS randomization and EDC, eCOA data the site cannot edit or correct, and audit-trail breaks at API handoffs. Each is an ALCOA failure waiting for an inspection.
• Software and validated processes enable compliance; they do not deliver it. Under ICH E6(R3) the sponsor retains ultimate responsibility for data reliability no matter how many vendors and systems sit in the flow.

The clinical data stack at a glance

Five acronyms recur on every modern study, and practitioners are routinely asked to “define the difference” as if it were trivia. The disambiguation is worth doing, but only as a setup for the real question: where does the source record sit, and who put it there.

• CRF (case report form): the protocol-defined record of the data to be reported to the sponsor for each participant. Historically paper.
• eCRF (electronic case report form): the same record in electronic form, with validation, query workflow and an audit trail layered on top. FDA’s eSource guidance calls the eCRF an auditable electronic record of information reported to the sponsor on each subject.
• EDC (electronic data capture): the system that hosts the eCRF and runs the edit checks, query management and review workflow around it. EDC is the platform; the eCRF is the form it serves.
• eCOA (electronic clinical outcome assessment): electronic capture of outcome assessments, including patient-reported outcomes (ePRO). The defining feature is the originator: often the participant, sometimes a clinician, not site data-entry staff.
• IWRS / RTSM (interactive web/voice response system, randomization and trial supply management): the system that randomizes participants and manages drug supply. It generates data, mainly randomization and dispensing records, that must reconcile against EDC.

ICH E6(R3) does not enumerate these products, and that is the point. Its definition of a Data Acquisition Tool (DAT) is a paper or electronic tool designed to collect data and associated metadata from a data originator and report it to the sponsor, and it lists CRFs, interactive response technologies and clinical outcome assessments together as examples. In the regulator’s frame these are not different categories; they are instances of the same regulated object, each carrying its own originator and its own source question.

From paper CRF to eCRF to EDC: what each layer adds

Moving from a paper CRF to an eCRF inside an EDC platform does not just digitize a form. It adds three regulated capabilities.

First, an audit trail. 21 CFR Part 11 §11.10(e) requires secure, computer-generated, time-stamped audit trails that independently record the date and time of operator entries and actions that create, modify or delete electronic records, and it requires that record changes not obscure previously recorded information. ICH E6(R3)‘s glossary echoes this: an audit trail should show activities, initial entry and changes to data fields by whom, when and, where applicable, why, and in computerised systems it should be secure, computer-generated and time stamped.

Second, access and authority controls. Part 11 §11.10(d) requires limiting system access to authorized individuals, and §11.10(g) requires authority checks so that only authorized individuals can use the system, sign a record or alter a record. ICH E6(R3) section 2.12.10 reinforces this on the site side: for systems deployed by the investigator/institution, appropriate individuals must have secure and attributable access.

Third, validation. Part 11 §11.10(a) requires validation of systems to ensure accuracy, reliability, consistent intended performance and the ability to discern invalid or altered records. None of these three capabilities is automatic just because a system is electronic; each is something the sponsor must require, configure and verify.

eCOA vs eCRF: the originator changes, and so do the source rules

This is where the stack stops being a vocabulary exercise. The difference between eCOA and ordinary eCRF data entry is not the screen, it is the data originator, and the originator drives the source-record rule.

FDA’s eSource guidance states that each data element in an eCRF is associated with an authorized data originator, and that the sponsor should develop and maintain a list of all authorized data originators (persons, systems, devices and instruments) and make it available at each clinical site. For a patient-reported outcome, the guidance is explicit: when a PRO instrument is used by a subject to transmit data elements directly to the eCRF, the subject is the data originator and the eCRF is the source.

Contrast that with ordinary site entry. Per the same guidance, when site staff enter a directly observed value such as blood pressure or weight at a visit, the eCRF is the source. But when site staff transcribe a value from a paper or electronic source document, the person transcribing is the originator and the underlying document is the source. So the same eCRF field can be “the source” or merely a transcription, depending entirely on who originated it and how.

The operational consequence for eCOA is sharp: there is frequently no site-editable equivalent of an ePRO entry. The patient is the originator, the eCOA capture is the source, and site staff cannot simply “correct” it. ICH E6(R3) section 2.12.2 underlines the discipline here: changes to source records should be traceable, should not obscure the original entry, and should be explained via an audit trail. A team that treats ePRO like ordinary eCRF data, and tries to overwrite it from the site, is editing a source record without authority.

IWRS / RTSM: randomization, supply, and the reconciliation duty

IWRS / RTSM sits to the side of the eCRF flow. It assigns randomization, manages kit allocation and tracks supply. Much of what it produces, the treatment assignment and dispensing record, is data the EDC also references, which is exactly why the two must agree.

ICH E6(R3) section 4.2.5 governs this seam directly. Validated processes, or other appropriate processes such as reconciliation, should be in place to ensure that electronic data, including relevant metadata, transferred between computerised systems retains its integrity, and the section calls for the transfer process to be documented to ensure traceability with reconciliation implemented as appropriate to avoid data loss and unintended modifications. A discrepancy between the IWRS randomization record and the EDC treatment field is not a clerical nuisance; it is the precise failure §4.2.5 exists to prevent.

Which system is the source? Map originator, source and audit trail per system

The single most useful artifact you can build is a per-system map of originator, source location and audit-trail location. Drawing on FDA’s eSource origination rules and ICH E6(R3)‘s DAT and source-record definitions, it looks like this.

System	Purpose	Data originator	Is it the source?	Where the audit trail lives	Key GCP / Part 11 obligation
CRF (paper)	Protocol-defined participant record	Site staff (transcriber)	Only if no prior written/electronic record exists; otherwise the underlying document is source	On the paper itself (dated, traceable corrections)	ICH E6(R3) 2.12.2: attributable, contemporaneous, traceable corrections
eCRF	Auditable electronic participant record	Depends on capture path (site, patient, device)	Source when data are directly entered; a transcription when copied from another record	In the EDC, per Part 11 §11.10(e)	Part 11 §11.10(e) audit trail; eSource originator + data element identifiers
EDC	Platform hosting eCRF, edit checks, queries	The platform does not originate; it captures	No; it hosts the source record, it is not itself the originator	EDC-wide, computer-generated and time-stamped	Part 11 §11.10(a) validation; §11.10(d)/(g) access and authority checks
eCOA / ePRO	Outcome and patient-reported assessment capture	The patient (ePRO) or clinician (ClinRO)	Source when the assessment is entered directly into the instrument	In the eCOA system; flows with the record	eSource: list the subject as originator; Part 11 audit trail and access controls
IWRS / RTSM	Randomization and supply management	The system (assignment) and site (requests)	Source for randomization and dispensing records	In the IWRS audit trail; must reconcile to EDC	ICH E6(R3) 4.2.5: validated, reconciled transfer between systems

Treat that table as a living deliverable per study, not a one-time slide. The originator column is the one auditors push on, and it is the one teams most often get wrong.

The seams are the risk: what breaks ALCOA at each handoff

ALCOA, attributable, legible, contemporaneous, original, accurate, is not optional vocabulary. FDA’s eSource guidance states that source data should be attributable, legible, contemporaneous, original and accurate, and ICH E6(R3) carries the same criteria into its definition of data integrity (attributable, legible, contemporaneous, original, accurate, complete, secure and reliable). The seams are where these criteria quietly fail.

• EDC ↔ IWRS reconciliation gaps (accurate, complete). When the randomization or dispensing record in IWRS and the corresponding EDC field drift apart, you have inaccurate data on at least one side. ICH E6(R3) §4.2.5 puts reconciliation of inter-system transfers squarely on the sponsor.
• eCOA with no site-editable equivalent (attributable, original). Because the patient is the originator and the eCOA capture is the source, site corrections that overwrite it break attributability and obscure the original entry, contrary to ICH E6(R3) §2.12.2.
• Audit-trail breaks at API handoffs (attributable, contemporaneous). When a device or service feeds the eCRF, eSource requires a data element identifier that names the system as originator and records who or what generated the data and when. If an integration drops that identifier, or the receiving system stamps its own ingestion time instead of the origination time, the audit trail no longer reconstructs who did what when. Part 11 §11.10(e) requires that trail to be secure and that changes not obscure prior information across the whole record’s life, not just inside one application.
• Unnecessary transcription steps (original, accurate). ICH E6(R3) §2.12.2 says transcription steps between the source record and the data acquisition tool should be avoided, and eSource lists eliminating transcription as a core reason to capture electronically. Every avoidable re-keying step is an ALCOA risk you chose to take on.

A useful tension to name plainly: 21 CFR Part 11 and ICH E6(R3) approach the audit trail from different angles, and a compliant stack must satisfy both. Part 11 §11.10(e) is a regulation that prescribes the audit trail as a system control, framed around US electronic records. ICH E6(R3) frames the audit trail as metadata that must let a reviewer evaluate the course of events across the trial. They align in substance, both require a secure, computer-generated, time-stamped record of who changed what and when, but they do not let you treat one as a substitute for the other. Your integration must produce a trail that reads correctly under each.

Part 11 and GCP expectations that apply across the whole stack

Some obligations are not per-system; they apply to the flow as a whole.

• Validation across the chain. Part 11 §11.10(a) requires validation for accuracy and reliability and the ability to discern invalid or altered records. ICH E6(R3) defines computerised systems validation as establishing, with documentation, that requirements are consistently fulfilled, scaled to a risk assessment of the system’s impact on participant protection and result reliability.
• Accurate, retrievable copies. Part 11 §11.10(b) requires the ability to generate accurate and complete copies of records in human-readable and electronic form suitable for agency inspection, and §11.10(c) requires protection for accurate, ready retrieval throughout the retention period. ICH E6(R3) §4.2.7 likewise requires data and relevant metadata to be archived for retrieval and readability and protected from unauthorized access throughout retention.
• Electronic signatures. Where the workflow requires signing, Part 11 §11.10(j) requires written policies holding individuals accountable for actions under their electronic signatures, and §11.200 sets the component and control requirements for those signatures.
• Sponsor responsibility is non-delegable. ICH E6(R3) section 3.4.6 states that a sponsor may transfer trial-related activities to a service provider, but the ultimate responsibility for those activities, including reliability of the trial data, resides with the sponsor. No EDC, eCOA or IWRS vendor absorbs that accountability for you. The honest framing is that these systems and validated processes enable compliance; the sponsor remains responsible for it.

Where teams get it wrong

The most common mistakes are conceptual, not technical, and they all trace back to misreading the seams.

1. Calling the EDC “the source” by default. The EDC hosts the source record for directly entered data, but for transcribed data the underlying document is the source, per eSource. Mislabel this and your source-data verification targets the wrong record.
2. Maintaining no originator list. eSource expects a maintained list of all authorized data originators, available at each site. Teams skip it, then cannot answer the originator question for a single data element under inspection.
3. Treating ePRO like editable site data. eCOA frequently has no site-editable equivalent. Overwriting it from the site breaks ICH E6(R3) §2.12.2’s rule that changes must not obscure the original.
4. Assuming integrations preserve the audit trail. API handoffs are exactly where data element identifiers and origination timestamps get dropped. The trail must reconstruct across systems, not just within each one.
5. Skipping IWRS↔EDC reconciliation. ICH E6(R3) §4.2.5 makes reconciliation of inter-system transfers a sponsor duty; many plans never name who reconciles randomization against EDC, or when.

A pre-build / oversight checklist for the integrated data flow

Use this before database build and again at oversight reviews. It is deliberately keyed to the regs above.

• Originator list exists and is current. Every data element maps to an authorized originator (person, system, device); the list is maintained by the sponsor and available at each site (eSource).
• Source record defined per data path. The protocol or data management plan states, for each capture path, which system holds the source (ICH E6(R3) §2.12.2; eSource).
• Direct-entry fields documented as source. Directly entered eCRF fields are recorded as source; transcription steps are eliminated where feasible and the source document retained where not (eSource; ICH E6(R3) §2.12.2).
• Audit trails verified end to end. Each system produces a secure, computer-generated, time-stamped trail, and integrations preserve data element identifiers and origination time across handoffs (Part 11 §11.10(e); eSource data element identifiers).
• Validation evidence for every system and interface. Validation covers each system and each transfer, scaled to risk (Part 11 §11.10(a); ICH E6(R3) computerised systems validation).
• IWRS↔EDC reconciliation named and scheduled. A validated or reconciliation process for inter-system transfer is defined, with an owner and cadence (ICH E6(R3) §4.2.5).
• Access and authority controls confirmed. Only authorized individuals can enter, alter or sign; access is attributable (Part 11 §11.10(d),(g); ICH E6(R3) §2.12.10).
• eCOA correction path defined. Where ePRO has no site-editable equivalent, the procedure for handling errors preserves the original entry and its audit trail (ICH E6(R3) §2.12.2).
• Inspection-ready copies and retention. The flow can produce accurate, complete, human-readable copies and retains records and metadata for the full retention period (Part 11 §11.10(b),(c); ICH E6(R3) §4.2.7).
• Sponsor oversight documented. Vendor delegation is captured, but data-reliability responsibility is explicitly retained by the sponsor (ICH E6(R3) §3.4.6).

For the sibling concepts this article leans on, see the ALCOA and data integrity explainer, the 21 CFR Part 11 explainer, and the audit trail and essential records explainer, and read this piece against the broader clinical data management pillar.

Sources

• ICH E6(R3) Good Clinical Practice, version r3 (ICH, 2025) — https://www.ich.org/page/efficacy-guidelines
• 21 CFR Part 11 Electronic Records; Electronic Signatures, version 2026-04 (FDA)
• FDA Guidance: Electronic Source Data in Clinical Investigations, version 2013 (FDA)