eSource vs EDC – What’s the Difference?

What is eSource?

According to the FDA, eSource is defined as “data initially recorded in electronic format. They can include information in original records and certified copies of original records of clinical findings, observations, or other activities captured prior to or during a clinical investigation used for reconstructing and evaluating the investigation.”

eSource is already widely used in clinical trials. Common examples of eSource include:

• Rater and patient reported outcomes (“electronic clinical outcome assessments”, or eCOA)
• Data from clinical instruments such as imaging equipment, ECG machines, or wearable devices
• Lab data from a Laboratory Information Management System (LIMS); or
• Electronic Informed Consent Forms (eICFs)

However, clinical research sites have historically not captured their source data in a sponsor-funded, electronic application. As a result, sponsors don’t have direct access to site source data, and therefore require that sites transcribe their source into the study’s Electronic Data Capture (“EDC”) system, which houses Electronic Case Report Forms (“eCRFs”). eCRFs are discrete and related datasets that often mirror site procedures. Typical examples of eCRFs include Demographics, Eligibility, Vitals, Urine Pregnancy Test, Physical Exam, Medical History, Concomitant Medications, Adverse Events, IP Accountability and Subject Status.

In this context – and for purposes of this blog post – eSource refers to the use of an electronic system to capture site source data.

Why sites don’t use the EHR as the source data collection tool.

EHR systems are designed for health care workflows, not clinical trial workflows. As a result most sites do not utilize an Electronic Health Records (EHR) system to capture study-specific source data (see our white paper, “A Comparison of EMR and eSource Data”). The biggest obstacle is that EHR templates are usually not flexible enough to accommodate the needs of a trial. For instance, there is no concept of an “Adverse Event” in an EHR system – an “Adverse Event” is a protocol-specific concept that is highly contextual to the study.

What most sites do is create paper worksheets using Microsoft Word or a word processing program. They translate the protocol requirements into worksheets, print out the worksheets on the day of the visit, and then complete them by hand.

How widespread is site eSource?

Site-based eSource is one of the fastest-growing categories of software in clinical research. CRIO is the leading site-based eSource provider and licenses its software directly to sites. Today, we estimate that 20% of US-based research sites have adopted eSource. The vast majority of these sites are using CRIO eSource.

This adoption is especially concentrated among higher-performing, more professional sites, including the emerging class of site networks. These networks, many of whom are backed by institutional investors, are using eSource to improve productivity and increase standardization (see our white paper, “The Reinvention of Site Networks, Part 2”). As these networks expand, so will eSource utilization.

For instance, on the Pfizer and Moderna COVID-19 vaccine trials, which relied heavily on site networks, over 30% of the U.S. sites are current CRIO clients. Across the majority of indications, there are enough CRIO eSource sites to power an entire study.

So if sites are capturing data this way, why do we need an EDC?

eSource lets sites capture data in the context of a site-based workflow system. However, eSource, by itself, does not facilitate the workflows sponsors need to review, query and lock the data before extraction – features that EDC systems have.

CRIO has solved this problem with an integrated eSource-EDC solution. This unique solution has three components:

Effectively, Reviewer is the EDC on the trial. But unlike the traditional model, the site does not have to re-enter data into the EDC, and the sponsor does not have to perform Source Data Verification of that data.

The benefits of the integrated CRIO model to the sponsor should be obvious:

• Higher quality data (as the edit checks fire during data collection, not afterwards)
• Immediate access to site data; and
• Lower cost

For a full explanation of our model, see our primer “Today’s Broken EDC Model vs The CRIO Model”.

Why can’t CRIO send the eSource data to the EDC vendor of my choice?

Our experience is that this is a subpar experience for sponsors. The CRIO integrated model is superior to an eSource-to-third-party-EDC API because:

1. There is only ONE study build in the CRIO model. Both the eSource and the eCRF templates are one and the same. If CRIO eSource were to integrate with another EDC system, the sponsor would have to build two separate templates, then do a mapping between the two. That’s three separate bodies of work, not one.
2. Very few EDC systems, in our experience, have a robust API that allows for seamless integration. The cost of building and validating an integration – using engineering resources – probably ends up being the same as the cost of entering the data manually.

What if I want to work with sites that are not already using CRIO eSource?

As a general rule, sites are free to use the electronic system of their choice to collect source data, so long as the system is 21CFR11 compliant. Thus, a sponsor would not ordinarily dictate how a site should collect their source data.

However, a sponsor may contractually require a site to use a specified eSource system as a condition of participating in the study. CRIO’s experience is that over 95% of sites would elect to utilize CRIO if it were a condition of the study. Since CRIO eSource was built for sites, the sponsor has assurance that its workflows will be intuitive to new sites.

So why can’t sites just enter data into the EDC?

The FDA has indicated that direct data entry into the EDC is permissible. For instance, in recent FDA DCT guidance, the FDA indicated that certain trial-related activities can be performed by local healthcare providers (HCPs): “If the local HCPs have access to the eCRF, they can enter trial-related data directly into the eCRFs” and “Remote trial personnel or local HCPs submitting trial data directly into the eCRF should be included in the sponsor’s list of authorized data originators.”

However, most EDC systems have major limitations that prevent them from being effective site-based eSource systems. Just as a site-based eSource system cannot meet sponsor needs, a sponsor-based EDC system cannot meet site needs effectively.

EDC Limitations

Here are some of the limitations of most EDC systems:

1. They do not have complete workflows for a site. Here are example workflows that CRIO eSource has, which are critical to optimal site usage and acceptance:
   • Ability to house PHI at the patient level so that sites know who they are dealing with and how to contact them;
   • Ability to schedule visits on a unified site calendar with built-in window calculations, and ability to program site-specific appointment reminders;
   • Ability to collaborate internally as a team through intra-team messaging and task assignment revolving around the study.
2. They do not have features that enable real-time data collection in a way that is consistent with site workflows.
   • For instance, most EDC systems house dynamic logs such as Conmeds or AE outside the visits, even though review and update of those logs is usually part of the visit. CRIO is different. The platform pulls the current version of the log at each visit. It then asks the site to confirm if there have been changes. By surfacing the current version of the logs within the visit, CRIO ensures consistent and accurate review.
3. They do not give the sites direct and permanent control over their source data.
   • In a unitary EDC-as-direct-entry system, the sponsor has ultimate control over site source. Many sites – and some regulators in Europe – have expressed concern over the lack of direct PI control over source records.

So while direct-to-EDC data entry is permissible under FDA guidance, the most realistic use cases are for targeted uses such as a health care provider or centralized rater capturing limited datasets. It is rarely scaleable for the clinical research site, who have complex workflows and user requirements.

How does the eSource template differ from an EDC template?

Like an EDC template, the eSource template should contain the data points required to power the statistical analysis and the Tables, Listings and Figures (“TLF”).

Unlike an EDC template, the eSource template should be a workflow tool for the sites to promote protocol compliance. Thus, the forms should contain rich, detailed instructions, and more granular questions that induce, and document, site compliance with the protocol.

For instance, an eCRF for Vitals really only needs three data points for purposes of statistical analysis:

1. Date/time of procedure
2. Systolic
3. Diastolic

However, the eSource version should contain data points that demonstrate compliance with the methodology specified in the protocol:  e.g., the patient’s position, the time the patient has been in that position, the arm used, and/or the blood pressure cuff used.

Writing eSource templates is a specific skill. At CRIO, we design the templates as a service. We use the protocol as our guide, writing the template to drive compliance. We then use a “Core” flag to designate the subset of fields required for the TLF. The “Core” flag is helpful for the sponsor to perform risk-based monitoring. It allows them hone in on the most critical data points that will influence the analysis.

We’d love to give you a walkthrough. To learn more about our integrated eSource-EDC solution, book a demo here.