Clinical research runs on an alphabet of systems — EDC, CTMS, eCOA, ePRO, eConsent, eTMF, IRT, and more — and the acronyms are a real barrier for people new to the field. Each names a class of system with a distinct job. This guide explains what each class does, what data lives in it, who uses it, and how the pieces connect. The classes matter beyond terminology: regulators expect sponsors to know which system holds which records, and to manage each accordingly [1][2].

A useful orientation: every study produces two intertwined streams of records. One stream is the data — what was measured about participants. The other is the evidence about the study itself — who consented, who was trained, what was approved, what happened operationally. Most system classes below serve primarily one stream or the other.

How a single data point connects to a submission
  1. Protocol
  2. Visit
  3. eCRF
  4. Data Point
  5. Query
  6. Clean Data
  7. Dataset
  8. Submission / Publication

An important conceptual relationship — not a universal database design.

EDC — Electronic Data Capture

What it does. The EDC system is the study database: it holds the electronic case report forms (eCRFs) that sites complete at each visit, the edit checks that validate entries, the queries raised against discrepancies, and the audit trail behind every value.

What data lives here. Participant research data: visit assessments, labs, adverse events, medications, endpoints. This is the database that gets cleaned, coded, locked, and analyzed.

Who uses it. Site coordinators enter data; data managers review, query, and clean it; monitors review it against source; statisticians receive its exports. Examples of products whose primary function is data capture include, among others, Castor, Medidata Rave, Medrio, OpenClinica, Oracle Clinical One, QuesGen, REDCap, and Zelta.

CTMS — Clinical Trial Management System

What it does. The CTMS tracks the operations of a study: site selection and activation, enrollment against targets, monitoring visits and reports, payments, milestones, and contacts (enrollment and site metrics, multi-site management).

What data lives here. Operational and administrative data — about sites, staff, visits, and money, not about participants' health. A CTMS typically knows that a participant enrolled on a date; it should not be where their blood pressure lives.

Who uses it. Project managers, clinical operations teams, monitors (CRAs), site-management staff, and finance. Sponsors and CROs are the heaviest users; many academic sites run a lighter equivalent or none at all.

eCOA and ePRO — Electronic Clinical Outcome Assessment

What it does. eCOA systems collect outcome assessments electronically — symptom diaries, quality-of-life questionnaires, performance measures — often on a participant's own phone (participant-reported outcomes, mobile and offline collection).

What data lives here. Outcome assessments captured at or near the moment they occur, with timestamps that make late or back-filled entries visible — a major reason regulators and sponsors favor electronic diaries over paper.

Who uses it. Participants and caregivers primarily; clinicians for clinician-reported and performance measures; data managers downstream, when eCOA data flows into the study database.

eConsent — Electronic Informed Consent

What it does. eConsent systems present the informed consent process electronically — the document, multimedia explanations, comprehension checks, and electronic signatures (electronic consent).

What data lives here. Consent records: which version each participant signed, when, and with what discussion documented. Consent versioning is the quiet hard problem here — amendments create new consent versions, and someone must always be able to show who signed which.

Who uses it. Participants, the site staff conducting consent, and — critically — IRBs/ethics committees, monitors, and auditors, for whom the consent record is among the first things checked.

eTMF — Electronic Trial Master File

What it does. The eTMF holds the essential records of the trial — the documents that, per ICH E6(R3), allow the conduct of the study and the quality of the data to be evaluated and reconstructed [1]: protocol and amendments, approvals, agreements, training records, monitoring reports, signature logs.

What data lives here. Documents about the study, not participant data. The participant's blood pressure is in the EDC; the certificate showing the blood pressure cuff was calibrated is in the TMF.

Who uses it. Regulatory and clinical operations staff maintain it; sponsors, CROs, and sites each hold their portions; inspectors read it. Florence Healthcare and Veeva are among the vendors known for site-facing and sponsor-facing document workflows in this space.

How the systems connect

In a well-run study the classes are wired together deliberately:

  • Integrations move data between systems — eCOA responses and central lab results flowing into the EDC, enrollment events flowing to the CTMS (integrations, APIs and data import). CDISC's ODM standard exists in part to give this exchange a common format [3].
  • Reconciliation covers the joints integration doesn't: confirming the safety database matches the EDC's serious adverse events, and external files match enrolled participants (data reconciliation, safety reconciliation).
  • The boundaries are governed. Each system carries its own audit trail, access controls, and — where FDA-regulated — Part 11 obligations (21 CFR Part 11) [2]. "Where does this record live, and which copy is authoritative?" is a design decision, not an accident.

Common confusions

  • EDC vs. CTMS. The most frequent mix-up. EDC holds data about participants; CTMS holds data about the study's operations. Enrollment counts appear in both — as clinical records in one and management metrics in the other.
  • eCOA vs. ePRO. ePRO — participant-reported outcomes — is one type of eCOA. eCOA also covers clinician-reported, observer-reported, and performance outcome assessments. Vendors use the terms loosely; the data classes are distinct.
  • eTMF vs. archive. The eTMF is a live working file maintained throughout the study; archiving is what happens to all the systems' records — TMF, EDC data, audit trails — after closeout, for the full retention period.
  • eConsent vs. a signature on a PDF. Consent is a process — disclosure, comprehension, voluntary agreement — that eConsent systems document. An e-signature tool captures only the final instant of that process.
  • EDC vs. "the database." Statisticians analyze datasets derived and transformed from the EDC (in industry, typically standardized to CDISC SDTM and ADaM [3]); the EDC itself is the capture and cleaning environment, not the analysis environment.

How these acronyms map to our six categories

Our technology landscape classifies products by primary function into six categories, and the mapping to this guide's acronyms is close but not one-to-one:

  • Study-Specific EDC and Institutional Research Platform both answer to "EDC" — one built per study, one run as shared institutional infrastructure.
  • Clinical Trial Operations Suite covers CTMS and eTMF territory, and suites increasingly bundle EDC, randomization, and consent modules — Medidata, Oracle, and Veeva all sell along this line.
  • Participant Data Collection covers eCOA, ePRO, eConsent, wearables, and decentralized-trial tools — the class where Science 37 and similar decentralized providers operate.
  • Research Data Platform and Configurable Application Platform have no tidy acronym; they aggregate and standardize data across the other systems, or provide the general-purpose scaffolding some teams adapt to any of these jobs.

Because suites span classes, we classify each product by primary function and note secondary functions in the technology directory. When you are ready to select within a class, start with Choosing an Electronic Data Capture System — its requirements-first method applies to every class here, not just EDC.