Inhaltsverzeichnis
Das Wichtigste vorab
Wie bewerten wir den Assurance-Bedarf nach einer kleinen Konfigurationsänderung mit möglicher großer Fehlerfolge?
Beschreiben Sie, welches Verhalten sich durch die Änderung verändert und welche früheren Nachweisaussagen dadurch betroffen sind. Prüfen Sie die möglichen Fehlerfolgen, Abhängigkeiten und vorhandenen Kontrollen. Nutzen Sie weiterhin passende Evidenz und ergänzen Sie gezielt die offenen Nachweise. Auch eine kleine Konfigurationsänderung kann eine wesentliche Wirkung haben. Die FDA-CSA-Guidance empfiehlt ein risikobasiertes Vorgehen, aber weder einen pauschalen Vollretest noch eine automatische Ausnahme für kleine Changes.
- Änderungswirkung statt Zeilenzahl oder Ticketgröße beurteilen.
- Betroffene bestehende Funktionen und Datenzustände mitdenken.
- Nutzung des geänderten Stands auf geeignete Evidenz und eine klare Entscheidung stützen.
1. Beschreiben Sie vorheriges und neues Verhalten
Eine technische Änderungsnotiz wie „Operator angepasst“ erklärt nicht, welche fachliche Entscheidung sich verändert. Beschreiben Sie deshalb den bisherigen Ablauf, den gewünschten neuen Ablauf und den Grund der Änderung. Benennen Sie die betroffenen Nutzer, Daten und nachfolgenden Entscheidungen.
Für ein KMU kann eine kurze Gegenüberstellung ausreichen, wenn sie präzise ist. Eine umfangreiche Ticketbeschreibung mit vielen technischen Details hilft wenig, wenn die fachliche Wirkung unklar bleibt. Fragen Sie besonders, ob eine bisherige Kontrolle entfällt, ein Grenzfall anders behandelt wird oder eine manuelle Entscheidung durch automatische Verarbeitung ersetzt wird.
Quellen: [1]
2. Halten Sie Guidance, Anforderungen und Meldefragen getrennt
Die FDA-CSA-Guidance vom 3. Februar 2026 behandelt Produktions- und QMS-Software im Medizinproduktebereich. Ihre Empfehlungen unterstützen ein risikobasiertes Vorgehen innerhalb des einschlägigen QMSR-Rahmens. Sie ersetzen keine verbindlichen Anforderungen und sind nicht pauschal auf Software als Medizinprodukt oder pharmazeutische GMP-Anwendungen übertragbar.
Abschnitt V.A.3 behandelt Änderungen außerdem im Zusammenhang mit bestimmten regulatorischen Einreichungs- beziehungsweise Meldepflichten. Daraus darf keine universelle Frist für jede Softwareänderung abgeleitet werden. Klären Sie solche Fragen getrennt nach Produkt und Zulassungsweg. Die hier dargestellte Arbeitshilfe beantwortet den Assurance-Bedarf einer Änderung, nicht sämtliche möglichen regulatorischen Meldeentscheidungen.
3. Prüfen Sie Abhängigkeiten systematisch
Die eigene Matrix richtet den Blick auf Aussagen, die durch eine Änderung unsicher werden können. Eine unveränderte Funktion kann betroffen sein, wenn sie dieselbe Berechnung oder dieselben Stammdaten nutzt. Ebenso können bereits vorhandene Records anders dargestellt oder verarbeitet werden, ohne dass neue Daten eingegeben wurden.
Erfassen Sie zunächst die plausible Wirkung. Wenn die technische Abhängigkeit unklar ist, markieren Sie diese Lücke und beschaffen Sie die nötige Information. Unbekannt ist nicht gleich unbetroffen. Umgekehrt muss nicht jede theoretisch denkbare Verbindung automatisch einen vollständigen Test aller Funktionen auslösen.
| Blickrichtung | Konkrete Frage | Möglicher Nachweis |
|---|---|---|
| Fachregel | Welche erlaubte oder unzulässige Entscheidung ändert sich? | Gezielte Grenz- und Fehlerfälle |
| Gemeinsame Logik | Welche weiteren Funktionen nutzen denselben Baustein? | Begründete Auswahl betroffener Regression |
| Vorhandene Daten | Werden alte Zustände neu bewertet oder überschrieben? | Vergleich repräsentativer bestehender Records |
| Schnittstelle | Ändern sich Format, Bedeutung oder Reihenfolge? | Übergang und Fehlerbehandlung prüfen |
| Betrieb | Ändern sich Rechte, Arbeitsablauf oder Rückfallweg? | Bereitstellung und Handhabung beurteilen |
Quellen: [1]
4. Illustrativer Fall: eine geänderte Toleranzregel
Ein fiktiver Hersteller verwendet eine Softwarefunktion, die einen gemessenen Abstand mit einer vorgegebenen Toleranz vergleicht. Für diesen Modellfall gilt die fachliche Anforderung: Werte von 9,5 bis 10,5 mm einschließlich beider Grenzen sind zulässig. Eine Konfigurationsänderung ersetzt versehentlich „kleiner oder gleich“ durch „kleiner“. Dadurch wird der obere Grenzwert anders behandelt.
Die folgende Sollmatrix nutzt bewusst Werte unterhalb, auf und oberhalb der Grenzen. Die Zahlen sind frei gewählte Annahmen und keine Spezifikation eines realen Medizinprodukts. Im tatsächlichen Projekt müssen Methode, Messauflösung und fachliche Akzeptanzkriterien feststehen, bevor daraus Prüferwartungen abgeleitet werden.
| Prüfwert | Fachliche Sollentscheidung | Bedeutung für die Änderung | Zusätzlicher Hinweis |
|---|---|---|---|
| 9,4 mm | Nicht zulässig | Untere Außengrenze bleibt erkannt | Keine stille Rundung auf 9,5 voraussetzen |
| 9,5 mm | Zulässig | Untere Grenze eingeschlossen | Konfigurierte Vergleichsregel prüfen |
| 10,0 mm | Zulässig | Wert innerhalb des Bereichs | Allein nicht ausreichend als Grenztest |
| 10,5 mm | Zulässig | Oberer Grenzwert muss eingeschlossen bleiben | Der geänderte Operator würde diese Erwartung verletzen |
| 10,6 mm | Nicht zulässig | Obere Außengrenze bleibt erkannt | Fehlerhafte Erweiterung ebenfalls erkennen |
Quellen: [1]
5. Wählen Sie zusätzliche Prüfungen begründet aus
Die Grenzwertmatrix prüft die konkrete Regel, aber noch nicht jede Verwendung ihres Ergebnisses. Fragen Sie, ob ein nachfolgender Prozess auf den Status zugreift, ob ein Export denselben Wert zeigt und ob gespeicherte frühere Ergebnisse erneut berechnet werden. Wählen Sie daraus die relevanten zusätzlichen Fälle.
Vorhandene passende Nachweise können weiterhin tragen. Wenn etwa eine unabhängige Benutzerverwaltung unverändert ist und keine nachvollziehbare Auswirkung besteht, muss die Toleranzänderung nicht automatisch alle Berechtigungstests auslösen. Dokumentieren Sie die Begründung. Entscheidend ist die Abdeckung der tatsächlichen Wirkung, nicht eine möglichst große oder möglichst kleine Zahl erneut ausgeführter Tests.
Quellen: [1]
6. Behandeln Sie unerwartete Wirkungen als Befund
Zeigt die Prüfung, dass 10,5 mm unzulässig bewertet werden, ist zunächst die Abweichung zur Anforderung festzuhalten. Die Ursache kann in Konfiguration, Implementierung, Testdaten oder einer falsch verstandenen fachlichen Vorgabe liegen. Ändern Sie nicht nachträglich die Erwartung, nur damit der Lauf erfolgreich aussieht.
Bewerten Sie außerdem, ob dieselbe Regel bereits verwendet wurde und welche bisherigen Ergebnisse betroffen sein könnten. Eine Korrektur des Operators beantwortet diese Frage nicht automatisch. Der Abschluss verbindet die Ursache, die Änderung, passende erneute Prüfungen und die Bewertung möglicher früherer Auswirkungen. Eine solche Betrachtung sollte proportional zur konkreten Bedeutung erfolgen.
Quellen: [1]
7. Verbinden Sie Nachweis und tatsächliche Bereitstellung
Ein geeigneter Test in einer Prüfumgebung belegt nicht von selbst, dass genau dieselbe Konfiguration bereitgestellt wurde. Ordnen Sie den geprüften Stand der tatsächlichen Änderung zu. Berücksichtigen Sie, welche Parameter, Daten oder Berechtigungen bei der Übernahme relevant sind und wie eine fehlerhafte Bereitstellung erkannt wird.
Definieren Sie außerdem den Umgang mit Problemen nach der Änderung. Ein Rückfall kann technisch möglich sein, aber bereits verarbeitete Daten oder getroffene Entscheidungen nicht automatisch rückgängig machen. Die Nutzungsentscheidung sollte daher die reale Übergangssituation berücksichtigen. Welche Personen entscheiden, richtet sich nach geregelter Befugnis und Kompetenz; eine pauschale Rollenfolge wird nicht vorgegeben.
8. Checkliste für einen begründeten Änderungsabschluss
Der Abschluss sollte erkennen lassen, welche Funktion geändert wurde, welche bisherigen Aussagen weiter gelten und welche zusätzliche Evidenz entstanden ist. Ein Ticketstatus „erledigt“ genügt nur dann als Teil des Nachweises, wenn die entscheidenden Informationen kontrolliert zugeordnet bleiben.
Die folgende eigene Checkliste kann ein bestehendes Change-Verfahren ergänzen. Sie vermeidet sowohl die unkritische Ausnahme kleiner Änderungen als auch einen automatischen Vollretest. Beide Extreme können die eigentliche Frage verdecken: Ist der geänderte Stand für den vorgesehenen Einsatz ausreichend abgesichert?
- Vorheriges und neues Verhalten fachlich beschrieben.
- Produkt- und Softwarescope sowie separate Meldefragen eingeordnet.
- Mögliche Fehlerfolgen und tragende Kontrollen bewertet.
- Abhängigkeiten und bestehende Daten berücksichtigt.
- Übernommene Evidenz und zusätzliche Prüfungen begründet.
- Befunde einschließlich möglicher früherer Auswirkungen bearbeitet.
- Geprüften und bereitgestellten Stand mit Nutzungsentscheidung verbunden.
Quellen: [1]
Häufige Fragen zu FDA CSA: Softwareänderungen nach ihrer Wirkung absichern
Ist eine Ein-Zeilen-Änderung automatisch geringfügig?
Nein. Ein einzelner Operator kann eine wichtige Entscheidung verändern. Beurteilen Sie das betroffene Verhalten und seine mögliche Folge. Die technische Größe des Changes kann bei der Planung helfen, ersetzt aber keine fachliche Auswirkungsbewertung.
Quellen: [1]
Müssen wir nach jedem Update vollständig neu validieren?
Nicht pauschal. Prüfen Sie, welche bisherigen Aussagen betroffen sind und welche Nachweise weiterhin tragen. Zusätzliche Aktivitäten sollten die relevanten Lücken schließen. Unklare Abhängigkeiten müssen geklärt werden, statt sie automatisch als folgenlos oder als Anlass für sämtliche Tests zu behandeln.
Quellen: [1]
Sind Konfigurationsänderungen weniger wichtig als Programmcode?
Nicht grundsätzlich. Konfiguration kann Berechnungen, Berechtigungen oder automatische Entscheidungen steuern. Ihre Wirkung kann daher wesentlich sein. Bewerten Sie die konkrete Funktion und den vorgesehenen Einsatz; die technische Änderungsart allein bestimmt den Assurance-Bedarf nicht.
Quellen: [1]
Warum reichen Werte mitten im zulässigen Bereich nicht aus?
Sie zeigen nicht, ob die Grenzen richtig behandelt werden. Im Beispiel würde 10,0 mm auch bei der fehlerhaften Änderung erfolgreich sein. Erst der Wert 10,5 mm macht den Unterschied zwischen eingeschlossener und ausgeschlossener Obergrenze sichtbar.
Quellen: [1]
Dürfen wir die Erwartung nach einem fehlgeschlagenen Test ändern?
Ja, wenn die ursprüngliche Prüferwartung nachweislich falsch war oder eine fachlich begründete Anforderungsänderung vorliegt. Halten Sie ursprüngliches Soll, Befund, Korrekturgrund und erforderliche erneute Prüfung nachvollziehbar fest. Die Erwartung nur dem beobachteten Ergebnis anzupassen, erzeugt keinen geeigneten Nachweis.
Quellen: [1]
Was passiert mit vorhandenen Daten nach einer Regeländerung?
Prüfen Sie, ob sie unverändert bleiben, neu dargestellt oder erneut verarbeitet werden. Diese Wirkung kann die Bewertung früherer Ergebnisse beeinflussen. Eine erfolgreiche Prüfung neuer Eingaben beantwortet die Frage nach alten Records nicht automatisch.
Quellen: [1]
Muss der Lieferant alle nötigen Nachweise liefern?
Lieferanteninformationen können wesentlich beitragen. Prüfen Sie deren tatsächliche Abdeckung für Ihre Konfiguration und Nutzung. Verbleibende eigene Prozess- oder Übergangsfragen müssen geklärt werden. Eine allgemeine Release-Notiz ersetzt nicht automatisch die konkrete Auswirkungsbewertung.
Quellen: [1]
Gibt es eine allgemeine 30-Tage-Frist für Softwareänderungen?
Eine solche universelle Regel wird aus CSA nicht abgeleitet. Die Guidance behandelt bestimmte produkt- und zulassungsbezogene Meldekontexte. Ob eine Änderung eine Einreichung oder Meldung auslöst, muss getrennt anhand des zutreffenden regulatorischen Rahmens beurteilt werden.
Quellen: [1]
Ist ein technisch erfolgreicher Rollback ausreichend?
Er kann Teil eines Rückfallkonzepts sein, beantwortet aber nicht automatisch die Folgen bereits verarbeiteter Daten oder Entscheidungen. Prüfen Sie den Zustand nach Rücknahme und gegebenenfalls nötige Korrekturen. Die fachliche Wirkung ist ebenso wichtig wie die technische Wiederherstellung.
Quellen: [1]
Wie dokumentieren kleine Teams die Entscheidung sinnvoll?
Nutzen Sie eine kompakte Zuordnung von Änderung, Wirkung, vorhandener Evidenz, zusätzlichen Prüfungen und Schlussfolgerung. Verweisen Sie auf erhaltene Details. So bleibt die Entscheidung nachvollziehbar, ohne dieselben Informationen in mehreren unverbundenen Berichten zu wiederholen.
Quellen: [1]
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.
- FDA: Computer Software Assurance for Production and Quality Management System SoftwareFinal Guidance 03.02.2026; nicht bindende Empfehlungen für Produktions-/QMS-Software im Medizinproduktebereich.
- 21 CFR Part 820 – Quality Management System RegulationAktueller QMSR-Text; seit 02.02.2026 wirksam. §§820.1,820.7,820.10,820.35,820.45.
Zuletzt fachlich geprüft am 07.10.2026.
Daniel Herrmann Consulting
Den konkreten Nachweisprozess gemeinsam bearbeiten
Wir unterstützen Sie dabei, eine konkrete Softwareänderung abzugrenzen, passende Nachweise auszuwählen und die Nutzungsentscheidung nachvollziehbar zu dokumentieren.
- 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.