Inhaltsverzeichnis
Das Wichtigste vorab
Welche Entscheidung und Befunde muss unser Assurance-Nachweis nachvollziehbar machen?
Dokumentieren Sie den vorgesehenen Einsatz, das Ergebnis der Risikobeurteilung, die Assurance-Aktivitäten, wesentliche Ergebnisse und gefundene Probleme. Die Schlussfolgerung muss erklären, ob die Funktion für diesen Einsatz akzeptabel ist und wie Befunde gelöst oder vertretbar behandelt wurden. Ordnen Sie die Evidenz den beteiligten Personen, dem Zeitpunkt und dem geprüften Stand zu. Die FDA empfiehlt dafür keinen universellen Berichtstyp; passende digitale Nachweise können Bestandteil des Records sein.
- Der Record trägt eine begründete Entscheidung, nicht nur eine Testzählung.
- Offene Befunde und ihre Behandlung müssen in der Schlussfolgerung sichtbar bleiben.
- Vorhandene digitale Evidenz gezielt verknüpfen statt unnötig doppelt dokumentieren.
1. Schreiben Sie für eine konkrete Nutzungsentscheidung
Der Ausgangspunkt ist eine verständliche Aussage darüber, was die Funktion tun soll. „Das System wurde getestet“ ist zu allgemein. Beschreiben Sie etwa, dass ein berechtigter Nutzer eine Reklamation mit bestimmten Pflichtangaben erfassen und an den zuständigen Bearbeiter übergeben können soll. Grenzen gehören dazu: Welche Entscheidungen trifft die Anwendung nicht?
Die FDA-CSA-Guidance vom 3. Februar 2026 behandelt Produktions- und QMS-Software im Medizinproduktebereich. Ihre Empfehlungen zur Aufzeichnung unterstützen die Erfüllung anwendbarer Anforderungen; sie sind kein eigenständiges Gesetz und kein vollständiger Compliancekatalog. Ein Record muss zum tatsächlichen Einsatz passen, nicht nur ein vorgegebenes Formular vollständig füllen.
2. Verbinden Sie die wesentlichen Informationselemente
Abschnitt V.A.6 der Guidance beschreibt die Informationen, die eine nachvollziehbare Assurance-Aufzeichnung tragen sollen. Dazu gehören Einsatzzweck, Risikobeurteilung, Aktivitäten, Probleme, Schlussfolgerung sowie Angaben zur Durchführung. Eine festgelegte Prüfung und Genehmigung ist zu berücksichtigen, soweit sie im konkreten Zusammenhang angemessen ist.
Die eigene Matrix übersetzt diese Elemente in praktische Fragen. Sie ist keine vorgeschriebene FDA-Vorlage. Die Informationen dürfen in mehreren kontrolliert verbundenen Objekten liegen. Entscheidend ist, dass ein späterer Leser die Aussage ohne mündliches Projektwissen nachvollziehen kann und die erforderlichen Detailnachweise verfügbar sind.
| Element | Konkrete Frage | Typischer schwacher Eintrag |
|---|---|---|
| Einsatzzweck | Welche Funktion unter welchen Bedingungen? | Standardsoftware validiert |
| Risiko | Welche Fehlerfolge trägt die Nachweistiefe? | Risiko niedrig ohne Begründung |
| Aktivität | Was wurde mit welcher Grundlage untersucht? | Test erfolgreich |
| Befunde | Was wurde gefunden und wie behandelt? | Keine kritischen Punkte ohne Befundbezug |
| Schlussfolgerung | Welche Nutzung ist auf dieser Grundlage akzeptabel? | Freigegeben ohne Umfang |
| Zuordnung | Wer, wann, welcher Stand und welche Evidenz? | Link auf überschriebenen Sammelordner |
Quellen: [1]
3. Machen Sie den geprüften Stand identifizierbar
Ein Ergebnis braucht eine erkennbare Grundlage. Abhängig von der Anwendung können Version, Konfiguration, Schnittstellenstand und verwendete Daten relevant sein. Wenn ein Test nur in einer abweichenden Umgebung möglich war, benennen Sie diese Abweichung und ihre Bedeutung. Ein identischer Produktname allein belegt keine identischen Bedingungen.
Verknüpfen Sie außerdem übernommene Lieferantennachweise mit der konkreten Aussage, die sie tragen. Nicht jedes Dokument muss vollständig kopiert werden. Es muss aber klar sein, welche Evidenz tatsächlich beurteilt wurde und welche Grenzen verbleiben. Ein bloßer Link auf das allgemeine Herstellerportal ist dafür häufig nicht ausreichend, insbesondere wenn sich dessen Inhalte laufend ändern.
Quellen: [1]
4. Illustrativer Fall: ein Record für eine Pflichtfeldprüfung
Ein fiktiver Hersteller ergänzt in seiner Reklamationsanwendung ein Pflichtfeld für die betroffene Produktkennung. Die Funktion soll unvollständige Fälle nicht als vollständig bearbeitbar weiterleiten. Im angenommenen Prozess erfolgt die sicherheitsbezogene Beurteilung separat; diese Voraussetzung gehört ausdrücklich zur Risikobegründung.
Die folgende eigene Sollaufzeichnung zeigt, wie ein Befund mit der Schlussfolgerung verbunden wird. Für das Beispiel wird angenommen, dass eine erste Prüfung eine Umgehung über den Import entdeckt und eine anschließende Korrektur mit passenden Nachweisen belegt wird. Das ist ein durchgearbeiteter Modellfall, kein Bericht über einen tatsächlich ausgeführten Kundentest.
| Feld | Beispielinhalt | Kommentar zur Aussage |
|---|---|---|
| Zweck und Grenze | Produktkennung bei manueller Erfassung und Import erforderlich; keine automatische Sicherheitsentscheidung | Beide Eingangswege gehören zum Umfang |
| Risiko | Unvollständige Zuordnung verzögert Bearbeitung; separate Sicherheitsbeurteilung bleibt wirksam | Kontrollannahme im echten Projekt belegen |
| Aktivitäten | Vollständige und unvollständige Datensätze über beide Wege prüfen | Prüfung richtet sich auf die tatsächliche Regel |
| Befund | Manuelle Erfassung verhindert Weiterleitung; Import umgeht zunächst Pflichtfeld | Kein pauschaler Gesamterfolg |
| Behandlung | Importregel korrigiert; betroffene Fälle erneut geprüft; Ergebnisse zugeordnet | Korrektur und Nachweis gehören zusammen |
| Schlussfolgerung | Nutzung der beschriebenen Pflichtfeldfunktion im korrigierten Stand akzeptabel, wenn die genannten Nachweise vorliegen | Keine Freigabe aller sonstigen Reklamationsfunktionen |
Quellen: [1]
5. Begründen Sie die Behandlung offener Punkte
Nicht jeder Befund hat dieselbe Bedeutung. Beschreiben Sie, welche Funktion betroffen ist, welche Folge möglich ist und ob eine geeignete Korrektur oder Kontrolle vorliegt. Der Record sollte erkennen lassen, weshalb die verbleibende Nutzung akzeptabel ist oder weshalb die Entscheidung zurückgestellt wird.
Eine allgemeine Formulierung wie „keine kritischen Fehler“ ist schwach, wenn die Kriterien oder die zugehörigen Befunde fehlen. Im Beispiel wäre der Importweg Teil der Anforderung und könnte nicht ohne Begründung aus dem Abschluss verschwinden. Falls seine Nutzung zunächst ausgeschlossen wird, muss diese Einschränkung wirksam umgesetzt und in der Schlussfolgerung ausdrücklich benannt werden.
Quellen: [1]
6. Nutzen Sie digitale Evidenz mit ausreichendem Kontext
Die Guidance ermutigt dazu, geeignete digitale Records, Logs und vorhandene Systeminformationen zu nutzen. Das kann unnötige manuelle Wiederholungen vermeiden. Entscheidend sind Aussagekraft und Nachvollziehbarkeit, nicht das Medium allein. Eine automatisch erzeugte Datei ist nicht schon deshalb vollständig oder richtig.
Prüfen Sie, ob der Nachweis später noch dem richtigen Lauf und Stand zugeordnet werden kann. Berücksichtigen Sie erforderliche Ergebnisdetails, Abweichungen und die Bedeutung von Statuswerten. Ein zusammenfassender Bericht darf auf diese Informationen verweisen. Ein Screenshot ist sinnvoll, wenn er etwas Relevantes belegt; eine universelle Screenshotpflicht lässt sich daraus nicht ableiten.
Quellen: [1]
7. Gestalten Sie Review und Zuständigkeit passend
Eine nachvollziehbare Schlussfolgerung braucht die fachliche Befugnis und Kompetenz der beteiligten Personen. Welche Rollen prüfen oder genehmigen, richtet sich nach den anwendbaren Anforderungen und dem festgelegten Verfahren. Die CSA-Empfehlung begründet keine universelle QA-Unterschrift unter jedem einzelnen Testlauf.
Prüfen Sie im Review insbesondere die Übereinstimmung von Zweck, Risiko, Abdeckung und Entscheidung. Wurden relevante Befunde berücksichtigt? Trägt die übernommene Evidenz wirklich die Schlussfolgerung? Eine rein formale Vollständigkeitskontrolle kann solche Widersprüche übersehen. Für kleine Teams kann ein kompakter, gut verknüpfter Record wesentlich leichter zu beurteilen sein als mehrere unverbundene Berichte.
8. Checkliste für den Abschluss des Records
Beenden Sie die Aufzeichnung mit einer klaren Nutzungsgrenze. Sie sollte weder enger sein als die tatsächlich getroffene Entscheidung noch weiter reichen als die vorhandene Evidenz. Ein Nachweis für eine Pflichtfeldfunktion ist kein vollständiger Nachweis der gesamten Reklamationsplattform.
Die eigene Checkliste hilft bei der letzten Zusammenführung. Sie kann in bestehende Arbeitsabläufe eingebaut werden. Entscheidend ist, dass die dokumentierte Schlussfolgerung auch nach einem Personal- oder Versionswechsel noch verständlich bleibt und die erforderlichen Nachweise verfügbar sind.
- Einsatzzweck und nicht abgedeckte Funktionen klar beschrieben.
- Risikobeurteilung mit tatsächlichen Kontrollannahmen verknüpft.
- Aktivitäten und geprüfte Grundlage nachvollziehbar.
- Befunde einschließlich ihrer Behandlung sichtbar.
- Erforderliche digitale Detailnachweise zugeordnet.
- Schlussfolgerung passt zur erreichten Abdeckung.
- Durchführung, Zuständigkeit und angemessener Review dokumentiert.
Quellen: [1]
Häufige Fragen zu FDA CSA: Assurance-Nachweis mit klarer Schlussfolgerung
Gibt es ein vorgeschriebenes FDA-CSA-Formular?
Die Guidance beschreibt geeignete Informationselemente und Beispiele, aber keinen universellen Berichtstyp. Verwenden Sie eine Form, die Einsatzzweck, Aktivitäten, Ergebnisse und Schlussfolgerung nachvollziehbar verbindet. Ein vorhandenes elektronisches Werkzeug kann dafür geeignet sein, wenn die erforderliche Evidenz erhalten bleibt.
Quellen: [1]
Muss jeder Testschritt im Detail protokolliert werden?
Das hängt von der Methode und der benötigten Aussage ab. Bei explorativen Prüfungen können Ziele, relevante Aktivitäten, Ergebnisse und Befunde ohne vorab festgelegte Klickfolge dokumentiert werden. Bei anderen Nachweisfragen sind detailliertere Erwartungen sinnvoll. Die Aufzeichnung muss die Schlussfolgerung tragen.
Quellen: [1]
Reicht eine Zusammenfassung aller bestandenen Tests?
Nicht allein, wenn Einsatzzweck, Grundlage oder Befunde fehlen. Eine Zusammenfassung ist hilfreich, muss aber auf die entscheidenden Details verweisen. Auch nicht ausgeführte Prüfungen und Probleme können für die Entscheidung wesentlich sein und dürfen nicht durch eine Erfolgsquote verdeckt werden.
Quellen: [1]
Wie werden offene Befunde dokumentiert?
Beschreiben Sie Auswirkung, Behandlung und verbleibende Bedeutung für die geplante Nutzung. Eine begründete Einschränkung kann Teil der Entscheidung sein. Der Record darf einen offenen Punkt nicht allein deshalb ausblenden, weil seine Behebung in einem späteren Ticket vorgesehen ist.
Quellen: [1]
Müssen wir Lieferantentests erneut vollständig abschreiben?
Nein. Geeignete vorhandene Evidenz kann mit nachvollziehbarer Zuordnung genutzt werden. Prüfen Sie ihre Qualität und Abdeckung für Ihren Einsatz. Es muss erkennbar bleiben, welche Aussage übernommen wird und welche eigene Konfiguration oder Prozessbedingung zusätzlich zu untersuchen ist.
Quellen: [1]
Sind Screenshots immer erforderlich?
Eine pauschale Pflicht nennt die Guidance nicht. Nutzen Sie geeignete digitale Records, Logs oder andere Nachweise, die das relevante Verhalten belegen. Ein Screenshot kann ergänzen, ersetzt aber keine unsichtbaren Daten- oder Verarbeitungsinformationen, wenn diese für die Aussage wesentlich sind.
Quellen: [1]
Muss QA jeden Assurance-Record unterschreiben?
Eine universelle Rollenpflicht wird hier nicht abgeleitet. Maßgeblich sind anwendbare Anforderungen und Ihr geregeltes Verfahren mit passender Kompetenz und Befugnis. Die Guidance berücksichtigt Review und Genehmigung, soweit angemessen; sie schreibt keine identische Unterschriftenfolge für jede Organisation vor.
Ist eine elektronische Genehmigung automatisch eine Part-11-Signatur?
Nein. Record-Scope, Bedeutung der Handlung und tatsächliche Umsetzung müssen betrachtet werden. Ein Statuswechsel ist nicht allein durch seinen Namen eine elektronische Signatur. Umgekehrt kann eine elektronische Genehmigung im passenden Kontext entsprechende Anforderungen auslösen; die konkrete Funktion ist zu prüfen.
Quellen: [1]
Kann ein Record mehrere Softwarefunktionen zusammenfassen?
Ja, wenn deren Einsatz, Risiko und Nachweise ausreichend unterscheidbar bleiben. Ein gemeinsamer Bericht kann sinnvoll sein. Er darf aber nicht den Eindruck erzeugen, ein erfolgreicher Test einer Funktion belege automatisch die Eignung aller anderen Funktionen derselben Plattform.
Quellen: [1]
Was ist die wichtigste Abschlussfrage?
Kann ein fachkundiger Leser erkennen, weshalb genau dieser Funktionsstand für genau diesen Einsatz akzeptabel ist? Wenn die Antwort nur mit zusätzlichem mündlichem Wissen möglich ist, fehlen meist Verknüpfungen oder eine klare Schlussfolgerung. Ergänzen Sie gezielt diese Lücke.
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 Ihr Team dabei, vorhandene Ergebnisse und offene Befunde zu einem nachvollziehbaren Assurance-Nachweis zusammenzuführen.
- 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.