Über föderiertes Training von KI-Algorithmen und Methoden aus dem maschinellen Lernen wird in der Medizininformatik recht viel geredet, aber es gibt bisher erstaunlich wenige funktionierende Projekte. Sie setzen ein solches föderiertes Algorithmen-Training derzeit mit der Arbeitsgruppe AI/ML des DZHK an einem Beispiel konkret um, nämlich an der Prothesenplanung beim Transkatheter-Aortenklappenersatz (TAVI). Bevor wir zur Informatik kommen: Was ist das Problem beim TAVI-Planen, so wie es im Moment abläuft?
Ich bin Informatikerin, keine Medizinerin, insofern will ich mich da nicht zu weit aus dem Fenster lehnen. Aber typischerweise wird für diesen Eingriff ein CT-Datensatz angefertigt, auf dessen Basis sich dann der Kardiologe oder die Kardiologin für eine TAVI-Prothese in einer bestimmten Größe entscheidet. Wir glauben, dass wir das mit einer Software unterstützen können, die die geometrischen Verhältnisse der patientenindividuellen Anatomie und die Kalklast an den Herzklappen auf CT-Datensätzen analysiert und die dann Vorschläge für geeignete Klappen-typen und Klappengrößen machen kann. Natürlich werden auch in Zukunft am Ende die Behandler:innen die Entscheidung treffen. Rein automatische Entscheidungsunterstützung ist für solche komplexen und weitreichenden Entscheidungen auf absehbare Zeit aus rechtlicher Sicht keine Option.
Warum braucht es dafür eine KI? Was ist das Problem an der Prothesenwahl?
Es kann bei einer TAVI zu Komplikationen kommen. Der Patient kann nach der Operation schrittmacherpflichtig werden, weil eine nicht optimal sitzende Prothese auf das Reizleitungssystem des Herzens drückt. Ob das passiert, hängt unter anderem davon ab, wie gut die gewählte Prothese zur individuellen Anatomie passt. Die Variabilität zwischen den Einrichtungen und auch zwischen einzelnen Behandelnden ist bei dieser Komplikation relativ groß. Da versuchen wir anzusetzen. Es gibt Kriterien für die Auswahl der Prothesen, aber insgesamt ist das recht subjektiv, entsprechend Spielraum gibt es für Verbesserungen. Das Risiko für Schrittmacherpflichtigkeit vorauszusagen, ist eine der Fragestellungen, die wir uns in unserem Konsortium gestellt haben. Und im nächsten Schritt: Kann es durch optimale Auswahl der Prothese reduziert werden? Unser medizinischer Sprecher Prof. Tim Seidler von der Universität Gießen kann Ihnen hier noch viel besser Auskunft geben. Er war maßgeblich für die Definition des Use Cases verantwortlich.
Wie viele CT- und EKG-Datensätze brauchen Sie, um so einen Algorithmus zu trainieren?
Es gibt nie eine Obergrenze, je mehr, umso besser, vorausgesetzt die Standards an Datenqualität sind erfüllt. Das Problem ist, dass ein Klinikum allein nicht genug Daten zur Verfügung hat. Hier in Heidelberg kommen wir derzeit auf ungefähr 800 bis 1 000 geeignete Datensätze. Das ist nicht schlecht, aber es reicht nicht. Deswegen haben wir unter dem DZHK-Dach ein nationales Konsortium aufgebaut, damit wir multizentrisch arbeiten können. Aktuell haben wir von acht sehr aktiven Zentren 8 124 Datensätze zur Verfügung. Wichtig ist: Es geht nicht nur um die Menge, es geht auch um die Variabilität. Wir wollen mit Routinedaten arbeiten und wir wollen einen Algorithmus, der nicht nur in Heidelberg funktioniert, sondern überall, wo TAVIs gemacht werden. Dazu müssen wir mit Daten aus unterschiedlichen Kliniken trainieren. Die CT-Datensätze unterscheiden sich beispielsweise je nachdem, von welchem Hersteller der Scanner ist. Auch die Bildausschnitte variieren, und die Parametrierung der Untersuchung.
Nun könnten Sie die ganzen Datensätze aus acht Standorten alle auf einen Server packen. Sie gehen aber einen anderen Weg, Sie lassen die Algorithmen reisen, nicht die Daten. Was ist grundsätzlich der Vorteil eines solchen dezentralen Ansatzes?
Das hat beides Vor- und Nachteile. Ein zentrales Training ist zum Beispiel im Rahmen von eigens eingerichteten Registern möglich. Das ist dann sehr effizient, nur müssen dazu die Daten erst mal ins Register. Das klappt in der Realität oft nicht besonders gut, aus unterschiedlichen Gründen. Das dezentrale Training hat demgegenüber Vorteile, weil die jeweiligen Kliniken beziehungsweise Abteilungen die Hoheit über die Daten behalten. Man kann dann differenzierter mitbestimmen, für welche Forschungsfragen die Daten letztendlich genutzt werden.
Wie läuft das vernetzte Lernen konkret ab?
Wir haben an den einzelnen Kliniken eine Rechnerinfrastruktur angeschafft. Das sind High-Performance-PCs mit sehr guten Grafikkarten, was etwas günstiger ist, als eigene Server zu installieren. Auf diese Rechner oder „Knoten“ müssen die Daten verschoben werden. Wir haben also keinen Direktzugriff auf die klinischen Informationssysteme. Der dezentrale Knoten kann nur mit einem einzigen äußeren Server kommunizieren, und das ist der zentrale Server im Netzwerk. Dieser Server schickt einen Algorithmus, den wir trainieren wollen, simultan an die einzelnen Knoten. Der Algorithmus wird dann auf den dezentralen Daten des jeweiligen Standorts trainiert. Während dieses Trainings, das typischerweise mehrere Tage dauert, werden die sogenannten Modellgewichte nach bestimmten Iterationen ausgetauscht. Klingt kompliziert, aber letztlich sind die Modellgewichte quasi der jeweils aktuelle Status des Algorithmus nach einer bestimmten Trainingszeit. Diese Modellgewichte aller Knoten werden vom Server empfangen, sie werden über alle Standorte hinweg gemittelt, der neue Algorithmus wird danach wieder simultan an alle Standorte geschickt und dann fängt das Ganze von vorne an. Über mehrere Trainingsrunden hinweg wird der Algorithmus immer robuster: Wir „mergen“ sozusagen die Informationen von allen Standorten in ein gemeinsames neuronales Netz. Dabei kann es durchaus sein, dass der Algorithmus an einem Standort etwas schlechter performt als ein Algorithmus, der nur an diesem Standort trainiert worden wäre. Aber in der Gesamtheit wird der im Netzwerk trainierte Algorithmus am Ende weniger falsche Entscheidungen treffen – er ist robuster. Wir wollen ja keinen Algorithmus haben, der zwar in Heidelberg super funktioniert, in Hamburg oder München aber komplett fehlschlägt.
Der TAVI-Anwendungsfall ist letztlich nur ein Beispiel, das illustriert, was so eine Infrastruktur leisten kann. Sie könnten das für andere Algorithmen-Trainings genauso verwenden.
Genau. Am Ende geht es uns um die Infrastruktur, die es erlauben soll, unterschiedliche Use Cases zu trainieren und damit „Large Scale AI“ zu ermöglichen. Neuere KI-Algorithmen wie Foundation Models basierend auf Transformer-Architekturen werden immer datenhungriger. Wir können dem nur nachkommen, wenn wir multizentrisch mit geringen Hürden kooperieren. Grundsätzlich sind viele andere medizinische Fragestellungen interessant für so ein dezentrales Konzept.
Was waren die Herausforderungen bei der Umsetzung Ihres Netzwerks?
Die größte Herausforderung ist die heterogene IT-Infrastruktur, also die Integration der dezentralen Knoten in die jeweilige IT-Landschaft. Das ist in allen Kliniken anders, weil unterschiedliche Software genutzt wird, weil die Firewalls unterschiedlich konfiguriert sind, weil man es mit unterschiedlichen Port-Konfigurationen zu tun hat. Wir haben – bzw. mein Doktorand Malte Tölle hat – über 200 Support-Calls mit den anderen Standorten von hier aus durchgeführt. Das ist schon erheblich. Trotzdem bin ich überzeugt davon, dass das, was wir hier machen, eine der Arten und Weisen sein wird, wie wir in Zukunft KI-Methoden trainieren können und sollten. Wir brauchen diese multizentrischen Infrastrukturen in Deutschland. Unsere Kliniken sind im internationalen Vergleich nicht groß genug, um als einzelne Kliniken im KI-Bereich eine Rolle spielen zu können. So ein Netzwerk hat noch einen weiteren Vorteil: Wir können nicht nur trainieren, sondern auch validieren. Wer im medizinisch-algorithmischen Kontext hochrangig publizieren will, muss auf jeden Fall zeigen können, dass der Algorithmus nicht nur am eigenen Standort gut funktioniert, sondern auch anderswo. Das können wir mit unserer Architektur wunderbar umsetzen: Wir können beim Training zum Beispiel einen Knoten aussparen und dort validieren, oder wir machen aus einer Teilmenge aller Datensätze eine multizentrische Validierungskohorte.
Gibt es Verbindungen zwischen dem, was Sie machen, und anderen Netzwerkstrukturen in der deutschen Universitätsmedizin, dem Netzwerk Universitätsmedizin (NUM) beispielsweise oder der Medizininformatik-Initiative (MII)?
Ich bin sehr froh darüber, dass es bereits große Initiativen wie das NUM gibt, die entsprechende Infrastruktur in den letzten Jahren zwischen den 36 Uniklinika in Deutschland aufgebaut hat. NUM RACOON ist ein Radiologie-bezogenes Netzwerk, welches bisher hauptsächlich COVID-Fragestellungen betrachtet hat. Es gibt die MII mit ihren Datenintegrationszentren. Der Integrationsprozess beider Initiativen hat bereits begonnen. Für uns ist es natürlich sehr interessant, zu diesen Initiativen Brücken zu bauen. Wir haben bei unseren Entwicklungen darauf geachtet, dass die Software stark an die bisherigen Entwicklungen in NUM RACOON angelehnt ist, damit die Kompatibilität gewährleistet bleibt, und wir freuen uns auf zukünftige mögliche Zusammenarbeiten.
Sie nutzen also nicht die Datenintegrationszentren (DIZ) der MII für Ihre Knoten?
Bisher nicht. Ich halte das schon für eine Möglichkeit und es gab auch schon erste Gespräche dazu, aber dazu müssen die DIZ nachhaltig finanziert werden. Bisher war das meines Kenntnisstandes nach noch in der Diskussion. Ich glaube, wir konnten deswegen so vergleichsweise schnell sein, weil wir es erst mal im Rahmen unserer gut funktionierenden und gut kooperierenden DZHK-Arbeitsgruppe selbst gemacht haben. Das bedeutet aber nicht, dass wir die Funktion des DIZ erfüllen, denn die geht weit über das hinaus, was wir im Projekt erreicht haben. Technisch machen wir einiges, was andere Plattformen auch machen oder machen wollen: Daten vorfiltern zum Beispiel, oder Ausreißer entfernen. Wir haben das föderierte Lernen nicht erfunden. Aber ich trau mich schon zu sagen, dass wir nicht nur in Deutschland, sondern weltweit eines von wenigen Netzwerken sind, die föderiertes Lernen in der Medizin wirklich in die Anwendung gebracht haben, und mein Wunsch ist, dass dieser Ansatz nun nachhaltig verfolgt, adaptiert und sukzessive verbessert wird.
Lassen Sie uns über Datenqualität reden. Welche Anforderungen haben Sie an die Daten in Ihrem TAVI-Projekt? Und wie stellen Sie eine hohe Datenqualität sicher?
In unserem TAVI-Projekt brauchen wir für die Auswertung der CT-Datensätze Annotationen von Expertinnen und Experten. Auch das war eine der Herausforderungen. Diese manuellen Annotationen, wie beispielsweise das Einzeichnen anatomischer Landmarken oder die Segmentierung der Kalzifikation, müssen an jedem Standort angefertigt werden. Die an den Standorten bereits verfügbaren Softwares zur TAVI-Planung können dies, aber es wird oft nicht nachhaltig gespeichert oder das proprietäre Speicherformat ist für Forscher:innen nicht lesbar. Es war uns von Anfang an klar, dass wir nicht Tausende von Datensätzen nochmals annotieren lassen können. Dafür fehlt die Zeit. Wir haben die Algorithmen deswegen so entwickelt, dass wir mit relativ wenigen annotierten Datensätzen auskommen. Das ist aus Informatiksicht ein Highlight des Projekts, da sind wir auch ein bisschen stolz drauf. Letztlich haben wir pro Standort nur 20 bis 40 Datensätze nachannotieren lassen – in Heidelberg etwas mehr, um noch eine bessere Überprüfbarkeit zu gewährleisten.
Dieses Spannungsfeld zwischen Bedarf an möglichst vielen möglichst gut annotierten Daten einerseits und begrenzten Personal- und Dokumentationsressourcen im klinischen Bereich andererseits gibt es ja überall, wo mit medizinischen Daten geforscht wird.
Genau, und unter anderem deswegen geht die Bedeutung dieses Projekts auch über den konkreten Use Case TAVI hinaus. Die algorithmischen Weiterentwicklungen, die wir genutzt haben, um mit den vergleichsweise wenigen annotierten Datensätzen ein effizientes Training zu erreichen, lassen sich auf andere Szenarien übertragen.
Sie haben das Projekt im Rahmen des DZHK durchgeführt. Gibt es Interesse von anderen DZHK-Arbeitsgruppen oder von anderen Deutschen Zentren der Gesundheitsforschung (DZG), diese Infrastruktur zu nutzen?
Wir wurden schon von vielen wegen anderer Use Cases angesprochen. Ich habe da bis jetzt immer ein bisschen gebremst, denn wir mussten erst mal am eigenen Use Case zeigen, dass die technische Realisierung solide ist. Natürlich ist es immer auch ein finanzielles Thema, der Wunsch einer signifikanten Weiterförderung besteht. Bisher mussten wir das Projekt mit relativ geringfügigen Summen realisieren. Das wird in Zukunft nicht mehr tragfähig sein. Der Aufwand für die Koordination und die technische Umsetzung ist schon beachtlich. Grundsätzlich könnte das föderierte Lernen weit über die Bildgebung hinausgehen, man könnte zum Beispiel mit Wearable-Daten arbeiten. Auch für die Omics-Community ist das interessant, zumal bei genetischen Daten noch mal höhere Anforderungen an den Datenschutz bestehen.
Was gäbe es für Optionen für eine Verstetigung?
Das müssen wir jetzt diskutieren. Wenn eine solche Infrastruktur eine Dauereinrichtung werden soll, dann muss die finanziell hinterlegt sein auf die eine oder andere Weise. Es liegt schon nahe, Infrastrukturen wie jene der Medizininformatik-Initiative mit ihren Datenintegrationszentren zu nutzen. Aber das löst noch nicht die Finanzierungsfrage. Das NUM geht jetzt in eine neue Phase, es werden neue Projekte ausgeschrieben, das könnte interessant sein. Aber das ist alles noch ziemlich spekulativ.
Was empfehlen Sie anderen Projekten, die etwas Ähnliches vorhaben?
Es steht und fällt mit den Menschen, die in einem Netzwerk zusammenarbeiten. Unser Projekt findet im Rahmen der DZHK-Gruppe AI/ML statt, die wurde 2019 am Standort Göttingen auf Initiative von Herrn Prof. Dr. Tim Friede aus der Biostatistik ins Leben gerufen. Im Rahmen der Pandemie sind wir zusammengewachsen, zuerst über einen gemeinsam Review-Artikel zu KI-Projekten in der Kardiologie. Irgendwann wurde uns dann klar, dass wir in Deutschland multizentrische KI in den Kliniken forcieren müssen, und da lag ein föderiertes Training nahe. Und dann haben wir beschlossen, die DZHK-Struktur und eine übersichtliche Menge an Fördermitteln zu nutzen, um ein Federated-Learning-Projekt auf den Weg zu bringen. Wir hatten also ein starkes Netzwerk, bevor wir uns auf den Weg gemacht haben, und natürlich war der Wille da, etwas zu bewegen. Das braucht es.
Frisch aus der Datenbank:
Wie genau das föderierte Lernen im Bereich der kardialen CT-Bildgebung abläuft, ist jetzt auch nachlesbar. Auf dem arXiv Preprint-Server beschreiben Malte Tölle, Sandy Engelhardt und Kolleg:innen den Aufbau der Infrastruktur und den Ablauf des föderierten Lernens:
Tölle, M. et al. (2024). Federated Foundation Model for Cardiac CT Imaging.
https://doi.org/10.48550/arXiv.2407.07557
Das Interview führte Philipp Grätzel von Grätz, Chefredakteur E-HEALTH-COM