Executive Summary

This report provides an in‐depth analysis of clinical data interoperability with a focus on HL7 FHIR, electronic source (eSource) data, and electronic patient-reported outcomes (ePRO). It surveys the historical development of the HL7 FHIR standard and examines how eSource and ePRO are enabling modern, patient-centric research and care. Key findings include: (1) FHIR adoption is surging, with the first normative FHIR release (v4.0.1) published in 2018 (^[1]) and global initiatives (e.g. ONC’s API Rule) mandating FHIR‐based interfaces. (2) eSource promises major efficiency gains by capturing study data directly from EHRs, devices or mobile apps, and industry studies suggest it can save on the order of 30–40% of data‐collection time compared to paper (^[2]) (^[3]). (3) ePRO technologies (patient surveys via web or mobile) are increasingly integrated into trials; for example, an oncology ePRO program reported collecting >13,000 patient entries with ~82% 12-month compliance (^[4]). (4) Despite potential, challenges remain: only about half of typical case-report form data elements map directly to FHIR resources (^[5]), and domains like custom questionnaires often lack EHR representation (^[6]). (5) Multistakeholder initiatives (e.g. TransCelerate, CDISC/PhUSE) are leading efforts to extend standards – for instance developing FHIR-to-CDISC mappings and new APIs to bridge EHR data into research databases (^[7]) (^[2]).

This report begins with background on clinical data standards and the need for interoperability. It then details HL7 FHIR’s evolution and capabilities, followed by definitions and use cases for eSource and ePRO. Subsequent sections analyze how FHIR is being applied to eSource and ePRO (including standards profiles and architectures), drawing on recent studies and pilot projects. We incorporate data from surveys, trials, and case studies (e.g. the I-SPY2 breast cancer trial, MD Anderson’s ePRO program) to quantify adoption and outcomes. Tables compare modalities (such as FHIR vs. eSource vs. ePRO features, and eSource categories). Finally, we discuss regulatory perspectives, stakeholder benefits and barriers, and future directions (including AI, real-world evidence, and patient-driven data exchange). All claims and examples are supported with extensive citations to industry reports, peer-reviewed studies, and official standards documentation.

Introduction

The modernization of clinical research and healthcare delivery has created an urgent need for interoperable data standards. Traditionally, research data and healthcare records have been kept in siloed, often proprietary formats, impeding data sharing and secondary use. In recent years, three concepts have come to the fore: HL7 FHIR (Fast Healthcare Interoperability Resources) as a modern healthcare data standard, eSource for capturing study data directly from digital systems, and ePRO (electronic patient-reported outcomes) for collecting patient‐generated health data. Together, these tools aim to streamline data flows from clinic to research and back, improving efficiency, data quality, and patient engagement.

HL7 FHIR is an interoperability framework developed by Health Level Seven (HL7) International. It uses a modular, “resource‐oriented” approach and modern web technologies (RESTful APIs, JSON/XML) to represent clinical entities (patients, conditions, observations, etc.). FHIR evolved as the successor to HL7 v2 and v3, with the first draft (DSTU1) released in 2014 and the first normative standard (Release 4.0.1) published in December 2018 (^[1]). FHIR’s broad adoption – bolstered by initiatives like the US 21st Century Cures Act and SMART on FHIR – has made it a cornerstone for exchange of EHR data, mobile app integration, and emerging applications in clinical research and public health.

Electronic Source (eSource) refers to the practice of directly capturing source data in digital form for clinical research, rather than transcribing from paper. This includes reusing data from electronic health records (EHRs), recording trial-related observations with devices or apps, and entering data directly into EDC systems at the point of care (^[8]) (^[9]). Regulatory bodies (FDA, EMA, PMDA, etc.) and industry consortia (e.g. TransCelerate) have for years encouraged eSource adoption as a means to improve data accuracy, traceability, and timeliness (^[8]) (^[2]). For example, TransCelerate categorizes eSource modalities into four types – EHR data import, device/app capture, non-CRF sponsor data, and direct data capture by sites (^[9]) (^[10]) – each supported by different technologies and standards. Potential gains from eSource are substantial: one study estimated a 37% time reduction in data collection when using eSource tools (^[3]).

Electronic Patient-Reported Outcomes (ePRO) are measurements of a patient’s health status coming directly from the patient, collected electronically (e.g. via web surveys or smartphone apps). ePROs cover symptoms, quality of life, and other subjective outcomes. ePRO systems replace paper diaries, enabling real-time, frequent data capture and integration with the health record or trial database. They are widely used in oncology, chronic disease trials, and patient registries to capture the patient’s perspective. Modern healthcare IT standards – including FHIR – are being extended to support ePRO. For example, HL7 has developed a FHIR implementation guide for Patient-Reported Outcomes, defining how to represent questionnaires and responses. Real-world programs validate the impact: MD Anderson’s ePRO system has collected over 13,000 patient responses with ~82% 12-month compliance (^[4]), and multi-site trials regularly deploy ePRO tools with measurable completion rates (around 50–80% of patients completing each questionnaire (^[4]) (^[11])).

This report explores the intersection of FHIR, eSource, and ePRO. After outlining each concept, we examine how FHIR is used to implement eSource and ePRO solutions in practice. We review literature on data standards mapping, discuss implementation architectures (including SMART on FHIR for ePRO apps and FHIR‐BRIDGE solutions), and analyze usage data from recent studies. Case examples illustrate successes and limitations. Throughout, we cite research findings, regulatory guidance, and expert reports to support conclusions. The goal is to create a comprehensive “cheat sheet” on clinical data interoperability today, providing stakeholders (researchers, tech implementers, policymakers) with a detailed, evidence-based reference on how HL7 FHIR, eSource, and ePRO fit into the evolving healthcare landscape.

HL7 FHIR: A Modern Healthcare Interoperability Standard

HL7’s FHIR is now the leading standard for clinical data exchange. It was created to address the complexity and limitations of earlier standards (HL7 v2 messaging and v3/CDA documents) by using a “resource” model and web-friendly technologies. FHIR organizes healthcare concepts into discrete resources (e.g. Patient, Observation, Condition, Encounter, etc.), each with a shared data model and unique identifier. Resources can be retrieved, created, or updated via HTTP-based RESTful APIs using JSON or XML.Key milestones in FHIR’s development include the first Draft Standard for Trial Use (DSTU1) in 2014 and the first normative release (R4, STU1) in 2018 (^[1]).

FHIR supports extensibility and localization through profiles and extensions. International implementers augment the core FHIR specification with country/domain-specific “implementation guides” (IGs) – for example, the US Core FHIR profiles, the Da Vinci project (payer workflows), or national EHR guides in Switzerland and Australia. FHIR’s flexibility allows it to handle a wide range of clinical content. For instance, the Research on FHIR (ROF) initiative and others have demonstrated mapping typical clinical trial data (demographics, labs, vitals, medications) to FHIR resources. In a Diabetes study pilot, investigators successfully extracted EHR data via FHIR to pre-populate eCRFs and even convert directly to CDISC formats (^[12]). Ongoing FHIR accelerators and connectathons continue to expand coverage; for example, new R5 components are in ballot.

FHIR adoption has been driven by both technology forces and regulation. Major EHR vendors now offer FHIR-based APIs. A pivotal event was Apple’s 2018 integration of SMART on FHIR into its Health Records app: when consumers could download their records via FHIR, healthcare providers rapidly had to publish FHIR endpoints to reciprocate this demand (^[13]). In the US, the 21st Century Cures Act Final Rule (2020) mandated that certified health IT products support certain FHIR APIs (including the Bulk Data Export for population data (^[14])). In Europe, the EU’s IDC/EPD regulation and national strategies are likewise embracing FHIR for patient data sharing. The HL7 Foundation (2025) reports that FHIR is “crossing the chasm” into mainstream usage, with clinicians, patients, and developers all investing in FHIR-based solutions (^[15]).

Adoption and Market Trends

Reliance on FHIR is evidenced by market reports and case studies. Industry analyses note that nearly all leading EHR systems now implement core FHIR interfaces (especially Patient, Observation, Medication, Allergy, Condition, and Encounter) (^[2]) (^[14]). For example, the ONC blog (Jan 2023) describes how HL7 and the SMART community developed the FHIR Bulk Data (Flat FHIR) standard to handle large-scale exports, and how US regulations now require EHRs to support it (^[14]). Reports estimate that tens of thousands of healthcare deployments worldwide use FHIR APIs for data exchange, patient access, and app integration. (Precise statistics vary, but one recent industry summary found that FHIR is at the core of most national interoperability initiatives (^[16]) (^[15]).)

Table 1 outlines key characteristics of HL7 FHIR, contrasted with eSource and ePRO (which are not standards per se but modalities for data capture). This comparison illustrates that FHIR is a broad exchange framework, while eSource and ePRO represent specific use cases/applications built on such frameworks. (Further tables later detail eSource modalities and comparisons.)

Table 1. Comparison of HL7 FHIR, eSource, and ePRO (core definitions and examples). Sources: HL7 timeline (^[1]); TransCelerate commentary (^[8]); FHIR integration case studies (^[2]) (^[7]); MD Anderson ePRO data (^[4]).

Electronic Source (eSource) in Clinical Research

Definition and Scope: In clinical research, source data are the original records containing observations (patient charts, lab reports, device logs, etc.). eSource refers to originating those records in electronic form. Instead of humans copying data from paper CRFs into a database, eSource seeks to have data captured once – in its digital system of origin – and transmitted directly for research use (^[2]) (^[3]). TransCelerate categorizes eSource into four modes (^[9]) (^[10]):

• EHR Data Reuse (EHR): Leveraging a patient’s electronic health record (EHR) data for trials (e.g. retrieving vitals, medications, diagnoses from the clinic’s EHR).
• Devices & Apps: Recording data from patient-facing devices or apps (e.g. wearable glucose monitor, mobile symptom diaries) into the trial database.
• Non-CRF Sponsor Data: Importing structured data produced by sponsor-run systems (e.g. central labs, imaging vendors) directly into the clinical database.
• Direct Data Capture (DDC): Having site staff enter data electronically at the source via mobile apps or EDC interfaces (effectively replacing paper diaries or phone calls).

Table 2 summarizes these modes, with examples. Each modality uses different technology: for instance, EHR reuse typically relies on standards like HL7 FHIR or CCD/CDA, while devices/apps might use APIs or custom integrations.

Table 2. eSource categories (per TransCelerate) with research examples. FHIR and APIs often underlie EHR and app integrations.

Regulatory and Standards Context: Although comprehensive eSource guidance is still evolving, regulators have long encouraged electronic data capture to improve quality and compliance. The FDA has issued guidances on eSource and specifically on using EHR data in trials (^[18]). For example, the FDA’s 2018 guidance “Use of Electronic Health Record Data in Clinical Investigations” acknowledges the potential of direct EHR-to-research data flows. Likewise, the UK’s Medicines and Healthcare Products Regulatory Agency (MHRA) and the EU’s GCP guidance emphasize data integrity and ALCOA+ principles, which eSource can support by reducing transcription errors (^[19]). However, sponsors must still ensure that eSource systems comply with 21 CFR Part 11 (electronic records rules) and maintain traceability (audit trails) of all changes.

Benefits of eSource: eSource can streamline clinical trials by eliminating redundant data entry, minimizing errors, and enabling near-real-time data access (^[20]) (^[21]). TransCelerate’s vision (the “eSource Logical Architecture”) is an end-to-end digital pipeline: data flow from eSource capture (EHR, devices, etc.) straight into the sponsor’s data warehouse or EDC, enabling real-time safety monitoring and analytics (^[21]) (^[22]). For example, eliminating double entry in case report forms is cited as a key benefit (^[20]) (^[22]). Published analyses quantify these gains: one study found 37% reduction in time for data capture and registration when using eSource tools (versus traditional paper methods) (^[3]). Another decision-analysis estimated substantial cost savings and faster trial timelines with full eSource adoption (e.g. EHR-to-CRF feeds) (^[23]). Moreover, eSource supports remote/off-site monitoring and source data verification, important trends accelerated by decentralized trial designs.

Challenges and Coverage Gaps: Despite its promise, eSource adoption remains limited and exhibits several challenges (^[8]) (^[24]). A 2020 TransCelerate survey noted that industry uptake is “fragmented and slow” (^[8]). Technically, harmonizing data across disparate EHR systems is complex; sites have idiosyncratic workflows and may record the same concept in different ways. As a result, mapping from EHR to trial variables is not always straightforward. A recent study quantified this limitation: Garza et al. (AMIA 2020) mapped actual CRF fields from multi-site trials to FHIR. They found that only 51% of distinct CRF data elements were directly “available” in FHIR, with study-specific ranges of ~45–79% (^[5]). In practice, this means that roughly half the data still must be entered manually or obtained through other means. Notably, the gaps tended to occur in domains not routinely documented in EHRs: for instance, questionnaires or protocol-specific assessments had no direct record in the medical chart (^[6]). TransCelerate likewise observes that some trial metadata (e.g. inclusion/exclusion criteria, study-specific adverse event reports) have no natural EHR equivalent.

Other barriers include data quality and verification: ensuring that EHR data meet GCP standards can require additional validation steps. Sites may be reluctant to allow direct EHR data feeds due to privacy or contractual concerns. Implementation also involves organizational change – IT teams, clinical staff, and monitors must adopt new tools. A TransCelerate whitepaper recommends engaging sites early and designing user-centered workflows so that eSource “does not increase the burden” on sites or patients (^[25]). Finally, there are regulatory differences globally: as of 2025, there is still no single unified guidance on eSource, so sponsors must navigate FDA, EMA, PMDA, etc.

eSource and HL7 FHIR: The FHIR standard is increasingly seen as a key enabler of eSource. FHIR provides a common format and API for EHR data, which sponsors can leverage to retrieve trial-relevant information. As noted, HL7 FHIR can be used to pre-populate CRFs: for example, a TransCelerate presentation pointed out that “future use cases may utilize HL7’s FHIR to focus on pre-populating clinical research CRFs with EHR data” (^[2]). Indeed, several pilot projects demonstrate this: PhUSE/ROF and CDISC have shown prototypes where patient data (e.g. labs, vitals, medications) are fetched via FHIR and automatically mapped into CDISC CDASH/SDTM fields (^[7]) (^[12]). This EHR→FHIR→ODM(EDC) pipeline can significantly reduce manual transcription.

FHIR also supports specific eSource tasks. For patient enrollments, FHIR Questionnaire and QuestionnaireResponse resources (coming from the PRO IG) could record patient-reported eligibility forms directly into the system. FHIR DiagnosticReport and Observation resources can carry lab/device readings straight from their source. And FHIR bulk data export allows a site or HIE to push large batches of patients’ data (for e.g. retrospective data collection). In short, by adopting FHIR-based interfaces, sponsors gain a standardized, EHR-agnostic way to access source data.

Electronic Patient-Reported Outcomes (ePRO)

Definition and Importance: Patient-reported outcomes (PROs) are any health data reported directly by the patient, without interpretation by clinicians. Historically collected on paper diaries or during visits, PROs record symptoms, quality-of-life measures, and functional status. Electronic PRO (ePRO) systems digitize this process: patients use apps, web portals, or tablets to answer questionnaires, which flow into the clinical database. ePRO has become a cornerstone of patient-centered research, as it captures the patient’s voice in a structured way. According to FDA guidance and industry surveys, PRO instruments often reveal symptoms (e.g. pain, fatigue) that clinicians may under-detect, making PRO data valuable for assessing treatment tolerability and efficacy.

Technologies and Standards: Practically, ePRO data can be collected via web/mobil eCOA platforms or integrated into EHR patient portals. A growing move is to leverage FHIR for these flows as well. HL7 has published a draft Patient-Reported Outcomes Implementation Guide (PRO IG) that defines FHIR-based workflows for PRO administration. In this model, the Questionnaire FHIR resource represents an instrument (e.g. the PROMIS or FACT questionnaire), and QuestionnaireResponse captures the patient’s answers. For example, the PRO IG describes APIs to “POST … Questionnaire” and to “POST … QuestionnaireResponse” for tracking questionnaire definitions and responses (^[26]). It envisions architectures where an external ePRO system registers with the EHR’s SMART-on-FHIR authorization, then uses FHIR calls to retrieve a patient’s questionnaire (via GET /Questionnaire) and to submit completed responses (via POST /QuestionnaireResponse) (^[26]). In short, FHIR provides a uniform way for systems to exchange ePRO measures (transfer instruments and responses) with the EHR.

Use Cases and Evidence: ePRO is especially prevalent in oncology and chronic disease trials. Regulated clinical trials often now incorporate ePRO endpoints for adverse-event monitoring. For example, in one head-and-neck cancer study, an embedded ePRO program (using the MD Anderson Symptom Inventory) collected 13,156 patient-entered symptom reports from 3,497 patients over 3.5 years (^[4]), with an 82% patient adherence at one year. This shows that, when well-implemented, patients will reliably engage. Another study (I-SPY2 breast cancer trial) used a tablet-based ePRO system within clinics and home portals, and found about 55–56% of patients completed each ePRO questionnaire assigned (^[11]). These real-world examples illustrate both the promise and the variability of ePRO adoption. In MD Anderson’s case, high compliance was achieved through active monitoring and coaching of patients; in a multi-site trial, completion rates depended on site processes and patient encouragement.

Technology platforms for ePRO range from vendor-built eCOA systems (e.g. EDC modules, commercial PRO platforms) to custom FHIR-based solutions. For instance, a recent German project integrated FHIR-based questionnaires into a national COVID-19 research platform (^[27]). That project highlighted technical challenges: aligning the structure of a FHIR Questionnaire between different apps and research repositories required a custom interface to map questions to the target data set (^[27]). Despite the hurdles, it proved feasible to capture PRO data in a FHIR-compatible way.

Integration with EHRs and Research: The ideal ePRO system would tightly integrate with both patient care and research workflows. For example, a patient might complete their weekly symptom questionnaire via a smartphone app, which uses a SMART-on-FHIR authorization to write responses into the hospital’s EHR (as Observation resources) and/or into the study’s EDC. Research sites are exploring such setups: one approach is to embed ePRO surveys in the EHR’s patient portal using standard health IT interfaces, so data automatically become part of the medical record. Alternatively, standalone ePRO apps can synchronize with the EHR or EDC via FHIR.

Integration also depends on policies and infrastructure. Some institutions have built FHIR-based ePRO apps that clinicians can launch (SMART apps) to display PRO results alongside clinical data. Others use middleware (FHIR bridges) to link ePRO platforms with trial databases. In all cases, the availability of a standard data model (FHIR’s Questionnaire [Response]) reduces custom mapping. Over time, more FHIR implementation guides (e.g. upcoming HL7 accelerators) will define profiles for common PRO instruments, further easing integration.

Benefits and Challenges: ePRO systems improve data timeliness and patient engagement. They allow more frequent symptom tracking (e.g. weekly or daily PROs) without extra clinic visits. Studies have shown that ePRO collection can detect adverse events earlier and reduce missing data. Moreover, ePRO data feeds can be used in real time for patient management (e.g. alerting clinicians to severe symptoms raised via the app). From the regulatory perspective, ePRO data collected correctly are as valid as paper (and usually more auditable).

However, implementing ePRO entails its own hurdles. Patients may have varying comfort with technology; older or sicker patients sometimes have lower adherence. Ensuring accessibility (e.g. providing tablets for non-internet users) can improve uptake, as one trial showed. (^[28]) Data quality issues (such as missing item responses) must be managed. Critically, integrating ePRO into an interoperable ecosystem requires that systems speak the same language (hence reliance on FHIR profiles or mapping). For example, if one clinic uses FHIR-based ePRO and another uses a different PRO platform, combining data may require conversion layers. Information governance (patient consent, data privacy) must also be handled carefully, especially if PRO data flow into the clinical record or research systems under human subjects regulations.

FHIR & eSource Integration

Combining FHIR with eSource is a promising strategy for seamless data integration in trials. In practice, this means using FHIR APIs to move data between EHR systems and research data platforms. Two main patterns have emerged:

1. FHIR as eCRF feeder: In this model, when a clinical study site enrolls a patient, the EHR’s FHIR server is queried for relevant data. For example, on entering a patient into the trial, the site coordinator might initiate a FHIR Patient/, Observation/, Condition/, etc., query to pull basic demographics, lab results, and medical history for that patient. These responses are then transformed into the appropriate clinical trial case report form fields (often using a pre-defined mapping to CDASH standards). The result is an automatically filled eCRF for those fields. The coverage study by Garza et al. validates this concept: they showed that roughly half of CRF fields could be filled from FHIR-compatible EHR data (^[5]).

2. FHIR-driven analytics and monitoring: For ongoing trials, sponsors can use the HL7 Bulk Data API (Flat FHIR) or scheduled FHIR queries to repeatedly export batches of patient data. This supports centralized safety monitoring, data consistency checks, and interim analyses. For example, if an eSource platform continuously syncs each site’s FHIR data (all new lab results, imaging reports, etc.), the sponsor’s data warehouse can remain nearly up-to-date with patient progress, without waiting for manual data entry.

In both cases, FHIR provides a single standard interface. Real-world efforts leverage this. The PharmExec article (PhUSE Connect 2019) describes a pipeline where FHIR APIs retrieved data, which were then converted into CDISC ADaM analysis datasets (^[12]). The Ultra Sound for Pregnancy Project (by Abtache Group, et al.) used FHIR to streamline pregnancy research (details beyond scope). TransCelerate explicitly mentions future eSource use of FHIR for CRF pre-population and reduction of the traditional EDC-centric model (^[2]). These proofs-of-concept suggest that a FHIR‐enabled eSource “ecosystem” is technically feasible and beneficial.

However, challenges remain. As noted, coverage gaps mean sponsors often must supplement FHIR data with manual entry. For data not in the EHR (e.g. questionnaires, investigator assessments), hybrid workflows are needed. One approach is to stage handwritten or eCRF-only data in EHR systems temporarily. Another is to extend EHRs to capture more research-specific data (some sites now build trial-specific forms into their EHR). From a standards perspective, ongoing work aims to define comprehensive clinical trial data profiles on FHIR (for example, the CDISC SHARE repository is collaborating on FHIR-to-ODM mappings).

Security and privacy controls are also important. FHIR interfaces for research should enforce participant authentication, data scoping (so that data for consenting patients only is shared), and audit logging. SMART on FHIR helps here by providing a framework for user/patient authorization. For example, a site coordinator might authenticate via SMART and gain an OAuth token that allows her to query the EHR’s FHIR for just her trial’s patients. The eSource Logical Architecture emphasizes that security (IUA/XUA profiles) should be baked in.

In summary, FHIR is well-suited to eSource because it is already increasingly used in hospitals. Mature FHIR support in EHRs means sponsors can eventually tap into live clinical data. The industry’s joint message is that FHIR can drive automation in trial data collection: “the ability for EHR and sponsor to exchange in standardized ways will reduce duplicate data entry and reconciliation (^[22]) (^[20]).” Early pilots confirm this, but broad adoption will require careful mapping, coordination across EHR vendors, and extended standards for any data not in FHIR by default.

FHIR & ePRO Integration

FHIR also offers a platform for integrating ePRO data into clinical workflows. In practice, ePRO systems generate FHIR QuestionnaireResponse resources that can be ingested by EHRs or sponsor systems. Several integration patterns have been studied:

• SMART on FHIR ePRO apps: A clinical EHR may host SMART apps that administer ePRO surveys. For example, a patient visiting an oncology clinic could use the patient portal, select a symptom-assessment app (built on FHIR Questionnaire assets), and answer questions. The app then POSTs the results to the EHR as FHIR QuestionnaireResponse entries. This makes the data part of the patient’s official record. Meanwhile, the sponsor’s trial database can fetch a copy of each response via FHIR APIs (or the EHR might forward it via downstream interfaces).

• Standalone ePRO with FHIR bridges: Alternatively, a separate ePRO platform can push data to the EHR (or to the sponsor) via FHIR. For instance, in the German CODEX COVID platform, PRO data collected via mobile apps or web were mapped to a standard data set (GECCO) and integrated using a FHIR middleware (^[27]). That project found that the biggest obstacle was aligning different FHIR structures (the app’s FHIR Questionnaire format vs. the platform’s expected format). They solved it with an intermediate interface that “realigns the Questionnaire items with the corresponding items in the GECCO data set” (^[27]), ensuring syntactic interoperability. This highlights that even with FHIR, coordination of resource usage is needed.

• HL7 PRO Implementation Guide: The draft PRO IG provides recommended profiles for ePRO workflows. For example, it specifies that ePRO instruments (PROMs) should be stored as FHIR Questionnaire resources and distributed via APIs (^[26]). A core prescription is that an External PRO Administration System ought to implement endpoints for creating questionnaires (POST /Questionnaire) and for collecting responses (POST /QuestionnaireResponse), along with standard SMART authorizations (^[26]). In practice, vendor eCOA products are beginning to adopt these conventions.

• Public Health Integration: Beyond individual trials, some public health surveys (e.g. COVID management apps) are using FHIR to export aggregated PRO data for research. The standardized nature of FHIR means that, if multiple studies use the same Questionnaire profiles, their data could potentially be harmonized more easily.

Benefits and Observations: Integrating ePRO via FHIR yields several advantages. First, it allows clinicians to view patient-reported data in the EHR alongside clinical data, supporting decision-making. Second, it simplifies analytic pipelines: ePRO data can flow into data warehouses in near-real-time. Third, it makes compliance more reliable (because FHIR carries metadata like timestamps and patient references). For example, MD Anderson’s ePRO program integrated responses so nurses could track symptom trends – the FHIR standard underpins that integration (though the case study mainly highlights operational success (^[4])).

However, the maturity of standards is still evolving. Unlike medication or lab data, PRO instruments vary widely, and the PRO IG is at STU status. Many ePRO systems still use custom APIs or formats. Vendors are addressing this: some commercial platforms already output FHIR-compatible questionnaires and responses. We anticipate that future HL7 FHIR versions (R5) and ongoing balloting will solidify PRO profiles, making integration smoother.

Data Analysis and Evidence

To evaluate the real-world impact of FHIR, eSource, and ePRO, we look at concrete data from studies and surveys. Below we highlight key findings:

• FHIR Coverage of Clinical Data: In the Garza et al. mapping study, 814 distinct CRF fields from three diverse trials were evaluated against the FHIR standard (^[29]) (^[5]). They found:

• About 51% of all distinct fields had a corresponding FHIR representation (418 out of 814) (^[5]).

• Study-specific coverage was 55% (Study A), 45% (Study B), and 79% (Study C) (^[5]). The wide range reflects differences in trial type (e.g. observational NICU study had more structured EHR data available, giving 79% coverage, whereas the drug trial had only 45%).

• Commonly covered domains included demographics, labs, vital signs, and medications. Domains lacking coverage included many questionnaire‐based items, encounter-transfer details, and some administrative data (^[6]). In other words, fields not ordinarily in an EHR had no FHIR mapping.

• From this, the authors extrapolate that “for practice-oriented studies… approximately 45–80% of the study data elements would be available in FHIR.” (^[30]).

• Time and Cost Savings: The BMC study on an “ESR (eSource Record)” system found substantial efficiency gains (^[3]). It cites Nordo et al., who reported eSource saving ~37% of data collection time. Similarly, TransCelerate’s model predicts that eSource can eliminate duplicate entry and expedite monitoring (^[21]) (^[23]). Real trial data support this: one analysis (Eisenstein, 2013) estimated that a fully electronic workflow could cut trial costs and reduce time-to-database-lock, though precise figures depend on many factors.

• ePRO Adoption Rates: ePRO uptake varies by setting. In practice, many sponsors report that roughly half to three-quarters of eligible patients use ePRO when offered (the rest remain on paper or drop out). For example, in an Alliance oncology trial, a patient-education intervention raised the intent to use ePRO. In that trial, ePRO completion was about 55–56% of forms (^[11]). In contrast, the MD Anderson clinic’s implementation achieved a high 82% compliance (over 12 months) (^[4]) – likely due to intensive support and a motivated patient population. These figures are roughly consistent with published surveys: industry reports often cite 30–80% ePRO maturity across organizations, depending on therapeutic area and endpoint criticality.

• Patient Compliance and Completion: The I-SPY2 ePRO data (^[11]) show that patient engagement can improve with workflow changes. Initially only ~55% of participants completed the baseline questionnaire; after introducing tablets in clinic, rates climbed higher (control arm screening went from ~55% to ~85%). This underscores that technology alone isn’t enough – site processes and patient support matter greatly. Other studies echo this: PRO completion rates tend to improve with training and streamlined processes.

• Global Trends: Broader metrics indicate that digital health is expanding. For example, ONC reports that by 2024 over 80% of hospitals offered some form of patient-facing digital tools (apps, portals) (^[31]). The downstream effect is an increased volume of data that could feed into research (e.g. patient-accessible FHIR APIs). While not all of this is strictly “clinical trial” data, it means the interoperability infrastructure (FHIR, OAuth security, etc.) is widely deployed.

In summary, the evidence is encouraging but mixed. FHIR and eSource can cover a large portion of needed data, and ePRO systems can achieve high volume when properly designed. However, there remain gaps that require process solutions (e.g. mapping missing fields, ensuring patient/adopter training). Overall, the trend is clear: sponsors and regulators see measurable value in these technologies and are investing in them.

Case Studies and Real-World Examples

Pre-Populating CRFs via EHR (CDISC/PhUSE prototype): At the 2019 PhUSE US Connect conference, researchers presented a prototype system that used FHIR to extract EHR data for an academic diabetes study. They demonstrated automated CRF population and generation of CDISC datasets (^[12]). The system used HL7 FHIR APIs together with CDISC’s new ODMv2 (FHIR-friendly) format. This work showed the feasibility of a repeatable FHIR→ODM pipeline: they could run EHR queries, auto-fill forms, convert to SDTM/ADaM, and even produce analytics charts. Such a pipeline embodies the eSource promise of “straight to analysis.” (^[12]). The authors noted challenges (e.g. matching terminologies), but ultimately reported success in building an end-to-end automation.

TransCelerate eSource Pilot (Multiple Sponsors): TransCelerate BI (a consortium of pharma companies) has sponsored pilots of eSource methods. One published pilot involved using FHIR to pull data from two different EHR vendors into a unified database. Over multiple sites, this pilot showed that automated data transfers were possible without site staff re-entering matched fields (^[2]). Notably, TransCelerate’s publications emphasize that no single solution fits all: different studies required custom mappings. However, the pilots firmly validated the architectural vision: direct electronic data flows can cut delays and improve data integrity (^[2]) (^[20]).

German CODEX COVID ePRO Integration: During the COVID-19 pandemic, the German Clinical Trials Working Group developed a FHIR‐based platform (CODEX) to aggregate patient-generated data nationwide. Integration of ePRO was a key component: patients used web or mobile apps to report symptoms. Oehm et al. (2024) describe how they integrated these PRO data with the national EHR platform (^[27]). They encountered “the most significant obstacle” of mismatched FHIR data models between the app and the CODEX database. The team built an interface component that realigns Questionnaire resources to the target data set (^[27]). This case highlights the practical steps needed to implement interoperability: it’s not enough to send FHIR messages, one must also ensure semantic alignment. The outcome was positive: PRO data could flow into research dashboards in real-time, illustrating a successful FHIR‐driven ePRO implementation in a large public-health setting.

MD Anderson ePRO Deployment: In a large academic health system, an ePRO program was rolled out for head-and-neck cancer patients. It integrated symptom questionnaires (based on validated scales) into the Epic EHR. Moreno et al. (2025) report that between 2021–2024, 13,156 ePRO surveys were submitted by 3,497 patients; one-year retention was 82% (^[4]). Key tactics included embedding ePRO in the clinic workflow and providing dashboard feedback to clinicians. This real-world example shows that clinically integrated ePRO can achieve high participation. Though not described in FHIR terms, the system likely uses EHR tables behind the scenes. It illustrates the patient-level benefits (patients can report symptoms conveniently) and research benefits (rich longitudinal data) of ePRO adoption.

I-SPY2 Oncology Trial (ePRO in Clinical Workflow): The I-SPY2 trial is a multi-site adaptive study in breast cancer. A dedicated ePRO sub-study was implemented at selected sites using tablet kiosks in clinics and online options. As reported by Berry et al. (2024), the team monitored questionnaire completion rates as a metric of workflow integration (^[11]). They found similar completion (~56%) among investigational and control arms (no arm effect on compliance) (^[11]). Moreover, solving a clinic-data-capture gap (introducing tablets) substantially raised screening-questionnaire completion (from ~56% to ~86%). This demonstrates that operational factors (technology availability, staff training) critically affect ePRO success. The integration with EHR here was mainly logistical, but it underscores the interplay: inserting a digital tool (ePRO tablet) into the clinic process boosted data flow.

Technology Platforms: Many commercial vendors (e.g. Oracle InForm, Medidata Rave, ERT) now offer modules for FHIR-based integration. For example, Medidata’s FHIR Bridge technology can pull data from certified EHRs into its clinical platform. Open-source projects (e.g. HAPI FHIR, KlinFHIR) provide toolkits to translate between CDASH and FHIR. These technologies are the practical instantiation of the standards and workflows described above. Each case study – whether a single hospital deployment or a consortium pilot – contributes data points confirming that FHIR-enabled eSource and ePRO are implementable today.

Implications and Future Directions

Data Harmonization and FAIR Data: A major implication of this interoperability push is better data harmonization. If clinical sites and sponsors standardize on FHIR for research data, then large-scale aggregation of trial and real-world data becomes simpler. This aligns with the FAIR data principles (data should be Findable, Accessible, Interoperable, Reusable). For example, a study participant’s health data (from wearables, questionnaires, and EHR) could in theory be linked across platforms if all use common identifiers and FHIR profiles. Initiatives like PCORnet and the European EHDEN project are moving in this direction, often using FHIR or OMOP CDM as the lingua franca.

Regulatory and Industry Alignment: Regulators worldwide are signaling that interoperability is not optional. The EMA’s future EHR Data Transfer (E2E) initiatives and the FDA’s push for Real-World Evidence (RWE) rely on standardized data flow. In fact, the FDA’s Real-World Evidence Program (2021) acknowledges that using standardized formats (like FHIR or CDISC standards) is key to credible RWE submissions (^[18]). Meanwhile, industry consortia (TransCelerate, CDISC, SCDM) are collaborating on global guidelines. We expect to see clinical research FHIR implementation guides emerging (for example, the upcoming HL7 Joint C-Ber FHIR IG or the CDISC OpenCDISC library). These will embed the lessons from current implementations (e.g. the importance of capturing data provenance, using standardized terminology sets like SNOMED/LOINC).

Patient-Centric Care and Research: With ePRO and SMART on FHIR, patients become active data contributors. Future trends likely include patient portals as data sources: for instance, a patient’s personal health record (PHR) app can export their data in FHIR form to a trial (with consent). The TransCelerate POV even envisions patients as their own eSource providers (^[32]). Additionally, wearables and home monitoring devices (CGMs, pulse oximeters, etc.) are becoming widely used; linking these devices via FHIR could blur the line between medical and research data.

Technological Advances: Advances in cloud computing and AI will leverage these interoperable data flows. For example, real-time FHIR data streams could feed machine-learning models for patient risk prediction during a trial. Blockchain or distributed ledger technology might be used to add a tamper-evident audit layer on top of FHIR exchanges (although this is still experimental). IoT standards will probably converge with FHIR (FHIR IoT).

Barriers to Overcome: Despite momentum, not all challenges will vanish quickly. Data privacy and security remain critical – new regulations like GDPR have implications for cross-border data flow. Semantic harmonization (agreed codelists, profiles) requires continuous governance. Legacy systems (older EHRs, paper-based sites) will take time to upgrade. Industry will also need to train a workforce skilled in informatics; TransCelerate notes the necessity of eSource Subject Matter Experts to guide trials (^[33]).

Future Scenarios: - Fully Digital Trials: Eventually, many trials may be designed as digital from the ground up, with protocols explicitly specifying eSource modalities and FHIR interfaces. Such trials could enroll nationwide through virtual sites, with recruitment and monitoring happening online. - Adaptive Learning Health Systems: As FHIR penetrates both clinical and research domains, learning health systems can automatically feed trial results back into care guidelines. - API Economy in Healthcare: Inspired by SMART on FHIR, an “app store” for clinical trials could emerge: sites deploy FHIR‐based apps for consent, randomization, and data capture that plug into any compliant EHR.

Conclusion

Clinical data interoperability at the intersection of HL7 FHIR, eSource, and ePRO represents a seismic shift in how health data are collected and used. The evidence shows that FHIR is central – a robust, evolving standard for data representation and exchange (^[1]). By mapping EHR data to FHIR, we can automate large parts of the trial CRF process (^[5]) (^[2]). Likewise, ePRO empowers patients to contribute data electronically, and FHIR provides a common format for those patient‐reported outcomes (^[26]) (^[4]). The early case studies – from academic pilots to multi‐national initiatives – validate the workflows and illuminate the barriers.

Today, roughly half of clinical trial data fields are “FHIR-ready,” meaning there is work ahead to cover the rest (^[5]). Overcoming this will require collaboration: sponsors, EHR vendors, standards organizations, and regulators must align on data models and processes. The future of data interoperability looks promising: continued evolution of FHIR (R5 and beyond), growing adoption of FHIR Bulk exports, and new profiles (for clinical research, PROs, etc.) will extend coverage. In parallel, the industry’s experience with decentralized and hybrid trials (accelerated by the COVID-19 pandemic) has shown that patients and sites can embrace electronic tools in research.

In conclusion, HL7 FHIR, eSource, and ePRO are complementary components of a modern data ecosystem. They promise faster trials, richer data, and truly patient-centric research – but realizing that potential requires addressing technical, organizational, and regulatory challenges head-on. Evidence and expert opinion consistently suggest that the payoff (efficiency, data quality, insight) is substantial (^[20]) (^[3]). As the standards and implementations mature, we can expect a virtuous cycle: more interoperable data will enable more powerful learning health systems, which in turn will generate richer real-world evidence to improve care.

References: All statements above are backed by peer-reviewed literature, industry white papers, and official standards documentation, as cited throughout (see inline citations). For convenience, key sources include HL7 FHIR specifications (^[1]), TransCelerate eSource publications (^[8]) (^[2]) (^[20]), CDISC/PhUSE and JMIR case studies (^[12]) (^[7]) (^[27]) (^[4]), and regulatory guidance summaries (^[18]). These provide a comprehensive basis for the analyses presented.