ICH E6(R3) Annex 2: decentralised elements, pragmatic trials and real-world data

ICH E6(R3) was split into parts. The Principles and Annex 1, adopted at Step 4 on 6 January 2025, set the core of good clinical practice and are covered in our ICH E6(R3) guide for clinical trial teams. Annex 2 is the companion for designs that have moved beyond the traditional site-based model. It groups them as "methodologies" and names three.

Decentralised elements are trial activities done outside the investigator's location: visits or procedures at the participant's home, a local healthcare centre or a mobile unit, plus remote interactions such as video calls and digital health technologies (DHTs). Annex 2 treats a DHT that acquires trial data as a data acquisition tool. Pragmatic elements bring usual clinical practice into the trial: eligibility and procedures that mirror routine care, care delivered by local providers, and streamlined data collection that captures only the minimum necessary data at the times routine care already generates it. RWD is data on patient health collected outside trials, such as electronic health records (EHRs), registries and claims databases.

The annex also separates primary data collection (gathered for the trial under the protocol) from secondary use (data collected for another purpose and later brought into the trial). Both can serve a trial, but the quality and governance questions differ. For broader background on these designs, see the decentralised clinical trial guide and the glossary entry on the pragmatic clinical trial.

Pragmatic elements look like less work, because routine care does part of the job. Annex 2 shows the hidden cost: the protocol must say how, by whom and under what circumstances each routine-care activity will be performed, and the investigator still needs the resulting records. If assessments happen whenever a clinic visit falls, the protocol schedule and the real data will not line up, and the analysis plan must handle that. Our page on pragmatic clinical trial software covers the data-collection side.

RWD raises the bar on access. When RWD supports a key efficacy or safety endpoint, assessing the data source in general may not be enough: the sponsor may need to confirm whether a clinical event occurred, was assessed or was documented, which means access to source records. If a data holder will not allow access, ICH says to consult the regulator. For exploratory endpoints, system and process-level assessments may be sufficient if the protocol explains the reasoning. See EDC for real-world data studies for how RWD fits alongside data collected for the trial.

Annex 2 is guidance for sponsors and investigators, not a software standard, and Capture does not claim E6(R3) compliance. What a system can do is make the controls Annex 2 asks for easier to run and to show. In Capture, participants complete questionnaires in the phone browser through a secure link or QR code, with no app to install; eConsent uses an on-screen signature confirmed with an email one-time code, investigator countersignature, and optional witness or legally authorised representative signatures. A study can also enable a wearable connection (for example Oura) that the participant links to their own account. See eConsent for decentralised trials and EDC for wearable device studies.

On the privacy and oversight side, role-based access separates site coordinators, who see participant names, from researchers, who see coded IDs, and a field-level audit trail records who changed what, when and why. Edit checks raise automatic queries when data from any setting breaks a rule. Be clear about the gaps too: an email code confirms access to an inbox, not a person's identity, so the ID check Annex 2 describes remains a site procedure you document. Capture does not extract data from hospital EHRs, and it does not ship investigational product.