Ihr KI-Abgleich-Tool unterscheidet einen zentralvenösen Katheter nicht von einer Herzkatheteruntersuchung. Das kostet Sie 800.000 $ pro Tag.

Wie unterscheidet sich der ontologiegestützte Abgleich von dem, was Tempus oder IQVIA bereits anbieten?

Tempus Patient Query und die Abgleich-Tools von IQVIA verwenden große Sprachmodelle, um klinische Notizen zu lesen und die Relevanz anhand von Studienkriterien zu bewerten. Das funktioniert gut bei einfachen Kriterien, scheitert jedoch bei ontologischen Unterscheidungen. Wenn ein Protokoll eine „Herzkatheteruntersuchung“ ausschließt und eine Patientenakte eine „Anlage eines zentralvenösen Katheters“ erwähnt, sieht ein LLM, das auf Vektorähnlichkeit arbeitet, zwei Katheter-Eingriffe am kardiovaskulären System und markiert eine Übereinstimmung. Ein SNOMED-CT-verankertes System erkennt, dass diese auf völlig unterschiedlichen Zweigen der Eingriffshierarchie liegen (SCTID 41976001 vs. 392230005), und stuft den Patienten korrekt als geeignet ein.

Der praktische Unterschied zeigt sich in den Screening-Fehlschlagsraten. LLM-basierter Abgleich erreicht bei gut strukturierten Kriterien typischerweise 85–94 % Genauigkeit, fällt jedoch bei Protokollen mit komplexen ontologischen Unterscheidungen, zeitlicher Logik oder Ausnahmeklauseln auf 70–80 % ab. Ontologiegestützter Abgleich hält über alle Kriteriumstypen hinweg eine Genauigkeit von über 95 %, weil die Eignungsentscheidung von einem symbolischen Reasoner berechnet und nicht von einem Sprachmodell vorhergesagt wird.

Der andere strukturelle Unterschied ist die Auditierbarkeit. Ein LLM erzeugt einen Relevanzwert. Unser System erzeugt eine Schlusskette: Patient hat SCTID X, Kriterium erfordert nicht-SCTID Y, X ist-kein-Untertyp-von Y gemäß SNOMED-Hierarchie, daher geeignet. Diese Schlusskette ist es, was Regulatory-Affairs-Teams für die Dokumentation der FDA-Einreichung benötigen.

Lässt sich dies in unser bestehendes EHR-System integrieren, ohne Patientendaten an externe APIs zu senden?

Ja, und das ist ein zentrales Architekturprinzip, kein nachträglicher Gedanke. Die neuro-symbolische Architektur trennt die neuronale Schicht (LLM zur Entitätsextraktion) von der symbolischen Schicht (Wissensgraph und Logiklöser). Beide können vollständig innerhalb Ihrer Firewall laufen.

Die LLM-Extraktionsschicht wird als lokales Modell bereitgestellt, typischerweise ein feingetuntes klinisches Sprachmodell, das auf Ihrer Infrastruktur oder einer sicheren Private-Cloud-Instanz läuft. Sie sendet niemals rohen Patiententext an externe APIs. Der Wissensgraph (Neo4j oder gleichwertig) und die SNOMED-CT-Ontologie liegen vor Ort. FHIR R4 ist der Eingabestandard. Für Epic-Umgebungen entwickeln wir gegen die über App Orchard verfügbaren FHIR-R4-Endpunkte und rufen die Ressourcen Patient, Condition, Procedure und MedicationAdministration ab. Für Oracle Health (Cerner) nutzt die Integration deren Millennium-FHIR-APIs.

Die Extraktionsschicht verarbeitet klinische Notizen lokal, bildet Entitäten auf SCTIDs ab, und der symbolische Reasoner bewertet die Eignung anhand der Protokollkriterien. Geschützte Gesundheitsinformationen verlassen niemals Ihre sichere Umgebung. Wir konzipieren von Tag eins an für die HIPAA-BAA-Konformität, einschließlich Audit-Protokollierung, Zugriffskontrollen nach dem Prinzip der minimal notwendigen Daten und De-Identifizierungsfunktionen für alle Daten, die tatsächlich zwischen Systemen bewegt werden müssen.

Für welche Therapiebereiche funktioniert das, und wie lange dauert die Einrichtung der Ontologie?

Die Architektur funktioniert für jeden Therapiebereich, weil SNOMED-CT über 350.000 medizinische Konzepte abdeckt. Die Variable ist die Ontologietiefe, also wie viele domänenspezifische Zuordnungen, Synonyme und hierarchische Beziehungen für Ihre spezifischen Protokolle vorkonfiguriert sind.

Die Onkologie ist der Bereich, mit dem wir die meisten Mandate beginnen, weil die Kriterien am komplexesten sind: Biomarker-Anforderungen (PD-L1-Expressionsniveaus, BRCA1/2-Mutationsstatus, EGFR-Varianten), Staging-Systeme (TNM, AJCC 8. Auflage), vorherige Therapieverläufe mit zeitlichen Bedingungen und Performance-Status-Werte. Eine produktionsreife Onkologie-Ontologie, die die wichtigsten 50 Biomarker, über 200 Behandlungsschemata und Standard-Staging-Systeme abdeckt, dauert 6–8 Wochen für Entwicklung und Validierung.

Kardiovaskulär und ZNS sind die nächsthäufigsten. Die kardiovaskuläre Ontologie konzentriert sich auf Eingriffshierarchien (die Unterscheidung der Herzkatheteruntersuchung ist nur eine von Dutzenden), Medikamenten-Interaktionsketten über CYP-Enzym-Stoffwechselwege und Laborwertbereiche mit standortspezifischen Referenzanpassungen. Das ZNS fügt die Handhabung subjektiver Endpunkte und das Mapping kognitiver Bewertungswerte hinzu.

Seltene Erkrankungen sind technisch am anspruchsvollsten, weil die SNOMED-Abdeckung bei ultraseltenen Erkrankungen dünn sein kann. Wir ergänzen mit Orphanet-Ontologie-Mappings und entwickeln benutzerdefinierte Konzepterweiterungen, die in den Graphen zurückfließen. Die Einrichtung für einen Therapiebereich für seltene Erkrankungen dauert 8–12 Wochen. Jede Ontologie wird vor dem Live-Gang anhand realer Protokollkriterien aus Ihrem Studienportfolio validiert.

Wie bewältigt das die komplexen „es sei denn“- und „außer“-Klauseln in modernen Studienprotokollen?

Hier übertrifft deterministische Logik probabilistische Sprachmodelle am deutlichsten. Standard-NLP behandelt Eignungskriterien als zu interpretierenden Text. Wir behandeln sie als zu berechnende formale Logik.

Nehmen Sie ein reales Kriterium: „Schließen Sie Patienten mit Bluthochdruck aus, es sei denn, er ist seit mindestens 3 Monaten unter stabiler Medikation gut eingestellt.“ Ein LLM sieht das Wort „Bluthochdruck“ und muss aus dem Kontext entscheiden, ob ausgeschlossen werden soll. Es trifft dies meistens richtig, aber „meistens“ bedeutet, bei jeder Studie geeignete Patienten zu verlieren.

Unser Parser zerlegt dies in deontische Operatoren. Prohibition: Bluthochdruck vorhanden. Permissions-Bedingung: Bluthochdruck UND eingestellt (Blutdruck unter 140/90 gemäß Protokolldefinition) UND stabile Medikation (gleiches antihypertensives Schema) UND zeitliche Bedingung (Dauer von mindestens 3 Monaten). Das System fragt dann die Medikationshistorie des Patienten aus dem Wissensgraphen ab, identifiziert das Antihypertensivum, prüft das Verordnungsstartdatum, berechnet die Dauerdifferenz gegenüber dem Screening-Datum und verifiziert die Blutdruckmesswerte innerhalb des Beobachtungsfensters. Jeder Schritt erzeugt eine überprüfbare Ausgabe.

Dieselbe Logik bewältigt Ketten wie „keine vorherige Chemotherapie, es sei denn, eine neoadjuvante Therapie wurde vor mehr als 6 Monaten abgeschlossen“, indem sie das Therapieintentionsattribut (neoadjuvant vs. adjuvant vs. palliativ), das Enddatum und die zeitliche Differenz prüft. Dies sind keine Sonderfälle. IQVIA-Daten zeigen, dass Protokolle mittlerweile durchschnittlich über 27 Eignungskriterien umfassen, viele mit verschachtelten Bedingungen. Eine einzige falsch behandelte Ausnahmeklausel pro Protokoll summiert sich über Hunderte gescreenter Patienten zu Dutzenden verlorener Rekrutierungen.

Wie sieht ein typisches Mandat aus, und was kostet es im Vergleich zur Lizenzierung einer Plattform?

Ein typisches Mandat läuft über drei Phasen in 14–20 Wochen. Phase 1 (3–4 Wochen) ist ein Audit der Rekrutierungsabläufe: Wir analysieren Ihre aktuellen Screening-Fehlschlagsraten, kartieren Ihre EHR-Datenlandschaft, überprüfen 10–15 repräsentative Protokolle aus Ihrem Studienportfolio und identifizieren die spezifischen Kriteriumstypen, die die meisten Falsch-Positiven und verpassten Übereinstimmungen verursachen. Diese Phase liefert ein technisches Architekturdokument und ein ROI-Modell auf Basis Ihrer tatsächlichen Daten.

Phase 2 (8–12 Wochen) ist die Entwicklung: Ontologie-Entwicklung für Ihren priorisierten Therapiebereich, LLM-Feintuning auf Ihre Muster klinischer Notizen, Aufbau des Wissensgraphen, Konfiguration des symbolischen Reasoners und FHIR-Integration mit Ihrer EHR-Umgebung. Phase 3 (3–4 Wochen) ist die Validierung: retrospektive Tests anhand abgeschlossener Studien mit bekannten Rekrutierungsergebnissen, Genauigkeits-Benchmarking und Integration in den Koordinator-Workflow.

Die Kosten hängen vom Umfang ab. Eine Entwicklung für einen einzelnen Therapiebereich mit einer EHR-Integration kostet typischerweise 180.000 $ bis 350.000 $. Multi-therapeutische oder Multi-Site-Bereitstellungen skalieren mit der Breite der Ontologie und der Integrationskomplexität. Zum Vergleich: Die Plattformlizenzen von Tempus und IQVIA kosten 200.000 $ bis über 500.000 $ jährlich, zuzüglich Gebühren pro Patient oder pro Studie.

Der grundlegende wirtschaftliche Unterschied ist das Eigentum. Eine Plattformlizenz ist wiederkehrende Ausgabe mit Anbieterabhängigkeit. Eine Eigenentwicklung ist ein Vermögenswert, den Sie besitzen, pflegen und erweitern. Für Organisationen, die jährlich über 20 Studien durchführen, erreicht die Eigenentwicklung typischerweise innerhalb von 18 Monaten den Break-even gegenüber der Plattformlizenzierung, mit dem zusätzlichen Vorteil einer auf die Komplexität Ihres spezifischen Protokolls abgestimmten Abgleichgenauigkeit.

Erfordert dies eine FDA-Zulassung, oder qualifiziert es sich unter der CDS-Ausnahme?

Die im Januar 2026 aktualisierte Clinical-Decision-Support-Leitlinie der FDA ist hier der relevante Rahmen. Die Schlüsselfrage ist, ob das System autonome klinische Entscheidungen trifft oder die menschliche Entscheidungsfindung unterstützt.

Unsere Architektur ist für die CDS-Ausnahme gemäß Abschnitt 3060 des 21st Century Cures Act konzipiert. Das System erfüllt alle vier Ausnahmekriterien: Es ist nicht dafür bestimmt, medizinische Bilder oder Signale zu erfassen, zu verarbeiten oder zu analysieren; es zeigt die Grundlage für Empfehlungen an (die vollständige Schlusskette); es ist für medizinisches Fachpersonal mit unabhängiger Überprüfungsfähigkeit bestimmt; und es ersetzt nicht das klinische Urteil bei Eignungsentscheidungen.

In der Praxis bedeutet das, dass das System geordnete Patienten-Studien-Übereinstimmungen mit Konfidenzwerten und Schlussketten ausgibt. Ein Standortkoordinator oder klinischer Forschungsassistent überprüft jede Übereinstimmung vor jedem Patientenkontakt. Das System rekrutiert niemals automatisch.

Allerdings verschiebt sich die Auslegung des CDS-Umfangs durch die FDA weiterhin. Wenn Ihre Organisation plant, Abgleichausgaben zu nutzen, um Patienten ohne menschliche Überprüfung automatisch auszuschließen, kann das System in den Geräte-Bereich übergehen, der eine 510(k)-Zulassung oder De-Novo-Klassifizierung erfordert. Wir empfehlen, das Digital Health Center of Excellence der FDA frühzeitig in der Designphase einzubeziehen. Wir erstellen die regulatorische Dokumentation, einschließlich der Begründung der CDS-Ausnahme, der Erklärung der Zweckbestimmung und des klinischen Bewertungsberichts, als Standardergebnis in Phase 1.