A recent note-to-file podcast from Brad Hightower with Bree Burks from Veeva discussed why EDC systems have been designed and developed for the benefits of the Sponsor over and above the Site?

I would like to discuss a few reasons.

Payer versus Stakeholder

Sponsor companies are the organizations that pay for the technology in order to fulfil a requirement to capture data according to their clinical trial protocol, and so, they must drive the definition of what ‘that is’.

The downside to the sites is that it does not necessarily help them.

Going back 25 years, EDC was introduced to replace the transposition of source data onto paper CRF Booklets.

Unfortunately, we stopped at that point. We didn’t move the eCRF from a transposition from source documents. Transposition largely continues. I believe this should be changed where the opportunities exist.

Changing the perspective

Our understanding of computer systems hasn’t significantly evolved from the notion that the organization possessing a server determines the identity of the ‘owner and user.’ Nowadays, our servers reside in the cloud.

Merely because an organization licenses a cloud server instance does not dictate whether a CRO, site, or patient has access to that server.

An EDC system should support and be of value to all stakeholders. We do not need separate EDC systems between sites and sponsors. We need a single EDC solution that serves and benefits all stakeholders.

Functional Changes to support

So what should we see changing to support ‘EDC for All’ ?

Data can be entered directly into an EDC system as eSource. It can be under the control of the site. The idea that because a sponsor funded a license for the EDC, that the site cannot control the data is simply false. Sites can and have been entering data directly into EDC as eSource for over 20 years. This might be direct data entry, or, data electronically transferred from a system such as EHR (via FHIR).

The term ‘source’ reflects back to the days of paper source documents. Sadly, we decided when implementing electronic representations of data to fail to appreciate the differences. We are stuck today with over-emphasing the importance of ‘eSource’ when in reality it is more about data governance.

I believe a subset of regulators perceive the concept of site ‘control’ as physical separation. However, I believe that ship sailed many years ago. It is rare today that even sites have data stored locally. All stakeholders use cloud hosted solutions. Trusted 3rd Party solutions support sites operating eSource platforms achieving control and having access to the same data as a sponsor but under a separate ‘role’.

Vendors including Veeva and CRIO provide solutions that achieve this model through differing methods.

For both duty of care and operational reasons, sites sometimes wish to capture additional data for a patient on a study. This should be possible. The fact that it is captured by the site, does not mean that this data forms part of the ‘study database’. EDC systems hold lots of data. Only a subset of that data ever makes it into the Analysis or Submission datasets. Supporting the ability for the sites to defined and record additional data is not difficult. Controlling who can see / use / change that particular data can also be controlled.

For 7 years I ran a platform that captured the patients name. This has survived regulatory and sponsor audits since 2012. Of course, not all sponsors wish to capture information as specific as a patients name. However, the principle holds for any PHI and PII. The platform and data should not be under the sole control of the Sponsor.

Sites have never said the words –

I wish I had multiple systems for each clinical trial.

Sites want ease of use, efficiency and simplicity when it comes to executing a clinical trial. Trial Management functions can co-exist with clinical trial data capture functions. This starts at the data acquisition and management tools but extends to trial management. This has tended to be where things fall down for sites. Some EDC solutions might provide some benefits but Sponsor CTMS solutions are either not available to sites, or, are not helpful. To address this, vendors are either providing extensions of their EDC solutions to support Site CTMS functionality, or, are extending their Sponsor CTMS tools to include Sites as stakeholders. I personally favour the latter. Many of the tasks and activities that are manually recognised in the lifecycle of a trial and recorded in Sponsor CTMS solutions come from the site. These are ‘gathered’ largely manually using Excel, Emails and on site monitoring.

Sites ideally want to use the same instance of a system across trials and even across sponsors.

Yes, they might want to work on a single trial at a time, BUT that does not mean they must be forced to go to another website with another password!

This requirement has implications on the existence of the software to the site outside the scope of a single trial or sponsor. Veeva made some progress here with the release of the Veeva Site Vault product. This allow a single Site Vault setup to be used by a site with a single login, and for the site to have multiple Veeva studies from one or more sponsors. However, the original product was limited in functionality servicing the sponsor more than site – Veeva have announced potential enhancements here for later in 2025.

One of the enduring frustrations for sites is the lack of interoperability between systems. Even when EDC platforms support multi-trial or multi-sponsor usage, integration with other essential systems—such as eConsent, ePRO, or laboratory portals—is often limited or proprietary.

Sponsors often opt for bespoke integrations that suit their internal workflows, with little thought given to how these decisions impact site efficiency. Conversely, sites are left stitching together disparate systems, re-entering the same data across platforms, and juggling multiple credentials and interfaces.

If we are serious about “EDC for All,” we must adopt and apply shared standards that ensure systems speak the same language and that data can flow smoothly between stakeholders without rework. FHIR and HL7 show promise, but their adoption has been patchy at best in the clinical research domain. Industry leaders, regulators, and vendors must collaborate to promote open APIs, interoperable data formats, and certification of systems that adhere to these principles.

Integrations should be a standard feature, not a service CROs profit from by choosing not to implement..

Until then, we risk embedding inefficiencies that disproportionately burden sites while sponsors continue to benefit from consolidated control.

Conclusion

It’s time we reframe EDC as more than a sponsor-driven database and start recognising it as a shared operational platform for all clinical trial stakeholders. The historical design bias toward sponsor priorities may have been inevitable when EDC first emerged, but it is no longer justifiable.

We now have the technology—and arguably the regulatory momentum—to build and deploy systems that empower sites without compromising sponsor oversight or data integrity. That means designing for shared governance, multi-stakeholder value, and real-world efficiency.

Sites aren’t just passive data recorders. They are central actors in clinical trial execution. The systems they use should reflect that. EDC for all isn’t just a slogan—it’s a requirement for modern, patient-centred research.