Mit ICH E6(R3) wird die Software Teil der klinischen Prüfung

In einer klinischen Prüfung arbeiten heute viele Systeme zusammen: das elektronische Prüfbogensystem, die Randomisierung, eine App für Patiententagebücher, die Patientenakte der Klinik. Lange galt deren Prüfung als Aufgabe der IT, die neben der eigentlichen Studie herläuft. Die überarbeitete Leitlinie ICH E6(R3) ordnet das anders: Ob ein System taugt, ist eine Frage der Studienqualität und damit Sache von Sponsor und Prüfstelle.

Grundlage: was gilt und seit wann

ICH E6 ist die international abgestimmte Leitlinie zur guten klinischen Praxis (GCP), also zu den Regeln, nach denen klinische Prüfungen geplant, durchgeführt und dokumentiert werden. Die dritte Revision besteht aus übergreifenden Grundsätzen, dem Annex 1 für interventionelle Prüfungen und dem Annex 2 für Prüfungen mit dezentralen oder pragmatischen Elementen und mit Daten aus der Versorgung. Grundsätze und Annex 1 sind in der EU seit dem 23. Juli 2025 in Kraft. Annex 2 hat die Europäische Arzneimittel-Agentur (EMA) im Juli 2026 veröffentlicht, er gilt ab dem 15. Januar 2027.

Eine ICH-Leitlinie ist kein Gesetz. Die Verordnung (EU) Nr. 536/2014 über klinische Prüfungen verpflichtet Sponsor und Prüfer aber in Artikel 47, die ICH-Leitlinien zur guten klinischen Praxis angemessen zu berücksichtigen. Für die Praxis heißt das: An E6(R3) wird gemessen.

Die Leitlinie versteht sich ausdrücklich als medienneutral. Sie schreibt keine Technik vor, sondern verlangt, dass Systeme zur Datenerfassung und -verwaltung für ihren Zweck geeignet sind und dass der Aufwand dafür dem Risiko für die Teilnehmenden und der Bedeutung der Daten entspricht (Grundsatz 9).

Was Annex 1 von computergestützten Systemen verlangt

Die Anforderungen stehen vor allem im Abschnitt 4 zur Daten-Governance. Vier Punkte prägen die Arbeit an der Software:

• Validierung nach Risiko. Die verantwortliche Partei ist für den Validierungsstatus über den gesamten Lebenszyklus zuständig. Der Umfang folgt einer Risikobewertung: Wofür wird das System genutzt, wie wichtig sind die Daten darin, und wie stark kann es die Sicherheit der Teilnehmenden und die Verlässlichkeit der Ergebnisse berühren (4.3.4). Ausdrücklich zu validieren sind auch studienspezifische Konfigurationen, automatische Plausibilitätsprüfungen, Berechnungen und Schnittstellen zwischen Systemen.
• Audit-Trail und Metadaten. Systeme sollen die erste Eingabe und jede spätere Änderung nachvollziehbar festhalten, Änderungen an Benutzerrollen protokollieren und Zeitstempel eindeutig setzen, etwa in koordinierter Weltzeit (UTC). Audit-Trails dürfen nicht abgeschaltet werden, und ihre Durchsicht ist eine geplante, risikobasierte Tätigkeit (4.2.2 und 4.2.3).
• Benutzerverwaltung und Sicherheit. Zugriffe richten sich nach Aufgabe, Verblindung und Organisation, werden dokumentiert und regelmäßig überprüft. Sicherung, Wiederherstellung und Schutz gegen unbefugten Zugriff gehören dazu (4.3.3 und 4.3.8).
• Ein Verzeichnis der Systeme. Der Sponsor führt eine Übersicht der wichtigen Systeme einer Prüfung mit Zweck, Funktionen, Schnittstellen, Validierungsstatus und Zuständigkeit (3.16.1 Buchstabe x).

Neu ist der Blick auf die Prüfstelle. Systeme der Klinik, die Quelldaten enthalten, etwa die elektronische Patientenakte, sollen schon bei der Auswahl der Prüfstellen darauf bewertet werden, ob sie für die Prüfung geeignet sind oder ob sich bekannte Schwächen ausgleichen lassen. Und wer Aufgaben an Dienstleister abgibt, behält die Verantwortung (Grundsatz 10, Abschnitt 3.6.6). Ein zertifizierter Anbieter ersetzt die eigene Bewertung also nicht.

Was Annex 2 ab Januar 2027 ergänzt

Annex 2 betrifft Prüfungen, in denen Tätigkeiten außerhalb der Prüfstelle stattfinden, etwa Hausbesuche, Videotermine oder Messungen mit digitalen Gesundheitstechnologien wie Apps, Wearables und Sensoren. Erfasst eine solche Technologie Daten für die Prüfung, gilt sie als Datenerfassungswerkzeug und unterliegt denselben Anforderungen wie ein Prüfbogensystem.

Der zweite Schwerpunkt sind Real-World-Daten: Daten, die außerhalb der Prüfung entstanden sind, etwa in Patientenakten, Registern oder Abrechnungsdaten. Der Sponsor muss belegen, dass sie für den Zweck geeignet sind, also verlässlich (genau, vollständig, mit nachvollziehbarer Herkunft) und relevant für die Fragestellung (3.5.1). Je wichtiger die Daten für die Ergebnisse sind, desto eher braucht er Zugang zu den Quelldaten. Das gilt etwa, wenn Real-World-Daten zentrale Endpunkte zur Wirksamkeit oder Sicherheit tragen. Bei explorativen Endpunkten kann eine Bewertung auf System- und Prozessebene genügen (3.4.1). Bei der Fernerfassung von Daten verlangt Annex 2 besondere Aufmerksamkeit für Cybersicherheit und Datenschutz (3.5.2).

Ein Beispiel

Nehmen Sie eine Prüfung, in der Teilnehmende Symptome über eine App erfassen und ein Wearable die Aktivität misst. Beides speist einen sekundären Endpunkt. Nach E6(R3) gehören App, Wearable und die Schnittstelle zur Studiendatenbank ins Systemverzeichnis. Validiert werden muss, dass Werte vollständig und unverändert ankommen, dass Zeitstempel eindeutig sind und dass eine verspätete Synchronisation nicht still Daten verliert. Die Plattform kann ein Dienstleister betreiben, die Bewertung, ob sie für diese Prüfung taugt, bleibt beim Sponsor. Der Prüfaufwand richtet sich nach der Bedeutung des Endpunkts. Trüge die App den primären Endpunkt, wäre er höher.

Vorgehen

1. Systemverzeichnis anlegen: alle Systeme der Prüfung mit Zweck, Datenflüssen, Schnittstellen, Betreiber und Validierungsstatus.
2. Kritische Daten und Funktionen bestimmen: Randomisierung, Dosierung, Endpunkte. Dort liegt der Schwerpunkt der Validierung.
3. Risiken je System bewerten und Testtiefe daran ausrichten. Die Nachweise des Anbieters nutzen und nur die Lücke für die eigene Konfiguration schließen.
4. Audit-Trail-Durchsicht und Benutzerprüfung als feste Termine im Studienplan verankern, nicht erst vor der Inspektion.
5. Für Prüfungen ab 2027 klären, ob dezentrale Elemente oder Real-World-Daten geplant sind, und deren Eignung vor Studienbeginn dokumentieren.

Einordnung

E6(R3) verlangt keine neue Validierungswelt. Wer Systeme schon risikobasiert prüft, etwa nach den Grundsätzen, die auch im GMP-Umfeld gelten, findet viel Bekanntes. Die Leitlinie ist zudem keine Checkliste: Sie lässt bewusst offen, wie tief ein System zu prüfen ist, und gerade das verlangt eine begründete eigene Entscheidung. Für Medizinprodukte, die in einer Prüfung eingesetzt werden, gelten außerdem eigene Regeln nach der Medizinprodukteverordnung. E6(R3) ersetzt sie nicht. Und nicht jede Software im Umfeld einer Studie ist betroffen. Ein Werkzeug zur Terminplanung ohne Einfluss auf Studiendaten braucht nach unserer Einschätzung keine Validierung im Sinne der Leitlinie. Wie die Aufsichtsbehörden Annex 2 in Inspektionen auslegen, wird sich erst ab 2027 zeigen. Die EMA-Leitlinie zu computergestützten Systemen in klinischen Prüfungen von 2023 bleibt dafür die ausführlichere Ergänzung.

Fazit

Mit E6(R3) wird die Eignung der Software zum Teil der Studienqualität. Wer jetzt ein Systemverzeichnis führt, den Prüfaufwand am Risiko ausrichtet und Annex 2 in die Planung der Prüfungen ab 2027 aufnimmt, muss vor der Inspektion nichts mehr nachholen.