Warum Ihr 2-Millionen-Euro-LIMS-Upgrade Ihr Data-Integrity-Problem nicht löst
Ein großer europäischer Wirkstoffhersteller verbrachte achtzehn Monate damit, ein neues Laborinformations- und Managementsystem einzuführen. State-of-the-Art-Software. Vollständige elektronische Signaturen. Umfassende Audit Trails. Jedes Feature, das die Berater versprochen hatten, würde die Data-Integrity-Themen lösen.
Sechs Monate nach Go-Live folgte eine EMA-Inspektion. Die erste Data-Integrity-Beobachtung des Inspektors hatte nichts mit dem teuren neuen LIMS zu tun. Sie zielte auf eine einfache Frage: „Wer im Senior Management überprüft Audit-Trail-Ausnahmen, und welche Maßnahmen folgen aus diesen Reviews?“
Der Quality Director konnte nicht antworten. Der IT-Manager auch nicht. Das LIMS erzeugte perfekte Audit Trails, die niemand in der Führungsebene jemals betrachtete.
Das Unternehmen hatte Millionen in Technologie investiert und dabei völlig übersehen, was Behörden tatsächlich interessiert: ob das Management die Integrität pharmazeutischer Daten kontrolliert.
Das grundlegende Missverständnis
In den meisten Pharmaunternehmen mit Data-Integrity-Themen hören Sie dieselbe Erklärung: „Wir brauchen bessere Systeme.“ Neuere Software. Mehr Validierung. Strengere IT-Kontrollen. Die Annahme dahinter: Data Integrity sei ein technisches Problem, das technische Lösungen erfordert.
Behörden sehen das völlig anders.
Aus Sicht von FDA und EMA zeigen Data-Integrity-Versagen etwas weit Ernsteres als unzureichende Software: Sie zeigen, dass das Management die Daten, auf denen seine Qualitätsentscheidungen beruhen, weder versteht noch kontrolliert. Das ist kein IT-Problem. Das ist ein Governance-Versagen.
Diese Trennung erklärt, warum Unternehmen immer wieder von Data-Integrity-Befunden überrascht werden. Sie investieren in Lösungen für Probleme, auf die Inspektoren gar nicht achten – und ignorieren die Governance-Lücken, die zu den eigentlichen Beanstandungen führen.
Wie Data-Integrity-Versagen tatsächlich aussieht
Die klassischen Data-Integrity-Verstöße – geteilte Login-Daten, gelöschte Audit Trails, manipulierte Chromatogramme – tauchen tatsächlich in Warning Letters und 483-Beobachtungen auf. Aber diese technischen Verstöße sind Symptome. Die zugrundeliegende Krankheit ist die Distanz des Managements zu den Datenprozessen.
Was Inspektoren typischerweise finden:
Geteilte Benutzerkonten über mehrere Analysten hinweg. Ja, das ist ein technisches Kontrollversagen. Aber das tieferliegende Thema ist: Warum hat niemand im Management bemerkt oder sich daran gestört, dass individuelle Verantwortlichkeit für analytische Daten unmöglich war? Die geteilten Logins existierten über Monate oder Jahre, sichtbar in Audit-Logs, die Vorgesetzte angeblich überprüften. Der technische Verstoß bestand fort, weil Management-Aufsicht fehlte.
Ein FDA-Inspektor formulierte es bei einem Closeout-Meeting unverblümt: „Ihre Audit Trails zeigen sechs Analysten, die seit zwei Jahren denselben Account nutzen. Niemand in Ihrer Organisation hat das je hinterfragt. Wie genau überwacht Ihr Management hier Datenintegrität?“
Audit Trails, die nichts Sinnvolles erfassen. Systeme sind so konfiguriert, dass technische Aktivitäten geloggt werden, aber die Aufzeichnungen sind so detailarm oder unstrukturiert, dass eine sinnvolle Überprüfung unmöglich ist. Inspektoren fragen dann: Hat irgendjemand im Management jemals geprüft, ob Audit Trails tatsächlich aussagekräftige Informationen liefern? Und gibt es einen Prozess, mit dem das Management dauerhaft sicherstellt, dass elektronische Datensysteme tatsächlich gesteuert werden? In den meisten Fällen, in denen Audit Trails unvollständig sind, lautet die Antwort: nein – die IT hat die Systeme vor Jahren konfiguriert und das Management hat nie überprüft, ob die Konfiguration noch passt.
Manuelle Datenmanipulation ohne Dokumentation. Analysten integrieren Peaks manuell, schließen Ausreißer aus oder passen Baseline-Einstellungen an – allesamt potenziell legitime wissenschaftliche Tätigkeiten, sofern sie sauber begründet sind. Das Problem ist nicht, dass diese Tätigkeiten stattfinden. Das Problem: Sie geschehen ohne dokumentierte Begründung, ohne Vorgesetzten-Review und ohne Beleg, dass das Management überhaupt weiß, dass dieser manuelle Eingriff Routine ist.
Wenn Inspektoren undokumentiertes manuelles Datenhandling finden, sind sie nicht primär über die einzelnen Fälle besorgt. Sie sind besorgt darüber, dass das Management keine Vorstellung davon hat, wie viel Datenmanipulation stattfindet, wo sie passiert und ob sie wissenschaftlich begründet ist. Das stellt ein fundamentales Versagen der Aufsicht dar.
Die richtigen Fragen stellen
Weiß das Management, woher kritische Daten kommen? Das wirkt elementar, doch viele Organisationen scheitern an diesem Test. Senior Quality Leader können Datenflüsse für Schlüsselprozesse nicht abbilden. Sie wissen nicht, welche Schritte manuelles Datenhandling enthalten. Sie sind unsicher, wo analytische Entscheidungen wissenschaftliches Urteilen erfordern – im Unterschied zu automatisierter Verarbeitung.
Bei Inspektionen zeigt sich das, wenn Führungskräfte nicht erklären können, wie bestimmte Datenpunkte in den Batch Records erzeugt wurden oder wer für deren Review verantwortlich war. Das signalisiert: Das Management lenkt Dokumente, nicht Daten.
Ein Quality VP eines Biologika-Herstellers beschrieb seine Wende: „Wir haben gemerkt: Unser Management konnte den Review-Prozess unserer papierbasierten Batch Records bis ins Detail beschreiben. Aber niemand konnte erklären, wie elektronische Produktionsdaten überprüft werden, von wem, oder was eine Eskalation auslöst. Wir hatten unsere elektronischen Systeme unbewusst wie eine Blackbox behandelt.“
Funktionieren die Kontrollen tatsächlich? Die meisten Unternehmen können belegen, dass Data-Integrity-Kontrollen existieren – Audit Trails sind aktiviert, Berechtigungen sind eingestellt, Verfahren sind dokumentiert. Der wichtigere Test: Verifiziert das Management regelmäßig, dass diese Kontrollen wirksam funktionieren? Werden Audit-Trail-Reviews tatsächlich durchgeführt – mit Erkenntnissen, die das Management auch erhält? Werden Berechtigungen überprüft? Werden Datenintegritäts-Trends analysiert?
Ohne diese Verifikationsschleife existiert die Kontrolle in der Theorie, nicht in der operativen Realität.
Werden Probleme eskaliert und adressiert? Wenn Data-Integrity-Probleme identifiziert werden – durch Audit-Trail-Reviews, interne Audits oder Abweichungsuntersuchungen – was passiert dann? Erreichen sie das Management? Lösen sie eine Bewertung auf Systemebene aus? Führen sie zu Korrekturmaßnahmen?
Inspektoren finden immer wieder Data-Integrity-Versagen, die zuvor identifiziert, aber nie über die lokale Aufsichtsebene hinaus eskaliert wurden. Ein Analyst manipulierte Daten; sein direkter Vorgesetzter ging dem nach; niemand informierte das Quality Management; niemand prüfte, ob ähnliche Risiken anderswo bestanden.
Dieses Muster sagt Behörden: Data-Integrity-Probleme werden als individuelle Vorfälle behandelt, nicht als potenzielle Systemschwachstellen. Es legt nahe, dass das Management von Data-Integrity-Risiken gar nichts wissen will – und das ist so besorgniserregend, wie es nur werden kann.
Wird Data Integrity auf Management-Ebene diskutiert? Das ist der ultimative Test: Erhält die Geschäftsleitung regelmäßig Informationen zu Data-Integrity-Risiken, -Kontrollen und -Trends?
Inspektoren prüfen Management-Meeting-Protokolle gezielt nach Data-Integrity-Themen. Sie wollen sehen, dass die Führung regelmäßig Audit-Trail-Befunde, Systemzugriffs-Kontrollen, Data-Integrity-CAPA-Trends und neu auftretende Risiken bespricht.
Wenn Data Integrity in Executive-Quality-Reviews nie auftaucht, signalisiert das: Das Thema gilt nicht als strategische Qualitätsfrage. Eine massive rote Flagge – sie legt nahe, dass die gesamte Qualitätskultur Data Integrity unterbewertet.
Die Governance-Lücke in der Praxis
So sieht das Versagen der Data-Integrity-Governance konkret aus:
Eine Tablettenproduktion erhält eine FDA-Inspektion. Der Inspektor prüft das Labordatensystem und findet nichts offensichtlich Problematisches – Audit Trails sind aktiviert, Berechtigungen kontrolliert, Data-Integrity-Verfahren existieren.
Dann fragt der Inspektor den Quality Director: „Wie oft im vergangenen Jahr hat Ihr QC-Vorgesetzter auffällige Muster in Audit-Trail-Reviews identifiziert?“
Der QD weiß es nicht. Sie hat nie eine Zusammenfassung der Audit-Trail-Befunde erhalten.
„Wie stellen Sie fest, ob Ihre Data-Integrity-Kontrollen wirksam funktionieren?“
Der QD erklärt, man führe jährliche Audits durch, die das Vorhandensein der Kontrollen verifizieren. Aber sie hat keine Kennzahlen dazu, ob diese Kontrollen tatsächlich Probleme erkennen, wie häufig Ausnahmen auftreten oder ob es Trends gibt.
„Welche Data-Integrity-Kennzahlen prüft das Senior Management?“
Keine. Das Management erhält Abweichungs-Counts und CAPA-Kennzahlen – aber nichts spezifisch zu Data Integrity.
Wie es in der Praxis funktioniert: drei Beispiele
Beispiel 1: Governance des Manufacturing Execution Systems
Ein Hersteller steriler Injektabilia erkannte: Sein MES erzeugte Tausende elektronischer Datensätze, die das Management nie überprüfte. Sein Vorgehen:
-
Alle kritischen Entscheidungspunkte im Produktionsprozess kartiert, an denen Operatoren elektronische Eingaben vornehmen.
-
Identifiziert, welche Eingaben das größte Maß an Ermessen/Beurteilung enthielten (höchstes Data-Integrity-Risiko).
-
Automatisierte Ausnahme-Reports implementiert, die ungewöhnliche Muster markierten (derselbe Operator macht alle kritischen Eingaben, Eingaben zu ungewöhnlichen Zeiten, häufige Datenkorrekturen).
-
Das Produktionsmanagement musste die Ausnahme-Reports wöchentlich prüfen und gegenzeichnen.
-
Wiederkehrende Muster wurden zur Untersuchung an das Senior Quality Management eskaliert.
Ergebnis: Bei der FDA-Inspektion konnte der Produktionsleiter 18 Monate dokumentierter Ausnahme-Reviews vorlegen, erklären, wie Muster Untersuchungen auslösten, und zeigen, wie Befunde zu Verfahrensverbesserungen führten. Der Inspektor hob dies ausdrücklich als Übererfüllung der Erwartungen hervor.
Die Technologie hatte sich nicht geändert. Das Management-Engagement schon.
Beispiel 2: Data-Integrity-Dashboard fürs Labor
Ein europäischer Hersteller fester oraler Darreichungsformen kämpfte mit der Data-Integrity-Aufsicht in seinen analytischen Laboren. Zu viele Daten, zu viele Systeme, kein kohärenter Weg, mit dem das Management die Integrität bewerten konnte.
Ihre Lösung: Ein monatliches Data-Integrity-Dashboard für die Quality Leadership – mit:
-
Anzahl durchgeführter vs. erforderlicher Audit-Trail-Reviews
-
Identifizierte Audit-Trail-Ausnahmen und deren Bearbeitungsstatus
-
Trends bei manuellen Integrationen und Reprocessing über Methoden hinweg
-
Verstöße gegen Systemzugriffe (geteilte Logins, ungewöhnliche Zugriffszeiten)
-
Schulungsabschlussraten für Data-Integrity-Verfahren
-
Offene Data-Integrity-CAPAs und deren Wirksamkeitsstatus
Jede Kennzahl hatte definierte Schwellenwerte, die eine Management-Untersuchung auslösten. Das Dashboard war keine Hightech-Lösung – anfangs überwiegend manuelle Datenaufbereitung – aber es erzwang regelmäßige Management-Aufmerksamkeit für Data Integrity.
Innerhalb von sechs Monaten identifizierten sie systemische Themen, die seit Jahren existierten: Bestimmte analytische Methoden erforderten routinemäßig manuelle Eingriffe, die nicht ausreichend begründet waren; einzelne Analysten erzeugten weit mehr Audit-Trail-Ausnahmen als ihre Kolleg:innen; Schulungen zu elektronischem Datenhandling waren wirkungslos.
Die Probleme waren in den Daten immer sichtbar gewesen. Das Dashboard machte sie für das Management sichtbar.
Beispiel 3: Data-Integrity-Risikobewertung
Ein CDMO wählte einen anderen Weg: eine formale Data-Integrity-Risikobewertung über alle Systeme, die GMP-relevante Daten erzeugen.
Für jedes System bewerteten sie:
-
Welche kritischen Daten werden erzeugt?
-
Wo finden menschliche Interaktion / Ermessensentscheidungen statt?
-
Welche Kontrollen existieren, um Datenintegrität zu gewährleisten?
-
Wie verifizieren wir, dass diese Kontrollen funktionieren?
-
Welche Aufsicht hat das Management?
Die Bewertung deckte überraschende Lücken auf. Die anspruchsvollsten Systeme (LIMS, MES) hatten starke Kontrollen und Aufsicht. Aber einfachere Systeme – Environmental-Monitoring-Equipment, Stabilitätskammern, Lagertemperatur-Logger – hatten kaum Kontrollen und so gut wie keine Management-Sichtbarkeit.
Diese Systeme waren nicht absichtlich ignoriert worden. Das Unternehmen hatte unbewusst angenommen, „einfach“ bedeute „geringes Risiko“. Die formale Bewertung zwang sie zu der Erkenntnis, dass Daten aus einfachen Systemen kritische Qualitätsentscheidungen weiterhin beeinflussen.
Sie führten risikobasierte Aufsicht ein: Hochrisiko-Systeme erhielten ein monatliches Management-Review. Mittleres Risiko quartalsweise. Auch Systeme mit geringem Risiko erhielten eine jährliche Bewertung.
Bei der EMA-Inspektion konnte das Unternehmen demonstrieren, dass das Management Datenintegrität systematisch über alle Systeme verstand und kontrollierte – nicht nur über die offensichtlichen.
Die Management-Fragen, die zählen
Möchten Sie wissen, ob Ihre Organisation ein Data-Integrity-Governance-Problem hat? Stellen Sie Ihrem Quality-Leadership-Team diese Fragen:
„Welcher Anteil unserer elektronischen Datensätze wird routinemäßig vom Vorgesetzten geprüft, und was löst eine Eskalation an das Quality Management aus?“
Wenn die Antwort fehlt, haben Sie eine Governance-Lücke.
„Zeigen Sie mir die Data-Integrity-Kennzahlen der letzten drei Monate, die Sie in Management-Meetings überprüft haben.“
Wenn sie nicht vorzeigbar sind, wird Data Integrity nicht wirklich auf Management-Ebene gelenkt.
„Wo in unseren Prozessen findet manuelles Datenhandling statt, und wie verifizieren wir, dass es angemessen begründet ist?“
Wenn die Antwort vage ist oder die IT befragt werden muss, versteht das Management Ihre Datenflüsse nicht.
„Wann fand unsere letzte Data-Integrity-Risikobewertung statt, was hat sie ergeben, welche Maßnahmen sind daraus entstanden?“
Wenn das mehr als zwei Jahre zurückliegt oder keine wesentlichen Maßnahmen folgten, ist Ihre Risikobewertung wahrscheinlich eine Papierübung.
„Welche Data-Integrity-Schulungen habe ich erhalten, und wann?“
Wenn Ihre Senior Quality Leader keine aktuelle, substantielle Data-Integrity-Schulung erhalten haben – wie sollen sie das Thema wirksam steuern können?
Das sind keine Fangfragen. Es sind dieselben Fragen, die Inspektoren stellen. Wenn Ihr Management Mühe hat, sie zu beantworten, werden Inspektoren – zu Recht – zu dem Schluss kommen, dass Data Integrity nicht ernsthaft von der Führungsebene kontrolliert wird.
Warum Technologie allein immer scheitert
Die Pharmabranche lernt diese Lektion immer wieder auf die harte Tour: Neue Systeme einzuführen, ohne die Governance zu ändern, produziert teure Fehlinvestitionen.
Unternehmen führen elektronische Laborbücher ein und erwarten, damit Data-Integrity-Themen zu lösen. Aber wenn Analysten in der Papier-Ära geteilte Logins genutzt haben, finden sie auch in der elektronischen Ära Wege, Kontrollen zu umgehen – es sei denn, das Management schafft Verantwortlichkeit und Aufsicht.
Organisationen setzen ausgereifte Audit-Trail-Analyse-Tools ein. Aber wenn niemand im Management den Output prüft oder auf Befunde reagiert, erzeugen die Tools nur ignorierte Reports – elaborierte Dokumentation der Management-Distanz.
Firmen validieren elektronische Systeme nach erschöpfenden Standards. Aber wenn die Validierung nie fragt: „Wie wird das Management verifizieren, dass dieses System Datenintegrität dauerhaft aufrechterhält?“, adressiert die Validierung die falsche Frage.
Technologie ermöglicht Datenintegrität. Sie kann Datenintegrität nicht garantieren. Das erfordert Management-Governance: zu verstehen, woher kritische Daten kommen, geeignete Kontrollen einzuführen, Wirksamkeit zu überprüfen, bei Versagen zu untersuchen und entstehende Risiken kontinuierlich zu bewerten.
Inspektoren verstehen das deutlich. Deshalb fokussieren sich Data-Integrity-Beanstandungen zunehmend auf Management-Aufsicht statt auf technische Spezifikationen.
Die kulturelle Realität
Die unbequeme Wahrheit hinter den meisten Data-Integrity-Problemen: Sie bestehen fort, weil das Management eigentlich nicht wissen will.
Audit Trails zu prüfen ist mühsam. Datenanomalien zu untersuchen ist zeitaufwändig. Systemische Data-Integrity-Risiken zu akzeptieren erfordert möglicherweise schwierige Gespräche über Ressourcenknappheit, Zeitdruck oder Leistungserwartungen, die im Konflikt mit Datenintegrität stehen.
Es ist einfacher, Data Integrity an die IT zu delegieren und anzunehmen, technische Kontrollen würden ausreichen. Es ist bequemer, jeden Data-Integrity-Befund als Einzelfall zu behandeln, statt zu prüfen, ob systemischer Druck mitverantwortlich ist. Es ist weniger bedrohlich, neue Software einzuführen, als harte Fragen darüber zu stellen, ob das Management elektronische Daten wirklich lenkt.
Behörden erkennen dieses Muster. Deshalb sprechen sie zunehmend deutlich aus, dass Data Integrity eine Management-Verantwortung ist, die sich nicht an technische Funktionen delegieren lässt.
Die Warning Letters machen es explizit: „Management failed to ensure adequate controls…“ „The firm’s executive leadership did not provide sufficient oversight…“ „Senior management did not establish effective data governance…“
Die Botschaft ist klar: Data-Integrity-Versagen sind Management-Versagen, und technische Lösungen beheben keine Management-Probleme.
Wie es gut aussieht
Organisationen mit starker Data-Integrity-Governance teilen erkennbare Merkmale:
Die Senior Leadership kann erklären, woher kritische Daten in den Schlüsselprozessen stammen. Sie muss nicht die IT fragen oder Verfahren konsultieren – sie versteht ihre Datenlandschaft grundlegend.
Das Management überprüft routinemäßig Data-Integrity-Kennzahlen und nutzt sie für Entscheidungen. Wenn Trends entstehen, werden Ressourcen umverteilt. Wenn Kontrollen versagen, finden Untersuchungen statt. Wenn Risiken identifiziert werden, werden sie priorisiert.
Data Integrity erscheint in der strategischen Planung – nicht nur in der Validierung von IT-Systemen. Die Führung diskutiert Data-Integrity-Risiken neben Kontaminationsrisiken, Lieferkettenrisiken und anderen strategischen Qualitätsthemen.
Mitarbeitende auf allen Ebenen verstehen, dass Data Integrity der Führung wichtig ist. Nicht weil Plakate das behaupten, sondern weil das Management-Verhalten es zeigt – durch Ressourcenallokation, Anerkennung guter Praxis, Untersuchung von Verstößen und die Bereitschaft, systemische Beiträge zu adressieren.
Wenn Inspektoren diese Organisationen besuchen, finden sie Management-Teams, die Data Governance verstehen, ihre Aufsicht artikulieren können und belegen können, dass diese Aufsicht wirksam ist. Die technischen Kontrollen sind in der Regel angemessen, aber unauffällig. Was beeindruckt, ist das offensichtliche Management-Engagement.
Das Wesentliche
Ihr Data-Integrity-Problem ist nicht Ihr Laborinformationssystem. Nicht Ihre Audit-Trail-Konfiguration. Nicht Ihre Validierungsdokumentation.
Ihr Data-Integrity-Problem ist, dass das Management die Daten, die Ihre Qualitätsentscheidungen treiben, nicht ausreichend versteht, kontrolliert oder überwacht.
Solange die Führung Data Integrity nicht als Governance-Verantwortung behandelt – etwas, das ihr aktives Engagement, regelmäßige Aufsicht und strategische Aufmerksamkeit erfordert – werden technische Lösungen weiter enttäuschen.
Behörden verstehen das längst. Die Frage ist, ob Ihre Organisation es auch versteht.
Denn beim nächsten Mal, wenn ein Inspektor fragt: „Wie überwacht das Senior Management Data Integrity?“, hilft Ihnen ein großartiges LIMS nicht – wenn niemand die Frage beantworten kann.