An eCRD — electronic case report form, also written eCRF — is the digital form a clinical study uses to capture data about a single patient: their visits, their measurements, their adverse events, everything the protocol asks for. "CRD" and "CRF" refer to the same thing; CRD (case report document/dossier) is more common in Spanish-language and European regulatory contexts, CRF in US and international ones. The "e" just means it lives in software instead of on paper.
That one-sentence definition is usually where people stop, and it's where the useful part starts. The interesting question isn't what an eCRD is — it's what has to be true around it for the data it captures to actually be trustworthy.
eCRD, eCRF, EDC, CDMS — the terms, untangled
These four terms get used almost interchangeably in casual conversation, and that causes real confusion when you're evaluating a platform. Here is the actual relationship:
- CRD / CRF — the document. A form, historically paper, that captures one patient's data for one study.
- eCRD / eCRF — the same document, electronic. Not a category of software, just the digital version of the form itself.
- EDC (Electronic Data Capture) — the category of software that builds and hosts eCRFs, plus the surrounding workflow: validation rules, user roles, audit trail.
- CDMS (Clinical Data Management System) — EDC plus the review layer on top: queries, source data verification, data cleaning, lock. Some vendors sell EDC and CDMS as separate products; others, including Arion, treat it as one system because the review layer is meaningless without the capture layer underneath it.
What actually goes into an eCRD
A modern eCRD is rarely one flat form. It is structured around the protocol's visit schedule: each visit (or "event") links to one or more pages, each page holds a set of fields, and each field has a type — text, number, date, enumerated choice, calculated/derived value — plus validation rules that decide what counts as a plausible entry.
Underneath the form the study team sees, a well-built eCRD keeps a normalized data model: the field definition (part of the study design) is a separate object from the field value (part of one patient's captured data). That separation is what makes two things possible later — safely changing the form after patients are already enrolled, and running statistics against the captured values without exporting them anywhere.
How an eCRD fits into a study, end to end
The eCRD itself is the capture step, but it sits in the middle of a longer chain: a protocol gets translated into study design (the eCRD structure), a site captures data against that design, reviewers work queries and source data verification against what was captured, and eventually someone runs statistics on the result.
Where that chain breaks matters more than the eCRD itself. In most EDC/CDMS setups, the analysis step happens in a separate system — the captured data gets exported, reshaped, and loaded somewhere else before a statistician can touch it. Every export is a place the number in the final report can drift from what the site actually typed into the eCRD, and it's the reason "data capture" and "data analysis" tend to be run by different teams with different tools, even inside the same study.
Why studies moved off paper CRFs
Paper CRFs have to be transcribed into a database before anyone can analyze them, and transcription is where errors get introduced — a second point of truth that has to agree with the first. An eCRD removes that step: the site enters data once, directly into the system that will eventually be analyzed.
The other advantage is real-time validation. A paper form can't tell a coordinator that a lab value looks implausible or that a required field is blank; an eCRD can flag it the moment it's entered, while the patient is still in the room and the answer is easy to check.
What to look for in a modern eCRD platform
A few things separate a genuinely useful platform from a digitized paper form:
- Non-blocking validation. A flagged value should be reviewable, not a wall that stops the visit from being recorded.
- A real audit trail. Every change should carry who, when, and what the value was before and after — not just a "last modified" timestamp.
- Change control that shows its impact. Protocol amendments happen; a platform should tell you what a structural change will affect before you commit to it, not after.
- Role-based access that's actually enforced. Permissions checked only in the interface can be bypassed by a direct request to the underlying system — they need to be enforced at the API level too.
- A path to analysis that doesn't require an export. If the platform can capture data but not analyze it in place, you're still running two systems and reconciling between them.