Last month, clinical trials professionals gathered for CRIO’s webinar, “From Hesitation to Confidence: Should Sponsors Provide Source Document Templates to Sites?” The panel discussion featuring Doug Schantz (Asklepios BioPharmaceutical), Edye Edens (EDEE Law), Dr. James Clark (Alcanza), and Melissa Gottschlich (ICON), moderated by CRIO co-CEO Raymond Nomizu, sparked tremendous engagement from the audience.
With more questions submitted than time allowed, we’ve compiled comprehensive answers to the questions raised during the session. Whether you’re a sponsor considering centralized eSource, a site evaluating platform options, or a CRO navigating implementation challenges, these insights address the practical, regulatory, and operational considerations that matter most.
Data Management and Access
Q: Who has ownership of the data if it is funded by the Sponsor. Does the site keep full access?
Sites maintain ownership over their data. CRIO archives the data for 25 years post-study to meet sites’ regulatory obligations.
Q: Another reason commonly given for why sponsors should not provide source templates is that a source template will have duplicate data that already exists and either the CRA will not look at the primary source or the CRA will have to reconcile discrepancies.
As defined by 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.” Generally speaking, site staff should not be capturing data elsewhere and then entering it into an eSource system. If there is an exception, the site user can note that the data entered in eSource is secondary and attach the underlying PDF.
Q: Why not use EDC directly as a Source?
The FDA has indicated that direct data entry into EDC is permissible. For instance, in the 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. Traditional EDC systems do not naturally follow site workflows, making contemporaneous data entry and intra-site collaboration extremely difficult. Moreover, there is usually significant additional data sites need to capture beyond what is traditionally in the eCRF.
Learn more here: https://clinicalresearch.io/blog/esource-vs-edc/.
Data Quality and Protocol Compliance
Q: How does Central eSource prevent protocol deviations? Will the eSource system have the same edit checks designed in the EDC system?
eSource edit checks are designed to guide site staff through the workflow as data collection is happening and prevent errors before they occur. For example, if vitals should be checked 30 minutes after an IP injection, the system can prompt the coordinator with the correct time to check vitals. The system can also notify the site when a value is out of range, so the site can confirm the value and take appropriate action during the visit. EDC queries and edit checks by design are intended to clean up data after the fact. That said, eSource edit checks should lead to better quality data, resulting in fewer queries in the EDC.
Q: Please help me understand how Central eSource leads to fewer protocol deviations—is this because the deviations are discovered sooner and not repeated? The protocol is still the reference document.
Yes, partially. The eSource template contains real-time edit checks that prevent non-compliant data entry upfront, automated alerts when protocol violations are about to occur, logic checks that guide proper workflow (e.g., enforcing time windows between procedures), and continuous monitoring access allowing sponsors to catch and correct deviations before they recur across sites. The protocol remains the reference document, but the system enforces its requirements during data collection.
Q: How does Central eSource reduce the likelihood of data entry error? With the traditional model, monitors review source data at sites and catch mistakes made in EDC entry, e.g., weight entered in kg vs pounds.
eSource can significantly reduce the number of errors in data capture through features like real-time edit checks that prevent non-compliant data entry upfront, automated alerts when protocol violations are about to occur, logic checks that guide proper workflow (e.g., enforcing time windows between procedures), and continuous monitoring access allowing sponsors to catch and correct deviations before they recur across sites. The primary difference between the checks done in eSource and those done in EDC is that eSource checks are happening during subject visits, preventing errors rather than cleaning data up after the fact. In your example, a weight captured in kg vs. lbs could be caught through out of range checks on either weight or BMI.
Q: Central eSource could also prevent late entries and/or the need to add progress notes when information in the protocol changes. Do late entries and progress notes entered at different times hurt sites in the eyes of the CRO/Sponsor?
Generally speaking, many sponsors prefer sites that use eSource because it provides more transparency around when data is captured and who is entering it. Many of the features increase compliance and create a positive impression. In our experience, sponsors fully understand that sites do sometimes make late entries and often perform retrospective data reviews that could result in additional explanatory progress notes with a later time-stamp.
Q: Comment: There was a comment earlier about missing data points, since we cannot see EDC forms until we have that first patient. I think that has been understated. We almost always miss a data point even with fully annotated eCRF guidelines and have to go back to make corrections, only after that first patient is pushed through.
Perfectly on point, thank you.
eSource vs. EDC
Q: Isn’t the core of the challenge that we are designing the EDC incorrectly?
There is some important insight here and perhaps someday the industry will be ready for a more comprehensive shift in how data is collected and managed, but it is important to understand that as it exists today, eSource and EDC systems serve different purposes and operate with different constraints. While it is permissible to directly enter data into EDC (using the EDC as eSource), most EDC systems have major limitations that prevent them from being effective site-based eSource systems. Learn more here: https://clinicalresearch.io/blog/esource-vs-edc/.
Q: With the eSource validation containing edit checks as the EDC, it is basically a ‘copy’ of the EDC. As per GCP, we should not collect any data that is not required for the trial and hence, the eSource usually does not have more data than what must be collected by the trial protocol through the EDC.
There is usually significant additional data sites need to capture beyond what is traditionally in the eCRF—this data is often the workflow data that is specified in the protocol, such as how to collect the vitals, what type and how far back to collect medications, which body systems to include in a physical examination, or how IP accountability is to be calculated. Think of the protocol as a detailed instruction set—the sponsor wants to know the data that results at the end of each procedure, but doesn’t necessarily need to know all of the steps the site takes to execute those procedures. The eSource contains both the result data and the workflow data. With EDC integration, the overlapping data can be sent into the EDC.
Q: Comment: The main problem when creating source is that EDC completion guidelines, the protocol and blank CRFs do not always show the data that will be required. As a site, we try to be ready for data collection, but difficult to do if we cannot tell from what we are given, what it is that we need to collect. Potentially if the Sponsor provides the source, these unknowns are worked into that source.
Yes, the source should have all the data that the site needs to collect, and would contain more data than what’s in the eCRF for the reason you indicated. In addition, when integrated with the EDC, the centrally furnished eSource template should by design prompt the sites to collect all the data anticipated to go into the EDC.
Implementation and Adoption
Q: How do you handle studies where not all sites opt-in to Central eSource? Especially in studies that have academic sites who have limitations on certain technologies that can be used?
One of the benefits of this model is that it doesn’t require all sites to opt-in to see a benefit. The sites that choose not to opt-in continue to work in parallel, creating their own source using their existing systems and processes and then manually entering into EDC. Sites that do opt-in benefit, and sponsors see the benefit even without 100% adoption. For studies currently using this model, we typically see opt-in rates between 60-80% depending on the mix of site types and therapeutic areas.
Q: If the site is working with a non-CRIO CTMS or eSource platform, how do these (CRIO) sponsor-provided templates work for those sites?
Sites opting into Central eSource would use CRIO’s platform for that study. However, participation is voluntary—sites can opt out if they prefer their existing systems. Many sites already use CRIO for other studies, so sponsors can leverage existing site adoption. The site would not have access to the centralized template if they opt out, since the build is system-specific. In CRIO Central eSource studies, we typically see opt-in rates between 60-80%.
Timing and Efficiency
Q: How can eSource assist in speeding up enrollment? I don’t quite get that.
Sites reach first patient in (FPI) a lot faster because they don’t have to spend time building the source template. On average, sites that opt in have 30-40 days faster time to enrollment. Thus, the enrollment window is longer.
Q: But usually the critical path for enrollment is regulatory approval, not the design of any source template…
While this may be true for the study overall, at the individual site level, the site cannot start enrolling subjects until the source is built. The data we’ve captured shows that individual sites are often delayed by the time it takes them to translate the protocol into source, sometimes by as much as 30 to 40 days.
Q: Since sites receive IRB approval on amendments at different dates, how will the release of these amendments be managed to ensure amendments aren’t being released too soon (before site receives IRB approval) or too late?
A template can be sent to different sites at different times, so it should be timed to IRB approval. Coordination is key and the sponsor, sites, and CRIO need to work carefully to plan the deployment site by site depending on when each site receives IRB approval to proceed with that protocol amendment.
Q: What is the usual turnaround time for source templates to be updated based on a protocol amendment from the time of IRB approval to implementation? Any general timeline?
This obviously depends on the complexity of the changes introduced by the amendment, but for reference the standard build time for a complete new study is 6-8 weeks, so generally an amendment would be significantly faster. We work to be very responsive to client needs.
Q: How long would it take to design and validate an eSource system?
The core CRIO system is validated and extensive documentation is available for sponsors and sites to review. If sponsors have additional testing requirements outside of this, it would depend on those requirements.
Integration and Technical Considerations
Q: With all the different systems that Sponsors and CROs use, would that make CRIO responsible for ensuring the integration between CRIO and their EDC systems?
Yes, CRIO would work with the EDC vendor to build out the integration. CRIO currently offers integration with the two largest EDC vendors as well as our own fully integrated EDC system. We are open to evaluating the possibility of integration with additional systems in the future.
Q: For Central eSource and EDC integration, this would require both to be from CRIO? If EDC is a different system, is it fair to say integration is not possible?
No, CRIO can integrate with other EDC systems. We currently offer integration with the two largest EDC vendors as well as our own fully integrated EDC system. These integrations are built on CRIO’s API and could be expanded to other EDC systems if there is sufficient interest.
Q: How does the eSource and EDC integration work? Who’s responsible for the validation?
Typically, CRIO and the sponsor will validate. Sites then have a module they can use to trigger the data send. It’s still human in the loop—i.e., it’s incumbent on the site to transfer the data over, so that the site remains ultimately accountable.
Q: What back up is available in case the system does not work when a participant is at the site for a visit? Helpdesk support would be vital (in any electronic system that is used)?
CRIO provides 24/7 live, multilingual chat support. Sites should have backup procedures defined, and CRIO’s customer service team can address technical issues in real-time. (Our recommendation is for the site to download the PDF version of the eSource templates in case of a system/Internet outage.)
Monitoring and Oversight
Q: What impact does eSource have on site monitoring efficiencies?
It enables remote monitoring at scale, may reduce source data verification (SDV), and facilitates faster site data review because the source is easier to view, more standardized, etc.
Q: Could you please explain how you ensure PI’s ‘oversight’ for every single visit?
The system includes contemporaneous principal investigator (PI) signature collection, ability to continuously lock visits with PI review, real-time visibility for PIs to review data as collected, and audit trails showing who collected and reviewed each data point.
Site Training and Customization
Q: When a coordinator designs source templates, it helps them learn the protocol in great detail. Although I like the idea of source being provided, it could create issues with the coordinator not knowing the study as well as they should.
This is an excellent point as many sites do use this as an opportunity to familiarize themselves with the protocol. First, it is important to still do a thorough review and training on the source templates. Another suggestion from one of the other commenters was to do a mock visit to walk through everything prior to the first subject visit.
Q: Who at the site would be best to modify the eSource?
Depending on the site, this may be done by either a coordinator or a designated study design person. In some cases, the sponsor has contracted with CRIO to make site level modifications and customizations based on site requests.
Q: Centralized source provided by sponsors in my experience has always been appreciated. However, there could be improvements in the creation of source if the sponsor worked with a site to confirm accuracy of the source.
The panel agrees.
Domain-Specific Considerations
Q: Based on the experience and adoption of these types of eSource solutions, are there more problematic domains—e.g., AEs, Conmeds that require more workflow design support than others?
This is pretty variable depending on the protocol. An advantage CRIO has is that our study design team has been assisting sites in building studies for many years. We are used to working with complex protocols, and from a study build perspective creating a centralized template on behalf of the sponsor isn’t different from what we have long done for sites.
Q: Has this been used for RWE where the data is not mandatory and increased compliance is always helpful?
For RWE studies, the source would be entirely within the EHR. In that case, CRIO’s system can function as an EDC, and our system has been used this way. We’d be happy to discuss this option in more detail.
Emerging Technologies
Q: Does CRIO use AI for building source templates?
CRIO is currently developing AI tools to assist in source builds, and plans to make this available to our site clients at some point in the future.
Q: Please discuss the use of AI in this.
Currently, all of the features we are discussing utilize traditional technology. We are currently investigating the use of AI for source builds, but this is not a generally available feature yet. We also see future application of AI in assisting in integration and data transfer, but this is not something available today.
Funding and Business Models
Q: Who funds the Centrally Designed eSource?
The sponsor pays for Central eSource. Sites that are existing CRIO clients are not charged for that study if they opt-in.
Q: Do you foresee any issue convincing sponsors to opt-into the central eSource system? They would have to dedicate a significant amount of time and continued resources to provide these to sites.
Any change in the status quo can be difficult, but we are seeing a substantial increase in both interest and adoption by sponsors as they view the potential benefits as being worth the application of additional resources.
Q: Can CRIO eSource be implemented in the Healthcare Reimbursement Workflow of an Institution? If so, how?
Potentially, yes. We would need to understand more about the workflow, but when sites are using both CRIO eSource and CRIO CTMS they are able to tie invoicing directly to procedures completed in eSource. That said, CRIO does not currently have a feature to differentiate Standard of Care vs. Research billing by line item.
Key Takeaways
The webinar questions reveal several consistent themes:
Flexibility is essential. Sites need options that work within their existing infrastructure while sponsors seek standardization. The voluntary opt-in model allows both needs to be met.
Speed to enrollment matters. The 30-40 day reduction in time to first patient enrollment represents a significant advantage for sites and sponsors alike.
Data quality improves with real-time validation. The shift from post-hoc data cleaning to prevention during data collection represents a fundamental improvement in clinical trial operations.
Integration challenges are solvable. With established integrations to major EDC systems and an API-based architecture, technical barriers continue to decrease.
The industry is evolving. The high engagement with this topic and the 60-80% opt-in rates demonstrate growing acceptance of centralized eSource approaches.
For those who missed the live discussion or want to revisit specific topics, the full webinar recording is available here.
The conversation around sponsor-provided source templates is shifting from “whether” to “how.” As more sponsors and sites gain experience with centralized eSource, the practical benefits are becoming clear: faster enrollment, improved data quality, reduced burden on sites, and enhanced protocol compliance.
Whether you’re considering implementing centralized eSource for the first time or looking to optimize your current approach, these questions and answers provide a comprehensive foundation for making informed decisions about the future of your clinical trial operations.