Excel ist intransparent und schmuggelt durch seine Autokorrektur-Funktion Fehler in die Datenlisten von Forschern. Grund genug, das Microsoft-Office-Programm ein für allemal zu schließen – zumal es genug Alternativen gibt. Illustr.: JM
(10.11.2021) Das Komitee für Gen-Nomenklatur der Human Genome Organisation (HUGO) legt die Namen aller menschlichen Gene fest. Dabei richtet es sich nunmehr nach den Formatanforderungen von Microsoft Office. Was erstmal lächerlich klingt, hat einen durchaus ernsten Hintergrund.
Während die Autokorrektur von Worten in Handy-Nachrichten manchmal für Lacher sorgt, ärgert sie andernorts die Wissenschaftsgemeinde. So enthält die PubMed-Datenbank für 2014 bis 2020 insgesamt 11.117 Publikationen mit Genlisten im Excel-Format im Anhang. Unter ihnen weisen 3.436 Publikationen mindestens einen Gen-Namen auf, der von Excels Autokorrektur-Funktion in ein Datum oder eine Gleitkommazahl konvertiert wurde (PLoS Comput. Biol., doi: 10.1371/journal.pcbi.1008984). Als anfällig für Excels automatische Texterkennung erwiesen sich nicht nur Gen-Bezeichnungen wie „MARCH3“, „SEPT8“ oder „DEC1“, sondern auch unauffällige Gen-Akronyme wie „BN7_676“ oder „MGP_AJ_G0035605“ sowie Identifikationsnummern biologischer Datenbanken wie etwa „2310009E13“.
Bereits 2016 bemängelte die Arbeitsgruppe um Mark Ziemann, Lecturer in Biotechnologie und Bioinformatik an der australischen Deakin University, dass Excel wissenschaftliche Daten in falsch verstandener Nutzerfreundlichkeit fehlinterpretiert (Genome Biol. 17: 177). Einen Nachbesserungsbedarf sah Microsoft jedoch nicht. Schließlich stellt die Wissenschaftsgemeinde nur einen vernachlässigbaren Bruchteil der Gesamtkundschaft dar, die Excels Standardeinstellungen befriedigen müssen. Kurzerhand zog die Human Genome Organisation ihrerseits Konsequenzen und benannte 27 besonders Autokorrektur-anfällige Gen-Namen um. So heißen unter anderem die Gene SEPT1 und MARCH1 jetzt SEPTIN1 und MARCHF1, während die tRNA-Synthetasen WARS und CARS auf WARS1 und CARS1 hören (Nat. Genet. 52: 754-8).
Im Vergleich zum humanen Genom mit seinen 20.000 Protein-codierenden Genen ist von Excels Fehlinterpretationen natürlich nur ein Bruchteil betroffen. Doch wenn schon eine Autokorrektur-Funktion Daten Tausender Publikationen vermurkst, wie viele Fehler schleichen sich durch unsachgemäß verwendete Microsoft-Office-Produkte wohl noch ein?
Das ist nicht nur eine Frage der Wissenschaftsgemeinde. Im Jahr 2012 verkündete beispielsweise die US-amerikanische Bank JPMorgan Chase & Co. Verluste von vier Milliarden Euro – nur infolge von falsch kopierten Formeln in Excel-Tabellen, wie das Wirtschaftsmagazin Quartz berichtet („Damn you, Excel spreadsheets, JP Morgan Chase edition”). Vergangenes Jahr verlor laut BBC die britische Gesundheitsbehörde die Daten von 15.000 COVID-19-Fällen, deren Kontakte infolgedessen nicht nachverfolgt werden konnten – nur weil sie zur Kontaktdatenspeicherung ein altes Excel-Dateiformat mit begrenzter Zeilenanzahl gewählt hatten („Excel: Why using Microsoft’s tool caused Covid-19 results to be lost”).
Forscher sind vor derartigen Patzern natürlich ebenfalls nicht gefeit. Zum Beispiel veröffentlichte die Arbeitsgruppe um Erstautor Julian Klingbeil, Assistenzarzt an der Leipziger Klinik für Neurologie, im Januar 2021 Studienergebnisse zu Magnetresonanztomographie(MRT)-Läsionsprofilen nach Schlaganfall (Stroke 52: e485) – und zog die Publikation sechs Wochen später wieder zurück. Denn die Schlaganfall-Forscher waren in einer Excel-Tabelle auf einen simplen Kopierfehler gestoßen. „Während einer Folgeanalyse fiel einem Mitautor auf, dass Patienten im analysierten Datensatz andere Zeitpunkte ihrer Schlaganfälle zugeordnet waren als in den Rohdaten“, beschreibt Klingbeil ihren Fehler. Die Ironie folgt jetzt: „Für unsere mehrere Hundert Patienten legten wir extra eine SQL-basierte Datenbank an. Denn uns war klar, dass wir so viele Datensätze unmöglich in Excel-Dateien organisieren können. Da unsere Statistik-Software aber Eingabedaten im xlsx-Format verlangt, mussten wir alle Datenbank-Einträge kurzerhand konvertieren. Und dabei sortierte ein Mitautor Spalten ungewollt um – im Nachhinein unbegreiflich, dass uns das passiert ist.“
Die Leipziger Neurologen um Julian Klingbeil bemerkten ihren Excel-Fauxpas erst nach Publikation – und zogen ihr Paper wieder zurück. Screenshot: LJ
Dass tomographische Läsionsprofile nun falschen Zeitpunkten nach Schlaganfall zugeordnet waren, fiel im Peer-Review-Prozess nicht auf. Die randomisierten Datensätze bestätigten sogar, was frühere Untersuchungen von Schlaganfall-Patienten nur andeuteten: Läsionen im linken, ventrolateralen präfrontalen Cortex erhöhten Monate später das Risiko für Depressionen. Eine frühe Diagnose dieser Art psychischer Störungen schien anhand von MRT-Aufnahmen in Reichweite. Das machte die Neurologen extrem glücklich – zumindest bis sie Wochen nach Publikation ihren Irrtum erkannten. „Eine Unaufmerksamkeit entkräftete alle Schlussfolgerungen unseres Manuskripts. Zwar war es weder Gutachtern noch Lesern möglich, diesen Fehler zu finden, aber nicht nur für Folgestudien wäre es natürlich völliger Wahnsinn gewesen, das unkorrigiert stehen zu lassen.“ Also wiesen Klingbeil et al. den Editor-in-Chief von Stroke schweren Herzens auf ihren Flüchtigkeitsfehler hin und nahmen dessen Angebot einer umgehenden Retraction an.
Trotz Schock und Scham weist Klingbeil auf das Wesentliche hin: „Das gesamte Studiendesign, die Teilnahmebereitschaft Hunderter Patienten und die Arbeit aller Mitautoren überwiegen die zugegebenermaßen weitreichenden Konsequenzen dieses Schnitzers um ein Vielfaches. Mittlerweile haben wir alle Daten korrekt analysiert und konnten erneut – wenn auch andere – Schlussfolgerungen ziehen. Am wichtigsten ist uns, dass wir die Studie überhaupt publizieren.“ Ein Riesen-Lob für wissenschaftliche Integrität ist ihnen allemal sicher.
So profan dieses Fallbeispiel klingen mag, zeigt es eines ganz deutlich: Folgenschwere Fehler können jedem jederzeit trotz maximaler Sorgfalt unterlaufen. Niemand sollte sich in Sicherheit wägen. Was haben Klingbeil und Kollegen daraus gelernt? „Alle Daten müssen in der identischen SQL-Datenbank editiert und dürfen nach Export nicht mehr angefasst werden. Denn im Gegensatz zu Excel-Dateien lässt sich nur in einer Datenbank nachvollziehen, wer was wann wie in welcher Reihenfolge geändert hat.“
Die Lektion für den Wissenschaftsbetrieb ist folglich klar: Auch wenn Excel noch so bequem und vielseitig ist, verbietet seine Intransparenz jegliche Datenspeicherung und statistische Analyse. Denn Reproduzierbarkeit gewährleistet es nicht. Für komplexe Daten mit mehr als einer Handvoll Zeilen wie etwa Listen von Gen-Namen oder auch nur, um mal eben supplementäre Daten an die Kollegin zu schicken, sollte Excel vielleicht echter Datenbank- und Statistiksoftware weichen.
Diejenigen, die unmöglich auf Tabellenkalkulationen verzichten können, finden in den Open-Source-Programmen LibreOffice und Gnumeric vielleicht attraktive Alternativen. Im Gegensatz zu Microsoft Excel sind sie weniger anfällig für Autokorrektur-Fehler (PLoS Comput Biol., doi: 10.1371/journal.pcbi.1008984), ihre Automatikfunktionen können leicht abgeschaltet werden und sie sind kostenlos verfügbar.
Oft reicht es auch schon, Gen-Listen als simple Text-Dateien in csv-, tsv- oder txt-Formaten zu speichern. Formatierungsfehler macht das unmöglich. Darüber hinaus lassen sich Excel-Dateien mit Web-Tools wie Truke (maplab.imppc.org/truke) und Escape Excel (apostl.moffitt.org) auf Konvertierungsfehler überprüfen. Noch mehr Tipps zu Tabellenkalkulationen bietet der Biostatistiker Karl Broman von der University of Wisconsin-Madison auf seiner Homepage: kbroman.org/dataorg.
Die vielleicht beste Alternative, um große Datenmengen zu analysieren, bieten Skript-basierte Programmiersprachen für statistische Berechnungen und Grafiken wie Python (python.org) und R (r-project.org). Auch ohne lokale Installation lassen sie sich in Cloud-Oberflächen wie der Open-Source-App Jupyter Notebook nutzen (jupyter.org). Anfänglich sicher gewöhnungsbedürftig und aufwendig liegen ihre Vorzüge auf der Hand: Alle Nutzer wissen genau, was wie an welcher Stelle durch wen geschieht. Autokorrektur-Funktionen existieren nicht. Jeder Arbeitsablauf lässt sich auditieren. Selbst vorgefertigte Funktionen können begutachtet werden. Alle Software-Versionen sind dokumentiert und Modifikationen in einem Quellcode-Archiv hinterlegt.
Entsprechend verleiht schon Grundlagenwissen in Python oder R wissenschaftlicher Reproduzierbarkeit Flügel. Einsteigern bieten die kostenlosen Workshops für Wissenschaftler der Gemeinschaftsinitiative Software Carpentry (software-carpentry.org), zu denen unter anderem die Universität Stuttgart und das Karlsruher Institut für Biomedizinische Technik beitragen, einen zukunftsträchtigen Startpunkt.