EDC Software Problems: The 7 That Stall Studies and Multiply Queries

Why does the scope get set as a form builder instead of a data model?

Because the demonstration everyone asks for is a case report form. A sponsor evaluating a build wants to see a form designer, a rendered form and data going in, and that is a satisfying thing to show in week three. So the project gets shaped around design, render and store, and the parts that make the system survive a study are treated as later work.

An electronic data capture system is not a form builder with a database behind it. It is a versioned data model with a legally significant audit trail, a rules engine that must behave identically on data entered before and after a change, and an export contract with statistical programming that cannot drift. Anyone quoting you a form designer has understood a fifth of the problem, and the missing four fifths are where the cost lands later.

Set the scope around the design object instead. The study design itself is a versioned artefact, every collected datapoint carries the design version under which it was captured, and edit checks are bound to a version rather than to a global rule set. Get that right and adding a cohort in month nine does not invalidate the subjects who have already passed the affected visit, because the engine knows which rules applied to whom. Get it wrong and every amendment is a rebuild. This is one decision, made before any form is drawn, and it determines the economics of the whole platform.

What goes wrong migrating existing studies and legacy databases?

The long tail is where migration bites, and the long tail is exactly what a custom build usually exists to serve. Registries in spreadsheets, an old instance nobody validated, an academic partner's database with no defensible audit trail, a device follow up in an accounting of visits kept by a coordinator. Each holds real subject data and none holds it in a form the new system can accept without judgement.

The specific trap is migrating data whose provenance you cannot describe. A datapoint arriving in a validated system without a source, a capture date and an attributable entry is worse than one left outside it, because now the audit trail asserts something you cannot support. Legacy free text values that do not map to a controlled terminology cause the same problem more quietly, since a coded field silently populated from ambiguous text will look clean and be wrong.

Decide the treatment per study rather than globally. Ongoing studies with clean provenance migrate fully. Closed studies migrate as read only historical datasets, flagged as such, outside the audit trail of the live system. Anything with unclear provenance stays where it is and is referenced rather than absorbed. Then write the migration plan into the validation documentation, because a regulator asking how data arrived in the system expects an answer, and the answer cannot be that somebody uploaded a spreadsheet.

Why do randomisation, laboratory and device feeds break after launch?

Because each one is a reconciliation design, not a connection. A central laboratory sends results with its own identifiers, its own visit naming and its own units, and a study that changes a visit label mid stream will keep receiving the old label for weeks. Randomisation systems allocate on their own schedule and a subject who is randomised but not yet entered creates a legitimate mismatch. Device and wearable feeds carry timestamps in whatever timezone the device thought it was in.

What actually breaks is rarely the transport. It is the assumption that identifiers stay stable. A site corrects a subject identifier after enrolment, or a subject is re screened under a new number, and every downstream feed continues referencing the original.

Design external data as a peer to entered data on the same subject and visit spine, with its own provenance and its own reconciliation rules that raise a query when the feed and the site disagree. Hold an identifier mapping that supports corrections and re screening rather than assuming a subject number is immutable. Report arrival volumes per source per week so a feed that stops is visible against history within days. And keep high volume sensor data in a separate analytic store joined on the subject and visit keys, because continuous accelerometry produces orders of magnitude more rows than the case report forms and putting it in the same tables degrades everything else.

What happens when amendment handling and the export contract are missing?

These two gaps produce most of the regret in this category. Without per form migration policy at amendment, a visit that splits in two leaves the data manager with a manual decision for every subject who has already passed it, and the decision gets made in email. Without a defined export contract, statistical programming reverse engineers your form names in month nine, which is exactly when nobody has time for it.

Both are cheap early and expensive late. Design the export contract before the first form is drawn: CDISC ODM-XML carrying the raw and audit content, and an annotated mapping toward SDTM that exists from study design rather than being reconstructed at database lock. Medical coding uses MedDRA and WHODrug, which are licensed dictionaries you subscribe to rather than build, with the system offering suggestions and a human coder signing off, and both the suggestion and the acceptance recorded.

For amendments, publish each design change as a new version with an explicit per form policy: which data carries forward, which stays valued under the old version, and which triggers retrospective collection tasks routed to sites. The team decides that policy once per amendment in a screen rather than negotiating it through tickets. Because validation recurs at every significant release, and adds fifteen to twenty five percent on top of engineering in our delivery experience, every amendment absorbed by configuration rather than code is a direct saving.

Should you build custom or configure what you already own?

Licence if you are a small sponsor running one or two pivotal studies. Medidata Rave EDC has by far the deepest ecosystem and handles complex designs, Veeva Vault EDC is strong when the rest of your estate is already Vault, and Oracle Clinical One brings capture and randomisation together, which removes a class of integration problems. Those platforms carry regulatory familiarity, monitor and site experience and a support model you cannot replicate quickly, and your money is better spent on data management people.

Castor EDC suits investigator initiated and academic studies with self service build, and becomes less comfortable as derivations, external feeds and adaptive logic accumulate. OpenClinica gives you a self hostable base with the lowest licence friction, in exchange for owning validation, hosting and operations, which is a real cost people forget when comparing the sticker price.

Build when two or more apply: a long tail of registries, investigator initiated, post marketing or device studies where per study build fees and licences cost more than the science, adaptive designs where every protocol change becomes a services engagement with a lead time your enrolment cannot absorb, device and sensor endpoints that sit awkwardly beside case report form data, or a contract research organisation wanting one platform it controls across sponsors. The tipping point is when your study design logic has become a company asset and renting it back per study stops being defensible.

How do hidden costs get into the quote?

Validation is the largest and the most commonly omitted. An electronic data capture system holds source relevant clinical data, which puts you inside 21 CFR Part 11 and EU Annex 11 with GAMP 5 as the working framework: a validation plan, requirements traced to executed test scripts, installation, operational and performance qualification, documented change control and periodic review. Fifteen to twenty five percent on top of engineering is our experience, recurring at each significant release. Ask which deliverables the supplier writes and which you write.

Integrations are the second, and each one is its own reconciliation design rather than a connector. Price them individually by named system. Third is multi language, because translated forms need version control per language and a review trail, so five languages is not five times a translation invoice.

Fourth is blinding, if unblinded roles need walled off data inside the same system, which changes access control everywhere rather than adding a screen. Fifth is offline capture for sites where connectivity fails. Sixth, and the one that decides whether the platform earns its keep, is the reusable library of standard forms and checks built against CDASH. Build the library and study fifteen takes days. Skip it and every study is a project, which is the situation you were trying to leave.

What separates a build that works from one that fails here?

The builds that work treat edit checks as code. Every check is a function with fixtures: example records, whether it should fire, and the exact query text produced. The suite runs before deployment and a reviewer sees a real diff. This sounds like ordinary engineering because it is, and it is startling how rarely clinical data capture gets it. The visible result is that query volume falls to the queries that matter and site coordinators start reading the queue again, which is the thing that actually protects the data.

They also scope release one around three representative studies from the tail rather than around the most complex pivotal design in the portfolio. Satisfying the hardest study first produces a system that is late and still not right, because the hardest study changes while you are building for it.

The failures are visible at the whiteboard. Ask a prospective developer what happens to 190 already cleaned subjects when a visit splits in two. A partner who has done this talks about design versions, per form migration policy and retrospective collection tasks. A partner who talks about updating the form has never survived an amendment. Then confirm in writing before kickoff that you own the repository, the infrastructure accounts and the validation package, because without the validation documentation a future partner starts qualification from zero, and that is a cost you should never inherit by accident.