ICH E6(R3) makes software part of the clinical trial

A clinical trial today relies on many systems working together: the electronic case report form, randomisation, an app for patient diaries, the hospital’s health record. For a long time, assessing them was seen as a task for IT, running alongside the trial itself. The revised guideline ICH E6(R3) puts it differently: whether a system is fit for use is a question of trial quality, and therefore a matter for the sponsor and the trial site.

The basis: what applies, and since when

ICH E6 is the internationally harmonised guideline on good clinical practice (GCP), the rules by which clinical trials are designed, conducted and documented. The third revision consists of overarching principles, Annex 1 for interventional trials, and Annex 2 for trials with decentralised or pragmatic elements and with data from routine care. The principles and Annex 1 have been in effect in the EU since 23 July 2025. The European Medicines Agency (EMA) published Annex 2 in July 2026; it applies from 15 January 2027.

An ICH guideline is not law. Article 47 of Regulation (EU) No 536/2014 on clinical trials does, however, require sponsors and investigators to take appropriate account of the ICH guidelines on good clinical practice. In practice, E6(R3) is the yardstick.

The guideline expressly describes itself as media neutral. It does not prescribe a technology; it requires systems for data capture and management to be fit for purpose, with the effort proportionate to the risks to participants and the importance of the data (principle 9).

What Annex 1 requires of computerised systems

The requirements sit mainly in section 4 on data governance. Four points shape the work on software:

• Risk-based validation. The responsible party is accountable for the validation status throughout the system’s life cycle. The scope follows a risk assessment: what the system is used for, how important its data are, and how far it can affect participant safety and the reliability of the results (4.3.4). Protocol-specific configurations, automated data checks, calculations and the interfaces between systems must also be validated.
• Audit trails and metadata. Systems should record the initial entry and every later change in a traceable way, log changes to user roles, and set unambiguous time stamps, for example in coordinated universal time (UTC). Audit trails must not be disabled, and reviewing them is a planned, risk-based activity (4.2.2 and 4.2.3).
• User management and security. Access follows duties, blinding arrangements and organisation, is documented and is reviewed periodically. Backup, disaster recovery and protection against unauthorised access are part of this (4.3.3 and 4.3.8).
• A record of systems. The sponsor keeps a record of the important systems in a trial, with their use, functionality, interfaces, validation status and who is responsible for them (3.16.1(x)).

What is new is the attention to the trial site. Hospital systems that hold source records, such as the electronic health record, should be assessed as early as site selection for whether they are fit for purpose or whether known issues can be mitigated. And anyone who transfers activities to a service provider retains responsibility for them (principle 10, section 3.6.6). A certified vendor therefore does not replace your own assessment.

What Annex 2 adds from January 2027

Annex 2 covers trials in which activities take place outside the investigator’s location, such as home visits, video calls or measurements with digital health technologies like apps, wearables and sensors. Where such a technology acquires data for the trial, it counts as a data acquisition tool and is subject to the same requirements as a case report form system.

The second focus is real-world data: data generated outside the trial, for instance in health records, registries or claims databases. The sponsor must show that they are fit for purpose, meaning reliable (accurate, complete, with traceable provenance) and relevant to the trial question (3.5.1). The more important the data are to the results, the more likely the sponsor needs access to source records. This applies, for example, where real-world data support key efficacy or safety endpoints. For exploratory endpoints, an assessment at system and process level may suffice (3.4.1). For remote data collection, Annex 2 calls for particular attention to cybersecurity and data privacy (3.5.2).

An example

Consider a trial in which participants record symptoms in an app and a wearable measures activity. Both feed a secondary endpoint. Under E6(R3), the app, the wearable and the interface to the trial database belong in the record of systems. Validation must show that values arrive complete and unaltered, that time stamps are unambiguous, and that delayed synchronisation does not silently lose data. A service provider may operate the platform; the judgement of whether it is fit for this trial stays with the sponsor. The depth of testing follows the importance of the endpoint. If the app carried the primary endpoint, it would be greater.

How to proceed

1. Set up a record of systems: every system in the trial with its purpose, data flows, interfaces, operator and validation status.
2. Identify critical data and functions: randomisation, dosing, endpoints. That is where validation concentrates.
3. Assess the risk of each system and align testing depth with it. Use the vendor’s evidence and close only the gap left by your own configuration.
4. Build audit trail review and user access review into the trial plan as fixed activities, not as preparation for an inspection.
5. For trials from 2027, establish whether decentralised elements or real-world data are planned, and document their fitness for purpose before the trial starts.

Where this does not apply

E6(R3) does not call for a new world of validation. If you already assess systems on a risk basis, for example along the principles that also apply in a GMP setting, much will be familiar. Nor is the guideline a checklist: it deliberately leaves open how deeply a system must be tested, and that is precisely what calls for a reasoned decision of your own. Medical devices used in a trial are also subject to their own rules under the Medical Device Regulation; E6(R3) does not replace them. And not every piece of software around a trial is affected. A scheduling tool with no effect on trial data needs, in our assessment, no validation in the sense of the guideline. How supervisory authorities will interpret Annex 2 in inspections will only become clear from 2027. The EMA guideline on computerised systems in clinical trials from 2023 remains the more detailed companion.

Conclusion

With E6(R3), the fitness of software becomes part of trial quality. Keep a record of systems now, align the testing effort with the risk and bring Annex 2 into the planning of trials from 2027, and there is nothing left to catch up on before the inspection.