Inhalt
GAMP 5 ist ein Leitfaden der ISPE für einen risikobasierten Umgang mit computergestützten Systemen im GxP-Umfeld. Er behandelt, wie Unternehmen den vorgesehenen Einsatz eines Systems mit nachvollziehbaren Anforderungen und Nachweisen absichern.
Die ISPE beschreibt die zweite Ausgabe von Juli 2022 als Fortschreibung, die Grundsätze und Rahmen der ersten Ausgabe beibehält und mehr Gewicht auf kritisches Denken und auf Dienstleister legt. Der Leitfaden ist keine behördliche Zulassung eines Produkts. Die Aussage „GAMP-5-konforme Software“ erklärt daher nicht, welcher Einsatz geprüft wurde und welche Verantwortung beim Betreiber bleibt.
Die Softwarekategorien
GAMP 5 ordnet Software in Kategorien ein. Der Validierungsexperte R. D. McDowall erläutert sie in einer Kolumne der Fachzeitschrift Spectroscopy für die erste Ausgabe von 2008. GAMP 4 kannte noch fünf Kategorien; die Kategorie 2 für Firmware ist entfallen, solche Software wird je nach Art einer der übrigen Kategorien zugeordnet.
| Kategorie | Bezeichnung | Einordnung |
|---|---|---|
| 1 | Infrastruktursoftware | Breit verfügbare Software wie Betriebssysteme, Datenbanken und Bürosoftware; wird qualifiziert |
| 3 | Nicht konfigurierte Produkte | Standardsoftware im Auslieferungszustand; wird validiert |
| 4 | Konfigurierte Produkte | Standardprodukte, die für den Prozess konfiguriert werden; wird validiert |
| 5 | Kundenspezifische Anwendungen | Eigens entwickelte Software; wird validiert |
Zu Kategorie 1 zählt McDowall auch Datenbanken, Programmiersprachen, Statistikwerkzeuge und Tabellenkalkulation. Anwendungen, die mit diesen Paketen gebaut werden, etwa Excel-Vorlagen und Makros, fallen nach dem Leitfaden dagegen je nach Komplexität in Kategorie 3, 4 oder 5. In der Reihenfolge steckt nach McDowall bereits eine Risikoeinschätzung. Kategorie 1 ist am wenigsten riskant, mit steigender Kategorie wird die Software in ihrer Funktion spezieller, und Spezifikation und Test werden umfangreicher.
Eine Kategorie beantwortet aber nicht, welche Konfiguration verwendet wird, welche Schnittstellen Daten verändern oder welche Entscheidung daraus folgt. Ein Standardprodukt kann im konkreten Prozess eine kritische Aufgabe übernehmen. Lieferantendokumente können die Bewertung stützen, wenn sie den Verwendungszweck und die eingesetzte Fassung abdecken; ihre Übernahme braucht eine nachvollziehbare Begründung.
Annex 11 in der Fassung von 2011
Die veröffentlichte Revision 1 von Annex 11 fordert in Abschnitt 1 eine begründete, dokumentierte Risikobewertung. Abschnitt 4.4 verlangt Benutzeranforderungen auf Basis einer Risikobewertung, die über den Lebenszyklus nachverfolgbar bleiben.
Die Europäische Kommission hat eine überarbeitete Fassung von Annex 11 zusammen mit Kapitel 4 und einem neuen Annex 22 zu künstlicher Intelligenz vom 7. Juli bis 7. Oktober 2025 zur Konsultation gestellt. In der Übersicht zu EudraLex Band 4 steht Ende Oktober 2026 weiterhin die Fassung vom Januar 2011.
Eine Anforderung bis zum Test verfolgen
Angenommen, eine Anwendung soll einen Temperaturwert mit Zeitstempel übernehmen. Der Betreiber will erkennen, wenn während eines Zeitabschnitts Werte fehlen. Das Beispiel ist ausgedacht und zeigt einen Arbeitszusammenhang, keine vollständige Validierungsplanung.
| Schritt | Beispiel | Prüfbare Spur |
|---|---|---|
| Benutzeranforderung | Fehlende Messwerte müssen für den vereinbarten Zeitraum erkennbar sein | Kennung UR-07 und definierter Verwendungszweck |
| Risiko | Eine Lücke könnte fälschlich als unauffälliger Verlauf gelesen werden | Bewertung der Auswirkung und ihrer Kontrolle |
| Spezifikation | Fehlende Werte kennzeichnen; Zeitbasis und Lückenkriterium festlegen | Verweis auf UR-07 |
| Test | Übertragung gezielt unterbrechen und anschließend fortsetzen | Sollverhalten, Istverhalten, Datum und Testergebnis |
| Änderung | Zeitbasis oder Auswertungsregel wird verändert | Betroffene Anforderungen und erneut nötige Tests bestimmen |
Ein Test mit ausschließlich vollständigen Daten deckt die Anforderung nicht ab. Der kritische Fall ist die Lücke. Sie muss in der Spezifikation und im Nachweis dieselbe Bedeutung haben.
Auch die Einheit gehört in den Test. Ein plausibel aussehender Zahlenwert kann falsch sein, wenn eine Schnittstelle eine andere Einheit liefert. Bekannte Eingabewerte werden deshalb mit erwarteter Darstellung und Verarbeitung verglichen, und das Ergebnis bleibt dem geprüften Systemstand zugeordnet.
Für Änderungen hilft ein geregelter Change-Control-Prozess. Er hält fest, welcher Stand verändert wird, welche Risiken betroffen sind und welcher Nachweis vor der Nutzung benötigt wird.
Was SYMESTIC dazu beiträgt
Ob ein MES für einen regulierten Nachweis eingesetzt werden darf, hängt vom definierten Einsatz und den dafür geführten Nachweisen ab. SYMESTIC ist ein Cloud-MES für Produktionskennzahlen wie OEE und Stillstände. Für die Bewertung des vorgesehenen Einsatzes zählen zwei Eigenschaften. Rollen und Rechte werden je Modul und Linie vergeben, und zu jeder Prozessrückmeldung führt SYMESTIC eine Änderungshistorie, die festhält, wer wann was geändert hat.
Maschinen werden über digitale Signale ohne Eingriff in die SPS angebunden; dafür nimmt die IoT Box, eine Hardware von SYMESTIC, die Signale an der Maschine ab. Mehr dazu auf der Seite zur Maschinendatenerfassung.
Quellen
- ISPE: GAMP 5, Second Edition
- Spectroscopy: McDowall, GAMP 5 Software Categories, 2009
- Europäische Kommission: EU-GMP Annex 11
- Europäische Kommission: Konsultation zu Kapitel 4, Annex 11 und Annex 22
- Europäische Kommission: EudraLex Band 4, Übersicht
Wie Linien angebunden und Stillstände ausgewertet werden, zeigt die kostenlose Live-Demo am eigenen Anwendungsfall.
Sehen Sie SYMESTIC an Ihrem eigenen Anwendungsfall
In der kostenlosen Live-Demo zeigt Ihnen ein Produktexperte an der laufenden Plattform, wie OEE, Stillstände und die Anbindung Ihrer Maschinen und Ihres ERP konkret aussehen.
- OEE live
- Stillstände und Gründe
- Maschinen und ERP anbinden
