Thank you to everyone who joined us for our recent webinar, “Bridging the Gap: EHR to EDC Integration in Clinical Trials – Reality Check.”
We received an overwhelming number of thoughtful questions during the session, and while we addressed many live, we know there were many we didn’t have time to cover. This follow-up post provides comprehensive answers to the questions submitted, organized by key themes.
Implementation and Setup
Timeline and Template Development
Q: How long does it take to prepare the eSource template and include the complete protocol into the template?
The typical timeline to build a central eSource template is 6-12 weeks based on protocol complexity.
Q: Will it also include treatment protocol?
The eSource protocol will contain instructions and questions that cover all data required to be completed by the site; this would include treatment protocols such as IP dispensation, accountability, or data around IP administration.
Site Requirements and Setup
Q: I still don’t understand what work the site has to do to enable eSource to EDC integrations.
In the Central eSource model, the site doesn’t have to do anything to enable the EDC integration – they are provided the system, the study template, and the pre-mapped integration. In the EHR model, there are different vendors, and at minimum, the site has to authorize EHR access and in some instances, install an app onto their EHR. This is not an onerous process from a technology perspective; it’s more a matter of organizational consent.
Q: In the Central eSource model (non-oncology), how does the panel envisage the ‘sending’ of eSource data to the EDC? My concern is most sites do not have the expertise to set up integrations.
There is no setup work required for the site. Instead, they will be able to use a highly intuitive interface to view their data and send it into the EDC with a click of the button. It’s an out-of-the-box solution from their perspective.
Technology Landscape and Vendor Considerations
Market Fragmentation
Q: What are the vendors in the eSource space? Do we have a large fragmentation and will the sponsor/CRO be facing multiple interfaces in proprietary format causing an increase in cost/complexity on their side for mapping these systems?
There are 3 major vendors in the US, and 1 additional vendor with presence in Europe. Not all of these systems may be able to support the Central eSource model. Moreover, some sites are willing to utilize a different vendor if it means not having to build a template and faster EDC entry through automation.
Speaking from CRIO’s experience, we have seen many late phase studies where 15-50%+ of the U.S. sites on the trial are pre-existing CRIO clients (see this blog post), and many of the remaining clients are paper-based. Therefore, Central eSource using CRIO could have 30-80% site adoption.
Q: Could you tell me what kinds of eSource systems are being used at the site in the US?
eSource vendors in the US include CRIO, Advarra, and Real-Time. Some of these systems may have global capabilities. CRIO has multi-lingual software, source template translation facilitation, and global help center support. For more information about CRIo’s global capabilities, check out this blog post.
EHR vs. eSource Strategy
Q: Since there is no single universal eSource solution, isn’t this not adding another layer of technology versus continuing to improve the EHR-EDC integration since we have a couple of EHRs which are used more broadly?
- EHR-EDC integration will not help with the sites who are not using an EHR to collect data; that’s like asking a grocery store to purchase and install bank software – it’s simply inapplicable. These sites constitute the VAST MAJORITY of the sites on trials in CNS, metabolic, vaccine and other TAs. Further investment in EHR-EDC integration will therefore not help with a lot of these trials.
- For these non-EHR sites, a site eSource solution is the ONLY viable electronic platform that would facilitate electronic data collection. The alternative is that these sites utilize paper.
- There are a limited number of site eSource solutions. CRIO is the market leader, and there are 2-3 other players in the U.S. and 1 in the EU that have material commercial traction.
Data Quality and Accuracy
EHR Data Reliability
Q: Can you give example(s) of inaccurate data you have seen in EHRs?
Medication lists are often inaccurate. They may contain medications the patient is not actually taking (ie, they were prescribed once, but never filled); or may have incorrect or incomplete start dates; or may omit medications (ie, they are prescribed by other providers).
Diagnoses are notoriously inaccurate and incomplete for similar reasons. Sometimes, a single condition may have received differential diagnoses, resulting in multiple incorrect or outdated diagnoses. Sometimes, a provider will put down a diagnosis for insurance purposes.
Source Data Verification
Q: With Central eSource, is there still SDV activity that has to go and find the source that may reside in an electronic health record?
Yes, there often remains the step of confirming elements of the eSource such as eligibility, medications or adverse events against an underlying medical record. Sites frequently prepare medical records as part of the source binder, and in the case of eSource, can upload the PDFs for remote monitoring. Regardless of how the source data is captured (ie, Central eSource, local eSource, paper), this exercise needs to be done.
Regulatory and Compliance Considerations
GCP Compliance
Q: How does the fact that many EHRs are not regulatory compliant systems under GCP or other clinical trial regulations, impact any of this process?
It doesn’t impact this process. As part of Lilly’s site selection process, we review the source systems used by sites to ensure they meet our standards for systems controls and validations before the site is selected. We also rely on Ignite Data’s analysis of the site’s EHR fit for purpose and conformance to FHIR standards to enable the integration on the front end.
Q: From your experience, have any of the IRBs/RECs and Regulatory authorities required review and approval of the mapping process?
No. IRBs are focused on aspects of the clinical trial that involve the patients’ rights and safety. By implementing EHR to EDC, we are actually increasing the quality of the data in our EDC and the timeliness in which that data becomes available to us.
Privacy and Data Protection
Q: What are the safeguards in place for ensuring that PHI is not mistakenly sent to the EDC?
The only data that is sent to the EDC is pre-mapped source fields, which should not contain PHI. It is theoretically possible a site could populate PHI in an inappropriate place; for instance, under the “medication” field, they could populate “Joe Smith takes metformin’, but that is a fantastical scenario.
Q: What about interoperability of data when we have more and more patients crossing borders in the EU?
Both EHR-to-EDC and Central eSource can have data captured by the site sent into the EDC without PHI leaving the site system. Therefore, both models can work across geographic borders.
AI and Future Technologies
Role of AI in Data Integration
Q: Clearly we all agree that there is a major issue with the diverse set of systems and multiple modalities where data is captured and shared and ultimately require transformation for the purpose. Where do you see LLM based models and tools could play a role to help unify this issue?
Both EHR-to-EDC and Central eSource rely on transmission of pre-mapped, structured data, so AI is not needed. Central eSource can cover most of the eCRF, but EHR cannot, as much of the EHR data is unstructured. Therefore, AI could be helpful to permit the user to populate the eCRF by searching and interpreting the EHR. However, this AI development is still in the early stages.
Q: If we may see a reduction in monitoring, and are using AI for mapping, how will we catch potential errors/misassumptions if AI drifts over time or encounters new situations?
Current models do not utilize AI to do mapping; instead, the mapping is done while the eCRF is being built. Therefore, there is no current risk of mis-transcribed data as long as the mapping is validated.
Site Perspectives and Adoption
Site Preferences
Q: Would sites rather use their own eSource vs a sponsor providing Central eSource?
CRIO’s experience is that most sites prefer the convenience of a centrally designed eSource template because it alleviates a significant burden for them. That said, some sites do prefer using their own locally designed source templates.
Q: How many sites have engaged with CRIO so far?
CRIO has 2500 sites using the system in 30 countries.
Site Burden and Capacity
Q: With site staff working for multiple sponsors and CROs, how do they ensure they have the capacity in place to meet the expectations of timely enrollment and quality data entry?
This is the permanent challenge! Sites are in fact grossly understaffed and struggle to meet expectations. That is why the EHR-to-EDC and Central eSource models are so powerful – they help alleviate site burden.
Operational Considerations
Query Management
Q: How are queries handled?
Data queries are still issued in the EDC. The major models contemplate ‘human in the loop’ when it comes to EDC entry, so the site will still need at least one person who can perform/oversee complete data entry and query resolution.
System Updates and Versioning
Q: For transmission of data from Central eSource to EDC, how do updates to source affect EDC integration? What if a change to source needs to be made that affects the mapping/link to EDC?
Central eSource is versioned, just like the EDC. So when v2 of the protocol comes out, then a new v2 of the source gets published to the site, and this will map to the v2 of the eCRF.
Therapeutic Area Considerations
Oncology Applications
Q: Why can’t eSource not be used for oncology?
eSource can be used in oncology. It’s just that for many cancer trials, AMCs and cancer centers are used, and those sites tend to use the EHR as source, not industry eSource. Additionally, in oncology, the data captured for patient care and the data captured for research are more closely aligned than in other therapeutic areas. That said, some oncology trials utilize a significant number of community-based sites, and these trials could be suitable candidates for Central eSource.
Q: Where you have successful deployment of EHR-to-EDC in oncology, what proportion of the data can be acquired this way, vs. entered by site?
This case study assumes 50% of EDC data can be populated from direct mapping from the EHR; this is a reasonably achievable upper limit.
Cardiology Applications
Q: Is this used often in cardiology?
Yes, both models can be used in cardiology. Some complex cardio trials may be heavily AMC-oriented, so EHR-to-EDC could be appropriate. Others utilize community-based sites, so Central eSource could be appropriate.
Metrics and Efficiency
Performance Measurement
Q: Have you tracked efficiencies gained through implementing the EDC model, with actual metrics?
Since Lilly has not gone live yet, we do not have those metrics at this time. We have modeled the metrics we will be tracking. As soon as that metadata becomes available, we’ll be reviewing and reacting to them.
Q: The metric you provided was 8″/DP. Was that for manual entry? What is the goal for EHR metrics?
The case study from MSK’s pilot of EHR-to-EDC found an average of 3 minutes per data point for EDC data entry, and potentially higher for more complex data points.
Future Outlook
Long-term Vision
Q: How will the future look in 5 years from a site technology perspective? Will the site work with multiple EHR2EDC and eSource vendors at the same time? This will add further burden and complexity at the end. What’s the feedback from sites dealing with multiple different technologies?
AMCs utilizing EHR as source will likely continue to do so, and then only the “connector” technology would be different; the site still benefits. Sites using eSource will opt in to Central eSource if it’s their particular vendor’s system, since the same site login can be utilized; sites using a different eSource may still choose to switch vendors for the study given it’s a discrete study that has additional benefits such as EDC integration. This model is already in effect when it comes to eISF.
Q: The biggest issue with scale that we see in Pharma is how to minimize what looks like custom integrations to sites for this purpose. What do you think the solution is? How do we standardize the way we acquire data from sites if they all have different eSource systems or different EHR?
Longer term, the ecosystem could evolve such that a middleware vendor could serve as a single pipe, connecting multiple source systems into the EDC. This will take time.
Academic and Small Biotech Considerations
Academic Institution Challenges
Q: How are academic institutions receiving the need to map EHR-to-EDC given privacy concerns and does it potentially delay study start while negotiating this model specially for small biotechs with limited pipeline of trials?
We are only starting this at academic sites where Ignite Data has an engagement. Ignite has to do all of the start-up work anyway to map their FHIR server to Archer. If a site does not already have an established engagement with Ignite Data, that can be started while the study is on-going during that time we implement normal transcription into EDC. EHR-to-EDC capability can be easily turned on while a study is active.
Patient Benefits and Sponsor Value
Q: From a sponsor perspective, which stakeholders gain the most value from EHR-to-EDC integrations? Beyond operational efficiencies, is there a direct benefit to patients?
Sites and sponsors clearly benefit from EHR-to-EDC integration. One direct benefit to patients is their data is received by the sponsor much sooner and much cleaner. The data received through the integration is still fully deidentified. We are just connecting patient record identifier (EHR) to participant identifier (EDC). That linkage allows us to ensure all safety events are appropriately tracked. Lastly, EHR data may not be shared with a sponsor without the patient’s explicit informed consent.
Looking Forward
The questions from our webinar demonstrate that the clinical research community is actively working through the practical challenges of implementing data integration technologies. While both EHR-to-EDC and Central eSource models present unique opportunities and challenges, the common thread is their potential to reduce site burden, improve data quality, and accelerate clinical research.
We hope these responses provide some clarity around these challenges. As these technologies continue to evolve, we’re committed to sharing real-world experiences and lessons learned.
Have additional questions or want to dive deeper into any of these topics? We’d love to continue the conversation. Feel free to reach out to our team or join us for future webinars where we’ll continue exploring the latest developments in clinical data integration.
Thank you again for your engagement and for helping drive these important conversations forward.