Inhaltsverzeichnis
Das Wichtigste vorab
Wie beeinflusst fehlendes Erfahrungswissen den Umfang unserer Absicherung einer neuen Funktion?
Beginnen Sie mit dem vorgesehenen Einsatz und den möglichen Fehlerfolgen. Halten Sie fest, welches Verhalten belegt ist und wo Erfahrung oder belastbare Daten fehlen. Leiten Sie daraus gezielte Prüfungen, begrenzte Einsatzbedingungen und Kriterien für eine spätere Erweiterung ab. Neuheit allein bestimmt weder eine feste GAMP-Kategorie noch einen pauschalen Testumfang. Bei GMP-Anwendungen tragen Annex 11 und risikobasierte Qualitätsentscheidungen die regulatorische Einordnung.
- Unsicherheit getrennt von Schadensschwere und vorhandenen Kontrollen dokumentieren.
- Lieferantennachweise auf die tatsächlich neue Funktion und Umgebung beziehen.
- Erfahrungsaufbau mit überprüfbaren Grenzen und klarer Erweiterungsentscheidung verbinden.
1. Benennen Sie, was tatsächlich neu ist
Eine neue Versionsnummer ist nicht automatisch eine neue Technologie. Umgekehrt kann eine kleine Erweiterung einen bisher nicht geprüften Entscheidungsweg eröffnen. Beschreiben Sie die Änderung auf Funktionsebene: Eingangsdaten, Verarbeitung, Ergebnis, Nutzer und Folgeentscheidung. Notieren Sie auch, welche bisherigen Kontrollen entfallen oder ihre Wirkung verändern.
Für ein KMU hilft eine konkrete Frage: Würden die bisherigen Nachweise denselben Fehler im neuen Ablauf erkennen? Wenn etwa eine manuelle Sichtung durch eine automatische Sortierung ersetzt wird, ist nicht nur die Sortierfunktion relevant. Auch die Sichtbarkeit zurückgestellter Fälle und die Verantwortung für deren Bearbeitung ändern sich. Diese Auswirkungen gehören in die Betrachtung, selbst wenn die Plattform bereits lange genutzt wird.
2. Trennen Sie GAMP-Methodik und anwendbare Anforderungen
Die öffentliche Beschreibung der zweiten GAMP-5-Ausgabe betont kritisches Denken, geeignete Methoden, Werkzeuge und den Umgang mit neuen Technologien. Sie ist keine Rechtsvorschrift und belegt keine obligatorische Dokumentvorlage. Der öffentliche Zugang ersetzt auch nicht den vollständigen Leitfaden, wenn Ihr Unternehmen dessen Detailmethodik verbindlich einsetzen will.
Für Computersysteme im hier angenommenen Humanarzneimittel-GMP-Einsatz beschreibt Annex 11 einen risikobasierten Lebenszyklus und einen begründeten Validierungsumfang. ICH Q9(R1) behandelt unter anderem Unsicherheit und die angemessene Formalität des Risikomanagements. Beide Perspektiven helfen bei der Entscheidung; ein neuer Produktname liefert dagegen weder einen Risikowert noch eine automatische Zuordnung zu einer Softwarekategorie.
3. Führen Sie eine Wissenslückenmatrix
Die folgende eigene Arbeitshilfe trennt Fragen, die häufig vermischt werden. Ein bekannter Fehler mit schwerer Folge braucht wirksame Kontrollen. Eine unklare Fehlerhäufigkeit braucht Erkenntnisgewinn. Ein noch nicht belegter Lieferantenclaim braucht eine passende Quelle oder eigene Prüfung. Eine einzige Ampelfarbe macht diese Unterschiede nicht ausreichend sichtbar.
Formulieren Sie jede Lücke so, dass sie geschlossen werden kann. Aus „zu wenig Erfahrung“ wird beispielsweise „Verhalten bei zwei gleichzeitig bearbeiteten Fällen unbekannt“. Hinterlegen Sie einen Verantwortlichen und ein erwartetes Ergebnis. Die Tabelle ist keine vorgeschriebene GAMP-Vorlage.
| Aspekt | Bereits bekannt | Noch offen | Nächster Nachweis |
|---|---|---|---|
| Dateneingang | Bisherige Formatprüfung belegt | Wie verhält sich der Import bei leeren Pflichtfeldern der neuen Quelle? | Gezielte Importfälle mit fehlenden Werten |
| Bearbeitung | Einzelbearbeitung nachvollziehbar | Gleichzeitige Änderungen unbekannt | Konkurrierende Bearbeitung mit Zustandsvergleich |
| Entscheidung | Manuelle Prüfung vorgesehen | Bleiben zurückgestellte Fälle im tatsächlichen Arbeitsablauf sichtbar? | Sichtbarkeit und Arbeitsablauf prüfen |
| Betrieb | Supportweg vorhanden | Reaktion auf neue Fehlerklasse unklar | Verantwortung und Eskalation durchspielen |
4. Wählen Sie Evidenz passend zur offenen Frage
Lieferantenunterlagen können relevante Erfahrung und Prüfungen enthalten. Prüfen Sie Version, Konfiguration, Datenbedingungen und behauptete Funktion. Eine belastbare Prüfung des tatsächlich verwendeten Moduls kann mehr beitragen als eine breite Zertifikatsliste. Dokumentieren Sie, welche Frage bereits beantwortet ist und welche Abweichung zu Ihrem Einsatz verbleibt.
Ergänzende eigene Tests sollten diese Restlücke treffen. Mehr Wiederholungen desselben einfachen Falls zeigen nicht automatisch mehr über einen unbekannten Grenzfall. Kombinieren Sie gezielte Grenzprüfungen, die Beobachtung typischer Arbeitsabläufe und eine unabhängige Ergebnisbewertung. Für schwer erkennbare Fehler sind außerdem erkennbare Störungen und ein handhabbarer Rückfallweg wichtig. Umfang und Tiefe bleiben begründete Projektentscheidungen.
5. Illustrativer Fall: Vorschläge zur Dokumentzuordnung
Ein fiktives Team möchte eine neue Funktion einsetzen, die eingehende Dokumente vorhandenen Vorgängen zuordnet. Sie darf zunächst nur Vorschläge erzeugen; die Annahme durch einen berechtigten Mitarbeiter bleibt Voraussetzung für die verbindliche Zuordnung. Diese Grenze ist eine ausdrückliche Annahme des Beispiels und muss technisch wie organisatorisch geprüft werden.
Die eigene Sollprüfung umfasst 30 vorbereitete Dokumente: 18 eindeutig zuordenbare, acht bewusst mehrdeutige und vier mit fehlender Vorgangskennung. Damit gilt 18 + 8 + 4 = 30. Die erwartete Reaktion folgt der vorher definierten Anforderung, nicht einer nachträglich passend gewählten Erfolgsquote. Die Zahlen sind kein statistischer Wirksamkeitsnachweis.
| Gruppe | Anzahl | Erwartetes Verhalten | Zusätzlicher Prüfpunkt |
|---|---|---|---|
| Eindeutig | 18 | Passenden Vorschlag anzeigen; keine automatische Buchung | Annahme und Vorgang nachvollziehbar |
| Mehrdeutig | 8 | Mehrdeutigkeit sichtbar; keine verdeckte Vorauswahl | Auswahl und Verwerfen möglich |
| Kennung fehlt | 4 | Klärungsbedarf; keine erfundene Zuordnung | Datensatz bleibt auffindbar |
| Gesamtabgleich | 30 | 30 Eingänge im nachvollziehbaren Bearbeitungsbestand | 18 + 8 + 4; keine Verluste oder Doppelungen |
6. Legen Sie Einsatzgrenzen vor dem Pilot fest
Ein Pilot ist keine allgemeine Ausnahme von erforderlichen Kontrollen. Entscheidend ist, ob die Funktion bereits für regulierte Entscheidungen verwendet wird. Benennen Sie daher die zulässigen Daten, Nutzer, Entscheidungen und Übergänge. Ein rein beobachtender Parallelbetrieb hat andere Auswirkungen als ein Pilot, dessen Ergebnisse die tatsächliche Bearbeitung steuern.
Im Beispiel darf eine spätere automatische Zuordnung nicht unbemerkt durch eine Einstellung aktiviert werden. Die Erweiterung verändert den Einsatzzweck und die verbleibende menschliche Kontrolle. Vorher sind die betroffenen Anforderungen, Fehlerfolgen und Nachweise erneut zu beurteilen. Eine gute Beobachtungsphase liefert dafür Erkenntnisse, ersetzt aber nicht die Entscheidung über den erweiterten Funktionsumfang.
7. Nutzen Sie Betriebserfahrung mit nachvollziehbaren Kriterien
Definieren Sie, welche Beobachtungen eine erneute Bewertung auslösen: unbemerkte Fehlzuordnungen, nicht bearbeitbare Eingänge, neue Datenformate oder eine geänderte Nutzergruppe. Erfassen Sie nicht nur die Zahl der Meldungen, sondern auch deren Entdeckungsweg. Wenige gemeldete Fehler können sowohl gute Leistung als auch geringe Erkennbarkeit bedeuten.
Die Sichtung sollte zu einer Entscheidung führen: Grenze beibehalten, Kontrolle verbessern, zusätzliche Prüfung durchführen oder Funktion erweitern. Für ein kleines Team genügt häufig eine übersichtliche Liste mit Befund, Auswirkung, Maßnahme und Abschlussnachweis. Der Reviewumfang richtet sich nach dem System und seinem Risiko; ein pauschales monatliches oder jährliches Intervall wird hier nicht abgeleitet.
8. Checkliste für die begründete Nutzungsentscheidung
Schließen Sie die Bewertung mit einer konkreten Aussage über die freigegebene Nutzung ab. Ein Dokument mit vielen Testfällen hilft wenig, wenn unklar bleibt, welche neue Funktion unter welchen Bedingungen eingesetzt werden darf. Die folgende Checkliste ist eine eigene Arbeitshilfe für die Zusammenführung der Entscheidung.
Offene Punkte sollten nicht durch „wird im Betrieb beobachtet“ verschwinden. Beschreiben Sie die verbleibende Unsicherheit, ihre Bedeutung und die wirksame Begrenzung. Wenn die entscheidungsrelevante Funktion unter den vorgesehenen Bedingungen nicht ausreichend belegt ist, muss die Nutzung entsprechend eingeschränkt oder bis zur Klärung zurückgestellt werden.
- Neuartigkeit auf Funktion, Daten und Folgeentscheidung eingegrenzt.
- Evidenz mit Version und Einsatzbedingungen zugeordnet.
- Wissenslücken und Fehlerfolgen getrennt beschrieben.
- Restprüfungen und erwartete Ergebnisse festgelegt.
- Pilotgrenzen, Rückfallweg und Zuständigkeit umsetzbar.
- Auslöser für erneute Bewertung benannt.
- Zulässigen Einsatz und offene Punkte dokumentiert.
Häufige Fragen zu GAMP 5: Neue Technologien risikobasiert absichern
Ist eine neue Technologie automatisch besonders risikoreich?
Nein. Neuheit kann die Unsicherheit erhöhen, sagt aber allein wenig über die mögliche Folge eines Fehlers. Beurteilen Sie Einsatz, Datenwirkung und vorhandene Kontrollen. Eine neue Hilfsfunktion ohne Entscheidungswirkung kann anders zu behandeln sein als eine bekannte Funktion, die eine kritische Entscheidung ohne zusätzliche Kontrolle ausführt.
Verlangt GAMP 5 für neue Technologien immer Kategorie 5?
Eine solche pauschale Ableitung ist nicht begründet. Produktname, Neuheit und Softwarekategorie sind verschiedene Fragen. Betrachten Sie die eingesetzten Komponenten und Anpassungen. Der Validierungsumfang ergibt sich zusätzlich aus vorgesehenem Einsatz, Risiko und vorhandener Evidenz; die öffentliche ISPE-Beschreibung ersetzt keine vollständige Kategorienmethodik.
Wie beschreiben wir fehlendes Erfahrungswissen konkret?
Formulieren Sie eine prüfbare Unbekannte: etwa das Verhalten bei paralleler Bearbeitung oder bei fehlender Kennung. Ergänzen Sie deren Bedeutung und den passenden Erkenntnisschritt. „Das Produkt ist neu“ ist als Ausgangspunkt hilfreich, aber für die Auswahl eines konkreten Tests zu ungenau.
Reicht das Validierungspaket des Lieferanten?
Das hängt von seiner tatsächlichen Abdeckung ab. Vergleichen Sie Funktion, Version, Konfiguration und Einsatzbedingungen mit Ihrem Vorhaben. Übernehmen Sie passende Nachweise begründet und schließen Sie verbleibende Lücken gezielt. Weder pauschale Ablehnung aller Lieferantentests noch ungeprüfte vollständige Übernahme beantwortet die konkrete Nutzungsfrage.
Quellen: [1]
Dürfen wir zunächst nur einen begrenzten Pilot durchführen?
Ein begrenzter Einsatz kann sinnvoll sein, wenn seine Auswirkungen und Kontrollen geklärt sind. Ein Pilot, dessen Ergebnisse bereits regulierte Entscheidungen beeinflussen, braucht dafür geeignete Absicherung. Benennen Sie erlaubte Daten und Entscheidungen sowie Bedingungen, unter denen der Pilot gestoppt oder erweitert wird.
Beweisen 30 erfolgreiche Testfälle die Zuverlässigkeit?
Nicht allgemein. Die 30 Fälle des Beispiels prüfen bewusst gewählte Anforderungen und Randbedingungen. Sie sind weder eine universelle Mindestzahl noch ein statistischer Zuverlässigkeitsnachweis. Aussagekräftig ist, welche relevante Frage jeder Fall beantwortet und welche Unsicherheit nach dem Test noch bestehen bleibt.
Muss jede Wissenslücke durch einen eigenen Test geschlossen werden?
Nicht zwingend. Eine passende Lieferantenprüfung, belastbare technische Beschreibung oder nachweisbar wirksame Begrenzung kann ebenfalls beitragen. Die Entscheidung muss zur offenen Frage passen. Für eine konkrete kritische Funktion reicht eine allgemeine Produktbroschüre regelmäßig nicht als Nachweis des vorgesehenen Verhaltens.
Wann ist zusätzliche Betriebserfahrung ausreichend?
Erfahrung ist hilfreich, wenn Bedingungen, Beobachtung und Aussagegrenzen bekannt sind. Eine niedrige Fehlermeldezahl allein genügt nicht. Prüfen Sie auch, ob Fehler erkannt werden könnten und ob die beobachteten Daten Ihren künftigen Einsatz abdecken. Eine Erweiterungsentscheidung braucht eine begründete Gesamtbewertung.
Wer sollte die Entscheidung vorbereiten?
Benötigt werden Kenntnisse über Fachprozess, technische Funktion und geltende Qualitätsanforderungen. Welche Personen entscheiden dürfen, regelt Ihr Unternehmen passend zum Einsatz. Eine feste, für alle Organisationen identische Unterschriftenkombination lässt sich aus der hier beschriebenen Methode nicht ableiten.
Quellen: [1]
Gilt diese Vorgehensweise auch außerhalb von GMP?
Die Arbeitshilfe lässt sich übertragen, die zitierten Anforderungen nicht automatisch. Für klinische Studien, Medizinprodukte oder nicht regulierte Tätigkeiten müssen Sie den Rahmen gesondert bestimmen. GAMP ist eine Branchenmethodik; die regulatorischen Beispiele betreffen ausdrücklich Computersysteme im Humanarzneimittel-GMP-Einsatz.
Quellen & fachlicher Stand
Quellenstand 7. Oktober 2026. Behördenvorschriften, Leitlinien und Branchenmethodik sind getrennt einzuordnen. Tabellen, Zahlen und Fälle sind eigene illustrative Arbeitshilfen; keine ausgeführten Produktprüfungen oder Kundenergebnisse.
- EU-GMP Annex 11 – Computerised SystemsRevision Januar 2011; im Humanarzneimittelabschnitt gelistet. Principle, §§1–17.
- EMA: ICH Q9(R1) – Quality Risk Management, Corr.2EMA-Fassung 23.01.2025, Corr.2; fachlich R1, EU-Anwendung seit 26.07.2023. §§1–6, besonders 4.3,5.1–5.3.
- ISPE: GAMP 5 Guide, 2nd EditionÖffentliche Herausgeberbeschreibung und Editionsangabe; kein Zugriff auf kostenpflichtigen Volltext.
Zuletzt fachlich geprüft am 07.10.2026.
Daniel Herrmann Consulting
Den konkreten Nachweisprozess gemeinsam bearbeiten
Wir unterstützen Ihr Team dabei, eine neue Funktion fachlich abzugrenzen, vorhandene Nachweise einzuordnen und die verbleibenden Prüfentscheidungen nachvollziehbar zu treffen.
- IT-GxP-Audit →
Anforderungen, vorhandene Nachweise und relevante Lücken beurteilen.
- IT-GxP-Consulting →
Vereinbarte Bewertungs-, Dokumentations- und Testarbeit im Projekt bearbeiten.
- IT-GxP-Coaching →
Ihr Team bei konkreten Entscheidungen und der Anwendung eigener Verfahren begleiten.
- IT-GxP-Compliance-Programm →
Passende interne Verfahren, Vorlagen und Schulung aufbauen.