Excel im GxP Labor: Bequem, bekannt und ein regulatorisches Risiko

Warum regulierte Labore auf Excel verzichten sollten und wann individuelle Softwareentwicklung die bessere Antwort ist als jede Standardlösung.

Es ist eine Szene, die in fast jedem regulierten Labor vorkommt: Eine neue Anforderung entsteht – ein Probentracking, eine Berechnungslogik, eine Chargendokumentation. Das LIMS passt nicht, das ELN deckt es nicht ab. Und dann öffnet jemand Excel. Schnell, vertraut, flexibel. Innerhalb von Stunden läuft etwas. Innerhalb von Wochen hat sich die Datei tief in kritische Prozesse eingegraben. Innerhalb von Monaten weiß niemand mehr genau, welche Version die gültige ist.

Dieses Szenario ist kein Randproblem. Es ist eine der häufigsten Quellen für Datenintegritäts-Befunde in regulierten Industrien – und ein regelmäßiger Grund für FDA Warning Letters.

Was GxP eigentlich von Software verlangt

Bevor wir über Excel sprechen, lohnt ein Blick auf den regulatorischen Rahmen. GxP – der Sammelbegriff für Good Manufacturing Practice (GMP), Good Laboratory Practice (GLP) und Good Clinical Practice (GCP) – stellt klare Anforderungen an Daten und die Systeme, die sie erzeugen, verarbeiten und speichern.

Die FDA fasst diese Anforderungen im sogenannten ALCOA+-Prinzip zusammen. Daten müssen sein:

• Attributable – jede Dateneingabe muss einer Person und einem Zeitpunkt zugeordnet werden können
• Legible – dauerhaft lesbar und verständlich
• Contemporaneous – zum Zeitpunkt der Entstehung erfasst
• Original – Rohdaten sind Rohdaten, keine nachträgliche Rekonstruktion
• Accurate – korrekt und ohne unbegründete Korrekturen

Ergänzt wird dies durch Complete, Consistent, Enduring und Available. Diese Prinzipien sind nicht akademisch. Sie sind der Maßstab, an dem Inspektoren Systeme und Prozesse messen.

Für computergestützte Systeme gelten darüber hinaus 21 CFR Part 11 (USA) bzw. Annex 11 der EU-GMP-Leitlinien (Europa). Beide schreiben unter anderem vor: Audit Trails, Zugangskontrollen, Systemvalidierung und eine nachvollziehbare Datenhistorie.

Warum Excel in diesem Rahmen strukturell scheitert

Excel wurde nicht für regulierte Umgebungen entwickelt. Es wurde für Flexibilität entwickelt – und diese Flexibilität ist genau das Problem.

Kein robuster Audit-Trail

Excel kennt keine native, manipulationssichere Protokollierung von Änderungen. Wer eine Zelle überschreibt, hinterlässt keine Spur. Die integrierte "Änderungen verfolgen"-Funktion ist optional, kann deaktiviert werden und erfüllt nicht die Anforderungen an einen GxP-konformen Audit Trail. Excel fehlt eine robuste Audit-Trail-Funktionalität, die es schwierig macht nachzuverfolgen, wer wann welche Änderungen vorgenommen hat – in GxP-Umgebungen jedoch eine Kernvoraussetzung für den Nachweis von Datenintegrität und Compliance ist.

Unzureichende Zugangskontrollen

Zellschutz und Blattschutz in Excel sind kein Sicherheitsmechanismus. Sie lassen sich mit wenigen Handgriffen entfernen. Eine rollenbasierte Zugriffskontrolle, wie sie Annex 11 und 21 CFR Part 11 verlangen, lässt sich mit Excel nicht umsetzen.

Nicht validierbar im GxP Sinne

Die Systemvalidierung eines Excel-Arbeitsblatts ist möglich – aber aufwendig, fehleranfällig und nur begrenzt nachhaltig. Jede Änderung am Blatt erfordert eine erneute Validierung. Tabellenkalkulationssoftware gilt bei den meisten CSV- und QA-Teams als schwer bis gar nicht validierbar – und das aus guten Gründen, die direkt mit den inhärenten Eigenschaften dieser Werkzeuge zusammenhängen.

Fehlende Datenzentralisierung

Excel-Dateien werden häufig lokal auf einzelnen Rechnern oder auf Netzlaufwerken gespeichert, was eine zentralisierte Datenverwaltung erschwert – obwohl einheitliche Datenhaltung und Zugänglichkeit in GxP-Umgebungen essenziell sind. Wer hat die aktuelle Version? Wer hat eine Kopie auf dem Desktop? Diese Fragen sollten in regulierten Prozessen nicht offen sein.

Formellogik ohne Kontrolle

Unvalidierte Zellformeln können zu fehlerhaften Berechnungen führen – bis hin zu falschen Log-Reduktionen und Prozentwerten, die die Gültigkeit der gesamten daraus gewonnenen Daten in Frage stellen. Formeln können unbemerkt überschrieben, verschoben oder durch Drag-and-Drop verändert werden.

Das stille Risiko: Metadaten im Dateinamen

Ein Thema, das in GxP-Diskussionen zu selten explizit behandelt wird, ist die Frage der Metadaten. Metadaten beschreiben den Kontext von Daten: Wer hat sie wann erzeugt? Zu welchem Experiment, welcher Charge, welcher Studie gehören sie? Welche Version ist gültig?

In Excel-geprägten Laborumgebungen werden diese Informationen regelmäßig an einem Ort abgelegt, der dafür nicht vorgesehen ist: dem Dateinamen.

Dateinamen wie Stabilitaet_Charge_2023_v3_FINAL_neu_JM_geprüft.xlsx sind keine Ausnahme – sie sind die Regel. Was auf den ersten Blick funktional wirkt, ist bei näherer Betrachtung ein schwerwiegendes strukturelles Problem:

Dateinamen unterliegen keiner Formatvorgabe. Es gibt keine erzwungene Struktur, keine kontrollierte Vokabularliste, keine Pflichtfelder. Zwei Personen im selben Labor werden denselben Inhalt anders benennen.

Dateinamen sind begrenzt. Betriebssysteme limitieren die Länge. Sonderzeichen führen zu Fehlern. Was in einem Projekt als Metadatensystem beginnt, kollabiert spätestens bei 200 Dateien unter seiner eigenen Inkonsistenz.

Dateinamen sind nicht durchsuchbar als strukturierte Daten. Eine Suche nach "alle Stabilitätsproben aus Q2 2023 für Wirkstoff X, Charge Y, validiert von Person Z" ist in einem Dateisystem nicht möglich – zumindest nicht zuverlässig.

Dateinamen sind nicht versioniert. "v3_FINAL_neu" ist keine Versionsverwaltung. Es ist ein Warnsignal.

Was fehlt, ist eine strukturierte, erzwungene Metadatenschicht – Felder, die beim Anlegen eines Datensatzes ausgefüllt werden müssen, die durchsucht, gefiltert und ausgewertet werden können und die dauerhaft mit den Daten verbunden bleiben. Das ist keine Frage der Disziplin der Mitarbeitenden. Es ist eine Frage der Systemarchitektur. Excel bietet diese Architektur nicht. 

Was die Regulatoren sagen - und was sie tun

Die regulatorischen Behörden haben in den vergangenen Jahren deutlich klargestellt, dass unkontrollierte Tabellenkalkulationen in GxP-Prozessen nicht toleriert werden.

Aktuelle Fallstudien zeigen gravierende Fehler: Formelirrtümer, fehlende Audit Trails und mangelhafte Datenintegrität, die zu FDA Warning Letters, abgelehnten Zulassungsanträgen und kompromittierten Compliance-Unterlagen geführt haben.

Die FDA-Warndatenbank ist voll mit konkreten Befunden. Ein wiederkehrendes Muster: Originaldaten wurden zunächst in einem "inoffiziellen" und unkontrollierten elektronischen Tabellenblatt auf einem gemeinsamen Netzlaufwerk gespeichert und erst nachträglich in ein "offizielles" Formular übertragen. In einem anderen Fall wurden Excel-Tabellen für die Verfolgung von Abweichungen und CAPA-Aktivitäten eingesetzt, ohne dass Änderungen mit Datum, Benutzeridentifikation oder Begründung dokumentiert wurden – und ohne die Möglichkeit, Löschungen nachzuverfolgen.

Die Konsequenzen sind real: Import-Stopps, Produktrückrufe, aufwendige Remediation-Programme. Und das alles für ein Werkzeug, das im Kern nie für diesen Zweck gedacht war.

Weiterführend empfehlen wir den Artikel "Spreadsheets: A Sound Foundation for a Lack of Data Integrity?" in Spectroscopy Online (Quelle), der anhand realer FDA Warning Letters die Schwachstellen im Detail analysiert. 

Die Brücke zwischen LIMS/ELN und Excel

An dieser Stelle hören viele Diskussionen auf: "Nutzt ein LIMS oder ein ELN, dann ist das Problem gelöst." Das stimmt – wenn ein LIMS oder ELN die Anforderungen vollständig abdeckt. In der Praxis ist das oft nicht der Fall.

LIMS-Systeme sind exzellent für standardisierte Laborprozesse: Probenmanagement, Prüfpläne, Ergebniserfassung gegen definierte Spezifikationen. Aber sie stoßen an Grenzen, sobald Prozesse stark individuell, wissenschaftlich komplex oder methodisch im Fluss sind.

ELNs decken die freie Dokumentation von Forschungsarbeit ab. Aber strukturierte Datenprozesse mit Berechnungslogik, Statusworkflows oder Geräteintegration sind nicht ihr Kerngebiet.

Was bleibt, ist eine Grauzone: Prozesse, die zu komplex für ein Notizsystem sind, aber zu spezifisch für ein Standard-LIMS. In dieser Grauzone greift man heute typischerweise zu Excel. Und genau hier liegt das eigentliche Problem.

Der Fall für individuelle Softwareentwicklung

Wenn LIMS und ELN nicht greifen und Excel keine valide Option ist, gibt es eine dritte Möglichkeit, die im Labor-IT-Umfeld noch zu selten ernsthaft in Betracht gezogen wird: zweckgebundene, individuelle Softwareentwicklung.

Das klingt aufwendig. Für viele Teams ist es ein Reflex, das abzulehnen. Aber die Abwägung sieht bei ehrlicher Betrachtung oft anders aus.

Was individuelle Software leisten kann

Eine maßgeschneiderte Anwendung – sei es eine Webanwendung, eine API-gestützte Datenplattform oder eine schlanke Datenbanklösung – kann von Grund auf GxP-konform gestaltet werden:

• Audit Trail als feste Systemkomponente, nicht als nachträgliches Add-on
• Rollenbasierte Zugriffskontrolle mit erzwungener Authentifizierung
• Strukturierte Metadatenerfassung als Pflichtfelder beim Erstellen jedes Datensatzes – nicht als Dateiname
• Versionierung von Datensätzen und Konfigurationen
• Validierbarkeit nach GAMP 5, mit klarer Systemarchitektur und dokumentierten Schnittstellen
• Suchbarkeit über alle Metadaten und Inhalte hinweg
  
  

Datenintegrität als Designprinzip

Der entscheidende Unterschied zu Excel ist nicht technologischer, sondern konzeptioneller Natur. Bei einer individuellen Softwarelösung kann Datenintegrität von Anfang an als nicht verhandelbare Designanforderung verankert werden. Datenintegritätsprobleme im Nachhinein zu beheben ist teuer, zeitaufwendig und störend – Unternehmen, die von Anfang an keine robusten Kontrollen etablieren, riskieren regulatorische Strafen, Produktrückrufe und Reputationsschäden, die weit teurer sind als eine saubere initiale Implementierung.

Das gilt für individuelle Software genauso wie für kommerzielle Systeme – aber der Unterschied ist: Bei individueller Software können diese Anforderungen von Beginn an die Architektur prägen, statt nachträglich in ein generisches System hineinkonfiguriert zu werden.

Nachhaltigkeit: Wartbarkeit und Betrieb im Fokus

Ein Argument, das gegen individuelle Entwicklung oft vorgebracht wird, ist die langfristige Wartbarkeit. Wer kümmert sich in drei Jahren darum? Was passiert, wenn der Entwickler das Unternehmen verlässt?

Diese Fragen sind berechtigt – aber sie stellen sich bei Excel in verschärfter Form. Ein verschachteltes Excel-Workbook mit 15 Tabellenblättern, VBA-Makros und undokumentierten Abhängigkeiten ist in der Praxis schwerer zu warten als eine sauber dokumentierte, modular aufgebaute Anwendung mit versioniertem Source Code in einem Repository.

Nachhaltige individuelle Softwareentwicklung bedeutet:

• Dokumentation als Lieferobjekt, nicht als Nachgedanke
• Modulare Architektur, die Erweiterungen ermöglicht ohne das Gesamtsystem zu destabilisieren
• Standardtechnologien statt proprietärer Lösungen, die an einzelne Personen oder Werkzeuge gebunden sind
• Betriebskonzept mit definierten Update-, Backup- und Disaster-Recovery-Prozessen

Ein Excel-File auf einem Netzlaufwerk hat kein Betriebskonzept. Eine professionell entwickelte Laboranwendung kann und sollte eines haben – inklusive SLA-Definitionen, Monitoring und einem klaren Eskalationspfad.

Der Kostenvergleich, der selten gemacht wird

Die direkten Entwicklungskosten einer individuellen Lösung sind sichtbar. Die Kosten von Excel sind es nicht – bis es zu spät ist. Eine FDA-Inspektion mit Befunden zu Datenintegrität kann Produktionsstopps, Rückrufe und monatelange Remediation-Projekte nach sich ziehen. Erhebliche Zeit- und Finanzverluste entstehen dann, wenn Batches zurückgehalten oder neu geprüft werden müssen – und Verpflichtungen gegenüber Distributoren sowie der Unternehmensruf gefährdet sind.

Dagegen ist ein sauber entwickeltes, validiertes Softwaresystem – auch wenn es initial mehr kostet – eine Investition in Prozesssicherheit, Inspektionsbereitschaft und das Vertrauen von Behörden und Partnern.

Wann individuelle Entwicklung die richtige Wahl ist

Zur Orientierung: Individuelle Softwareentwicklung ist besonders dann sinnvoll, wenn...

• ein Prozess zu spezifisch ist für ein Standard-LIMS oder ELN
• Metadaten strukturiert, erzwungen und durchsuchbar sein müssen
• Berechnungslogik komplex und auditierbar sein muss
• Schnittstellen zu Geräten oder anderen Systemen bestehen
• der Prozess langfristig betrieben und weiterentwickelt werden soll
• eine GxP-Validierung nach GAMP 5 erforderlich ist und das System dafür ausgelegt sein muss

Individuelle Entwicklung ist kein Allheilmittel – sie erfordert sorgfältige Anforderungsaufnahme, ein klares Validierungskonzept und einen verlässlichen Entwicklungs- und Betriebspartner. Aber sie ist in vielen Fällen die einzige Antwort, die Compliance, Qualität und Langlebigkeit gleichermaßen erfüllt.

Fazit

Jedes Mal, wenn in einem GxP-Labor eine neue Excel-Datei für einen kritischen Prozess erstellt wird, wird eine Entscheidung getroffen. Meistens unbewusst, aus Pragmatismus. Aber regulatorisch und qualitativ ist es eine Entscheidung mit Konsequenzen.

Jedes computergestützte System, das in GxP-relevanten Umgebungen für die Erfassung, Aufzeichnung, Übertragung, Speicherung oder Verarbeitung von Daten eingesetzt wird, muss validiert werden – und es müssen die Risiken identifiziert werden, die das System und seine Nutzer für die Datenintegrität darstellen. Excel ist davon nicht ausgenommen. Der Unterschied ist: Bei einem ordentlich entwickelten, spezifischen System sind diese Risiken beherrschbar. Bei Excel strukturell nicht.

Das Ziel ist kein Labor ohne Werkzeuge für schnelle Analysen. Excel bleibt wertvoll für explorative Auswertungen, Visualisierungen, interne Kalkulation ohne GxP-Relevanz. Aber für Prozesse, die Datenintegrität, Rückverfolgbarkeit und Inspektionssicherheit erfordern, braucht es Systeme, die dafür gebaut wurden.

Manchmal ist das ein LIMS. Manchmal ein ELN. Und manchmal – öfter als gedacht – ist es eine individuelle Lösung, die genau das tut, was gebraucht wird. Nicht mehr. Aber auch nicht weniger.

Sie stehen vor einer ähnlichen Situation in Ihrem Labor? Ein Prozess, der zwischen LIMS und ELN fällt – und der heute mit Excel überbrückt wird, obwohl Sie wissen, dass das keine langfristige Antwort ist?

Wir begleiten Labor-IT-Teams, Qualitätsmanager und Forscher dabei, solche Lücken systematisch zu schließen: von der Anforderungsaufnahme über die Validierungsstrategie bis zur technischen Umsetzung und dem dauerhaften Betrieb.

Nehmen Sie Kontakt auf – für ein unverbindliches Erstgespräch, eine Einschätzung Ihrer aktuellen Situation oder eine Diskussion über den richtigen Lösungsansatz für Ihr spezifisches Umfeld.