eQMS-Validierung: ein risikobasierter Ansatz für kleine Qualitätsteams

Sie haben ein elektronisches Qualitätsmanagementsystem gekauft oder stehen kurz davor, und jemand hat Sie um den Validierungsplan gebeten. Das Qualitätsteam besteht aus drei Personen. Die letzte Computervalidierung, die hier jemand erlebt hat, bestand aus einem Aktenordner mit Screenshots für ein Laborgerät, und niemand möchte das für ein System wiederholen, in dem alle Ihre SOPs, CAPAs und Schulungsnachweise gespeichert werden. Dieser Artikel erläutert einen verhältnismäßigen Ansatz für die eQMS-Validierung: Was EU-GMP-Anhang 11 und ISO 13485 tatsächlich verlangen, wie die zweite Ausgabe von GAMP 5 und der Computer-Software-Assurance-Ansatz den Aufwand verringern, in welchem Umfang Sie sich auf die Tests des Anbieters verlassen können, welche Auswirkungen Konfiguration und kundenspezifische Anpassungen haben, was Sie selbst testen sollten und wie Sie das System nach der Inbetriebnahme weiterhin validiert halten.

Was die Anforderungen tatsächlich besagen

Für Medizinproduktehersteller verlangt Abschnitt 4.1.6 von ISO 13485:2016 dokumentierte Verfahren zur Validierung der Anwendung von Computersoftware, die im Qualitätsmanagementsystem verwendet wird. Die Validierung erfolgt vor der ersten Verwendung und gegebenenfalls nach Änderungen an der Software oder ihrer Anwendung. Der Ansatz muss dem mit der Verwendung der Software verbundenen Risiko angemessen sein. Die entsprechenden Nachweise sind aufzubewahren. Der technische Bericht ISO/TR 80002-2:2017 enthält spezifische Leitlinien zur Validierung von Software, die in Qualitätsmanagementsystemen für Medizinprodukte eingesetzt wird, und ist als praxisorientierter Rahmen sehr hilfreich.

Für Arzneimittel gilt EU-GMP-Anhang 11 für jedes computergestützte System, das bei GMP-regulierten Tätigkeiten zum Einsatz kommt. Abschnitt 1 verlangt ein Risikomanagement während des gesamten Systemlebenszyklus. Der Umfang der Validierung muss auf einer begründeten und dokumentierten Risikobewertung beruhen. Abschnitt 4 behandelt die Validierung: risikobasierte und auf GMP-Auswirkungen abgestimmte Benutzeranforderungen, die über den Lebenszyklus rückverfolgbar sind (4.4); die Bewertung des Anbieters (4.5); sowie den Nachweis geeigneter Testmethoden und Testszenarien (4.7). Abschnitt 3 behandelt formelle Vereinbarungen mit Anbietern, Abschnitt 11 die regelmäßige Bewertung. Eine überarbeitete Fassung von Anhang 11 wurde 2025 zur öffentlichen Konsultation vorgelegt. Zum Zeitpunkt der Erstellung dieses Artikels ist der Text von 2011 weiterhin die auf der EudraLex-Seite der Kommission veröffentlichte Fassung. Richten Sie Ihre Planung daher danach aus und behalten Sie die neue Fassung im Blick.

Keiner der beiden Texte verlangt, jede Schaltfläche zu testen. Beide verlangen, dass Sie verstehen, was das System in Ihren Prozessen tut, entscheiden, was schiefgehen könnte, und Ihre Anstrengungen darauf konzentrieren. ICH Q9(R1) bringt denselben Gedanken allgemein zum Ausdruck: Aufwand, Formalität und Dokumentation des Qualitätsrisikomanagements sollten dem Risikoniveau entsprechen.

GAMP 5, zweite Ausgabe, und Computer Software Assurance in der Praxis

ISPE veröffentlichte die zweite Ausgabe von GAMP 5 im Juli 2022. Die Softwarekategorien sind weiterhin hilfreich: Die meisten eQMS-Produkte sind konfigurierte Software (Kategorie 4), und alles, was speziell für Sie programmiert wird, fällt unter kundenspezifische Software (Kategorie 5). Wichtiger sind die veränderten Schwerpunkte. Die zweite Ausgabe fordert kritisches Denken von Personen, die den Prozess verstehen, erwartet von regulierten Unternehmen, das Wissen, die Tests und die Dokumentation des Anbieters umfassend zu nutzen, und unterstützt iterative Entwicklung sowie Cloud-Dienste.

Computer Software Assurance (CSA) geht in dieselbe Richtung. Der Ansatz wurde von der US-amerikanischen FDA in einer im September 2025 finalisierten und im Februar 2026 aktualisierten Leitlinie beschrieben. Obwohl es sich um ein US-amerikanisches Dokument handelt, bieten die vier Schritte eine solide Struktur für jedes kleine Team. Ermitteln Sie die vorgesehene Verwendung jeder Funktion. Entscheiden Sie, ob ein Ausfall dieser Funktion ein hohes Prozessrisiko darstellen würde. Wählen Sie dazu passende Assurance-Aktivitäten: Bei hohem Risiko verwenden Sie skriptbasierte Tests mit detaillierten Schritten und erwarteten Ergebnissen; bei geringerem Risiko eignen sich nicht skriptbasierte Methoden wie explorative Tests oder Fehlerratentests. Bewahren Sie ausreichende Nachweise auf, um die Durchführung der Arbeiten zu belegen – aber nicht mehr.

Zusammen bieten diese Ansätze Ihnen die Möglichkeit, auf Nachweise zu verzichten, die niemand nutzt. Sie geben Ihnen jedoch nicht die Möglichkeit, auf kritisches Denken zu verzichten.

Mit der vorgesehenen Verwendung beginnen

Verfassen Sie eine Seite, auf der Sie festhalten, wofür das eQMS an Ihrem Standort eingesetzt wird. Welche Prozesse werden damit ausgeführt (Dokumentenlenkung, Schulungen, Abweichungen, CAPA, interne Audits), welche nicht (Chargenfreigabe, Meldung von Beschwerden an Behörden, vielleicht), wer nutzt es und welche darin enthaltenen Aufzeichnungen sind GMP- oder ISO-13485-Aufzeichnungen? Nehmen Sie das System in Ihr Verzeichnis computergestützter Systeme auf, das Sie gemäß Anhang 11, Abschnitt 4.3, aktuell halten müssen.

Formulieren Sie anschließend Benutzeranforderungen für Ihre eigenen Prozesse und in Ihren eigenen Worten. „Eine SOP-Änderung tritt an ihrem Gültigkeitsdatum in Kraft und die vorherige Fassung wird am selben Tag zurückgezogen“ ist eine prüfbare Anforderung. „Das System muss die Dokumentenlenkung unterstützen“ ist es nicht. Für ein kleines Unternehmen reichen in der Regel einige Dutzend Anforderungen für ein eQMS aus. Bewerten Sie jede Anforderung nach ihrem Risiko: Könnte ein Ausfall die Produktqualität, die Patientensicherheit oder die Integrität eines GMP-Datensatzes beeinträchtigen? Bei den meisten Anforderungen ist das Risiko gering. Die Anforderungen, bei denen dies nicht der Fall ist – etwa der Übergang zum Gültigkeitsdatum, elektronische Signaturen, Audit-Trail, Rollenberechtigungen und die Zuweisung von Schulungen bei einer Revision –, sind diejenigen, die Sie selbst testen sollten.

Bewertung des Anbieters und Vertrauen auf dessen Tests

Anhang 11 besagt, dass Kompetenz und Zuverlässigkeit des Anbieters entscheidende Faktoren sind, dass die Notwendigkeit eines Audits risikobasiert beurteilt werden sollte (3.2) und dass Qualitätsmanagementsystem- und Auditinformationen zu Anbietern Inspektoren auf Anfrage zur Verfügung stehen müssen (3.4). Für die meisten kleinen Unternehmen, die ein konfiguriertes Cloud-System kaufen, ist eine Fernbewertung anhand eines Fragebogens und von Dokumenten angemessen. Ein Vor-Ort-Audit ist dann angezeigt, wenn die Antworten Zweifel aufkommen lassen.

Fragen Sie nach einer Beschreibung des Entwicklungslebenszyklus und des Qualitätsmanagementsystems des Anbieters, seinem Verfahren für Releases und Änderungsmitteilungen, einer Zusammenfassung seiner eigenen Tests der Kernfunktionen, der Funktionsweise von Audit-Trail und elektronischen Signaturen, dem Hosting-Standort der Daten, den Tests von Backups und Wiederherstellungen sowie dem Verfahren für den Ausstieg und den Datenexport. Unsere Checkliste für eQMS-Käufer enthält die vollständige Fragenliste.

Nun zu den Grenzen. Die MHRA-Leitlinie zur GxP-Datenintegrität (Abschnitt 6.19) besagt, dass es nicht akzeptabel ist, isoliert auf vom Anbieter bereitgestellte Validierungsdaten zu vertrauen, ohne die Systemkonfiguration und die vorgesehene Verwendung durch den Nutzer zu berücksichtigen. Tests des Anbieters außerhalb Ihres Prozesses entsprechen voraussichtlich nur einer Funktionsprüfung. Die Tests des Anbieters können das Kernprodukt abdecken: Die Audit-Trail-Engine erfasst Änderungen, Signaturen sind mit Datensätzen verknüpft und Berechtigungen werden entsprechend der Konfiguration durchgesetzt. Ihre Tests decken Ihre Konfiguration innerhalb Ihres Prozesses ab. Halten Sie diese Aufgabenteilung in einer kurzen Erklärung zur Nutzung von Anbieterunterlagen fest und nennen Sie die geprüften Dokumente sowie Ihre Schlussfolgerungen.

Konfiguration versus kundenspezifische Anpassung

Konfiguration bedeutet, das Produkt mit den bereitgestellten Werkzeugen einzurichten: Workflows, Genehmigungswege, Rollen, Nummerierungssysteme, Formularfelder und Schulungsregeln. Eine kundenspezifische Anpassung bedeutet, dass Code speziell für Sie geschrieben oder geändert wird. Dieser Unterschied hat erhebliche Auswirkungen auf den Validierungsaufwand.

Die Konfiguration wird anhand Ihrer Anforderungen getestet. Wenn für Ihren SOP-Genehmigungsweg zwei Prüfer und eine QA-freigebende Person vorgesehen sind, testen Sie diesen Ablauf – einschließlich des Falls, in dem ein Prüfer die Genehmigung ablehnt. Bei kundenspezifischen Anpassungen kommt Kategorie 5 ins Spiel, mit den damit verbundenen Anforderungen an Design, Codeprüfung und Tests. Außerdem müssen sie bei jeder neuen Version des Anbieters erneut getestet werden. Für ein kleines Team besteht die kostengünstigste Validierungsstrategie darin, das System an Ihren Prozess anzupassen und den Prozess dort zu ändern, wo er mit dem Produkt nicht harmoniert. Begründen Sie jede Anfrage nach einer kundenspezifischen Anpassung schriftlich.

Behalten Sie auch die Konfiguration selbst unter Kontrolle. Abschnitt 10 von Anhang 11 verlangt, dass Konfigurationsänderungen einem festgelegten Verfahren folgen. Dokumentieren Sie daher die Konfigurationsbasis zum Zeitpunkt der Inbetriebnahme und führen Sie spätere Änderungen über Änderungskontrolle mit Auswirkungsbewertung.

Was Sie selbst testen sollten

Konzentrieren Sie skriptbasierte Tests auf Funktionen, bei denen ein Ausfall Datensätze beschädigen oder dazu führen könnte, dass das falsche Dokument am Arbeitsplatz verwendet wird. Eine typische Aufteilung für ein eQMS sieht so aus:

Auch explorative Tests müssen dokumentiert werden: wer getestet hat, wann, welcher Bereich geprüft wurde, was versucht wurde und welche Ergebnisse dabei festgestellt wurden. Eine halbe Seite pro Sitzung reicht aus. Die Datenmigration muss separat geprüft werden, da Anhang 11, Abschnitt 4.8, verlangt, dass migrierte Daten weder in ihrem Wert noch in ihrer Bedeutung verändert werden.

Schließen Sie die Validierung mit einem zusammenfassenden Bericht ab. Dieser sollte die Anforderungen, die Nachweise für jede Anforderung (Ihre Tests, Anbieterunterlagen oder beides), die während der Tests festgestellten Abweichungen und deren Behebung (Anhang 11, Abschnitt 4.2) sowie eine klare Aussage enthalten, dass das System für seine vorgesehene Verwendung geeignet ist.

Das System weiterhin validiert halten

Ein Cloud-eQMS wird mehrmals im Jahr aktualisiert. Erstellen Sie ein kurzes Verfahren für Releases: Wie erfahren Sie davon? Wer liest die Versionshinweise? Wie werden die Auswirkungen im Hinblick auf Ihre Anforderungen bewertet? Wann ist eine Änderung der Anlass für erneute Tests? Bei einer Änderung der Signatur- oder Genehmigungslogik sind gezielte Wiederholungstests erforderlich. Bei einem neuen Berichtslayout nicht.

Abschnitt 11 von Anhang 11 verlangt regelmäßige Bewertungen, um zu bestätigen, dass sich das System weiterhin in einem validierten Zustand befindet. Dabei sind Funktionalität, Abweichungen, Vorfälle, Upgrade-Verlauf, Leistung, Sicherheit und Validierungsstatus zu berücksichtigen. Für ein kleines Unternehmen genügt eine jährliche Bewertung von ein bis zwei Seiten: Was hat sich geändert? Was ist schiefgelaufen? Sind die Benutzerzugriffe noch angemessen? Wurde die Wiederherstellung eines Backups überprüft? Entspricht das Validierungspaket noch der tatsächlichen Nutzung des Systems? Prüfen Sie bei dieser Gelegenheit auch den Audit-Trail anhand einer Stichprobe von Datensätzen.

Verhältnismäßigkeit wahren

Ein vertretbares Validierungspaket für ein eQMS in einem kleinen Herstellerunternehmen passt in einen einzigen Ordner: vorgesehene Verwendung, risikobewertete Anforderungen, Anbieterbewertung und Erklärung zur Nutzung von Anbieterunterlagen, Konfigurationsbasis, Ihre Testscripte und Aufzeichnungen explorativer Tests, ein zusammenfassender Bericht sowie ein Verfahren für Releases und regelmäßige Bewertungen. Ein Inspektor kann es innerhalb einer Stunde durchsehen. Wenn Ihr Paket deutlich umfangreicher ist, fragen Sie sich, welche Teile tatsächlich als Grundlage für Entscheidungen gedient haben.

Fazit

Validieren Sie die Konfiguration, die Sie für Ihren Prozess erstellt haben, verlassen Sie sich auf den Anbieter für das Kernprodukt, sobald Sie dessen Nachweise geprüft haben, und halten Sie das System durch die Bewertung von Releases und eine jährliche Überprüfung weiterhin validiert.

Wenn Sie diesen Arbeitsumfang gerade planen, beschreibt die Seite zur InnoQualis-Plattform die Module für Dokumentenlenkung, Schulungen, Abweichungen, CAPA und Audits, die Sie validieren würden. Die elektronischen Signaturen sind darauf ausgelegt, 21 CFR Part 11 und EU-GMP-Anhang 11 zu unterstützen; der Audit-Trail ist nur erweiterbar, nicht überschreibbar.