Patientenrekrutierung für klinische Studien mit KI beschleunigen
KI gleicht elektronische Patientenakten (EHR) automatisch gegen Ein- und Ausschlusskriterien einer Studie ab — und identifiziert geeignete Patienten schneller und präziser als manuelle Aktendurchsichten.
- Problem
- 30–40 % aller klinischen Studien verzögern sich wegen unzureichender Rekrutierung. Manuelle Aktendurchsichten durch Study Coordinators sind zeitintensiv und fehleranfällig — geeignete Patienten werden übersehen oder zu spät identifiziert.
- KI-Lösung
- NLP-Systeme lesen strukturierte und unstrukturierte EHR-Daten (Diagnosen, Laborbefunde, Arztbriefe) und gleichen sie automatisch gegen die Studienprotokoll-Kriterien ab. Site-Koordinatoren erhalten priorisierte Patientenlisten statt manueller Suche.
- Typischer Nutzen
- Kandidaten-Identifikation von 19 Tagen (Brust-CA) bzw. 263 Tagen (Lunge) auf Minuten bis Stunden reduziert. Screen-Failure-Rate von 40–60 % auf 20–35 % gesenkt. Bis zu 64 % mehr geeignete Kandidaten identifiziert als bei manueller Suche.
- Setup-Zeit
- 12–24 Monate bis Pilotbetrieb (EHR, IRB, Validierung)
- Kosteneinschätzung
- Gesamtanlaufkosten erste Site: 100–400 T€ (EHR-Integration, IRB, DSGVO, Validierung); jede weitere Site: 30–100 T€ zusätzlich
Es ist Montag, 8:47 Uhr.
Maren Dietrich ist Study Coordinator in der Onkologie eines großen Universitätsklinikums in Köln. Auf ihrem Schreibtisch liegt das Protokoll einer neuen Phase-III-Studie: zwei Seiten Ein- und Ausschlusskriterien, engmaschig wie ein Netz aus medizinischen Detailbedingungen. Ihre Aufgabe: herausfinden, wie viele der aktuell behandelten Patienten infrage kommen. Dafür öffnet sie das Krankenhausinformationssystem, tippt Namen für Namen ein und liest Akte für Akte.
Nach drei Stunden hat sie 22 Fälle durchgearbeitet. Zwei davon könnten passen — sie ist sich nicht sicher, weil das entscheidende Laborergebnis aus dem letzten Quartal in einem handgeschriebenen Befund irgendwo in der gescannten Dokumentation steckt. Für die Studie werden 80 Patienten benötigt. Allein für diese Site.
Elf Wochen später hat das Study-Team die nötige Patientenanzahl immer noch nicht erreicht. Der Sponsor überlegt, eine zweite Site zu aktivieren, was weitere 60.000 Euro kostet und den Abschluss der Studie um vier Monate verschiebt.
Das ist kein schlechtes Zeitmanagement. Das ist der Normalzustand.
Das echte Ausmaß des Problems
Die Zahlen sind seit Jahrzehnten bekannt und immer noch erschreckend: Mehr als 80 Prozent aller klinischen Studien werden nicht im geplanten Zeitrahmen abgeschlossen — der häufigste Grund ist unzureichende Patientenrekrutierung. Etwa ein Drittel aller Studien muss wegen nicht erreichter Patientenzahlen abgebrochen oder auf Eis gelegt werden.
Das ist kein akademisches Problem. Das Tufts Center for the Study of Drug Development (Tufts CSDD) hat 2024 in einer Analyse von 409 Studienbudgets ermittelt, dass ein einziger Tag Verzögerung in der aktiven Studienphase direkte Kosten von rund 40.000 US-Dollar verursacht — dazu kommen entgangene Umsätze von bis zu 800.000 Dollar täglich, wenn der potenzielle Marktstart entsprechend nach hinten rückt. Für Phase-III-Studien liegt der direkte Tageskostensatz sogar bei 55.716 Dollar (in 2023er US-Dollar).
Der strukturelle Engpass sitzt meist nicht an der Zahl potenziell geeigneter Patienten — die meisten existieren, sie werden nur nicht gefunden. Study Coordinators berichten, dass sie bis zu 19 Tage benötigen, um für eine Brustkrebsstudie geeignete Kandidatinnen manuell zu identifizieren. Bei Lungenkrebsstudien, wo Staging- und Mutationsdaten über viele Systemquellen verteilt liegen, dauert die Standard-Vorprüfung im Schnitt 263 Tage.
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. Rund 80 Prozent der klinisch relevanten Informationen befinden sich in unstrukturierten Freitextdokumenten, nicht in maschinenlesbaren Feldern.
Study Coordinators sind der Flaschenhals. Mehr als 60 Prozent der für klinische Studien vorgesehenen Sites enrollen weniger als 100 Patienten pro Studie; 15 Prozent enrollen gar keine. Das liegt 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
| Kennzahl | Ohne KI-Unterstützung | Mit EHR-basiertem KI-Abgleich |
|---|---|---|
| Zeit bis zur Kandidaten-Identifikation | 19 Tage (Brust-CA) bis 263 Tage (Lunge) | Minuten bis wenige Stunden |
| Aktendurchsicht-Aufwand pro Site | 4–6 Stunden täglich je Coordinator | 1–2 Stunden für Follow-up und Verifikation |
| Erkannte potenzielle Kandidaten | Baseline | Bis zu 64 % mehr identifizierte Kandidaten (Ophthalmologie-Studie, JCO 2024) |
| Screen-Failure-Rate | 40–60 % bei vielen Indikationen | Reduktion auf 20–35 % realistisch |
| Feasibility-Analyse vor Studienstart | 6–12 Wochen manueller Site-Outreach | 48 Stunden via Netzwerk-Query |
Die Vergleichswerte stammen aus publizierten Studien und Praxisberichten. 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), eine IRB-Genehmigung für die Nutzung von Routinedaten zu Forschungszwecken und eine tiefe EHR-Integration. Tools wie Deep 6 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 verifikieren — 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. Bei 40.000 Dollar direkten Kosten pro Verzögerungstag ist die theoretische Einsparung enorm. 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, Agfa Orbis, CGM) ist deutlich aufwändiger als in die US-Standards Epic und Cerner. Realistische Zeitschiene bis zum produktiven Pilotbetrieb: 12–24 Monate. Kein anderer Use Case in der Pharmabranche benötigt so lange zum ersten produktiven Einsatz.
ROI-Sicherheit — hoch (4/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. Im Vergleich zu indirekten Nutzen wie Wissensdatenbanken ist hier der Bezug zwischen Maßnahme und Ergebnis transparent. Die Einschränkung: Der Effekt tritt erst nach abgeschlossener Integration auf, also frühestens im zweiten Jahr.
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 IRB-Genehmigungen 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 das informed Consent. Die KI ist ein Vorsortierungswerkzeug — der klinische Entscheid bleibt immer beim Menschen.
IRB 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 (§ 40 AMG, ICH GCP 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) 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 der richtige Einstiegspunkt. Die MII-Datenintegrationszentren (DIZ) an Unikliniken bieten strukturierten EHR-Datenzugang für klinische Forschung im Rahmen bereits vorhandener Ethikvoten (Broad Consent). Wer als Sponsor oder CRO die DIZ-Schiene nutzt, kann Teile der Genehmigungsarbeit auf bestehende Infrastruktur aufsetzen — das verkürzt die Vorlaufzeit um 3–6 Monate.
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 systematisch schlechter dokumentiert werden — was für ältere Menschen, Personen mit Migrationshintergrund und Patienten in ländlichen Versorgungsregionen bekannt ist — dann lernt das System, diese Gruppen systematisch zu benachteiligen. Das Ergebnis: Die gefundenen Studienpatienten sind tendenziell jünger, besser dokumentiert und städtischer 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):
Deep 6 AI 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 sind die beiden dominierenden Enterprise-Plattformen für klinisches Studienmanagement. 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 von Vanderbilt University entwickelte und von mehr als 7.000 Institutionen weltweit genutzte Open-Source-Tool, 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, aber selbst zu hosten.
Zusammenfassung: Wann welcher Ansatz
- Protokolldesign und Site-Selektion → TriNetX (Feasibility-Netzwerk)
- Aktives Pre-Screening, US-Sites, Epic/Cerner → Deep 6 AI
- Deutsches KIS-Ökosystem, Custom-Entwicklung → IBM watsonx als Plattform
- CTMS-Endpunkt → Medidata oder Veeva Vault
- Kleines Budget, akademische Studie → REDCap (Open Source, 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 IRB-Antrag 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 Statistiken werden übermittelt. EU-Hosting für Aggregationsebene verfügbar.
- Deep 6 AI: Verarbeitung primär US-seitig — für deutsche Sites ist ein Datentransfer in Drittland nur nach Art. 46 DSGVO zulässig (Standardvertragsklauseln + ergänzende technische Maßnahmen).
- 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: Patienten-Abgleich-Systeme, die Empfehlungen zu medizinischen Entscheidungen nahelegen, könnten als Hochrisiko-KI nach Anhang III EU AI Act klassifiziert werden. Die finale Interpretation hängt von der spezifischen Systemarchitektur und der Rolle des menschlichen Entscheiders ab — eine Rechtsauskunft vor der ersten Inbetriebnahme ist in diesem Kontext keine Vorsichtsmaßnahme, sondern Standard.
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: mittleres fünfstelliges USD-Bereich pro Indikation/Jahr (Schätzwert aus Branchenberichten; keine öffentliche Preisliste)
- Deep 6 AI: Enterprise-Preis auf Anfrage; typisch im fünf- bis sechsstelligen USD-Bereich pro Site/Jahr
Integrationskosten (einmalig oder pro neuer Site):
- EHR-Integration (FHIR/HL7-Anbindung, Datenmapping): 30.000–150.000 € je nach KIS-System und Komplexität
- IRB-Antrag und Ethikvotum-Vorbereitung: 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: Der Tufts-CSDD-Wert von 40.000 Dollar direkten Tageskosten gilt für die Verlängerung einer aktiven Studienlaufzeit. Wenn das System auch nur 10 Wochen Rekrutierungsverzögerung einspart — was bei komplexen Studien mit Abgleich-Systemen dokumentiert ist — ergibt sich ein theoretischer Gegenwert von 2,8 Millionen Dollar. Die tatsächlich erzielbare Einsparung liegt tatsächlich bei einem Bruchteil davon, weil Rekrutierungsverzögerungen multi-kausal sind. Aber selbst ein konservatives Szenario (20 % der theoretischen Einsparung) rechtfertigt die Investition in Studien mit Marktpotenzial.
Für kleine Sponsor-Teams und akademische Studien: Der Break-Even liegt realistisch nur bei einem Studienbudget über 5 Millionen Euro. 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.0 (depressive Episode) — aber die klinisch relevante Differenzierung zwischen leichter und schwerer Ausprägung 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. Veröffentlichte Studien zeigen für NLP-basierten Patientenabgleich einen Positive Predictive Value (PPV) zwischen 13 % und 63 % — je nach Indikation, Datenqualität und Systemkonfiguration. Das bedeutet: Bei einer PPV von 30 % müssten Study Coordinators für jeden tatsächlich geeigneten Kandidaten zehn Vorschläge manuell verifikieren. Das reduziert den Zeitvorteil dramatisch. 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 an einer konkreten Site. Eine Folgenutzung desselben technischen Systems für eine andere Indikation oder eine andere Site erfordert einen neuen Antrag — das überrascht regelmäßig Teams, die nach dem ersten erfolgreichen Pilot sofort skalieren wollen. Lösung: Schon im ersten IRB-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 stilste 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 Principals 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
| Phase | Dauer | Was passiert | Typisches Risiko |
|---|---|---|---|
| Strategische Planung und Partnerwahl | Monat 1–2 | Tool-Evaluation (TriNetX vs. Deep 6 AI vs. Custom), Site-Auswahl, erste Gespräche mit KIS-Anbieter | Kein belastbarer Vergleich möglich ohne eigene Machbarkeitsprüfung — Demo-Versprechen überschätzen oft die Integration |
| Datenschutz und Genehmigungen | Monat 2–8 | Ethikvotum beantragen, DSFA erstellen, AVV verhandeln, IT-Sicherheitsprüfung des Krankenhauses | Ethikkommission fordert Nachbesserungen, Verfahren dauert 2–3 Monate länger als geplant |
| EHR-Integration und Datenmapping | Monat 6–12 | API-Anbindung an KIS, Datenmapping für Diagnosen/Laborcodes, Validierung der Datenqualität | KIS-Version inkompatibel oder FHIR nicht verfügbar — Sonderlösung über HL7 v2 nötig |
| Klinische Validierung | Monat 10–16 | Retrospektive Validierung auf historischen Patientendaten mit bekanntem Ergebnis, PPV-Messung | PPV unter 40 % — Kalibrierung erforderlich, Zeitplan rutscht um weitere 2–3 Monate |
| Pilotbetrieb erste Studie | Monat 14–24 | Produktiver Einsatz für eine konkrete laufende Studie, kontinuierliches Monitoring | Study Coordinators nutzen das System nicht aktiv — Adoption-Problem, kein Technik-Problem |
| Skalierung auf weitere Sites | Ab Monat 18 | Neue Sites werden angebunden, IRB-Anträge für weitere Indikationen | Neue Site hat anderen KIS-Anbieter — Integrationsaufwand wiederholt sich |
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 IRB-Einreichen 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:
-
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.
-
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.
-
Keine Ressourcen für IRB-Prozess 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 das laufende oder geplante Studienprotokoll mit einem großen Sprachmodell auf Machbarkeit der Einschlusskriterien. 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.
Mitarbeiter:in
KI-Assistent
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 Tageskosten: ~40.000 $/Tag (alle therapeutischen Bereiche), 55.716 $/Tag Phase III; entgangene Umsätze: ~800.000 $/Tag. Volltext: csdd.tufts.edu
-
JAMIA Scoping Review (2024): “Artificial intelligence for optimizing recruitment and retention in clinical trials: a scoping review.” Journal of the American Medical Informatics Association, November 2024. Analyse von 51 Studien 2004–2023; dokumentierte Fairness-Probleme in 11 Studien; NLP Positive Predictive Value 13–63 % je nach Indikation und Systemkonfiguration. PMC: pmc.ncbi.nlm.nih.gov/articles/PMC11491624
-
JCO Clinical Cancer Informatics (2024): Clinical Trial Patient Matching mit KI-System: 94 % retrospektive Genauigkeit, 41 % Reduktion der Screening-Zeit, 10-fache Reduktion des Chart-Review-Aufwands (Onkologiestudie, PubMed PMID 41512229).
-
Ophthalmologiestudie (Ophthalmology Science 2024): KI identifizierte 64 % mehr potenzielle Studienteilnehmer verglichen mit Keyword-basierter Suche (1139 vs. 693 Kandidaten). DOI: doi.org/10.1016/j.xops.2024
-
Rekrutierungszeitvergleich: Mendel.ai-Studie (Applied Clinical Trials 2025): Standard Pre-Screening Brustkrebsstudie 19 Tage, Lungenkrebsstudie 263 Tage; KI: Minuten bis wenige Stunden.
-
Medizininformatik-Initiative (MII): Datenintegrationszentren an deutschen Unikliniken mit Broad-Consent-Infrastruktur für klinische Forschung. medizininformatik-initiative.de
-
KIS-basiertes Rekrutierungsprojekt (BMBF): Universitätskliniken Münster, Düsseldorf, Erlangen, Heidelberg und Gießen: Projekt zur KIS-basierten Rekrutierungsunterstützung in deutschen Krankenhäusern. medizin.uni-muenster.de
-
Integrationskosten und Laufzeitschätzungen: Erfahrungswerte aus publizierten Implementierungsberichten und Branchenschätzungen (Stand Mai 2026). Lizenzkostenangaben für TriNetX und Deep 6 AI aus Branchenberichten — 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.
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.
Diesen Inhalt teilen:
Interesse an diesem Use Case?
Schreib uns, wenn du mehr erfahren oder diesen Use Case für dein Unternehmen umsetzen möchtest. Wir melden uns zeitnah bei dir.
Weitere Use Cases
Klinische Studiendokumentation strukturieren und prüfen
KI unterstützt bei der Erstellung und Prüfung klinischer Studiendokumente — Protokolle, ICF und Clinical Study Reports — auf Vollständigkeit und ICH-Konformität.
Mehr erfahrenZulassungsanträge für BfArM und EMA vorbereiten
KI unterstützt die Erstellung von CTD-Modulen für nationale und europäische Zulassungsanträge — durch automatische Formatprüfung, Lückenanalyse und Konsistenzcheck.
Mehr erfahrenGxP-Compliance-Status kontinuierlich verfolgen
KI überwacht laufende GxP-Anforderungen, verfolgt offene CAPA-Maßnahmen und erstellt Compliance-Dashboards für QS-Leitung und Behördenaudits.
Mehr erfahren