eQMS-Einführung im GxP-Umfeld: Digitalisierter Fortschritt mit Fokus auf Datenintegrität, Annex 11 und Annex 22

Wenn GMP-Behörden heute digitale Qualitätsmanagementsysteme prüfen, richten sich Augenmerke vor allem auf Stammdaten, Berechtigungen und Zeitstempel. Genau in diesen digitalen Spuren entscheidet sich, ob eine Inspektion glimpflich verläuft oder in kritischen Mängeln zu Datenintegrität und Computerised Systems endet. Welche regulatorischen Vorgaben die Datenintegrität eines eQMS heute bestimmen, wie der Weg von der User Requirement Specification zu einem validierten System führt und was der Lebenszyklus verlangt, sobald KI-gestützte Funktionen hinzukommen, erfahren Sie in den nachfolgenden Abschnitten.

Digitale Systeme durchziehen mittlerweile jeden Winkel der pharmazeutischen Qualitätssicherung, von der Dokumentenlenkung bis zur Chargenfreigabe. Mit dieser Durchdringung wächst die Komplexität dessen, was ein einzelnes System regulatorisch leisten muss, und genau in dieser Komplexität liegt die eigentliche Kunst jeder eQMS‑Einführung. Wer ein eQMS heute aufbaut oder erneuert, entscheidet über die eigene Auditfähigkeit der kommenden Jahre, oft weit über den Tag der Einführung hinaus. Ein genauer Blick auf die zentralen Bausteine dieses Weges lohnt sich daher.

Annex 11, Annex 22 und die Sprache der Datenintegrität

In der EU trägt das Arzneimittelgesetz gemeinsam mit EudraLex Band 4 die tragende Säule dieses Feldes, und innerhalb dieses Werks öffnen Annex 11 zu Computerised Systems zusammen mit Kapitel 4 zur Dokumentation den eigentlichen Resonanzraum für IT‑gestützte Qualitätssysteme. Wer außerdem den amerikanischen Markt bedient, begegnet in 21 CFR-Part 11 einem verwandten Anspruch der FDA an elektronische Aufzeichnungen und Signaturen, formuliert in einer eigenen Sprache, doch im Kern demselben Gedanken verpflichtet.

Annex 11 verlangt einen vollständigen Lebenszyklusansatz von der Spezifikation über die Validierung bis zum laufenden Betrieb, mit besonderem Gewicht auf Zugangskontrollen, Audit Trails, Datensicherung und regelmäßige Reviews. Der aktuelle Entwurf präzisiert diese Anforderungen weiter, etwa in Bezug auf Sicherheitsarchitektur, Lieferantenaufsicht und Datenintegrität über den gesamten Systemlebenszyklus.

Der ebenfalls neue Entwurf zu Annex 22 setzt in genau diesem Klima an und ergänzt den Rahmen um Anforderungen an künstliche Intelligenz und maschinelles Lernen in GMP‑Prozessen. Er widmet sich dem Lebenszyklus von Modellen, der Governance von Trainings- und Testdaten, dem Performance‑Monitoring und der Kontrolle durch qualifizierte menschliche Bewertung. Beide Dokumente stehen vor dem Hintergrund derselben Datenintegritätsanforderungen, wie sie unter anderem in Form der ALCOA+‑Prinzipien etabliert sind: der Forderung nach zurechenbaren, lesbaren, zeitnahen, originalen, genauen, vollständigen, konsistenten, dauerhaften und verfügbaren Daten.

Wer die User Requirement Specification für ein eQMS entwirft, tut gut daran, diese Prinzipien von der ersten Zeile an als regulatorische Muss‑Anforderung zu verankern, getrennt von den prozessualen Vorgaben aus QMS und Pharmakovigilanz und getrennt von den eher wünschenswerten Komfortfunktionen, die ein Lastenheft gerne anschwellen lassen.

Der Weg von der Anforderung zur Validierung

Aus dieser Anforderungslandschaft wächst der eigentliche Fahrplan des Projekts heran, Schritt für Schritt, in einer Choreografie, die das V‑Modell seit Jahren vorgibt. Entlang dieses Modells folgen auf die URS die funktionalen und die Design‑Spezifikationen, jede von ihnen eine Übersetzung des vorherigen Gedankens in eine konkretere Sprache.

Schon die Design Qualification ermöglicht einen strukturierten Vergleich verfügbarer Systeme und führt zu einer begründeten Wahl des am besten geeigneten eQMS. Ist diese Entscheidung gefallen, folgt die Qualifizierung des Anbieters. Dabei werden die regulatorischen Fähigkeiten des Herstellers oder Dienstleisters geprüft, meist über Audits oder eigens entwickelte Fragebögen für IT-Dienstleister. Auch hier bleiben Annex 11 und Kapitel 7 der EU-GMP-Leitlinie der Maßstab: jenes Kapitel zu ausgelagerten Tätigkeiten, das für jede Zusammenarbeit mit einem externen Dienstleister einen schriftlichen Vertrag und ein Auditrecht des Auftraggebers verlangt. Besonders bei Cloud-basierten oder ausgelagerten Lösungen bleibt die regulatorische Verantwortung immer beim pharmazeutischen Unternehmen selbst, unabhängig davon, wie viele externe Parteien am Code beteiligt waren.

GAMP 5 liefert dafür einen möglichen Referenzrahmen, die Landkarte gewissermaßen, entlang derer sich Systeme klassifizieren und Validierungstiefe wie Testumfang risikobasiert bestimmen lassen. Infrastruktursoftware der Kategorie 1 verlangt einen schlankeren Nachweis, konfigurierte Standardsoftware der Kategorie 4 bereits mehr, und kundenspezifisch entwickelte Software der Kategorie 5 stellt die höchsten Ansprüche an Dokumentation und Test. Je tiefer die individuellen Anpassungen eines eQMS reichen, desto weiter wandert das System auf dieser Skala nach oben, und mit ihm der Validierungsaufwand.

Aus dieser Einstufung entsteht ein Validierungsplan. Ein Testsystem nimmt Gestalt an, und Installation Qualification, Operational Qualification und Performance Qualification prüfen gemeinsam, ob das System tatsächlich hält, was die Anforderungen versprochen haben.

Die Risikoanalyse steuert dabei den Umfang der Tests. Umgekehrt fließen die Testergebnisse wieder in die Überarbeitung dieser Risikobewertung ein und werden Teil des Validierungsberichts, der die Eignung des Systems in einer einzigen, belastbaren Aussage zusammenfasst.

Der Lebenszyklus, der nach der Validierung nicht endet

Mit der Unterschrift unter dem Validierungsbericht ist der Lebenszyklus eines Systems noch längst nicht beendet. Annex 11 und der Entwurf zu Annex 22 verlangen einen periodischen Review, eine fortlaufende Beobachtung relevanter Qualitätskennzahlen, Audit-Trail-Reviews und eine nachvollziehbare Bewertung, welche Auswirkungen jede Änderung auf den Validierungsstatus hat. Updates am System rufen ggf. nach einer gezielten Revalidierung der betroffenen Funktionen, verhältnismäßig zugeschnitten auf den tatsächlichen Umfang der Änderung.

Sobald ein eQMS KI‑gestützte Funktionen trägt, etwa zu Trending, Klassifizierung von Abweichungen oder Priorisierung von CAPA‑Maßnahmen, greifen zusätzlich die Anforderungen aus Annex 22. Sie betreffen die Governance der Trainings- und Testdaten, die Versionierung der Modelle, logische Performance‑Kennzahlen und die Gewissheit, dass kritische Entscheidungen stets einer qualifizierten, menschlichen Bewertung unterliegen müssen. Ein zeitgemäßer eQMS‑Ansatz verwebt klassische CSV‑Praktiken, also bewährte Methoden der Computerised System Validation wie risikobasierte Anforderungsdefinition, dokumentierte Testung, Traceability, Change Control und regelmäßige Reviews, mit einem strukturierten, dokumentierten KI‑Modelllebenszyklus - zwei Ansätze, die zunehmend miteinander sprechen müssen.

TentaConsult als Ihr Experte für die eQMS‑Validierung

Wer eine eQMS‑Einführung für eine reine IT‑Umstellung hält, unterschätzt die Tiefe des aktuellen Regulierungswandels, der sich in Annex 11, im Entwurf zu Annex 22 und in der gelebten Praxis der ALCOA+‑Prinzipien zu einem konsistenten Governance‑Rahmen abzeichnet. Entscheidend bleibt ein durchgängiger, risikobasierter Lebenszyklusansatz, der diese drei Stränge zusammenführt und über Jahre trägt.

Unsere Expertinnen und Experten bei TentaConsult begleiten Sie von der ersten Zeile der User Requirement Specification über die Lieferantenqualifizierung bis zur Umsetzung der Validierung inkl. Dokumentation.

Sprechen Sie uns an!