GAMP 5 vs CSA: Methode und FDA-Geltungsbereich trennen

Drei Ebenen verhindern einen Scheinkonflikt

Trennen Sie den regulatorischen Rahmen, die gewählte Branchenmethodik und Ihren betrieblichen Ablauf. Eine Rechts- oder Aufzeichnungsanforderung beantwortet eine andere Frage als ein Leitfaden zur Durchführung. Ihre SOP beschreibt schließlich, wie das Unternehmen Entscheidungen trifft und dokumentiert.

Ein sauberer Projektstart hält diese Zuordnung ausdrücklich fest. So wird aus „Wir machen jetzt CSA“ eine prüfbare Aussage darüber, welche Softwarefunktion betrachtet wird, welcher Regelbereich betroffen ist und welches Nachweiskonzept das Team verwendet.

Quellen: [1] [2]

FDA CSA 2026 im tatsächlichen Anwendungsbereich lesen

Die aktuelle FDA-Guidance ist vom 3. Februar 2026 und betrifft Produktions- und QMS-Software für Medizinprodukte. Ihr Scope unterscheidet diese Nutzung von Softwarefunktionen, die selbst als Medizinprodukt einzustufen sind. Der Pharmahersteller erhält damit keine pauschale Ablösung seiner GMP-Anforderungen.

Beispielsweise kann eine identische Dokumentenplattform verschiedene Zwecke unterstützen: einen Medizinprodukte-QMS-Prozess, einen Humanarzneimittel-GMP-Prozess oder rein organisatorische Zusammenarbeit. Die Produktmarke der Plattform entscheidet diese Zuordnung nicht. Bei gekoppelten Abläufen müssen auch relevante Abhängigkeiten berücksichtigt werden.

Quellen: [2] [3]

Was Sie tatsächlich vergleichen sollten

Die folgende Orientierung vergleicht Rollen und Arbeitsfragen. Sie ist kein Ranking der besseren Methode. Eine zeilenweise Gleichsetzung von Begriffen kann Unterschiede verdecken; eine Zuordnung sollte daher immer erläutern, welcher Entscheid damit unterstützt wird.

Quellen: [1] [2]

Die Fehlerfolge ist konkreter als das Softwareetikett

Formulieren Sie eine mögliche Fehlentscheidung im Prozess. „Das QMS ist kritisch“ ist zu grob. Präziser wäre: Eine geänderte Spezifikation könnte vor ihrer fachlichen Freigabe in die Fertigung gelangen. Daraus werden betroffene Daten, Schutzmechanismen und notwendige Beobachtungen ableitbar.

Behandeln Sie eine GAMP-Kategorie nicht als Ersatz für diese Beschreibung. Auch „Low Code“, „Standardsoftware“ oder die Größe eines Änderungspakets sagen allein wenig darüber aus, welche Folge ein Fehler hat. Das Team sollte erklären können, welche Unsicherheit der geplante Nachweis tatsächlich reduziert.

Quellen: [3] [4]

Illustratives Beispiel: Ein Spezifikationsworkflow

Ein fiktiver Medizinproduktehersteller verwendet eine elektronische Spezifikation. Vor der Prüfung wird festgelegt: Nur die genehmigte Revision darf im Produktionsauftrag ausgewählt werden. Ein Entwurf bleibt gesperrt, und ein bereits erzeugter Auftrag darf seine dokumentierte Revisionszuordnung nicht unbemerkt verlieren. Das ist eine eigene Sollbeschreibung, kein Hersteller- oder Kundentest.

Für dieses Beispiel soll der Anbietertest die allgemeine Versionsanzeige abdecken. Ob er die eigene Rollenregel und Auftragsanbindung ebenfalls belegt, wird erst anhand seines Inhalts entschieden. Die folgende Matrix zeigt mögliche ergänzende Prüfungen; sie behauptet keine universelle Testliste.

Quellen: [2]

Die Testmethode dem Erkenntnisziel zuordnen

Ein gezielter Sollvergleich ist für eine präzise Revisionsregel zweckmäßig. Ein explorativer Test kann zusätzliche Umgehungswege sichtbar machen. Automatisierte Prüfungen können wiederholbare Sachverhalte abdecken, sofern deren Eignung und Auswertung beurteilt werden. Keine dieser Formen ist allein wegen ihres Namens ausreichend.

Eine starre Regel „hohes Risiko immer geskriptet, geringes Risiko immer ungeskriptet“ verkürzt die Entscheidung. Beschreiben Sie stattdessen, warum die Kombination aus Prüfung, vorhandener Evidenz und Prozesskontrolle das konkrete Risiko angemessen behandelt. Unerwartete Befunde benötigen eine nachvollziehbare Bewertung und gegebenenfalls zusätzliche Arbeit.

Quellen: [2] [3]

Das tatsächliche Lieferpaket ist maßgeblich

Ein Lieferant kann allgemeine Plattformtests, konfigurationsbezogene Prüfungen oder auch kundenspezifische Nachweise bereitstellen. Die Bezeichnung „Validierungspaket“ sagt nicht, welche Ihrer Anforderungen darin enthalten sind. Ebenso wenig darf vorab angenommen werden, das Paket decke nur Standardfunktionen ab.

Für jede übernommene Aussage sollten Gegenstand, Stand, Ergebnis und Übertragungsbedingungen erkennbar sein. Fehlende Schnittstellen-, Rollen- oder Fehlerfälle werden gezielt ergänzt. Der Aufwand folgt den offenen Fragen; er wird nicht aus der Anzahl gelieferter Dokumente oder einer pauschalen Wiederholungsquote berechnet.

Quellen: [2] [3]

Ein kleines Team braucht eine gemeinsame Entscheidungsgrundlage

QA ordnet Anforderungen und akzeptable Evidenz ein. Fachverantwortliche beschreiben Folgen einer Fehlfunktion. IT und Anbieter erklären Konfiguration und Datenwege. Eine gemeinsame Fallbesprechung an einem vorhandenen Prozess ist häufig hilfreicher als eine abstrakte Schulung mit zwei konkurrierenden Begriffswelten.

Vor einer breiten Einführung sollte klar sein, wie die neue Arbeitsweise in Ihre Verfahren passt. Wenn die bestehende SOP bestimmte Nachweise vorsieht, wird sie kontrolliert angepasst oder weiter angewendet. Eine neue Überschrift im Projektplan ändert die internen Regeln nicht von selbst.

• Regelbereich und konkrete Funktion dokumentieren.
• Fehlerfolge und vorhandene Kontrollwirkung beschreiben.
• Lieferantenbelege mit eigenen Anforderungen vergleichen.
• Prüfmethode und verbleibende Unsicherheit begründen.
• Befunde, Abschlussentscheidung und spätere Änderungsbewertung nachvollziehbar halten.

Quellen: [3] [2]