Wie ZebraMedicalVision klinische KI-Diagnoselösungen entwickelt

Warum gibt es bisher so wenige KI-Diagnoselösungen?

Zahlreiche Studien konnten bereits belegen, dass Machine Learning Modelle - unter anderem im Bereich der Radiologie - manche Aufgaben genauso gut ausführen können wie ausgebildete Ärzte. Die Modelle können teilweise sogar Muster entdecken, die einem menschlichen Arzt gar nicht auffallen würden.

Trotzdem wurden viele Jahre lang kaum KI-gestützte Diagnoseverfahren in Krankenhäusern eingesetzt. In anderen Branchen lässt sich dagegen eine weitaus schnellere Umsetzung von der Forschung in die Praxis beobachten: nach einem großen Durchbruch in der Gesichtserkennungs-Technologie dauerte es beispielsweise nur um die sechs Monate, bis man auf Facebook anhand dieser Technologie seine Freunde markieren konnte. Doch in der medizinischen Diagnostik haben sich vorhandene Innovationen bisher kaum in die Praxis durchsetzen können. Warum ist das so?

Genau vor dieser Frage standen Eyal im Jahr 2014, als ZebraMedicalVision entstand: jede Menge bahnbrechende Forschung, klarer Bedarf an KI-Unterstützung in der Diagnostik, reichlich Engineering Talent, aber kaum KI Lösungen in den Kliniken.

Also machten Eyal und sein Team sich auf die Suche nach möglichen Ursachen für dieses Phänomen. Schnell mussten sie feststellen, dass die KI-Forschung schlichtweg nicht in der Lage ist, alle Ansprüche zu erfüllen, die der Einsatz von KI-Diagnostik im klinischen Kontext stellt. Zusätzlich zu guter Performance brauchen klinische Modelle nämlich auch folgendes:

1. Modelle, die auf repräsentativen Datensätzen trainiert wurden;
2. Eine nahtlose Integration in klinische Arbeitsabläufe;
3. Eine Plattform, die KI-Forschung und Krankenhäuser verknüpft.

Challenge 1: Ein repräsentativer Datensatz

Das erste Problem, das Eyal und sein Team beobachteten, bestand darin, dass die meisten akademischen Forschungsprojekte auf eher kleinen Datensätzen basieren. Sie sind außerdem nicht nur klein, sondern repräsentieren auch selten die Bandbreite an verschiedenen Krankheits- und Behandlungsfällen, mit denen in Kliniken gearbeitet wird. Für Diagnoselösungen, die in der Praxis eingesetzt werden sollen, sind repräsentative Daten jedoch unverzichtbar.

Die erste Herausforderung bestand also darin, einen großen, vielfältigen Datensatz zu bauen, der exakt so aussieht, wie man ihn in einer Klinik erwarten würde.

Aus diesem Grund hat ZebraMedicaVision in seinen ersten zwei Jahren kaum Machine Learning Modelle gebaut. Stattdessen konzentrierten sie sich auf den Ausbau von Datenkooperationen mit über 30 Krankenhäusern in Israel, den USA und Indien.

Ein komplettes Bild des Patienten

Während viele Studien lediglich die Diagnosen von Arzt und Maschine anhand einer einzelnen Art von Daten (e.g. CT Scan) vergleichen, musste ZebraMedicalVision deutlich mehr in die Tiefe gehen.

Dabei haben sie folgende Daten erhoben:

• Radiologische Aufnahmen verschiedener Modalitäten (Röntgen, CT, MRI, Mammographie, PET und Nuklearmedizin);
• Laboranalysen;
• Informationen zu Aufnahme und Entlassung von Patienten;
• Ärztliche Diagnosen;
• Klinische Resultate (Zustand der Patienten nach Entlassung).

Der entscheidende Punkt bestand darin, dass die gesammelten Daten exakt die gleiche Vielfalt und Komplexität an Fällen repräsentieren sollten, mit der Ärzte im Krankenhaus konfrontiert sind.

Proof-of-Concept vs. klinische Diagnoselösungen

Angenommen, du entwickelst ein System, das anhand einer radiologischen Aufnahme  korrekt einschätzen kann, ob es sich um einen gesunden oder an Lungenkrebs erkrankten Patienten handelt. Auf den ersten Blick klingt so ein System zwar nützlich - in der klinischen Praxis kann man aber kaum etwas damit anfangen.

Erstmal ist das nur ein Proof-of-Concept: Du hast demonstriert, dass ein Algorithmus radiologische Aufnahmen verarbeiten und zwischen zwei klar definierten Patientengruppen differenzieren kann. Aber entspricht dieses Szenario (Lungenkrebs vs. gesunder Patient) wirklich der Problematik, mit der ein Arzt konfrontiert ist?

In Wirklichkeit taucht diese Frage in einer Klinik nicht auf. Es ist weitaus wahrscheinlicher, dass ein Patient bereits einige Symptome aufweist und dafür eine Ursache gefunden werden muss: Milchglastrübung, Lungenembolie, COPD, Emphysem und Lungenkrebs können sich alle in ähnlichen Symptomen äußern.

Damit ein Machine Learning Modell für einen Arzt von Nutzen ist, muss es in der Lage sein, zwischen verschiedenen radiologischen Aufnahmen symptomatischer Patienten zu unterscheiden - und nicht zwischen gesunden und erkrankten Menschen.

Anders ausgedrückt: Die Daten, auf denen das diagnostische Modell trainiert wird, müssen die unterschiedlichen Patienten in einer Klinik repräsentativ darstellen.

Das ist jedoch nicht die einzige Herausforderung bei der Entwicklung eines sinnvollen Modells für den Klinikalltag.

Challenge 2: Nahtlose Integration in klinische Arbeitsabläufe

Ärzte sind verständlicherweise nur dann dazu bereit, mit einer neuen Lösung zu arbeiten, wenn sie Ihren Arbeitsalltag auch erleichtert - und nicht verkompliziert.

Die wissenschaftliche Forschung lässt diesen Faktor jedoch außen vor. Manche Machine Learning Modelle, die in der Forschung entwickelt werden, sind beispielsweise sehr präzise und treffsicher, funktionieren jedoch nur dann, wenn die Aufnahmen mit ganz bestimmten Geräteeinstellungen gemacht werden - Einstellungen, mit denen ein Arzt bei einer Routineuntersuchung nie arbeitet. In der Forschung mag das Modell dann sehr gut funktionieren, für die Praxis ist es jedoch unbrauchbar.

Damit ein Modell im Klinikalltag auch wirklich eingesetzt werden kann, muss es sich nahtlos in vorhandene Arbeitsabläufe integrieren lassen. Das bedeutet:

Nutzung von Daten, die im Standard-Workflow erfasst werden

Ein medizinisch brauchbares Modell sollte den Ärzten keine zusätzlichen Arbeitsschritte abverlangen. Es sollten nur genau die Daten - im gleichen Datenformat - benötigt werden, mit denen bereits im normalen Diagnoseablauf gearbeitet wird.

Integration in bereits bekannte Software

ZebraMedicalVision hat kein neues Software-Tool entwickelt, mit dem sich Ärzte auseinandersetzen müssen. Stattdessen integrierten sie ihre Vorhersagen direkt in die Softwaretools, mit denen Ärzte bereits arbeiten und vertraut sind.

Diese nahtlose Integration ist unbedingt notwendig - nicht nur, weil es unrealistisch ist, von Ärzten neue Arbeitsabläufe zu verlangen, sondern auch, weil es beim Einsatz von KI vor allem darum geht, Zeit zu sparen und keinen zusätzlichen Aufwand zu verursachen.

Das war jedoch nicht einfach. Es gibt verschiedenste Anbieter von Workstations und Software, wie auch verschiedene Arten von Umgebungen (z. B. webbasiert oder Windows-basiert). Außerdem ist ein Großteil der verwendeten Software bereits veraltet. Trotzdem muss sich Zebra mit jeder von ihnen integrieren lassen.

Entkopplung von Integration und Berechnung  

Zebra bietet eine intelligente Infrastruktur, die Flexibilität gewährleistet und gleichzeitig doppelte Arbeitsschritte vermeidet. Die Klinik muss lediglich ein Modul in ihrem lokalen System installieren, das sich um Datenschutz, Sicherheit und Anonymität kümmert und eine lokale Benutzeroberfläche bereitstellt. 

Die gesamte Rechenleistung und die KI Vorhersagen finden allerdings in der Cloud statt. Das macht es für Eyal und sein Team auch recht einfach, neue Versionen des Modells bereitzustellen. Die in der Klinik installierten Module kommunizieren mit dem zentral gehosteten Modell, das regelmäßig aktualisiert wird. Auf Seite der Klinik muss also nichts manuell aktualisiert werden.

Zebra berechnet seine Vorhersagen außerdem im Voraus, so dass ein Arzt, wenn er auf eine Aufnahme klickt, das Ergebnis ohne Zeitverzögerung sofort sehen kann.

Nehmen wir also an, dir ist es gelungen, ein Modell zu entwickeln, das die Bevölkerung akkurat repräsentiert, sich nahtlos in diagnostische Workstations integrieren lässt und in den Arbeitsablauf des Arztes eingebunden ist.

Selbst dann kannst du noch nicht sicher sein, dass ein Arzt von deinem Diagnosemodell profitieren würde. Ein wichtiger Faktor bleibt die Zeit.

Zeitersparnis des Arztes

Nehmen wir an, auf 1.000 Mammographien kommen 6 Krebsdiagnosen, und du hast ein Machine Learning Modell trainiert, das die Aufnahmen in Echtzeit auswerten kann. Der Arzt bekommt nun die Einschätzungen des KI-Modells neben allen Aufnahmen angezeigt und kann die gekennzeichneten Fälle entsprechend priorisieren.

An dieser Stelle stehen wir vor zwei entscheidenden Überlegungen:

Die Falsch-negativ-Rate. Wie oft geht das Modell davon aus, dass ein Patient gesund ist, obwohl er es in Wirklichkeit nicht ist? Diese Art von Fehler ist höchst gefährlich. Wenn der Arzt einen Scan nicht näher untersucht, weil das System fälschlicherweise von einem gesunden Patienten ausgeht, dann verpasst der Patient möglicherweise die Chance, behandelt zu werden. Das wäre ein folgenschwerer Fehler, der unbedingt vermieden werden muss.

Die Falsch-positiv-Rate. Wie oft markiert das System einen Scan, obwohl der Patient eigentlich gesund ist? Dieser Fehler ist weitaus weniger problematisch - der Arzt wird den Scan gegenprüfen und feststellen, dass es sich um einen Fehlalarm handelt.

Insgesamt entscheidet aber die Falsch-Positiv-Rate darüber, ob das System dem Arzt Zeit spart oder nicht. Stell dir vor, du würdest sehen, dass ein Scan markiert wurde. Du würdest ihn gründlich überprüfen, versuchen zu verstehen, warum das KI-System ihn als kritisch eingestuft haben könnte, und viel Zeit verschwenden, bevor du zu dem Ergebnis kommst: “Nein, die KI hat einen Fehler gemacht. Dieser Patient ist in Wirklichkeit gesund.” Nehmen wir an, dass sei bei 49 von 50 Scans der Fall, die von der KI als kritisch kennzeichnet werden.

In diesem Fall spielt es keine Rolle, wie viel schneller die KI eine einzelne Beurteilung vornehmen kann. Wenn der Arzt so viel zusätzliche Zeit aufwenden muss, um die meisten markierten Fälle zu überprüfen und zu widerlegen, ist die Lösung nicht praktikabel. 

Um zu beurteilen, ob eine KI-Lösung einen Diagnose-Workflow wirklich beschleunigen kann, muss man also folgendes berücksichtigen:

• Integration. Wie nahtlos lässt sich das Modell in die aktuellen Tools integrieren? Passt eine KI-Auswertung in den Workflow?
• Präsentation. Können die Vorhersagen so dargestellt werden, dass sie für den Arzt verständlich sind?
• Klinische Prävalenz. Wie viele Fälle werden bei einer bestimmten Anzahl von Scans vermutet? Und erreicht man eine falsch-positive Rate, mit der der Arzt arbeiten kann?

Bis hierhin haben wir aufzeigen können, wie wichtig es ist, reale klinische Daten als Grundlage für ein Modell zu verwenden, das in der Praxis funktionieren soll. Außerdem haben wir erläutert, dass ein automatisiertes Diagnosemodell nicht automatisch mit Zeiteinsparung einhergeht - eine nahtlose Integration und niedrige Falsch-Positiv-Raten sind entscheidend.

Doch wenn wir die Forschung mit der klinischen Praxis verknüpfen wollen - und zwar so, dass auch rechtliche Anforderungen erfüllt werden - dann müssen noch weitere Punkte beachtet werden.

Challenge 3: Das technologische Gerüst einer KI-Diagnoselösung

Ein kompetentes Data-Science- und Forschungsteam ist zwar unerlässlich, aber nicht ausreichend.

Sobald Eyal und sein Team sowohl die erforderlichen Daten als auch einen Weg gefunden hatten, die Lösungen in die Kliniken zu bringen, mussten sie sich einer weiteren großen Aufgabe stellen: das technologische Gerüst, auf dem alles basiert.

Große Datenmengen annotieren und kuratieren

Machine Learning Modelle lernen aus Datensätzen. Wenn es also Fehler in den Daten gibt - wie z.B. eine falsche Diagnose - dann erlernt das Modell auch diese Fehler. Bevor man also Experimente durchführt, müssen alle Datenpunkte doppelt geprüft und korrekt beschriftet werden.

Für ihre Studien hat ZebraMedicalVision mit bis zu 60 verschiedenen Annotations-Experten weltweit zusammengearbeitet. Das erforderte einiges an Koordination, weshalb Eyal interne Tools entwickelt hat, um all diese Annotationen zu sammeln, zu vergleichen und zu kombinieren.

Tausende von Experimenten gleichzeitig

Früher konnten sich Forscher viel Zeit nehmen, ein optimales Experiment zu planen, es durchzuführen und dann zu beurteilen, ob der Ansatz das Problem löst. Im Machine Learning funktioniert das aber nicht: Es gibt so viele verschiedene Möglichkeiten, die Daten zu analysieren und ein Modell zu entwickeln, dass man auf diese Weise nie zum Ziel kommen würde.

Also mussten Eyal und sein Team eine Plattform entwickeln, die es den Forschern ermöglicht, nicht nur eines, sondern Tausende von Experimenten gleichzeitig durchzuführen. Sie entwickelten außerdem mehrere Tools, um all diese Experimente zu tracken und anschließend die Ergebnisse zu vergleichen.

Unterschiedliche Systeme in Forschung und Praxis

Viele Unternehmen sprechen von Feedback-Schleifen: dabei verbessert sich ein Modell anhand von Nutzer-Feedback. Für klinische Lösungen sind solche Schleifen in der Regel jedoch nicht praktikabel oder umsetzbar.

Ein Diagnosemodell wird als Medizinprodukt eingestuft, wodurch jede Änderung einen behördlichen Genehmigungsprozess durchlaufen muss.

Die beiden Systeme von ZebraMedicalVision für die Forschung (Modelltraining) und die klinische Praxis (Anwendung der Modelle) sind daher vollständig voneinander getrennt. Zwischen den beiden besteht eine Firewall, und sie werden sogar an zwei physisch getrennten Standorten gehostet.

Selbstverständlich nutzt das Team nach wie vor die Rückmeldungen von Ärzten, um nachzuvollziehen, wie sich das Modell verhält. Es wird jedoch nicht als direktes Feedback in das aktuelle Modell integriert.

Aber das ist nur eine der Hürden, die die Arbeit in einem gesetzlich geregelten Rahmen mit sich bringt.

Einhaltung regulatorischer Vorgaben

Alles, was mit der Entwicklung und Verwendung eines Diagnosemodells zusammenhängt, muss nachvollziehbar sein, einschließlich:

• Produktdefinition und Systemanforderungen;
• Design;
• Datenaufbereitung;
• Forschung und Entwicklung;
• Tests;
• Deployment Prozess; 
• Nutzerfeedback.

ZebraMedicalVision hat ein globales Qualitätsmanagementsystem aufgebaut, das der FDA diese Informationen laufend zur Verfügung stellt und so durch Transparenz Vertrauen schafft. Darüber hinaus werden drei verschiedene ISO-Normen eingehalten sowie Berichte über interne Kontrollen nach SOC 2 Type 2 von externen Prüfern erstellt.

Diese Schritte haben enorme Investitionen erfordert, sowohl in die Sicherheit, als auch in die Gewährleistung, dass alles protokolliert und dokumentiert wird.

Nun haben wir Kooperationen, Daten, Integrationen und das technische Grundgerüst angesprochen. All das reicht jedoch immer noch nicht aus, um ein Machine Learning-Diagnoseproblem zu lösen - oder das, was Eyal eine “klinische Mission” nennt. Wir brauchen auch noch das richtige Team.

Die Band: Ein interdisziplinäres Team mit klinischer Mission

ZebraMedicalVision hat schnell erkannt, dass Data Scientists allein kein brauchbares Medizinprodukt entwickeln können. Darüber hinaus sprechen Data Scientists und Klinisches Personal meist ganz unterschiedliche Sprachen und tun sich schwer, direkt miteinander zu arbeiten. Diese Lücke muss von jemand anderem geschlossen werden. 

Vermittlung zwischen zwei Welten: Die Rolle des Clinical Information Manager

ZebraMedicalVision benötigte jemanden mit Erfahrung im Management klinischer Studien – jemand, der sowohl die Sprache der Ärzte als auch die der Data Scientists beherrscht. Sie nennen diese Rolle "Clinical Information Manager" - meistens jemand mit Doktortitel in Biomedizintechnik oder klinischer Forschung.

Jede klinische Mission benötigt auch einen Projektmanager, einen Softwareentwickler und einen DevOps Engineer.

Eyal nennt dieses interdisziplinäre Team die Band: unterschiedliche Talente mit einer gemeinsamen klinischen Mission.

Jedes Bandmitglied hat eine bestimmte Funktion:

• Der Projektleiter hält das Projekt auf Kurs.
• Der Mediziner bringt Wissen über die Komplexität des Klinikalltags mit.
• Data Scientists formulieren und testen Annahmen über die Daten und wissen, wie man Machine Learning Modelle trainiert und validiert.
• Der Clinical Information Manager kennt die klinische Forschung und schließt die Lücke zwischen Ärzten und Forschern.
• DevOps Engineers und Software Entwickler implementieren die klinische Lösung auf robuste und skalierbare Weise.

Mit einer eng zusammenarbeitenden Band können alle Prozesse dynamisch ablaufen, was Eyals Erfahrung nach sehr wichtig ist.

Dynamisches Problemlösen: Die Mission bleibt im Wandel

Im Studium ist die Problemstellung, an der man arbeitet, meistens im Vorhinein festgelegt. Eyal und seine Band haben jedoch erkannt, dass die interessantesten Erkenntnisse oft erst dann entstehen, wenn man bereits an einem Problem arbeitet. Da diese Erkenntnisse wiederum das Verständnis des eigentlichen Problems grundlegend verändern, ändert sich oft sogar die gesamte dahinterliegende Mission.  

Das Band ist hervorragend dazu geeignet, sich an diese Änderungen anzupassen. Das liegt vor allem am technologischen Grundgerüst von ZebraMedicalVision, das schnelles Arbeiten und einfaches Anpassen der Experimente ermöglicht - ohne jedes mal von vorne anfangen zu müssen.

Dank dieser Infrastruktur und des dynamisch aufgebauten Teams kann ZebraMedicalVision in einem rasanten Tempo arbeiten. Inzwischen arbeiten sie bereits an ihrer siebten FDA-zugelassenen Diagnoselösung.

Werfen wir nun einen Blick auf zwei Anwendungsbeispiele der Diagnose-Lösungen, die Eyal und sein Team entwickelt haben.

Der Unterschied zwischen Praxis- und Forschungsansätzen in der medizinischen Bildgebung

Beispiel 1: Frühwarnung für koronare Herzkrankheit

Die Hälfte aller kardiovaskulär bedingten Todesfälle können auf die koronare Herzkrankheit zurückgeführt werden. Zelluläre Abfallstoffe, Proteine und Kalzium haften an den Blutgefäßwänden und verbinden sich mit Fett zu Plaque. Geschieht das in den Arterien, die den Herzmuskel mit Blut versorgen, dann wird die Sauerstoffversorgung des Herzens eingeschränkt, wodurch ein Herzinfarkt entstehen kann.

Häufig wird die Ablagerung von Verkalkungen in den Herzkranzgefäßen erst nach einem Herzinfarkt oder einem vergleichbaren kardialen Vorfall erkannt.

Der Ansatz der akademischen Forschung: Als ZebraMedicalVision dieses Problem genauer untersuchte, fanden sie einen Artikel, der beschreibt, dass wenn man die relevanten Bereiche manuell segmentiert und einen Gated-CT-Scan (ein Scan, der sich nur auf das Herz konzentriert) durchführt und in einem bestimmten Verfahren misst, dann kann man ein Modell erstellen, das das Äquivalent des Agatston-Scores (ein Risikomaß von 0 (geringes Risiko) bis 400 (sehr hohes Risiko)) für Herzinfarkte liefert.

Bei diesem Problem handelt es sich im Prinzip um ein Segmentierungsproblem: Man muss die die weißen Verkalkungen in den Koronararterien im Bild richtig segmentieren.

Das Problem dieser akademischen Lösung: Dieses spezielle CT-Scan-Protokoll würde man nur bei einem Patienten durchführen, von dem bereits bekannt ist, dass er ein erhöhtes Risiko für einen Herzinfarkt aufweist. Und damit wäre all den anderen Patienten, die gefährdet sind, aber noch keine Symptome haben, nicht geholfen.

In Hinblick darauf, wie wenige Patienten vor einem Herzinfarkt bereits Symptome aufweisen, wäre eine Methode, die nicht auf vorhandenen Symptomen beruht, wesentlich hilfreicher.

Der praktikablere Ansatz: ZebraMedicalVision hat festgestellt, dass CT-Scans auch für viele andere Krankheiten durchgeführt werden. Diese sogenannten Untargeted- oder Ungated-Scans erfassen unterschiedliche Organe, darunter auch das Herz. Eyal und sein Team konnten einen Ansatz entwickeln, bei dem diese wesentlich häufiger durchgeführten Scans eine ähnliche Genauigkeit - bezüglich der Risikovorhersage für Herzerkrankungen - erreichen wie das Modell, das die Forscher für die Gated-Scans erreichen.

So entsteht ein Frühwarnsystem für Herzerkrankungen, das ganz einfach im Hintergrund ablaufen kann. Dieses System alarmiert den Arzt automatisch, sobald ein Patient ein erhöhtes Risiko aufweist - auch wenn der Scan aus einem ganz anderen Grund durchgeführt wurde und das Herz möglicherweise gar nicht im Fokus stand. Auf diese Weise werden viele Patienten frühzeitig diagnostiziert und erhalten eine präventive Behandlung.

Stand heute ist das eine der bedeutendsten Lösungen von ZebraMedicalVision, die sich bereits umfassend bewähren konnte. Das KI-Modell übertrifft in seiner Genauigkeit sogar andere Lösungen, die ausschließlich mit Gated - also zielgerichteten - CT-Scans arbeiten.

Beispiel 2: Sinterungsbrüche

Osteoporose ist ein Krankheitsbild, bei dem eine frühzeitige Diagnose und Behandlung entscheidend für den Heilungsverlauf sind. Sinterungsbrüche - ein eindeutiges Symptom für Osteoporose - werden bei Routineuntersuchungen jedoch oft übersehen. 

Diese Sinterungsbrüche, bei denen einzelne Wirbel aufgrund einer veränderten Knochenstruktur in sich zusammensacken, werden von Radiologen oft nicht weiter beachtet. Sie gehören nicht zum standardmäßigen Arbeitsablauf, die Diagnose ist meistens nicht akut, und sie sind nur schwer zu erkennen: Ein Radiologe müsste dafür einen weiteren Abschnitt des Scans überprüfen und dann die Höhe jedes Wirbels mit seiner Ausgangshöhe vergleichen. Am Ende bleiben 75 % aller Sinterungsbrüche daher unerkannt.

Allerdings haben die meisten Menschen, die in die Risikogruppe für Osteoporose fallen, bereits einen Scan durchführen lassen. Das heißt, die Bilder sind bereits vorhanden und die möglichen Kompressionsfrakturen sind bereits in den Daten erfasst - sie wurden nur nicht erkannt.

Auch wenn dieses Thema nicht besonders viel Aufmerksamkeit zuteil wird, ist der Nutzen der Diagnose von Sinterungsbrüche - und damit von Osteoporose - für die Patienten immens. So sterben beispielsweise 50 % der Patienten, die sich eine Hüfte brechen, innerhalb der folgenden 10 Jahre an damit verbundenen Komplikationen. Hinzu kommt eine starke Belastung durch die Rehabilitation.

ZebraMedicalVision hat daher einen Algorithmus entwickelt, der diese Kompressionsfaktoren lokalisiert und erkennt.

So können Krankenhäuser, die Screenings für Patienten mit Osteoporose-Risiko durchführen, das Modell im Hintergrund laufen lassen und werden automatisch auf Patienten hingewiesen, die ein Risiko einer Fraktur aufweisen. Im Anschluss können Ärzte den Befund manuell überprüfen.

Wie Eyal sagt: "Manchmal beschäftigen wir uns mit den Problemen, die bedeutsam, aber nicht sexy sind." Genau diese Gelegenheiten ergeben sich, wenn man umfangreiche Datensätze mit einem explorativen Mindset betrachtet - das Mindset eines Data Scientists.

Das Unmögliche erreichen - durch naiven Optimismus

Im Mai 2014, also ganz zu Beginn, nahmen Eyal und seine Kollegen an einer Radiologiekonferenz in Dallas teil. Von allen Seiten wurde Ihnen gesagt: "So etwas wie maschinelle Bildverarbeitung wird es in der Radiologie nie geben. Das ist ein Hirngespinst. Ihr seid nette israelische Jungs. Genießt euren Urlaub, geht zurück nach Israel und beschäftigt euch mit etwas anderem.”

Doch ihr naiver Optimismus war ihre treibende Kraft. Eyal und sein Co-Founder waren der Meinung, sie könnten dieses Problem lösen, und zwar sehr schnell. Auch wenn es am Ende etwas länger dauerte, war es eine unheimlich sinnvolle Herausforderung mit unverkennbarem Wert.

Ihr naives Mindset hat sie durch die zahllosen Herausforderungen getrieben. Eyal selbst sagt dazu: "Man muss extrem naiv sein - auf eine positive Art."