gms | German Medical Science

Einleitung: Künstlichen neuronalen Netzen (KNN) finden zunehmend Anwendung in entscheidungsunterstützenden Systemen der Medizin. Dabei sind nicht nur die KNN oft komplex, sondern auch die unterliegenden Ausführungsumgebungen und IT-Systeme. Wie bereits in anderen Zusammenhängen gezeigt, können unterschiedliche Konfigurationen der Ausführungsumgebungen und Prozessorarchitekturen die Reliabilität von entscheidungsunterstützenden Verfahren beeinträchtigen [1]. In diesem Beitrag soll dies am Beispiel eines hochrangig publizierten auf KNN basierenden Verfahrens zur automatischen Bestimmung von Schlafphasen gezeigt werden [2]. Die Implementierung des Verfahrens basiert auf Python 3.6 mit diversen Programmierbibliotheken, darunter auch das KNN-Framework Tensorflow 1.9.0. Wir haben festgestellt, dass bei Verwendung einer falschen Python-Programmversion konsistent fehlerhafte Ergebnisse geliefert werden.

Methoden: Programmcode, Modelle, sowie ein Testdatensatz mit den zu erwartenden Ausgaben sind auf Github verfügbar [3]. Die Anwendung wird nach Anleitung [4] innerhalb eines Docker Images installiert. Als Basis dient das offizielle Tensorflow 1.9.0 Docker Image [5]. Bei diesem Image ist nicht unmittelbar ersichtlich, dass es Ubuntu 16.04 Programmbibliotheken (veröffentlicht 2016) mit Python 3.5 enthält und somit nicht der vorgegebenen Mindestversion 3.6 entspricht. Das Programm wird als Container ausgeführt und dabei ein lokales Verzeichnis mit dem Testdatensatz eingehängt. Die erzeugten Ergebnisdaten werden mit den Ergebnissen aus anderen Image-Konfigurationen verglichen. Dabei werden unterschiedliche Kombinationen auf Basis von Ubuntu 16.04 und 18.04 mit den Python-Versionen 3.5 und 3.6 getestet, in denen das Paket „tensorflow“, beziehungsweise „tensorflow-gpu“ für Berechnungen auf Cuda-GPUs, manuell nachinstalliert wird.

Ergebnisse: Die Ausführung des Containers auf Basis des Tensorflow-Images mit Python 3.5 läuft ohne Absturz und augenscheinlich ohne Probleme. Erst beim Vergleich der erzeugten Daten mit den erwarteten Ergebnissen werden Unterschiede deutlich. Zum einen weisen die Ergebnisse hauptsächlich die Schlafphase „Wach“ auf, während die Vergleichsdaten einen ausgeglichenen Schlaf über alle Schlafphasen zeigen. Zum anderen werden mit jeder Ausführung zufällige, leicht unterschiedliche Ergebnisse erzeugt, obwohl die Ausführung deterministisch sein sollte. Beim Vergleich mit anderen Image-Konfigurationen zeigt sich, dass die fehlerhaften Ergebnisse nicht durch ein bestimmtes Basis-Image, eine bestimmte Ubuntu-Variante oder den Einsatz von GPUs gegenüber CPUs zustande kommen. Stattdessen werden mit Python 3.5 in allen Varianten falsche Ergebnisse erzeugt, während der Einsatz von Python 3.6 deterministisch zu sein scheint und korrekte Schlafphasen liefert. Die genauen Gründe für das Fehlverhalten der Software sind noch nicht bekannt. Eine Teilmenge der verwendeten Docker-Konfigurationen inklusive der KNN-Modelle wurde auf Zenodo archiviert [6]. Wir haben die Entwickler über das Problem informiert [7], sodass ein Warnhinweis publiziert werden konnte.

Diskussion und Ausblick: Die experimentellen Ergebnissen zeigen, dass bereits kleine Abweichungen in der Software-Konfiguration zu falschen Ergebnissen ohne Absturz der Software führen können, die nur durch die zur Verfügung gestellten Testdaten nachvollziehbar sind. Den Autoren des verwendeten Verfahrens ist kein Vorwurf zu machen, da sie die getestete Softwareversionen dokumentiert haben und die Software noch nicht im klinischen Umfeld zum Einsatz kommt. Im Kontext des immer breiteren Einsatzes von Algorithmen in kritischen Bereichen, wie der medizinischen Diagnostik, zeigt dieses Ergebnis aber deutlich, dass bei Zulassungen im Produktivbetrieb eine Validierung der Anwendung nicht ausreicht und stattdessen immer die gesamte Ausführungsumgebung einbezogen werden muss [8], [9]. Container-Technologien können dazu beitragen diese Umgebungen zu definieren [10], [11], [12] und die Inbetriebnahme zu vereinfachen.

Die Autoren geben an, dass kein Interessenkonflikt besteht.

Die Autoren geben an, dass kein Ethikvotum erforderlich ist.