Softwarevalidierung unter GxP: Was Teams nachweisen müssen

„Wir müssen das System validieren“ ist ein Satz, der in Projekten Panik oder Achselzucken auslöst – selten Klarheit. Dabei ist der Ablauf gut beschreibbar. Dieser Deep Dive geht ihn Schritt für Schritt durch: was geplant, geprüft, dokumentiert und freigegeben wird, und was danach passiert.

1. Was genau nachgewiesen wird

Validierung belegt, dass ein System für seinen definierten Verwendungszweck geeignet ist – und zwar dokumentiert, nachvollziehbar und in der konkreten Einsatzumgebung. Drei Punkte folgen daraus unmittelbar:

• Ohne definierten Verwendungszweck ist Validierung nicht durchführbar, weil der Bezugspunkt fehlt.
• Validiert wird beim Betreiber, nicht beim Hersteller. Ein Produkt kann Voraussetzungen mitbringen, mehr nicht.
• Der Nachweis gilt für einen Stand. Nach Änderungen muss er gehalten oder erneuert werden.

2. Der Ablauf im Überblick

3. Validierungsplan

Der Plan entsteht vor der Prüfung und legt fest, was als Nachweis akzeptiert wird. Inhaltlich gehören hinein: Geltungsbereich und Abgrenzung, Risikobewertung, geplante Qualifizierungsschritte, Verantwortlichkeiten, Umgang mit Abweichungen, Lieferantenbewertung, Aufbewahrung und die Kriterien für die Freigabe.

Ein häufiger Fehler ist der zu große Geltungsbereich. Alles einzuschließen wirkt gründlich, macht die Validierung aber teuer und träge. Eine klare Abgrenzung – was gehört nicht dazu – ist genauso wichtig wie die Einschlussliste.

4. Anforderungen und Spezifikation

Anforderungen sind der Bezugspunkt für alles Weitere. Nützlich ist eine Kennzeichnung nach GxP-Relevanz: Nicht jede Anforderung ist regulatorisch bedeutsam, und diese Unterscheidung spart erheblichen Aufwand. Jede Anforderung braucht eine stabile Kennung, prüfbare Formulierung und eine Verknüpfung zu Design, Test und Freigabe – siehe Traceability.

5. Qualifizierung: IQ, OQ, PQ

Automatisierte Tests decken vor allem den OQ-Bereich gut ab – vorausgesetzt, Umgebung, Testdaten und Protokollierung sind kontrolliert. PQ bleibt in der Regel zu einem Teil manuell, weil dort das Zusammenspiel mit den Menschen und Prozessen geprüft wird.

6. Abweichungen und Bewertung

Abweichungen sind normal. Entscheidend ist, dass sie dokumentiert, bewertet und entschieden werden – und nicht durch stille Anpassung des Testfalls verschwinden. Ein tragfähiger Umgang umfasst:

• Beschreibung der Abweichung und des betroffenen Testfalls,
• Bewertung der Auswirkung auf Produktqualität, Patientensicherheit und Datenintegrität,
• Entscheidung: beheben und erneut prüfen, akzeptieren mit Begründung, oder Einschränkung des Verwendungszwecks,
• Freigabe der Entscheidung durch die zuständige Rolle.

7. Bericht und Freigabe

Der Validierungsbericht fasst zusammen, was geprüft wurde, mit welchem Ergebnis, welche Abweichungen auftraten und wie sie bewertet wurden. Er endet mit einer klaren Aussage zur Eignung für den definierten Verwendungszweck – gegebenenfalls mit Einschränkungen. Freigegeben wird durch die im Plan benannten Rollen, insbesondere die Qualitätseinheit, die unabhängig von der Entwicklung agiert.

8. Aufrechterhaltung des validierten Zustands

Nach der Freigabe beginnt der längere Teil. Dazu gehören:

• Change Control für jede Änderung an System, Konfiguration oder Umgebung,
• periodische Überprüfung in festgelegten Abständen – laufen die Prozesse noch wie beschrieben, sind Nachweise noch vorhanden?
• Umgang mit Fehlern und Sicherheitsupdates, inklusive Bewertung ihrer Validierungsrelevanz,
• Außerbetriebnahme mit geregelter Datenübernahme und Lesbarkeit über die Aufbewahrungsfrist.

9. Aufwand realistisch halten

Drei Hebel senken den Aufwand, ohne die Qualität des Nachweises zu senken:

1. Risikobasierung konsequent nutzen. Nicht alles gleich tief prüfen.
2. Lieferantenleistung anrechnen, statt Standardfunktionen erneut nachzuweisen.
3. Nachweise automatisch erzeugen, statt sie zu schreiben – siehe Evidence by Design.

Checkliste: Validierungsprojekt

Fazit

Validierung ist kein Dokumentationsprojekt, sondern ein Prüfprojekt mit aufbewahrten Ergebnissen. Wer den Verwendungszweck scharf fasst, risikobasiert plant, Lieferantenleistung anrechnet und Nachweise automatisch erzeugt, kommt mit deutlich weniger Aufwand zu einem deutlich belastbareren Ergebnis.

Der teure Teil ist selten die Prüfung selbst. Teuer wird es, wenn Anforderungen unscharf sind, Nachweise fehlen oder der validierte Zustand nach dem ersten Update nicht gehalten wird.