- Zielgruppe
- Entwicklungsleiter, QM-Leiterin, Regulatory-Verantwortliche — Klasse I–III, 10–200 MA
- Norm
- ISO 13485 §7.3.1–§7.3.7 · ISO 14971 · EU-MDR Anhang I
- Lesezeit
- ca. 12 Minuten
Design
verifiziert.
Aber wirklich
validiert?
Das Testprotokoll ist vollständig, alle Parameter liegen in der Toleranz, der Bericht ist unterschrieben. Wenn der Auditor dann nach dem Validierungsnachweis fragt — dem Nachweis, dass das Produkt unter realen Anwendungsbedingungen durch eine repräsentative Nutzergruppe die tatsächlichen Nutzerbedürfnisse erfüllt —, beginnt in vielen Betrieben die stille Suche. ISO 13485 §7.3 verlangt nicht nur Dokumentation. Er verlangt einen vollständigen Entwicklungssteuerungskreislauf: von der Eingabe über die Überprüfung bis zum formalen Transfernachweis.
ISO 13485 §7.3 beschreibt keinen Dokumentationsprozess — er beschreibt einen Steuerungskreislauf. Designlenkung beginnt mit einem formalen Planungsdokument (§7.3.1), das Phasen, Meilensteine und Review-Punkte festlegt. Bevor Entwicklungsarbeit beginnt, müssen Designeingaben dokumentiert und genehmigt sein (§7.3.2) — und zwar nicht als Kopie des Kundenpflichtenhefts, sondern als vollständige Anforderungsdokumentation, die auch Risikomanagement-Ergebnisse nach ISO 14971 als normative Eingabe enthält.
Am Ende der Entwicklung stehen zwei formal unterschiedliche Nachweise: Designverifizierung (§7.3.5) belegt, dass die Designausgaben die Designeingaben erfüllen — dass das Produkt der Spezifikation entspricht. Designvalidierung (§7.3.6) belegt, dass die Spezifikation selbst die tatsächlichen Nutzerbedürfnisse im bestimmungsgemäßen Gebrauch unter repräsentativen Bedingungen trifft. Beide Nachweise müssen getrennt dokumentiert sein, weil sie verschiedene Fragen beantworten.
Verifizierung fragt: "Haben wir das Produkt richtig gebaut?" Validierung fragt: "Haben wir das richtige Produkt gebaut?" Auditoren von Benannten Stellen kennen diesen Unterschied. Wer einen Testbericht vorlegt, wenn nach dem Validierungsplan gefragt wird, hat seinen §7.3.6-Befund.
Vier Muster zeigen, wo §7.3 in der Praxis kleiner Medizintechnik-Hersteller zum Audit-Finding wird — und warum die Ursache fast immer struktureller, nicht personeller Natur ist.
Alle Tests bestanden. Repräsentative Anwendungsbedingungen: nicht dokumentiert.
Das Produkt wurde im Engineering-Labor durch die Entwickler getestet — mit Vorserienprototypen, ohne Endverpackung, ohne simulierten Transport, ohne klinisches Umfeld. ISO 13485 §7.3.6 verlangt Designvalidierung unter "definierten Betriebsbedingungen" an "repräsentativem Produkt": finales Serienprodukt, nicht Prototypen; repräsentative Nutzergruppe, nicht das Design-Team; Bedingungen, die den tatsächlichen Einsatz simulieren. Ein Testbericht, der belegt, dass alle Parameter in der Toleranz liegen, beantwortet "Erfüllt das Produkt die Spezifikation?" — nicht "Erfüllt die Spezifikation die tatsächlichen Nutzerbedürfnisse im Einsatz?" Das ist der Unterschied zwischen Verifizierung und Validierung. Auditoren, die nach dem Validierungsplan fragen und ein Laborprotokoll bekommen, haben ihren §7.3.6-Befund.
Entwicklung startete mit Kundenpflichtenheft. §7.3.2-Aufzeichnungen: keine.
Der Kunde hat ein Anforderungsdokument übergeben. Die Entwicklung hat begonnen. Drei Iterationen später erfüllt das Produkt das, was gebaut wurde — aber niemand hat festgehalten, was vor dem ersten Entwurf als Designeingabe galt. ISO 13485 §7.3.2 verlangt, dass Designeingaben dokumentiert, vollständig, eindeutig und auf Angemessenheit geprüft werden. Dazu gehören zwingend: funktionale und leistungsbezogene Anforderungen, anwendbare gesetzliche und behördliche Anforderungen, Ergebnisse aus dem Risikomanagement nach ISO 14971, Anforderungen aus früheren ähnlichen Designs und alle weiteren wesentlichen Anforderungen. Ein Kundenpflichtenheft ist ein Ausgangspunkt, kein §7.3.2-Dokument. Die Differenz ist das Finding.
Drei Design Reviews protokolliert. Alle Teilnehmer: dasselbe Entwicklungsteam.
§7.3.4 verlangt, dass an Designüberprüfungen Vertreter aller betroffenen Funktionsbereiche beteiligt sind — einschließlich mindestens einer Person, die von der entwerfenden Funktion unabhängig ist. Der Sinn: externe Prüfung, nicht Selbstbewertung. Wenn dieselben drei Ingenieure, die das Produkt entworfen haben, auch alle Gates durchführen, hat der Review-Prozess keine Korrekturfunktion. Der Auditor sieht die Teilnehmerlisten: Entwicklungsleiter, Konstrukteur, Testingenieur — alle aus derselben Abteilung. Kein QM-Vertreter, keine regulatorische Expertise, kein unabhängiger Gutachter. Ein Review ohne diese Funktion ist ein Statusgespräch. Im Audit gilt er als fehlende §7.3.4-Anforderung.
Testbericht deckt alle Spezifikationsparameter ab. Validierungsnachweis: dasselbe Dokument.
In kleinen Entwicklungsteams verschmelzen Verifizierung und Validierung häufig zu einem einzigen Aktivitätsstrang — oder Verifizierung wird abgeschlossen und als Validierung deklariert. ISO 13485 §7.3.5 und §7.3.6 stellen zwei verschiedene Fragen: Verifizierung fragt "Entsprechen die Designausgaben den Designeingaben?" Validierung fragt "Erfüllt das Produkt die Nutzerbedürfnisse im bestimmungsgemäßen Gebrauch unter realen Bedingungen?" Beide Fragen können nicht mit demselben Dokument beantwortet werden — sie erfordern verschiedene Methoden, verschiedene Testbedingungen und separate Aufzeichnungen. Ein Testprotokoll, das alle Designparameter in der Spezifikation nachweist, ist ein Verifizierungsnachweis. Kein Validierungsnachweis — es sei denn, die Testbedingungen simulieren tatsächlich den repräsentativen Einsatz.
In allen vier Szenarien liegt die eigentliche Ursache nicht im fehlenden Wissen, sondern im fehlenden Prozess: Kein formales §7.3.2-Dokument, kein unabhängiger Review-Teilnehmer, keine getrennte Validierungs-Methodik, kein Transfernachweis. Die Entwicklung hat stattgefunden — aber nicht unter den Steuerungsbedingungen, die §7.3 als Kreislauf fordert.
§7.3 ist als Phasenkette konzipiert: jede Phase baut auf der vorigen auf, jede hat einen definierten Input, einen definierten Output und einen formalen Nachweis. Die häufigste Schwäche kleiner Hersteller ist nicht das vollständige Fehlen einer Phase — sondern das Fehlen des formalen Nachweises für eine Phase, die inhaltlich stattgefunden hat.
Die Phasen §7.3.5 und §7.3.6 sind der häufigste Ort struktureller Befunde — nicht weil Testaktivitäten fehlen, sondern weil sie methodisch nicht getrennt werden. §7.3.2 ist der zweithäufigste: nicht weil keine Anforderungen existieren, sondern weil sie nicht als formale Designeingaben dokumentiert und genehmigt wurden.
Designlenkung berührt in der Medizintechnik mindestens drei Normebenen gleichzeitig. Wer nur §7.3 im Blick hat, übersieht den ISO-14971-Zusammenhang — und den MDR-Kontext für den Belegpfad in die klinische Bewertung.
Designeingaben: mehr als das Pflichtenheft
Risikomanagement-Ergebnisse nach ISO 14971 sind normative Eingaben in §7.3.2 — keine optionalen Referenzen. Wer einen Risikoanalyseentwurf hat, aber keinen §7.3.2-Nachweis, der zeigt, wie Risikokontrollmaßnahmen in die Designspezifikation eingeflossen sind, hat eine Verbindungslücke, die Auditoren von Benannten Stellen konsequent nachverfolgen. Die Frage lautet nicht "Haben Sie eine Risikoanalyse?" — sondern "Zeigen Sie mir, wie Ihre Risikokontrollmaßnahmen in die Designspezifikation eingeflossen sind."
Verifizierung und Validierung sind keine Synonyme
Verifizierung prüft: Haben wir das Produkt richtig gebaut? Validierung prüft: Haben wir das richtige Produkt gebaut? Die erste Frage beantwortet ein Testprotokoll gegen die interne Spezifikation. Die zweite braucht repräsentative Nutzer, repräsentative Bedingungen und einen expliziten Abgleich mit den Nutzerbedürfnissen. Beide Nachweise müssen separat vorliegen — ein einziger Testbericht kann nicht beide Fragen beantworten, weil er verschiedene Methodiken erfordert.
Validierung und GSPR: der Belegpfad für die klinische Bewertung
Die Allgemeinen Sicherheits- und Leistungsanforderungen (GSPR) aus MDR Anhang I müssen durch klinische Belege oder präklinische Tests adressiert sein. Designvalidierungsergebnisse sind der direkte Input für die klinische Bewertung. Wer §7.3.6-Nachweise führt, hat damit gleichzeitig den Belegpfad für Anhang-I-Konformitätsnachweise — aber nur, wenn die Validierungsbedingungen tatsächlich repräsentativ waren und der Risikofile als Eingabe eingeflossen ist.
Designübertragung: der formale Abschluss der Entwicklung
§7.3.7 wird in kleinen Betrieben häufig übersprungen — mit der Folge, dass der Auditor beim Überwachungsaudit fragt: "Zeigen Sie mir den Transfernachweis, der belegt, dass Ihre Serienproduktion das validierte Design reproduzieren kann." Der Nachweis muss Fertigungsprozesseignung, Prüfprozessausrichtung auf Designausgaben und dokumentierte Bewertung aller Spezifikationsunterschiede zwischen Entwicklungsmustern und Serienprodukt enthalten.
Risikokontrollmaßnahmen gehören in die Designspezifikation — nicht daneben
ISO 14971 §5 verlangt, dass Risikokontrollmaßnahmen in das Design integriert werden. ISO 13485 §7.3.2 verlangt, dass Risikomanagement-Ergebnisse als Designeingaben dokumentiert sind. Die Verbindung: Wer einen Risikoanalyse-Entwurf und ein Designpflichtenheft getrennt führt, ohne explizit zu belegen, welche Risikokontrollmaßnahmen welche Designeingaben erzeugen, hat eine Traceability-Lücke.
Auditoren von Benannten Stellen fragen bei §7.3.2: "Zeigen Sie mir, wie die Ergebnisse Ihrer Risikoanalyse als Eingaben in die Designspezifikation eingeflossen sind." Die Antwort muss aus Dokumenten kommen, nicht aus Erläuterungen. Die Traceability-Matrix zwischen Risikokontrollmaßnahmen und Designeingaben ist das Dokument, das diese Frage schließt.
Serienprodukt ≠ Entwicklungsmuster — der Transfer muss dokumentiert sein
§7.3.7 ist der formale Abschluss der Entwicklungsphase: Der Transfer des validierten Designs in die Serienproduktion muss belegt sein — durch Nachweis der Prozesseignung, Ausrichtung der Prüfprozesse auf die Designausgaben und Bewertung aller Spezifikationsunterschiede zwischen Entwicklungsmustern und Serie.
Für Änderungen nach Abschluss des Transfers gelten §7.3.8 und §7.3.9 (Designänderungen) — jede Änderung muss bewertet werden, ob sie eine erneute Verifizierung, Validierung oder den Eingriff in das bestehende Zertifikat nach MDR Art. 120(3) auslöst. Dieser Zusammenhang ist im Stück zu Änderungsmanagement nach §4.1.4 und §7.3.7 vertieft.
§7.3 endet nicht mit der Validierung. Der vollständige Kreislauf schließt erst, wenn der Transfer in die Serie dokumentiert ist und Änderungen nach der Serienfreigabe formal bewertet werden. Für Auditoren ist das die Vollständigkeitsfrage: "Zeigen Sie mir den Bogen von der ersten Designeingabe bis zum aktuell produzierten Produkt — inklusive aller Änderungen."
Designlenkung nach §7.3 und Prozessvalidierung nach §7.5.6 sind verwandte, aber unterschiedliche Konzepte: §7.3.6 Designvalidierung belegt, dass das Produkt die Nutzerbedürfnisse erfüllt. §7.5.6 Prozessvalidierung belegt, dass der Fertigungsprozess die Produktspezifikation reproduzierbar herstellt. Beide sind Pflicht — für verschiedene Objektbereiche und mit verschiedenen Methoden. Den Unterschied erklärt das Stück zu Prozessvalidierung nach §7.5.6 im Detail.
Zum übergreifenden Thema ISO 13485 in der Praxis gibt es eine eigene Pillar-Page mit allen Kapiteln §4–§8. Designlenkung ist dort in §7 eingebettet — die Verbindung zu §4.2.4 (Dokumentationspflichten), §7.5.7 (sterile Produkte), §7.5.6 (Sonderprozesse) und §8.5.2 (CAPA) macht das Thema strukturell und nicht isoliert betrachtbar.
Produktrisiko, Prozessrisiko und Risiko-Nutzen-Analyse: Risiko-Outputs als normative §7.3.2-Eingaben →
Änderungsmanagement · §4.1.4 · §7.3.7Was nach §7.3.7 als Designänderung gilt, wann eine erneute Validierung fällig wird und warum MDR Art. 120(3) hängt →
Prozessvalidierung · ISO 13485 §7.5.6§7.3.6 Designvalidierung vs §7.5.6 Prozessvalidierung: Abgrenzung, IQ/OQ/PQ und wann Revalidierung Pflicht ist →
Eingaben.
Überprüfung.
Verifiziert.
Validiert.
In einer Demo zeigen wir, wie QIMS Designlenkung nach §7.3 mit Risikomanagement, Änderungsmanagement und CAPA verbindet: Traceability von der Designeingabe bis zum Validierungsnachweis, Verifizierungs- und Validierungsnachweise getrennt geführt, Transferdokumentation mit Prozesseignungsnachweis.
Kein Pitch. Kein Abschlussgespräch nach dem Termin.