Patientenrekrutierung für klinische Studien mit KI beschleunigen

Das echte Ausmaß des Problems

Das Problem ist seit Jahrzehnten bekannt: Viele Studien verfehlen ihren Zeitplan, und unzureichende Rekrutierung ist einer der häufigsten Gründe. Die Projektbeschreibung des BMBF-Projekts KIS-REK, in dem deutsche Universitätskliniken 2010 bis 2012 eine KIS-basierte Rekrutierungsunterstützung entwickelt haben, nennt als Ausgangslage, dass ein Drittel aller klinischen Studien abgebrochen werden müsse, weil nicht genug Patientinnen und Patienten im vorgesehenen Zeitraum rekrutiert werden konnten.

Das ist kein akademisches Problem. Das Tufts Center for the Study of Drug Development (Tufts CSDD) hat 2024 die Budgets von 447 Studienprotokollen ausgewertet: Im Mittel kostet ein Studientag in Phase II und III rund 40.000 US-Dollar direkte Kosten, in Phase III allein 55.716 Dollar (in US-Dollar von 2023). Das ist ein Durchschnitt, Gesamtbudget geteilt durch Laufzeit, nicht der Betrag, den ein zusätzlicher Tag kostet; patientenbezogene Kosten fallen ohnehin an. Dazu kommen laut derselben Auswertung im Mittel rund 800.000 Dollar Umsatz je Tag, um den ein Marktstart später kommt, gemittelt über 645 seit 2000 eingeführte Arzneimittel. Das ist Umsatz, nicht Deckungsbeitrag, und ein Mittelwert über sehr unterschiedliche Produkte.

Der strukturelle Engpass sitzt meist nicht an der Zahl potenziell geeigneter Patienten, die meisten existieren, sie werden nur nicht gefunden. Wie lange die manuelle Vorprüfung dauert, hängt stark an Indikation und Dokumentation: Wo Staging- und Mutationsdaten über viele Systemquellen verteilt liegen, wie in der Lungenonkologie, dauert sie deutlich länger als bei Kriterien, die strukturiert im KIS stehen. Anbieter nennen Wochen bis Monate; unabhängige Zahlen für deutsche Kliniken kennen wir nicht.

Drei strukturelle Ursachen verstärken sich dabei gegenseitig:

Dokumentation liegt überall, aber nicht zusammen. Die entscheidungsrelevanten klinischen Informationen, Diagnosestatus, Biomarker-Ergebnisse, Komorbiditäten, sind über Arztbriefe, Laborsysteme, Radiologieberichte und strukturierte ICD-Codes verteilt. Ein großer Teil davon steht in Freitext, nicht in maschinenlesbaren Feldern.

Study Coordinators sind der Flaschenhals. Manche Sites schließen weniger Patientinnen und Patienten ein als geplant, manche gar keine. Das liegt oft nicht an mangelndem Willen, sondern an begrenzten Personalressourcen: Eine Site-Koordinatorin kann pro Tag nur eine begrenzte Anzahl von Akten manuell prüfen.

Falsch definierte Protokollkriterien werden spät erkannt. Häufig zeigt sich erst nach dem Start der Rekrutierung, dass die Ein- und Ausschlusskriterien entweder zu restriktiv oder in der klinischen Praxis nicht exakt messbar sind, dann sind bereits Monate vergangen.

Mit vs. ohne KI, ein ehrlicher Vergleich

Unabhängige, auf deutsche Kliniken übertragbare Vorher-nachher-Zahlen haben wir nicht gefunden; veröffentlichte Studien stammen meist aus US-Zentren mit Epic oder Cerner. Die tatsächliche Wirkung variiert stark je nach Indikation, EHR-Dokumentationsqualität und Systemintegration, dazu mehr in den Abschnitten zu Werkzeugen und Ausschlusskriterien.

Feasibility vs. Pre-Screening, zwei verschiedene KI-Aufgaben

Wer über “KI in der Patientenrekrutierung” spricht, meint häufig zwei grundlegend verschiedene Aufgaben, die unterschiedliche Systeme, unterschiedliche Datenrechte und unterschiedliche Zeitpunkte im Studienzyklus erfordern. Den Unterschied nicht zu kennen, ist der häufigste Grund für falsche Werkzeugwahl.

Feasibility-Analyse passiert vor der Studienaktivierung. Die Frage ist: Existieren überhaupt genug Patienten mit diesen Kriterien, und in welchen Zentren? Dafür werden de-identifizierte, aggregierte Populationsdaten aus großen Netzwerken abgefragt. Das Ergebnis ist keine Patientenliste, sondern eine statistische Schätzung: “In euren 18 Partnerhäusern gibt es schätzungsweise 340 Patienten, die die Einschlusskriterien erfüllen.” Tools wie TriNetX arbeiten in diesem Modus, föderierte Abfragen, keine Re-Identifikation, kein direkter EHR-Zugriff auf Patientenebene.

Pre-Screening passiert während der aktiven Rekrutierungsphase. Hier geht es darum, konkrete Individuen zu identifizieren und dem Study Coordinator vorzuschlagen. Das erfordert Zugriff auf nicht-anonymisierte Patientendaten (pseudonymisiert, aber rückverfolgbar auf Site-Ebene), ein Votum der Ethikkommission, eine Rechtsgrundlage für die Nutzung von Routinedaten zu Forschungszwecken und eine tiefe EHR-Integration. Tools wie das frühere Deep 6 AI, heute Teil von Tempus AI, arbeiten in diesem Modus.

Die regulatorische und technische Vorbereitung für Pre-Screening ist erheblich aufwändiger als für Feasibility-Analysen. Wer beides in einen Topf wirft, unterschätzt entweder den Datenschutzaufwand oder überschätzt, was ein Netzwerk-Query-Tool leisten kann.

Einschätzung auf einen Blick

Zeitersparnis, hoch (4/5) Die Zeitersparnis ist der klarste Vorteil: Wo Study Coordinators bisher Tage bis Monate manuell im KIS gesucht haben, liefert ein gut integriertes Abgleich-System in Minuten eine priorisierte Kandidatenliste. Die Einschränkung, warum es keine 5 gibt: Maschinen liefern Vorschläge, Menschen müssen jeden Kandidaten klinisch verifizieren, der Zeitvorteil ist real, aber nicht vollständig. Die Rekrutierungsphase kann nicht vollständig automatisiert werden.

Kosteneinsparung, mittel (3/5) Jeder eingesparte Rekrutierungstag reduziert direkte Studienkosten. Tufts beziffert einen Studientag im Mittel auf rund 40.000 Dollar direkte Kosten; das ist ein Durchschnitt, kein Grenzwert, die tatsächliche Einsparung je gewonnenem Tag ist kleiner. Und sie fällt beim Sponsor an, während die Integrationsarbeit oft an der Site hängt. Im Alltag ist die Kausalität jedoch schwerer zu isolieren als bei der Rechnungsverarbeitung: Hängt die kürzere Rekrutierungszeit am KI-System, am besseren Protokolldesign, an der Site-Erfahrung oder am Patientenvolumen? Die Kosteneinsparung ist real, aber in der Kalkulation mit Vorsicht zuzuordnen.

Schnelle Umsetzung, sehr niedrig (1/5) Das ist der größte Stolperstein dieses Use Cases, und er ist strukturell, nicht technisch. EHR-Zugriff für Forschungszwecke erfordert in Deutschland mindestens ein Ethikvotum und häufig einen Vertrag mit dem IT-Betreiber des Krankenhauses. Die Integration in gängige deutsche KIS-Systeme (ORBIS von Dedalus, i.s.h.med, CGM Clinical) ist deutlich aufwändiger als in die US-Standards Epic und Cerner. Realistische Zeitschiene bis zum produktiven Pilotbetrieb: 12–24 Monate. Kaum ein anderer Use Case in der Pharmabranche braucht so lange bis zum ersten produktiven Einsatz.

ROI-Sicherheit, mittel (3/5) Die relevanten Metriken sind gut messbar: Screen-Failure-Rate vor und nach Einführung, Zeit bis zur Enrollmentzielerfüllung, Anzahl identifizierter Kandidaten pro Coordinator-Stunde. Die Einschränkungen: Der Effekt tritt erst nach abgeschlossener Integration auf, also frühestens im zweiten Jahr, und welcher Teil einer schnelleren Rekrutierung auf das System zurückgeht, lässt sich schwer isolieren. Deshalb 3.

Skalierbarkeit, hoch (4/5) Einmal aufgebaute EHR-Integrationen können für nachfolgende Studien in derselben Indikation wiederverwendet werden, der Mehraufwand je neuer Studie sinkt mit jeder zusätzlichen Implementierung. Warum keine 5: Jede neue Site braucht eigene Genehmigungsschritte und eigene EHR-Integrationsarbeit. Skalierung innerhalb einer Site ist einfach, Skalierung über neue Sites bleibt aufwändig.

Richtwerte, stark abhängig von KIS-System, Indikationsgebiet, Site-Infrastruktur und regulatorischem Rahmen.

Was das KI-System konkret macht

Ein EHR-basiertes Patientenmatching-System arbeitet in zwei Schritten: Erst liest es, dann vergleicht es.

Lesen: Das System verbindet sich mit dem Krankenhausinformationssystem über standardisierte Schnittstellen (FHIR, HL7 oder herstellerspezifische APIs). Es verarbeitet strukturierte Daten, ICD-10-Diagnoseschlüssel, LOINC-Laborcodes, Medikamentenlisten, und unstrukturierte Texte, Arztbriefe, Pathologieberichte, Operationsberichte, parallel. Für letztere kommt NLP zum Einsatz: Das System erkennt in einem Arztbrief semantisch, dass “cT3 N1 Adenokarzinom mit EGFR-Exon-19-Deletion” eine relevante Einschlussdiagnose für eine bestimmte NSCLC-Studie bedeutet, auch wenn der Begriff so im Protokoll nicht auftaucht.

Vergleichen: Die extrahierten Informationen werden gegen die formalisierten Ein- und Ausschlusskriterien des Studienprotokolls gehalten. Ergebnis ist ein Abgleich-Score pro Patient, keine Ja/Nein-Entscheidung, sondern ein Wahrscheinlichkeitswert, mit dem der Study Coordinator entscheidet, welche Fälle er zuerst manuell vertieft.

Was das System nicht macht: Es trifft keine Einschlussentscheidung. Es gibt keine Empfehlung an den Patienten. Es ersetzt nicht das aufklärende Gespräch und die Einwilligung (Informed Consent). Die KI ist ein Vorsortierungswerkzeug, der klinische Entscheid bleibt immer beim Menschen.

Ethikvotum und Datenschutz: Wer darf EHR-Daten für die Studie lesen?

Das ist die Frage, die alle technischen Überlegungen vorgelagert ist, und sie wird in der Praxis regelmäßig unterschätzt.

Für Feasibility-Analysen auf aggregierten, de-identifizierten Daten (etwa via TriNetX ) ist in Deutschland in der Regel kein vollständiges Ethikvotum erforderlich, wohl aber eine Vereinbarung mit dem Datenschutzbeauftragten des Krankenhauses und eine datenschutzrechtliche Prüfung, ob die Nutzung anonymisierter Daten für Sponsor-Feasibility durch die DSGVO gedeckt ist. Konkret variiert das je nach Bundesland und Trägerkrankenhaus erheblich.

Für Pre-Screening auf pseudonymisierter Patientenebene, also wenn das System konkrete Kandidaten identifiziert und dem Coordinator benennt, ist in Deutschland grundsätzlich ein positives Votum einer zuständigen Ethikkommission erforderlich (Verordnung (EU) Nr. 536/2014 und § 40 AMG, dazu ICH E6(R3)). Dazu kommt: Ein Auftragsverarbeitungsvertrag mit dem EHR-Anbieter und, soweit Drittanbieter-Software eingesetzt wird, mit dem KI-Plattformanbieter nach Art. 28 DSGVO. Patientendaten verlassen das Krankenhaus in der Praxis nicht, aber das KI-System, das im Krankenhaus-Netzwerk läuft, muss datenschutzrechtlich qualifiziert sein.

Typische Zeitachse für die Datenzugangsgenehmigung in Deutschland:

• Ethikkommission: 2–6 Monate (je nach Auslastung und Vollständigkeit des Antrags)
• IT-Sicherheitsprüfung des KIS-Betreibers: 1–4 Monate
• DSGVO-Prüfung und AVV-Verhandlung: 1–3 Monate
• Technische EHR-Integration: 3–9 Monate

Diese Phasen laufen nicht seriell, aber auch nicht vollständig parallel. Realistisch: 12–18 Monate bis zum ersten produktiven Pre-Screening.

Wichtig für die Praxis: Das Ethikvotum bezieht sich auf eine konkrete Studie, nicht auf das KI-System als solches. Wenn du dasselbe System für die nächste Studie nutzt, brauchst du erneut ein Votum, auch wenn es sich nur um eine andere Indikation an derselben Site handelt.

KIS-Integration in Deutschland: die unterschätzte Hürde

Der globale Markt für klinisches Patientenmatching wird von US-amerikanischen Tools dominiert, die für Epic und Oracle Health Cerner entwickelt wurden. Die deutsche Krankenhauslandschaft sieht anders aus.

Die marktführenden Krankenhausinformationssysteme in Deutschland sind ORBIS (Agfa HealthCare / Dedalus), IS-H/i.s.h.med (SAP-basiert) und CGM Clinical (CompuGroup Medical), mit erheblichen Versions- und Konfigurationsunterschieden zwischen Häusern. FHIR-basierte Schnittstellen, die in US-Krankenhäusern durch regulatorischen Druck (21st Century Cures Act) seit 2021 Standard sind, befinden sich in Deutschland noch in der Einführung, die Medizininformatik-Initiative (MII) hat hier Fortschritte gemacht, aber die Implementierungsreife variiert stark zwischen Unikliniken, kommunalen Häusern und privaten Trägern.

Das bedeutet für die Praxis:

FHIR ist nicht überall verfügbar. Für Häuser ohne FHIR-Unterstützung müssen HL7 v2-Nachrichten oder proprietäre Exportschnittstellen integriert werden, das erfordert klinische Informatiker auf Site-Seite und steigert den Integrationsaufwand erheblich.

Datenqualität ist nicht standardisiert. Dieselbe Diagnose kann in verschiedenen deutschen Häusern unterschiedlich kodiert sein, ICD-10-GM (die deutsche Variante) weicht von ICD-10-WHO ab, und dokumentationsbedingte Lücken sind systemüblich, nicht systemisch.

Die Medizininformatik-Initiative ist ein guter Einstiegspunkt. Die Datenintegrationszentren (DIZ) an Unikliniken bündeln Routinedaten für die Forschung, und im MII-Konsortium MIRACUM gibt es ein Rekrutierungswerkzeug, das über eine FHIR-Schnittstelle auf diese Datenbestände zugreift und Studienärztinnen und -ärzte per E-Mail auf mögliche Kandidaten hinweist. Wer als Sponsor oder CRO diese Schiene nutzt, setzt auf vorhandene Infrastruktur auf, statt jede Site einzeln anzubinden. Neu ist KIS-basierte Rekrutierungsunterstützung in Deutschland nicht: Die im BMBF-Projekt KIS-REK entwickelte Lösung hat laut Projektseite allein am Universitätsklinikum Münster seither mehr als 80 Studien unterstützt.

Ethik und Algorithmus-Bias: Wer wird systematisch übersehen?

Von 51 zwischen 2004 und 2023 publizierten Studien zu KI-optimierter Rekrutierung haben 11 Fairness-, Diskriminierungs- und Selektionsbias-Probleme der eingesetzten Algorithmen beschrieben. Das ist kein Randproblem.

EHR-basierte Abgleich-Systeme lernen aus historischen Patientendaten. Wenn bestimmte Patientengruppen in der Routineversorgung schlechter dokumentiert werden, etwa weil Vorbefunde von außerhalb nur auf Papier vorliegen oder Anamnesen wegen Sprachbarrieren kürzer ausfallen, dann übersieht das System genau diese Gruppen. Das Ergebnis: Die gefundenen Studienpatienten können besser dokumentiert und damit anders zusammengesetzt sein als die reale Patientenpopulation.

Konkrete Risiken für klinische Studien:

• Externe Validität: Ein Wirksamkeitsnachweis in einer selektierten Rekrutierungs-Subpopulation generalisiert möglicherweise nicht auf alle Indikationsträger.
• Regulatorisches Risiko: FDA und EMA legen zunehmend Wert auf demographische Repräsentativität in Studien. Ein algorithmisch verzerrtes Rekrutierungssystem kann eine nachträgliche Zulassungsauflage auslösen.
• Ethische Verantwortung: Wer KI zur Patientenselektion einsetzt, hat eine aktive Pflicht, Bias zu messen und zu mitigieren, nicht nur als Compliance-Thema, sondern als medizinethische Grundlage.

Was in der Praxis hilft:

Vor dem Go-Live sollte ein Fairness-Audit definiert werden: Werden die gefundenen Kandidaten nach Alter, Geschlecht, Herkunftsregion und Komorbiditätsprofil mit der Referenzpopulation verglichen? Wenn ja: durch wen, mit welchem Schwellenwert, und was passiert, wenn eine systematische Abweichung auftritt? Diese Entscheidungen gehören in das Studienprotokoll, nicht in eine optionale IT-Anforderungsliste.

Konkrete Werkzeuge, was wann passt

Der Markt gliedert sich klar nach dem Zeitpunkt im Studienzyklus und nach der Art des Datenzugangs.

Für die Feasibility-Phase (vor Studienstart):

TriNetX ist die international etablierteste Plattform für netzwerkbasierte Feasibility-Analysen. Du definierst Kohorten über ICD-10, SNOMED und Laborwerte, ohne Patientennamen, ohne Re-Identifikation. Das System gibt statistische Populationsschätzungen zurück, unterteilt nach Site und Region. Besonders wertvoll: historische Site-Performance-Daten im Netzwerk helfen bei der Selektion erfahrener Sites. Für Europa und Deutschland ist das Netzwerk kleiner als für Nordamerika, faktisch unverzichtbar für globale Studien mit EU-Komponente, aber kein Ersatz für lokale Feasibility-Gespräche.

Für aktives Pre-Screening (während der Rekrutierung):

Tempus AI hat Deep 6 AI im März 2025 übernommen und die Marke aufgelöst, das Produkt läuft dort weiter. Es liest unstrukturierte EHR-Daten direkt und liefert Study Coordinators priorisierte Kandidatenlisten, in Minuten statt Tagen. Integration primär über Epic und Oracle Health Cerner; europäisches KIS-Ökosystem ist schlechter abgedeckt. Datenhosting US-seitig, für europäische Einsätze ist eine individuelle DSGVO-Prüfung unabdingbar. Kein öffentlicher Preis; Einstieg ausschließlich über Enterprise-Sales.

Für Häuser ohne US-EHR-Systeme und mit striktem EU-Hosting-Anspruch bleiben heute noch wenige fertige Alternativen. IBM watsonx bietet als generische KI-Plattform die technische Grundlage für maßgeschneiderte NLP-Abgleich-Lösungen, erfordert aber erhebliche eigene Entwicklungsarbeit.

CTMS-Integration (Studienmanagement):

Medidata Rave EDC und Veeva Vault CTMS gehören zu den verbreiteten Enterprise-Plattformen für Studiendaten und Studienmanagement; Rave ist in erster Linie ein EDC-System für Studiendaten, Vault CTMS ein Studienmanagement-System. Sie sind keine Abgleich-Tools, aber der natürliche Endpunkt, in den die identifizierten Kandidaten als Screening-Records eingepflegt werden. Eine direkte API-Integration zwischen Abgleich-System und CTMS ist in reifen Setups Standard, ohne sie entsteht Medienbruch und Mehrarbeit.

Für Budget-bewusste Pilots und akademische Investigator-Initiated-Trials:

REDCap (Research Electronic Data Capture), das an der Vanderbilt University entwickelte Werkzeug, das gemeinnützige Einrichtungen über eine Lizenzvereinbarung kostenlos nutzen können (es ist kein Open Source), bietet keine native NLP-basierte Patientensuche, aber eine strukturierte Datenbank, in die manuell qualifizierte Kandidaten systematisch erfasst und verfolgt werden können. Kein Abgleich, aber ein erster Schritt weg von Excel-Listen. Kostenlos für gemeinnützige Einrichtungen, aber selbst zu hosten.

Zusammenfassung: Wann welcher Ansatz

• Protokolldesign und Site-Selektion → TriNetX (Feasibility-Netzwerk)
• Aktives Pre-Screening, US-Sites, Epic/Cerner → Tempus AI (früher Deep 6 AI)
• Deutsches KIS-Ökosystem, Custom-Entwicklung → IBM watsonx als Plattform, an Unikliniken die MII-Infrastruktur
• CTMS- und EDC-Endpunkt → Medidata Rave oder Veeva Vault
• Kleines Budget, akademische Studie → REDCap (kostenlos für gemeinnützige Einrichtungen, selbst hosten)

Datenschutz und Datenhaltung

KI-basiertes Patientenmatching ist datenschutzrechtlich eine der anspruchsvollsten Anwendungen im Pharma-Umfeld. Nicht weil die Technologie besonders invasiv ist, sondern weil der Zugriff auf Patientendaten zu Rekrutierungszwecken einen Rechtsrahmen erfordert, der sowohl DSGVO-Anforderungen als auch GCP-Prinzipien (ICH E6(R3)) gerecht werden muss.

Grundprinzip der Datenstrategie:

Feasibility-Analysen auf aggregierten, de-identifizierten Daten sind datenschutzrechtlich unkritischer als Pre-Screening auf Patientenebene. Diese Trennung sollte das architektonische Grundprinzip jeder Implementierung sein.

Konkrete DSGVO-Anforderungen für Pre-Screening:

• Art. 28 AVV mit dem KI-Plattformanbieter (vor Go-Live, nicht nach der ersten Demo)
• Datenschutz-Folgenabschätzung (DSFA) nach Art. 35 DSGVO, da Gesundheitsdaten nach Art. 9 besonders sensibel eingestuft werden, ist eine DSFA keine Ermessensfrage, sondern Pflicht
• Zweckbindung: Die Nutzung der Patientendaten muss im Antrag an die Ethikkommission und in der Patienteninformation explizit als Möglichkeit benannt sein (Broad Consent nach MII oder studienspezifischer Einwilligung)

Hosting und Datenlokalität:

• TriNetX : Federated-Architektur, Patientendaten verlassen das Krankenhaus nicht; nur aggregierte Ergebnisse werden übermittelt. Wo die zentrale Plattform gehostet wird, dokumentiert TriNetX öffentlich nicht, die Datenschutzerklärung sieht Übermittlungen auch in die USA vor.
• Tempus AI (früher Deep 6 AI): Verarbeitung primär US-seitig. Für deutsche Sites braucht ein Drittlandtransfer eine Rechtsgrundlage: den Angemessenheitsbeschluss für Empfänger, die nach dem EU-US Data Privacy Framework zertifiziert sind (Art. 45 DSGVO), sonst Standardvertragsklauseln mit ergänzenden Maßnahmen (Art. 46). Für Krankenhausdaten können die Landeskrankenhausgesetze zusätzliche Grenzen setzen.
• Medidata Rave und Veeva Vault : EU-Hosting konfigurierbar; AVV nach Art. 28 ist Enterprise-Standard. Pseudonymisierung der Subjekt-IDs nach GCP ist eingebaut.

EU AI Act-Relevanz: Anhang III zählt die Hochrisiko-Bereiche abschließend auf. Die Einträge mit Gesundheitsbezug betreffen Behördenentscheidungen über den Anspruch auf öffentliche Leistungen einschließlich Gesundheitsdiensten, die Risikobewertung in der Lebens- und Krankenversicherung und die Notfalltriage (Nr. 5 Buchst. a, c und d). Ein Kandidatenabgleich für eine Studie fällt unter keinen davon. Zum Hochrisiko-System würde er erst über Artikel 6 Absatz 1 in Verbindung mit Anhang I, also wenn er als Medizinprodukt eine Konformitätsbewertung durch eine Benannte Stelle bräuchte. Ein Rekrutierungswerkzeug ist kein Medizinprodukt, solange es keine diagnostische oder therapeutische Zweckbestimmung hat. Der Rahmen, der hier wirklich trägt, ist ein anderer: die Verordnung (EU) Nr. 536/2014 über klinische Prüfungen mit Humanarzneimitteln, ICH E6(R3) GCP und die DSGVO. Aus der KI-Verordnung bleibt Artikel 4 (KI-Kompetenz des Personals, seit dem 2. Februar 2025). Artikel 50 (Transparenzpflichten, seit dem 2. August 2026) greift nur, wenn ein System direkt mit Menschen interagiert oder Inhalte erzeugt, etwa ein Chatbot, der Patientinnen und Patienten über Studien informiert. Eine Rechtsauskunft vor der ersten Inbetriebnahme ist trotzdem sinnvoll, sie geht dann aber um Ethikvotum und Datenschutz, nicht um eine Risikoklasse.

Was es kostet, realistisch gerechnet

Die Kostenstruktur dieses Use Cases ist ungewöhnlich zweigeteilt: Die eigentlichen Lizenzkosten sind häufig geringer als die Integrationskosten.

Lizenzkosten (Plattformnutzung):

• TriNetX Netzwerk-Query: Einstieg im mittleren fünfstelligen USD-Bereich pro Indikation und Jahr (laut unserer Toolseite; keine öffentliche Preisliste)
• Tempus AI (früher Deep 6 AI): Enterprise-Preis auf Anfrage. Die kursierenden fünf- bis sechsstelligen USD-Beträge pro Site und Jahr stammen aus der Zeit vor der Übernahme

Integrationskosten (einmalig oder pro neuer Site):

• EHR-Integration (FHIR/HL7-Anbindung, Datenmapping): 30.000–150.000 € je nach KIS-System und Komplexität
• Vorbereitung des Ethikvotums: 10.000–30.000 € (interne Personalzeit)
• DSGVO-Prüfung, DSFA, AVV-Verhandlung: 5.000–20.000 € (externer Datenschutzanwalt)
• Validierung und Systemqualifizierung (GCP-konform): 20.000–80.000 €

Gesamtanlaufkosten realistisch: 100.000–400.000 € für die erste Site; 30.000–100.000 € je weitere Site danach.

Was dagegen gerechnet werden kann: Tufts beziffert die direkten Kosten eines Studientags im Mittel auf rund 40.000 Dollar. Rechenweg für den Fall, dass die gesamte Studie zehn Wochen früher fertig wird: 70 Tage mal 40.000 Dollar ergibt 2,8 Millionen Dollar. Das ist eine Obergrenze: Der Tageswert ist ein Durchschnitt aus Gesamtbudget und Laufzeit, patientenbezogene Kosten sparst du nicht, und eine einzelne Site mit schnellerer Vorauswahl verkürzt die Gesamtstudie nur, wenn sie der Engpass war. Belegte zehn Wochen Zeitgewinn durch Abgleich-Systeme haben wir nicht gefunden, wie viel bei euch ankommt, zeigt erst der Pilot. Und das Geld spart der Sponsor, während die Integrationskosten oft an der Site anfallen: Ohne Vereinbarung, wer was bezahlt, trägt die Rechnung nur für eine Seite.

Für kleine Sponsor-Teams und akademische Studien: Als grobe Orientierung, nicht als Rechnung: Unter einem Studienbudget von etwa 5 Millionen Euro ist das Kosten-Nutzen-Verhältnis meist ungünstig. Unterhalb dieser Schwelle ist das Kosten-Nutzen-Verhältnis ungünstig, REDCap und strukturierte manuelle Prozesse sind dann die wirtschaftlichere Wahl.

Typische Einstiegsfehler

1. Die EHR-Integration als technische Aufgabe behandeln, nicht als klinische. Das häufigste Scheitermuster: Die IT-Abteilung baut eine Datenbankanbindung, ohne die medizinischen Dokumentationspraktiken der Site zu verstehen. Das Ergebnis: Das System findet zwar Patienten mit dem ICD-Code F32.9 (depressive Episode, nicht näher bezeichnet), aber die klinisch relevante Einstufung nach Schweregrad steht nur im Freitext des Psychiaters. Ohne klinischen Informatiker, der die Datenstruktur kennt, liegt die False-Positive-Rate weit über dem handhabbaren Bereich. Lösung: Immer mit einem klinischen Champion und einer Informatikerin im Team starten, die beide die Dokumentationspraktiken der Site kennen.

2. NLP-Genauigkeit mit Entscheidungssicherheit verwechseln. Der Positive Predictive Value (PPV), also der Anteil der Vorschläge, die tatsächlich passen, schwankt je nach Indikation, Datenqualität und Systemkonfiguration stark. Rechenweg: Bei einem PPV von 30 Prozent müssen Study Coordinators für jeden tatsächlich geeigneten Kandidaten 1 geteilt durch 0,3, also gut drei Vorschläge manuell prüfen, bei 10 Prozent zehn. Das reduziert den Zeitvorteil erheblich. Kein produktives System sollte ohne vorherige Validierung der PPV auf der konkreten Site und für die konkrete Indikation eingesetzt werden.

3. Das Ethikvotum als einmalige Hürde behandeln. Das Votum einer Ethikkommission gilt für eine konkrete Studie. Eine Folgenutzung desselben technischen Systems für eine andere Studie erfordert einen neuen Antrag, und eine zusätzliche Site in einer laufenden Studie ist eine Änderung, die genehmigt werden muss. Das überrascht regelmäßig Teams, die nach dem ersten erfolgreichen Pilot sofort skalieren wollen. Lösung: Schon im ersten Antrag eine klare Formulierung für den technischen Systemrahmen verwenden, die eine spätere Erweiterung erleichtert.

4. Das System nach dem ersten Go-Live sich selbst überlassen. Das ist der stillste und häufig teuerste Fehler. EHR-Dokumentationspraktiken ändern sich: neue Arztbriefvorlagen, geänderte ICD-Kodierungsregeln, Systemmigrationen auf neue KIS-Versionen. Ein Abgleich-System, das bei Go-Live eine PPV von 55 % hatte, kann sechs Monate später bei 25 % liegen, ohne dass irgendjemand es bemerkt, weil Study Coordinators die falsch positiven Vorschläge still aussortieren, statt das Problem zu eskalieren. Lösung: Vierteljährliche Qualitätsaudits der Abgleich-Performance als vertragliche Pflicht definieren, nicht als optional.

Was mit der Einführung wirklich passiert, und was nicht

Die technische Integration ist lösbar. Die organisatorische Veränderung ist der eigentliche Aufwand.

Study Coordinators werden zu Algorithmuskritikern. Das klingt seltsam, aber es ist die gesündeste Reaktion. Erfahrene Coordinators haben ein intuitives Bild davon, welche Patienten für welche Studien infrage kommen. Wenn das System ihnen Kandidaten vorschlägt, die ihrem klinischen Bild widersprechen, werden sie skeptisch, und das ist gut so. Das Problem entsteht, wenn diese Skepsis nicht als Feedback in den System-Tuning-Prozess zurückfließt. Kein produktives Abgleich-System ohne strukturierten Rückmeldeprozess: Welche Vorschläge wurden abgelehnt, und warum?

Klinische Wissenschaftlerinnen und Wissenschaftler wollen die “Black Box” verstehen. Viele Principal Investigators wollen wissen, warum ein Patient vorgeschlagen wurde, welche Datenpunkte haben den Abgleich ausgelöst? Systeme, die keine nachvollziehbare Erklärung liefern, werden in akademischen Zentren regelmäßig abgelehnt. Explainability ist keine Kür, sondern Grundbedingung für Akzeptanz in der klinischen Forschung.

Die Site-Koordination wird zum Datenpfleger. In Häusern mit historisch lückenhafter Dokumentation bringt das Abgleich-System ein unbequemes Problem ans Licht: Viele Patienten sind schlecht genug dokumentiert, um vom System zuverlässig bewertet zu werden. Das löst manchmal Dokumentationsverbesserungen aus, was mittel- und langfristig wertvoll ist. Kurzfristig ist es zusätzliche Arbeit.

Was konkret hilft:

• Vor dem Go-Live eine Validierungsphase mit realen Patientendaten und bekanntem Ground-Truth (wer wäre manuell ausgewählt worden?) durchführen
• Study Coordinators aktiv in das Schwellenwert-Tuning einbeziehen, sie kennen den klinischen Kontext besser als jeder KI-Entwickler
• Einen strukturierten Feedback-Kanal für Ablehnungsgründe einrichten (warum wurde Vorschlag X nicht verfolgt?)
• Klare Rollenzuweisung: Wer ist verantwortlich für die monatliche Performancebewertung?

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände, und was dahintersteckt

“Wir haben keine Zeit, ein Jahr auf ein System zu warten.” Das ist das ehrlichste Gegenargument. Wenn eine Studie bereits läuft und die Rekrutierungsphase in 8 Monaten enden soll, hilft dieses System heute nicht. Die strategisch richtige Antwort: Mit dem Genehmigungsverfahren für die nächste Studie beginnen, während die aktuelle noch rekrutiert. Das System ist ein Investment für das Portfolio, nicht für den aktuellen Engpass. Für den laufenden Engpass helfen etablierte Patientenrekrutierungs-CROs schneller.

“Unsere Patienten würden das nicht wollen.” Das ist ein wichtiger Einwand, der oft falsch verstanden wird. Kein einwandfrei aufgesetztes Pre-Screening kontaktiert Patienten direkt oder teilt Patientendaten mit Dritten. Das System informiert den Arzt oder Coordinator, dass Frau X aufgrund ihrer klinischen Parameter für eine laufende Studie vorqualifiziert erscheint, und dieser entscheidet dann, ob er das Thema im nächsten Gespräch anspricht. Der Patient entscheidet selbst, ob er an dem Gespräch interessiert ist. Das ist strukturell nicht anders als wenn der Arzt selbst überlegt: “Wäre Frau X für die Studie geeignet?”, nur systematischer.

“KI kann die klinische Komplexität unserer Einschlusskriterien nicht abbilden.” Für hochkomplexe Kriterien ist das oft richtig, und es ist ein Argument für gutes Protokolldesign, nicht gegen KI. Wenn ein Einschlusskriterium wie “mindestens partielle Remission nach mindestens zwei Chemotherapielinien laut Investigator Judgment” definiert ist, kann kein System das zuverlässig aus dem EHR lesen, weil “Investigator Judgment” per Definition nicht im System steht. Gute Protokoll-Feasibility-Analysen mit TriNetX vor dem Antrag identifizieren genau solche Kriterien, und ermöglichen eine Überarbeitung, bevor sie zur teuren Hürde werden.

Woran du merkst, dass das zu dir passt

Passt gut, wenn:

• Ihr rekrutiert für Phase-II- oder Phase-III-Studien mit einem Budget über 5 Millionen Euro je Studie
• Die Rekrutierungsphase ist historisch immer länger als geplant, und ihr habt Daten darüber, wo die Engpässe saßen
• Die Site hat bereits ein strukturiertes EHR-System (kein papierdominiertes Haus)
• Die klinische Informatik der Site kann eine Vollzeitkraft für die Integration-Phase bereitstellen
• Ihr plant mehrere Studien in ähnlichen Indikationen, Wiederverwendbarkeit der Integration rechtfertigt den Initialaufwand

Wann es sich (noch) nicht lohnt, drei harte Ausschlusskriterien:

1. Zu kleines Patientenvolumen an der Site. Wenn eine Site historisch weniger als 200 Patienten pro Jahr mit der relevanten Diagnose behandelt, ist das Datenvolumen zu klein für zuverlässigen algorithmischen Abgleich. Hier ist persönlicher Kontakt, der Arzt kennt seine Patienten, effizienter als jede NLP-Lösung.

2. Papierbasierte oder fragmentierte Dokumentation ohne strukturierten EHR-Kern. Ein Abgleich-System kann nur lesen, was digitalisiert und strukturiert vorliegt. Wenn 40 % der klinischen Information in handschriftlichen Notizen, gescannten PDFs ohne OCR oder mündlicher Überlieferung steckt, wird das System systematisch falsch positive Ergebnisse produzieren, weil es entscheidende Ausschlusskriterien nicht findet, die im Arztbrief stehen würden, wenn er denn digitalisiert wäre.

3. Keine Ressourcen für das Ethikverfahren und kontinuierliche Systemwartung. Die Genehmigungsarbeit vor dem Start und das regelmäßige Audit der Abgleich-Performance danach brauchen eine dedizierte Person, nicht Vollzeit, aber verlässlich verfügbar. Wer hofft, ein System zu kaufen und dann laufen zu lassen, wird nach 12 Monaten entweder veraltete Treffer oder eine Ethikkommission haben, die nicht verlängert hat.

Das kannst du heute noch tun

Du musst keine EHR-Integration aufsetzen und kein Ethikvotum beantragen, um heute den ersten konkreten Schritt zu machen.

Das Sinnvollste, was du in den nächsten zwei Stunden tun kannst: Analysiere die Ein- und Ausschlusskriterien des laufenden oder geplanten Studienprotokolls mit einem großen Sprachmodell auf Machbarkeit. Nimm die Kriterien aus dem öffentlichen Registereintrag (CTIS oder ClinicalTrials.gov) oder kläre vorher mit dem Sponsor, ob das Protokoll in ein KI-Werkzeug darf; Protokolle stehen meist unter Vertraulichkeitsvereinbarung. Welche Kriterien sind aus strukturierten EHR-Daten ableitbar? Welche erfordern Freitext-Analyse? Welche sind im Prinzip nicht algorithmisch prüfbar?

Diese Analyse kostet nichts und gibt dir einen direkten Einblick, wie viel KI für dein konkretes Protokoll leisten kann, bevor du einen Anbieter kontaktierst.

Quellen & Methodik

• Tufts CSDD White Paper (August 2024): Smith Z, DiMasi JA, Getz KB. “New Estimates on the Cost of a Delay Day in Drug Development.” Tufts Center for the Study of Drug Development, August 2024. Direkte Kosten je Studientag im Mittel rund 40.000 $ für Phase II und III (447 Protokolle, Gesamtbudget geteilt durch Laufzeit), Phase III 55.716 $; Umsatz je Tag Verzögerung im Mittel rund 800.000 $ (645 Arzneimittel, eingeführt seit 2000). Volltext: csdd.tufts.edu, abgerufen am 19.09.2026

• JAMIA Scoping Review (2024): “Artificial intelligence for optimizing recruitment and retention in clinical trials: a scoping review.” Journal of the American Medical Informatics Association, September 2024. Analyse von 51 Studien 2004–2023; Fairness-, Diskriminierungs- und Selektionsbias-Probleme in 11 Studien. PMC: pmc.ncbi.nlm.nih.gov/articles/PMC11491624

• JCO Clinical Cancer Informatics (Januar 2026): Gong G et al., “Clinical Trial Patient Matching: A Real-Time, Common Data Model and Artificial Intelligence-Driven System for Semiautomated Patient Prescreening in Cancer Clinical Trials”, PubMed PMID 41512229. Beispiel einer publizierten Implementierung an einem US-Krebszentrum; die Ergebnisse haben wir nicht im Volltext geprüft.

• Medizininformatik-Initiative (MII): Rekrutierungswerkzeug des Konsortiums MIRACUM auf Basis der Datenintegrationszentren, FHIR-basiert, Hinweise an Studienärzte per E-Mail. medizininformatik-initiative.de

• KIS-basiertes Rekrutierungsprojekt KIS-REK (BMBF, Mai 2010 bis April 2012): Universitätskliniken Münster, Düsseldorf, Erlangen, Heidelberg und Gießen; in Münster seither mehr als 80 Studien unterstützt; Ausgangslage laut Projektseite: ein Drittel aller klinischen Studien wird wegen unzureichender Rekrutierung abgebrochen. medizin.uni-muenster.de

• Integrationskosten und Laufzeitschätzungen: grobe Schätzungen der Redaktion, keine erhobenen Werte. Lizenzkosten für TriNetX laut unserer Toolseite; für Deep 6 AI kursierten Beträge aus der Zeit vor der Übernahme durch Tempus AI, keine öffentlichen Preislisten verfügbar.

• DSGVO-Anforderungen: Datenschutz-Grundverordnung (EU) 2016/679, insbesondere Art. 9 (Besondere Kategorien personenbezogener Daten), Art. 28 (Auftragsverarbeitung), Art. 35 (Datenschutz-Folgenabschätzung). ICH E6(R3) GCP-Guideline für klinische Prüfungen.

• Rechtsrahmen klinische Prüfungen: Verordnung (EU) Nr. 536/2014 über klinische Prüfungen mit Humanarzneimitteln. Der EU AI Act ist hier nicht einschlägig: Die Einträge in Anhang III mit Gesundheitsbezug (Nr. 5 Buchst. a, c und d) betreffen Leistungsansprüche gegenüber Behörden, Kranken- und Lebensversicherung und Notfalltriage. Quelle: artificialintelligenceact.eu/de/annex/3/

Du willst wissen, ob dein Protokoll für KI-gestütztes Pre-Screening geeignet ist, und was der konkrete erste Schritt wäre? Meld dich für ein kurzes Gespräch.