November 4, 2026
CROs Article

What ICH E6(R3) means for your eClinical setup

Clinical trials look very different from how they did twenty years ago. A single study can now collect millions of data points from sites, laboratories, wearable devices and patients at home. That data often moves through five or more systems before it reaches the analysis, where each step adds work, and each handover is a place where errors and gaps can hide.

Good Clinical Practice (GCP) has evolved to reflect this reality. The current version of the guideline, International Council for Harmonisation (ICH) E6(R3) Guideline for Good Clinical Practice, no longer treats quality as something checked at the end. It asks trial teams to integrate quality from the start, focus effort where the real risks are, and prove that every system they use is fit for its purpose.

In our daily work with sponsors, Contract Research Organizations (CROs) and academic trial units, we see a consequence that gets less attention than Standard Operating Procedures (SOPs) or monitoring plans: your eClinical setup has become a quality decision. How many systems you use, how data flows between them, and who has access are no longer just IT concerns. They are GCP questions.

In this blog, we look at what modern GCP actually asks of trial data and computerised systems, and what that means when you evaluate your own technology stack.

What changed in E6(R3)

E6(R3) moves GCP from a checklist to a set of principles that each trial applies in proportion to its risks. The guideline is built in layers: overarching principles meant to stay valid as technology changes, and Annex 1, which explains how to apply them to interventional trials [1]. Annex 2, adopted by ICH in June 2026, adds considerations for decentralised and pragmatic trials and trials using real-world data. It takes effect in the European Union on 15 January 2027 [2, 3].

Three ideas run through the whole text. All three come from ICH E8(R1), the guideline on general considerations for clinical studies:

  • Quality by design: Factors critical to quality (the data and processes that matter most for participant protection and reliable results) should be identified before the trial starts.
  • Proportionality: Processes and controls should match the risks to participants and the importance of the data, not be applied uniformly.
  • Avoiding unnecessary complexity: Protocols, data collection and operational tools should be feasible and should not burden participants or sites.

The guideline does not dictate how organizations should work. Whether using legacy processes, modern platforms, or a combination of both, the expectation is the same: choose solutions that are fit for purpose and enable quality by design.

Guideline Updates.png

Sources: [1–4].

Risk-based quality management needs a live view of the trial

Under E6(R3), risk management is a continuous cycle, not a document filed at study start. The guideline expects sponsors to actively manage risks throughout the study. This includes risks related to key trial processes and technologies, such as computerized systems, randomization, blinding, and handling study data.

Risk evaluation weighs three things: how likely a problem is, how detectable it would be, and how much it would affect participants or results. Detectability is where technology matters most. A risk that only surfaces when two exports are reconciled weeks later is, in practice, a less detectable risk.

The same principle applies to monitoring. E6(R3) recognizes centralized monitoring as an important way to identify issues early by reviewing trial data on an ongoing basis. It also encourages defining acceptable limits in advance so potential problems can be investigated when those limits are exceeded.

This risk-based approach is also reflected in how monitoring is conducted. Across 1,168 phase I–IV studies from 53 sponsors, source data verification corrected a median of only 1.1% of eCRF data [5]. A post hoc analysis of three phase III trials, covering more than 3 million data fields, found an overall error rate of 0.45%. Complete SDV needed about 370 data points checked to avoid a single error [6].

The takeaway is not that monitoring matters less. It is that targeted, data-driven oversight only works if your systems can show the right data, across sources, while the trial is still running.

Data governance now covers the whole data life cycle

E6(R3) gives data governance its own section, shared by investigators and sponsors (Annex 1, section 4) [1]. Under E6(R2), these expectations were scattered across the guideline. Now they follow the data from capture to destruction:

  • Data capture
  • Relevant metadata, including audit trails
  • Review of data and metadata
  • Data corrections
  • Data transfer, exchange and migration
  • Finalisation of data sets before analysis
  • Retention and access
  • Destruction

Several of these steps put direct demands on system design. Source records should be attributable, legible, contemporaneous, original, accurate and complete. Changes must be traceable through an audit trail and must not obscure the original entry. The guideline also asks that unnecessary transcription between the source record and the data acquisition tool be avoided.

Audit trails get particular attention. They should be interpretable and able to support review, and review of data, audit trails and metadata should follow defined procedures. Transfers between systems must preserve integrity and confidentiality. Blinding is treated as a data governance issue too, with safeguards expected wherever unblinded information could reach blinded staff.

These requirements become significantly more challenging as data volumes continue to grow. A 2026 study by Tufts Center for the Study of Drug Development (CSDD) and TransCelerate found that phase III protocols now average 5.96 million data points. Almost one-third of procedures did not support primary, key secondary or safety endpoints [7]. Every unnecessary data point is one more item to capture, transfer, review and govern.

eClinical systems must be fit for purpose, and someone must own that

Principle 9.3 [1] sets the bar: computerised systems should be fit for purpose, for example through risk-based validation, and factors critical to their quality should be addressed in their design. Annex 1 (section 4.3) then covers procedures for use, training, security, validation, system release, system failure, technical support and user management.

Two points stand out for anyone choosing or running eClinical software.

Validation should be proportionate to risk and demonstrate that a system is fit for its intended purpose. Systems that affect patient safety or critical trial data require more extensive validation and control than lower-risk tools. Validation is also not a one-time exercise. As systems evolve, they should continue to be reviewed and managed to ensure they remain fit for purpose throughout their lifecycle.

Sponsors can outsource activities to service providers and technology vendors, but they retain responsibility for appropriate oversight, data quality, and data integrity. They are expected to assess their providers, maintain effective oversight, and monitor performance, including any subcontracted work. Investigators have similar responsibilities for the systems they use, including managing user access securely and reporting issues that could affect trial data.

In practice, each additional system adds its own validation package, user management, incident process and vendor to oversee. That is where the architecture question begins.

Why fragmented eClinical stacks struggle under E6(R3)

E6(R3) does not mandate any particular architecture. But many of its expectations become harder to meet when EDC, RTSM, eTMF, CTMS and patient-facing tools live in separate systems from separate vendors.

Fragmented stack vs unified platform.png

When information is spread across multiple systems, maintaining complete, accurate, and consistent documentation becomes more difficult, increasing the risk of findings during inspections.

We have written before about why compliance risk increases in modular eClinical setups and the architecture behind the data reconciliation challenge. E6(R3) provides a clear regulatory basis for these expectations.

This is why we built oomnia as one platform, with eight connected modules (EDC, eSource, RTSM, eTMF, ePRO, CTMS, eCOA and eConsent) on a single CDISC-based data model. It is not the only way to comply. But it removes many of the interfaces that E6(R3) would otherwise ask you to validate, monitor and explain.

Questions to ask about your setup

Whether you run one platform or ten tools, these questions help you see where E6(R3) will put pressure on your current setup:

Can you trace any data point from capture to analysis dataset, including every change and who made it?

How many times is the same data entered, transferred or mapped between systems?

Are your audit trails readable by a monitor or inspector without vendor support?

Is audit trail review a planned activity with a defined procedure, or only done when something looks wrong?

Can your centralised monitoring team see data across EDC, RTSM and patient-reported sources while the trial runs?

Are your quality tolerance limits tracked in a system, or calculated manually from exports?

How is unblinded information kept from blinded roles across every system that holds it?

Is validation evidence for each system proportionate to its risk, current and ready for inspection?

Do you have the SOPs, performance metrics and incident reports you need to oversee each technology vendor?

If several answers depend on spreadsheets, manual reconciliation or a specific person's knowledge, that is a risk worth naming in your next risk assessment.

Conclusion

E6(R3) asks trial teams to focus on what matters, prove that their systems are fit for purpose and keep oversight of every party involved. None of that requires a specific technology. The fewer systems your data has to move between, the easier it is to demonstrate quality and compliance.

At Wemedoo, we are clinical professionals who built oomnia around these problems. If you are reviewing your eClinical setup against E6(R3), book an intro meeting or request a demo. We are happy to walk through your questions.

References

International Council for Harmonisation of Technical Requirements for Pharmaceuticals for Human Use. (2026). Guideline for good clinical practice E6(R3) (Final consolidated version, adopted 16 June 2026). https://database.ich.org/sites/default/files/ICH E6(R3)_Step4_FinalConsolidatedGuideline_2026_0616_.pdf

European Medicines Agency. (n.d.). ICH E6 good clinical practice – Scientific guideline. Retrieved October 30, 2026, from https://www.ema.europa.eu/en/ich-e6-good-clinical-practice-scientific-guideline

U.S. Food and Drug Administration. (2025). E6(R3) good clinical practice: Guidance for industry. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/e6r3-good-clinical-practice-gcp

Swissmedic. (2025, July 23). Entry into force of ICH GCP E6 (R3) and Annex 1 on 15 August 2025. https://www.swissmedic.ch/swissmedic/en/home/news/mitteilungen/einfuehrung-leitlinie-ich-gcp-e6-r3.html

Sheetz, N., Wilson, B., Benedict, J., Huffman, E., Lawton, A., Travers, M., Nadolny, P., Young, S., Given, K., & Florin, L. (2014). Evaluating source data verification as a quality control measure in clinical trials. Therapeutic Innovation & Regulatory Science, 48(6), 671–680. https://doi.org/10.1177/2168479014554400

Andersen, J. R., Byrjalsen, I., Bihlet, A., Kalakou, F., Hoeck, H. C., Hansen, G., Hansen, H. B., Karsdal, M. A., & Riis, B. J. (2015). Impact of source data verification on data quality in clinical trials: An empirical post hoc analysis of three phase 3 randomized clinical trials. British Journal of Clinical Pharmacology, 79(4), 660–668. https://doi.org/10.1111/bcp.12531

Getz, K., Botto, E., Arques, A. C., et al. (2025). Insights informing strategies for optimizing the collection of clinical trial data. Therapeutic Innovation & Regulatory Science. https://doi.org/10.1007/s43441-025-00899-4