What an EDC System Does, and Four Jobs It Cannot Do
An electronic data capture system captures trial data, validates it with edit checks, keeps an audit trail, controls access and produces extracts. It does not own your study metadata, your export specification, your validation package or your query process. Those four stay with your team, whatever the demo implied.
Most EDC disappointment is not about the software. The platform does what it says. The trouble starts in the space around it, where four jobs sit that look like platform features until the moment you need to change something. Then it becomes clear that nobody was assigned to them.
This guide sets out what the system genuinely does, names the four jobs it cannot do for you, and shows where the boundary between the platform and the people should sit. It is the scope question underneath the wider subject of how clinical trial data moves from site entry to submission, and it is worth settling before you configure anything.
After reading this you will be able to:
- Say what your EDC is accountable for, and what your team is
- Spot the four jobs that quietly have no owner on most studies
- Ask a vendor the right scope question before signature rather than during an amendment
- Tell a platform problem from a specification problem when something goes wrong
What an EDC System Actually Does
Five functions, and a good platform does all five well.
It captures structured data, both typed at the site and arriving directly from laboratories, devices and patient-reported apps. It validates on entry, firing range, logic, cross-form and cross-visit checks. It maintains an audit trail in which every change is attributable to a person, timestamped, and carries a reason. It controls access through roles and permissions, including blinding. And it produces extracts.
Those five matter, and a platform that does them badly is not worth fixing. But notice what is missing from the list. Nothing in it decides what should be collected, what the checks should test, what the extract should contain, or whether the configured result is fit for the study you are actually running. Those are the four jobs.
Job One: Owning Your Study Metadata
Study metadata is the definition layer: the fields and their types, the edit check logic, the visit structure, the coding configuration. It is not the data. It is the thing that decides what the data can be.
The question that matters is not where the metadata is stored but who can change it. On some contracts your team edits it directly. On others every change goes to the vendor as a request, with a queue and a cost. Both models are workable. Only one of them lets you schedule an amendment rather than negotiate it.
This decision is made at procurement and felt for the life of the study, which is why it rarely gets the attention it deserves. The first time most teams think about it is when they need two new fields and find out what two new fields cost. That scenario is worked through in handling a mid-study amendment without revalidating the whole build.
Job Two: Writing the Export Specification
The export specification describes what leaves the system: which fields, in what structure, on what schedule, for whom. Platforms offer export tools. None of them writes the specification, because the specification is a set of decisions about your study.
Written at design time, with biostatistics present, it shapes the eCRF while the eCRF is still cheap to shape. Written at lock, it has to absorb every ambiguity that survived the build, in the weeks when there is least room to absorb anything. The cost difference between those two timings is the single largest avoidable line in most data management budgets.
Job Three: Your Validation Package
A vendor validates the software as a product. You validate your configured use of it. Those are different exercises with different evidence, and conflating them is the most expensive assumption in eClinical procurement.
Your package covers the build you specified, the checks you wrote, the roles you configured, the flows you connected and the procedures your people follow. A vendor certificate is an input to that, not a substitute for it. The practical test is whether your documentation describes what you validated rather than merely asserting that you validated, because the first is inspectable and the second is not.
Scoping validation effort by risk rather than by habit is the approach set out in GAMP 5 Second Edition, and it is consistent with how regulators expect effort to be targeted. Revalidating everything is expensive and is not more compliant.
Job Four: The Query Process Itself
Every EDC raises queries. None of them decides which checks should fire, how the query text should read, who resolves it, or what an acceptable resolution time is.
That design work determines site experience more than any interface decision. A check written against the protocol asks a technically correct question that the coordinator cannot answer without guessing. A check written against the site workflow catches the same data problem and produces a query someone can close. The metric worth watching is resolution time rather than raw query count, because resolution time measures whether the query was answerable in the first place. The mechanics are in why query volume rises late in a study, and what reduces it.
Where the Boundary Sits
Set against the activities of a study, the split looks like this.
The pattern is consistent. The platform provides a capability. Data management makes the decision and owns the outcome. Biostatistics sets the constraint that the decision has to respect. Where a study runs into trouble is almost always a row where two of those three believed the third had it.
What to Do About It
Three questions, asked of any activity you assume the platform covers.
- Who can change this without raising a ticket?
- What evidence exists that it does what we specified?
- Who is accountable if it turns out not to?
If the answer to any of them is the vendor, that can be perfectly sensible. What matters is that it was decided rather than inherited. Ask them during evaluation and the answers shape the contract; ask them in month five and they shape an invoice. The version of these questions to put to a vendor before signature is in twelve questions to ask an EDC vendor before you sign. If you are already configuring rather than choosing, the sequence and its compressible steps are covered in every step between final protocol and first patient in.
Clinera EDC is the capture and validation layer described here, and for teams looking at automation across review and reconciliation, clinical and R&D AI sets out where it helps and where it does not.
References
- 21 CFR Part 11, Electronic Records; Electronic Signatures. US Code of Federal Regulations, Title 21, Part 11. www.ecfr.gov
- ICH E6(R3) Good Clinical Practice. International Council for Harmonisation, adopted 6 January 2025. www.ich.org
- Good Clinical Data Management Practices. Society for Clinical Data Management. scdm.org
- CDASH, Clinical Data Acquisition Standards Harmonization. CDISC foundational standards. www.cdisc.org
This guide describes process and regulatory expectations in general terms and is not legal or regulatory advice. Confirm the current version and applicability of any standard or guidance for your study and region.
Frequently Asked Questions
What does an EDC system actually do?
Five things. It captures structured data from sites and direct feeds, validates it with edit checks as it arrives, keeps an attributable and timestamped audit trail of every change, controls who can see and do what, and produces extracts for review and analysis. Those five are the reason the category exists and a good platform does them well. What it does not do is decide what should be collected, what the extract should look like, or whether your configured build is fit for purpose.
Is an EDC the same thing as clinical data management?
No. The EDC is where the data lives. Data management is the set of decisions about what goes in it, how it is validated, what it is reconciled against and when it is locked. Teams that treat the two as equivalent tend to discover the difference during their first protocol amendment, when the platform can do the change but nobody has decided what the change should be.
Who owns our study metadata?
Check the contract, because the answer varies by vendor and by deal. Study metadata means the field definitions, the edit check logic and the coding configuration. If your team can edit it, a mid-study change is work you can schedule. If only the vendor can, every change is a ticket with a queue and a price attached. Neither model is wrong, but the second one belongs in the total cost of the study rather than being discovered halfway through it.
Our vendor says the system is validated. Are we validated?
No, and this is the most expensive misunderstanding in eClinical procurement. A vendor validates the software as a product. You remain responsible for validating your configured use of it: your study build, your edit checks, your user roles, your data flows and your procedures. Write the split down explicitly in the validation plan so that neither side assumes the other covered it.
When should the export specification be written?
At design time, alongside the eCRF, with biostatistics in the room. The export specification says what analysis receives, in what shape and on what schedule. Written early it shapes the eCRF and costs almost nothing. Written at database lock it has to absorb every decision that was left open during the build, under the tightest timeline in the study.
Does Nirmitee Healthtech provide the platform, the data management, or both?
Both are available separately. Clinera EDC is the capture and validation layer, and the data management work described here, specification, edit check design, reconciliation and lock, can be run by your team, by ours, or split. The useful first conversation is usually about which of the four jobs above your team currently owns, because that determines what is actually needed.
