Why interoperability between eSource, eCRF, and eConsent still breaks down
Most studies today don't run on a single system. Source data might sit in one platform, case report forms in another, and consent records in a third, each chosen because it did its own job well. The trouble rarely comes from any one of these systems individually. It comes from the seams between them, where a value entered once has to be trusted, mapped, and reconciled somewhere else.
The manual bridge is still the most common bridge
Despite years of talk about seamless data flow, a great deal of information still moves between systems through exports, re-entry, or a coordinator manually checking that two records agree. A feasibility study looking at automated transfer between electronic health records and an EDC system found real gains from removing that manual step, but also a genuine gap analysis worth reading on its own: automation reduced transcription error, but only once the underlying data structures on each side had been reconciled first. The integration wasn't the hard part. Agreeing what the data actually meant on both sides was.
A shared identifier is not the same as a shared meaning
Two systems can agree on a participant ID and still disagree on what a field represents. A "visit date" in an eConsent platform might mean the date consent was signed, while the same label in an eCRF means the date of the clinical encounter. These mismatches rarely cause an obvious error. They cause a subtler one: two systems that both look correct in isolation but tell a slightly different story when compared.
Consent status is where the stakes are highest
Of the three systems, eConsent is the one where a synchronisation gap has the most serious consequences. If a participant withdraws consent in one system and that status takes even a day to reach the systems still collecting or processing their data, that delay is not a technical footnote. It is a compliance and ethics problem. Consent status should propagate as close to real time as the architecture allows, and any manual step in that specific path is worth removing before almost anything else.
Plan the integration before choosing the vendors
It's tempting to choose the best eSource, eCRF, and eConsent tools independently and assume integration can be solved afterwards. In practice, the easiest integrations are the ones considered before procurement, not after: does a system expose a usable API, does it support standard data formats, and has anyone actually tested moving a real record through the full pipeline rather than trusting a vendor's word for it. A short proof-of-concept moving one real workflow between the actual systems in question is worth more than any specification sheet.
Audit the seams, not just the systems
An audit trail that covers what happened inside a single system, but not what happened as data crossed into another, leaves a genuine gap in the record. Logging when a value moved, whether it was transformed on the way, and who or what triggered that movement is what makes the full chain reconstructable later, not just each individual link.
Interoperability problems are rarely caused by any one system failing. They come from the assumption that connecting two good systems is itself a small technical detail rather than a design decision worth as much attention as the systems themselves.