So erstellen Sie einen Prozess für die ISO 13485
Die ISO 13485 macht die Nachweise zum Beweismittel für eine Behörde: Verifizierung gegen die Entwicklungsvorgabe, Validierung gegen den Nutzerbedarf, ein Tor für den Design-Transfer und eine Begründung an jedem Stopp-Zweig.
Ein Prozess für die ISO 13485 ist ein dokumentiertes Verfahren, dessen Ergebnisse regulatorische Nachweise sind: Risiko speist jede Phase, jedes Entwicklungsergebnis wird gegen seine Vorgabe verifiziert, und das Produkt wird danach im Gebrauch validiert.
Kurz gesagt
- Die Verifizierung prüft das Ergebnis gegen die Entwicklungsvorgabe, die Validierung das Produkt gegen den Nutzerbedarf.
- Jeder Stopp-, Ablehnungs- und Überarbeitungszweig trägt eine dokumentierte Begründung: ein gestoppter Weg ist auch ein Nachweis.
- Der Design-Transfer ist ein Tor: Die Spezifikation muss herstellbar sein, nicht bloß richtig.
- Wo 9001 die Organisation entscheiden lässt, benennt 13485 Abschnitt für Abschnitt ein dokumentiertes Verfahren.
- Risiko ist eine Eingabe in jede Phase und kein Register, das einmal beim Business Case überprüft wird.
Verifizierung und Validierung sind zwei Kästen
Die ISO 13485 baut auf der ISO 9001 auf und weicht in zwei Punkten ab, die verändern, wie ein Prozess gezeichnet wird. Risiko ist hier keine Denkweise, sondern eine Akte: nachverfolgbar von der Zweckbestimmung über die Gefährdungen bis zum Restrisiko und in jeder Phase herangezogen. Und die Nachweise entstehen nicht für die eigene Verbesserung der Organisation: Ein Inspektor liest sie Jahre später, ohne die Menschen, die damals entschieden haben. Ein Prozess, der unter 9001 ausreicht und darüber schweigt, warum eine Option verworfen wurde, ist unter 13485 unvollständig.
Verifizierung und Validierung sind nicht zwei Namen für Testen. Die eine fragt nach der Spezifikation, die andere nach dem Anwender, und jede wird nach eigenen Annahmekriterien dokumentiert, weshalb beide zu einer Testzeile zu verschmelzen die häufigste Feststellung zur Entwicklungslenkung überhaupt ist. Ein verschmolzener Kasten liefert ein Ergebnis, wo die Entwicklungsakte zwei braucht, und ein Ergebnis, das niemand an eine Anforderung hängen kann, belegt nicht, dass sie erfüllt wurde. Die meisten geerbten Entwicklungsabläufe stehen in diesem Zustand, das Beispiel dieser Seite eingeschlossen.
Das Beispiel unten ist ein allgemeiner Stage-Gate-Ablauf, und es trägt genau eine Testzeile: „Validierungstests planen und durchführen“. Nichts darin verifiziert ein Entwicklungsergebnis gegen die Spezifikation, und das ist die Verschmelzung in Reinform: lesen Sie das Diagramm also als den Zustand davor und ergänzen Sie die fehlende Zeile nach „Funktionsfähigen Prototyp bauen“. Richtig macht es dagegen die Abbruchwege: Zwei Fehlschläge führen zurück auf „Detailkonstruktion ausarbeiten“, und jedes Tor behält eine Abbruchzeile, deren Aufgabe es ist, eine Begründung zu halten.
Von der Idee zu einer übertragbaren Konstruktion
Ein Stage-Gate-Ablauf mit einer Testzeile und ohne Verifizierungsschritt. Lesen Sie ihn als den Zustand davor und ergänzen Sie dann den Kasten, der ihm fehlt.
Regulierung ist eine Entwicklungsvorgabe
Idee, Screening, Machbarkeit, Konzept, dann „Regulatorische Anforderungen ermitteln“. Diese Zeile liegt in der Bahn Qualität, während der Business Case noch entsteht, und nicht erst, wenn eine Konstruktion vorliegt. Zweckbestimmung und geltende Vorschrift sind Vorgaben, gegen die später verifiziert wird, und keine Prüfung am Ende.
Ein Stopp braucht eine Begründung in der Akte
„Gate 1: entwickeln oder stoppen?“ kommt mit beiden Abbruchwegen gezeichnet: „Überarbeiten“ gibt den Business Case zurück an „Business Case erstellen“, und „Stopp“ endet an „Idee mit Begründung zurückgestellt“, einem Kasten, dessen Zweck sein letztes Wort ist. „Go“ kommt in der nächsten Phase an. Ein Tor, das man nur bestehen kann, ist ein Meilenstein.
Zwei Prüfungen, eine Zeile im Diagramm
Die Überarbeitung geht zurück: „Design-Review bestanden?“ schickt „Überarbeiten“ an „Detailkonstruktion ausarbeiten“, und der Zweig „Bestanden“ direkt in „Validierungstests planen und durchführen“. Diese Zeile ist die Validierung; keine Zeile verifiziert das Ergebnis gegen die Spezifikation, und „Anforderungen erfüllt?“ fällt ebenfalls in die Konstruktion zurück.
Transfer ist ein Tor, keine Übergabe
Der Design-Transfer gehört an „Begrenzte Pilotserie fahren“: den Punkt, an dem eine funktionierende Konstruktion als auf der künftigen Linie herstellbar nachgewiesen werden muss. „Gate 2: Launch freigeben?“ schickt anschließend „Pilot verlängern“ zurück in diesen Pilot und „Stopp“ an „Launch an Gate 2 gestoppt“.
So funktioniert es
Schreiben Sie zuerst die Entwicklungsvorgaben
Zweckbestimmung, Nutzerbedarf, die geltenden regulatorischen Anforderungen und die Risikobeherrschungsmaßnahmen, die daraus folgen. Genau daran wird die Verifizierung später gemessen, eine unbestimmte Vorgabe macht die Verifizierung deshalb nicht überprüfbar. Eine Vorgabe, deren Erfüllung sich nicht zeigen lässt, ist die, über die im Audit gestritten wird.
Entscheiden Sie, welche Nachweise die Akte halten muss
Listen Sie sie auf, bevor Sie etwas zeichnen: Review-Protokolle mit den anwesenden Funktionen, Pläne und Ergebnisse für Verifizierung und Validierung, die Begründung hinter jeder verworfenen Option, den Transfernachweis und die Risikomanagementakte in jeder Phase. Die Landkarte hat zu zeigen, wo jeder davon entsteht, jeder Nachweis braucht also eine Zeile, die ihn hervorbringt.
Tippen Sie die Phasen ein, dann die fehlende Prüfung
Eine Zeile je Phase in der Spalte Boxtext. Ergänzen Sie danach die Zeile, die dieses Beispiel nicht hat: einen Verifizierungsschritt nach „Funktionsfähigen Prototyp bauen“, dessen Linie zu auf das Design-Review zeigt, damit das Review Verifizierungsergebnisse liest und „Validierungstests planen und durchführen“ allein die Frage des Anwenders beantwortet.
Geben Sie jedem Tor einen Zweig, der es stoppt
Jedes Tor bekommt in der Spalte Form die Entscheidung, mit seinen Ergebnissen im Linientext in der Reihenfolge der Nummern in Linie zu. Geben Sie dem stoppenden Ergebnis eine eigene Abbruchzeile statt eines Pfeils ins Leere: In einer Entwicklungsakte ist der nicht genommene Weg ein Nachweis, den irgendwann jemand lesen muss.
Prüfen Sie die Unabhängigkeit der Prüfer in den Bahnen
Die 13485 will, dass an jedem Design-Review Vertreter der betroffenen Funktionen und eine von der geprüften Phase unabhängige Person teilnehmen. Jeden Verantwortlichen in die Spalte Vertikale Bahn zu tippen macht das prüfbar: Im Beispiel liegt „Design-Review bestanden?“ in der Bahn Entwicklung / F&E, direkt neben dem Prototyp, den es prüft.
Verfolgen Sie eine Anforderung durch die Akte
Nehmen Sie eine Entwicklungsvorgabe (eine Anforderung aus „Regulatorische Anforderungen ermitteln“) und verfolgen Sie sie nach vorn. Sie sollte eine Zeile erreichen, die sie gegen die Spezifikation verifiziert, eine Zeile, die sie im Gebrauch validiert, und ein Review, das beide Ergebnisse gelesen hat. Erreicht sie nur eines der drei, ist das die Lücke, die ein Inspektor findet.
Häufige Fehler
Verifizierung und Validierung verschmolzen
Verifizierung und Validierung beantworten unterschiedliche Fragen nach unterschiedlichen Annahmekriterien und erzeugen getrennte Nachweise. Verschmolzen kann die Akte nicht zeigen, welche Anforderung ein bestandenes Ergebnis erfüllt hat, und genau das ist die Feststellung.
Tore, an denen niemand scheitern kann
Wo außer dem fortsetzenden kein Zweig ein Tor verlässt, ist das Review eine Statusrunde. Erst die Stopp- und Überarbeitungswege machen daraus eine Kontrolle, und die Begründung dahinter gehört in die Entwicklungsakte.
Eine Übergabe mit dem Transfer verwechselt
Zeichnungen in die Fertigung zu schicken ist kein Transfer. Transfer ist der Nachweis, dass die Spezifikation mit dem Prozess, den Anlagen und den Menschen, die sie herstellen werden, wiederholbar produzierbar ist, und er hat einen Annahmenachweis.
Risiko einmal beurteilt, beim Konzept
Eine im Konzeptstadium geschriebene und nie wieder geöffnete Risikobeurteilung kann nicht abbilden, was aus der Konstruktion geworden ist. Ziehen Sie die Risikomanagementakte in jeder Phase heran, in der sich die Konstruktion ändert, und dokumentieren Sie, was die Änderung an ihr verändert hat.
Eigenen Entwicklungslenkungsprozess erstellen
Öffnen Sie das Stage-Gate-Beispiel als eigenes Diagramm, ergänzen Sie die fehlende Verifizierungszeile und geben Sie jedem Tor ein dokumentiertes Ergebnis.
Verwandte Anleitungen
Häufig gestellte Fragen
Was ist der Unterschied zwischen Verifizierung und Validierung?
Die Verifizierung fragt, ob ein Entwicklungsergebnis die für es festgelegte Entwicklungsvorgabe erfüllt: ein gemessenes Maß gegen eine Zeichnung, ein geprüftes Ergebnis gegen eine formulierte Anforderung. Die Validierung fragt, ob das entstandene Produkt den Nutzerbedarf und die Zweckbestimmung erfüllt, unter Bedingungen, die den tatsächlichen Gebrauch abbilden, und an Produkten aus dem vorgesehenen Prozess. Die Verifizierung kann an einem Produkt bestehen, das für seinen Anwender falsch ist; die Validierung ist es, die das aufdeckt. Die ISO 13485 verlangt Pläne, Nachweise und Schlussfolgerungen für beide, getrennt.
Was verlangt Abschnitt 7.3 der ISO 13485?
Planung, dokumentierte Entwicklungsvorgaben und Entwicklungsergebnisse, Reviews in geplanten Phasen, Verifizierung, Validierung, Transfer, Lenkung von Entwicklungsänderungen und eine Entwicklungsakte je Produkttyp oder Produktfamilie. Jeder dieser Punkte ist genauso eine Nachweispflicht wie eine Tätigkeit. Der Abschnitt verlangt außerdem, dass die Vorgaben die geltenden regulatorischen Anforderungen und die Ergebnisse des Risikomanagements einschließen, und das trennt einen 13485-Entwicklungsprozess von einem Stage-Gate-Prozess mit einem angehängten Qualitätsschritt.
Was ist der Design-Transfer in der ISO 13485?
Der Design-Transfer ist die verifizierte Übersetzung einer Konstruktion in Fertigungsspezifikationen: Verfahren, Werkzeuge, Prüfmethoden, Schulung und Annahmekriterien, die das Produkt wiederholbar herstellbar machen. Die Norm verlangt Verfahren für den Transfer mit Nachweisen, dass die Entwicklungsergebnisse für die Fertigung geeignet sind, bevor die Produktion beginnt. Ihn als den Moment zu behandeln, in dem die Zeichnungen im Werk ankommen, ist der Grund, warum erste Serien aus Gründen ausfallen, die kein Prototyp je gezeigt hat.
Ist die ISO 13485 bei Verfahren strenger als die ISO 9001?
Ja, und zwar mit Absicht. Die ISO 9001:2015 lässt eine Organisation entscheiden, welche dokumentierte Information sie braucht; die ISO 13485:2016 benennt dokumentierte Verfahren Abschnitt für Abschnitt (Entwicklung, Beschaffung, Produktionslenkung, Reklamationsbearbeitung, Korrekturmaßnahmen) und behält die Forderung nach einem Qualitätsmanagementhandbuch, die die 9001 gestrichen hat. Die praktische Folge ist, dass eine Prozesslandkarte hier kein freiwilliges Beiwerk ist: Sie ist Teil des Verfahrens, das eine Behörde sehen will, in dem Stand, der damals galt.
