- Zielgruppe
- QM-Beauftragter, Regulatory Affairs, Entwicklungsleitung — 20–200 MA
- Norm
- ISO 13485 §4.1.4 · §7.3.7 · MDR Art. 120(3) · MDCG 2020-3
- Lesezeit
- ca. 11 Minuten
Änderung
gemacht.
Aber wirklich
erfasst?
Ein Materialtausch hier, ein Software-Update dort, ein neuer Lieferant für eine Komponente. Im laufenden Betrieb sind das operative Entscheidungen — schnell getroffen, gut gemeint, selten in einem Änderungsdatensatz erfasst. ISO 13485 §4.1.4 und §7.3.7 verlangen nicht nur die Aufzeichnung dieser Änderungen, sondern die dokumentierte Bewertung ihrer Auswirkungen. Wer das erst beim Audit klärt, erklärt dem Prüfer, warum validierte Prozesse seit Monaten ohne gültige Grundlage liefen.
Änderungsmanagement hat in ISO 13485 zwei regulatorische Verankerungen, die zusammenwirken und sich gegenseitig auslösen. §4.1.4 regelt Änderungen am Qualitätsmanagementsystem selbst: Wenn Prozesse, Verfahren oder Anweisungen im QMS geändert werden, müssen die Auswirkungen auf das gesamte System bewertet und dokumentiert werden — einschließlich der Frage, ob Produktanforderungen und regulatorische Anforderungen weiterhin erfüllt sind.
§7.3.7 greift bei Änderungen an Design und Entwicklung: Jede Änderung nach Freigabe des Designs muss überprüft, verifiziert und — soweit angemessen — validiert werden, bevor sie implementiert wird. Beide Paragrafen treffen sich in der Praxis regelmäßig: Eine Designänderung zieht fast immer eine Änderung der Prüfanweisung nach sich, die wiederum eine §4.1.4-relevante Änderung im QMS ist.
Eine Änderung dokumentieren und eine Änderung bewerten sind zwei verschiedene Tätigkeiten. §4.1.4 und §7.3.7 verlangen Letzteres: nicht nur den Nachweis, dass etwas geändert wurde, sondern dass die Auswirkungen dieser Änderung vor der Implementierung systematisch geprüft und freigegeben wurden.
Dazu kommt ein dritter regulatorischer Aspekt, der für alle Hersteller relevant ist, die noch unter einem MDD-Zertifikat produzieren: MDR Art. 120(3) macht die Weitergeltung bestehender Zertifikate davon abhängig, dass keine wesentliche Änderung an Design oder Zweckbestimmung vorgenommen wurde. Was als "wesentlich" gilt, entscheidet die MDCG-Leitlinie 2020-3 — und diese Bewertung muss für jede Produktänderung explizit vorliegen. Vier Muster zeigen, wo das in der Betriebspraxis regelmäßig scheitert.
Gleiche Spezifikation, anderes Material. Kein Eintrag.
Der Zulieferer für das Gehäuse-Polymer stellt seinen Betrieb ein. Der Einkauf findet einen gleichwertigen Ersatz — ähnliche Spezifikation, niedrigerer Preis. Die Qualitätsprüfung läuft einmalig, das Ergebnis ist gut. Was fehlt: Ein dokumentierter Änderungsbescheid, der bewertet, ob der Materialtausch eine sicherheitsrelevante Auswirkung hat. ISO 13485 §4.1.4 verlangt, dass Auswirkungen auf das QMS bewertet werden. Wenn Prüf- oder Fertigungsprozesse auf dem alten Material validiert wurden, ist mit dem Tausch die Validierungsbasis entfallen — auch wenn das neue Material optisch identisch ist.
Bugfix in Schritt 3 — niemand hat es aufgeschrieben
§7.3.7 verlangt für Änderungen an Design und Entwicklung eine Überprüfung, Verifizierung und ggf. Validierung vor der Implementierung. In der Praxis bedeutet das auch für Software: jede funktionale Änderung — auch ein vermeintlich kleiner Bugfix — ist ein Designänderungs-Ereignis. Wer einen Softwarestand ins Feld bringt, ohne den Änderungsstand im Technischen Dokumentation und im Change-Log zu spiegeln, hat eine Lücke, die der Auditor schließen wird: "Zeigen Sie mir den Change-Record zur aktuell eingesetzten Softwareversion."
Der Produktionsleiter hat umgestellt. Das QM hat es danach erfahren.
Ein validierter Reinigungsprozess wird auf ein neues Reinigungsmittel umgestellt, weil das alte nicht mehr lieferbar ist. Die Entscheidung trifft der Produktionsleiter im laufenden Betrieb — pragmatisch, schnell, nicht dokumentiert. §4.1.4 verlangt nicht nur, dass Prozessänderungen erfasst werden, sondern dass ihre Auswirkungen auf das bestehende QMS bewertet werden. Wenn der Reinigungsprozess validiert war, ist er durch den Mittelwechsel formell ungültig — bis zur erneuten Validierung. Das ist kein Formalfehler. Es ist ein Finding, das die gesamte Chargenfreigabe aus dem betroffenen Zeitraum in Frage stellt.
Das Zertifikat ist gültig — aber gilt es noch für das Produkt, wie es heute aussieht?
MDR Art. 120(3) erlaubt, dass Produkte mit gültigem MDD-Zertifikat weiterhin in Verkehr gebracht werden — sofern keine wesentliche Änderung an Design oder Zweckbestimmung vorgenommen wurde. Was als "wesentliche Änderung" gilt, ist in der MDCG-Leitlinie 2020-3 beschrieben. Das Problem: Viele kleine Hersteller haben in den letzten Jahren Anpassungen vorgenommen — Materialien, Software, Kennzeichnung, Zubehör — ohne zu prüfen, ob diese Änderungen kumulativ oder einzeln unter Art. 120(3) fallen. Wer das erst beim nächsten Re-Audit klärt, riskiert, dass Produkte retroaktiv als "nicht mehr unter MDD-Zertifikat gedeckt" eingestuft werden.
Die vier Szenarien haben eine gemeinsame Grundstruktur: Die Änderung wurde operativ entschieden und umgesetzt — aber nicht durch einen dokumentierten Bewertungsprozess geführt. Das Problem ist nicht Nachlässigkeit, sondern fehlende Infrastruktur: kein System, das den Change-Prozess als Pflicht einfordert, bevor die Änderung live geht.
In kleinen Betrieben läuft Änderungsmanagement oft über persönliche Kenntnis: Der QM-Beauftragte weiß, was sich getan hat, weil er in den relevanten Meetings sitzt und die richtigen Personen kennt. Das funktioniert für fünf bis zehn Personen und eine Handvoll Änderungen pro Jahr überraschend gut. Ab etwa 20 Mitarbeitern und mehreren parallelen Produktlinien entstehen drei strukturelle Probleme, die sich durch mehr Sorgfalt allein nicht lösen lassen.
Änderungen werden dokumentiert — aber an verschiedenen Orten: Die Konstruktionsänderung im PDM-System, die Prozessänderung im Schichtbuch, die Lieferantennachricht per E-Mail. Wer drei Wochen später wissen will, welche Änderungen im letzten Quartal vorgenommen wurden, braucht Zugriff auf vier verschiedene Systeme — und bekommt trotzdem kein vollständiges Bild. Ein zentrales Änderungsregister ist keine organisatorische Schönheit, sondern die Voraussetzung dafür, dass §4.1.4 operational erfüllt ist.
Die Frage, ob eine Änderung eine formale Bewertung, eine erneute Validierung oder eine neue Konformitätsbewertung auslöst, wird in den meisten kleinen Betrieben situativ und personenabhängig entschieden. Mal ist es der QM-Beauftragte, mal der Entwicklungsleiter, mal der Produktionsleiter. Das Ergebnis: unterschiedliche Bewertungsmaßstäbe für ähnliche Änderungen, keine Nachvollziehbarkeit der Entscheidungslogik im Audit und kein Schutz gegen Fehlklassifikation in einer richtungsändernden Situation.
ISO 13485 unterscheidet zwischen QMS-Änderungen (§4.1.4) und Design-Änderungen (§7.3.7) — aber in der Realität hängen beide zusammen. Eine Designänderung zieht meist eine Änderung der Prüfanweisung nach sich, was eine §4.1.4-Änderung im QMS bedeutet. Wer beide Pfade separat verwaltet, verpasst die Abhängigkeiten — und schließt Change-Records, ohne dass der andere Prozesszweig nachgezogen hat.
Das Ergebnis ist ein Änderungsmanagement, das für Routine-Vorgänge funktioniert, aber keine systematische Bewertungslogik hat. Grenzfälle werden personenabhängig entschieden, Abhängigkeiten zwischen Änderungssträngen werden nicht sichtbar, und die Verbindung zwischen §4.1.4-Änderungen und §7.3.7-Designänderungen bleibt dem Zufall überlassen — bis der Auditor nach dem letzten Change-Record zu einem bestimmten Produktstand fragt.
Änderungsmanagement in der Medizintechnik ist kein einzelner Paragraf, sondern ein Zusammenspiel aus vier regulatorischen Quellen. Wer nur eine davon im Blick hat, übersieht entweder die Validierungsverpflichtung oder das MDR-Zertifikatsproblem.
Änderungen am QMS bewerten und dokumentieren
Wenn Prozesse im QMS geändert werden, verlangt §4.1.4, dass die Auswirkungen dieser Änderung auf das gesamte Managementsystem bewertet werden — einschließlich der Frage, ob Produktanforderungen und regulatorische Anforderungen weiterhin erfüllt sind. Das ist keine Soll-Vorschrift, sondern ein Muss: Ohne dokumentierte Auswirkungsbewertung ist der Change-Prozess aus Norm-Sicht nicht abgeschlossen. Relevant sind dabei alle Änderungen, die einen dokumentierten Prozess des QMS berühren — von der Prüfanweisung über das Schulungsprogramm bis zum Lieferantenstamm.
Design- und Entwicklungsänderungen vor Implementierung freigeben
§7.3.7 verlangt, dass Änderungen an Design und Entwicklung vor der Umsetzung überprüft, verifiziert und — soweit angemessen — validiert werden. Die Auswirkung auf bereits hergestellte Teile und ausgelieferte Produkte muss bewertet werden. Die Norm verlangt Aufzeichnungen dieser Überprüfungen einschließlich der erteilten Freigaben. Das bedeutet in der Praxis: Jede Designänderung braucht einen dokumentierten Entscheidungspfad von der Änderungsanforderung über die Risikobewertung bis zur befugten Freigabe. Der Änderungsstand muss aus der technischen Dokumentation ableitbar sein.
Wesentliche Änderungen machen MDR-Konformitätsbewertung erforderlich
Produkte, die unter gültigem MDD-Zertifikat stehen, dürfen weiterhin in den Verkehr gebracht werden — außer wenn eine wesentliche Änderung an Design oder Zweckbestimmung vorgenommen wurde. In diesem Fall ist eine vollständige Konformitätsbewertung nach MDR erforderlich. Was als "wesentlich" gilt, hat die MDCG in der Leitlinie 2020-3 ausgeführt: Änderungen, die die Sicherheit oder Leistung des Produkts beeinflussen können, die Zweckbestimmung verändern oder die Klassifizierung beeinflussen. Für kleine Hersteller in der Übergangsphase bedeutet das: Jede Änderung am Produkt muss explizit gegen dieses Kriterium geprüft werden.
Leitlinie zur Bestimmung wesentlicher Änderungen
Die MDCG-Leitlinie 2020-3 gibt einen strukturierten Entscheidungsbaum für die Frage, ob eine Änderung unter Art. 120(3) als "wesentlich" einzustufen ist. Sie unterscheidet zwischen Änderungen an der Zweckbestimmung, an wesentlichen Leistungsparametern, an sicherheitsrelevanten Werkstoffen und an der Kennzeichnung. Für jede Änderungskategorie gibt es Kriterien, wann eine neue Konformitätsbewertung ausgelöst wird. Diese Leitlinie gehört in die Standard-Referenzliste jedes Change-Management-Prozesses, der Produkte in der MDR-Übergangsphase betrifft.
Nicht jede Änderung ist gleich — und das ist der Kern der Herausforderung. Ein pragmatisches Änderungsmanagement unterscheidet Änderungstypen nicht um ihrer selbst willen, sondern weil der Typ bestimmt, welche Bewertungsschritte vor der Freigabe durchlaufen werden müssen. Die folgende Übersicht zeigt vier häufige Änderungstypen in der Medizintechnik-Produktion, den regulatorischen Auslöser und das typische Fehlermuster beim Change-Prozess.
Der häufigste Fehler ist nicht die falsche Bewertung — sondern das Fehlen der Bewertung. Wer einen Änderungstyp nicht erkennt oder nicht im Change-System erfasst, trifft keine explizite Entscheidung. Er lässt die Änderung implizit als "unkritisch" klassifizieren — ohne Dokumentation, ohne Freigabe, ohne Rückverfolgbarkeit.
Was wird geändert, warum, von wem beantragt?
Die Änderungsanforderung ist der Startpunkt des Change-Records. Sie enthält den Auslöser (Lieferantenausfall, Qualitätsproblem, regulatorische Anforderung, Verbesserungsidee), die betroffenen Dokumente und Prozesse sowie den Antragsteller. Ohne diesen ersten Schritt als erzwungenes Pflichtfeld im System landet jede Änderung in einem informellen Kanal — und nie im Change-Register.
Welche Prozesse, Validierungen und Dokumente sind betroffen?
Das Impact Assessment beantwortet drei Fragen: Ist die Änderung nach §4.1.4 und §7.3.7 dokumentationspflichtig? Sind davon Validierungen nach §7.5.6 betroffen? Und — für Produkte in der MDR-Übergangsphase — ist die Änderung nach MDCG 2020-3 als wesentlich einzustufen? Dieser Schritt ist der Bewertungskern des Prozesses. Er muss von einer befugten Person durchgeführt und dokumentiert werden.
§7.3.7-Anforderungen erfüllen, bevor die Änderung live geht
Abhängig vom Impact Assessment: Muss die Änderung verifiziert werden (stimmt die Implementierung mit den Anforderungen überein)? Validiert (erfüllt das geänderte Produkt oder der geänderte Prozess seinen Zweck unter realen Bedingungen)? Diese Schritte dürfen nicht nach der Implementierung nachgeholt werden — §7.3.7 setzt sie vor die Umsetzung.
Wer darf diese Änderung freigeben — und auf welcher Basis?
Wie bei der Lenkung nicht-konformer Produkte gilt auch hier: Nicht jede Person darf jede Änderung freigeben. Das Change-Managementverfahren muss regeln, welche Änderungstypen welchen Freigabe-Level erfordern. Eine Layout-Änderung an einem Schulungsdokument ist etwas anderes als eine Materialänderung an einer sicherheitsrelevanten Komponente. Die Freigabe muss mit Datum, Person und Entscheidungsgrundlage dokumentiert sein.
Ein vollständiger Change-Record hat einen Eingang — die Anforderung — und einen dokumentierten Ausgang — die befugte Freigabe nach abgeschlossener Bewertung. Erst dann ist die Änderung aus Norm-Sicht abgeschlossen. Alles, was zwischen Anforderung und Freigabe passiert, muss nachvollziehbar im Datensatz stehen.
Auditoren prüfen bei §4.1.4 und §7.3.7 nicht nur, ob Änderungen dokumentiert wurden, sondern ob der Prozess vollständig ist: Gibt es ein zentrales Änderungsregister? Wurde jede Änderung mit einer Impact-Bewertung versehen? Sind Validierungsabhängigkeiten erkannt und nachgezogen worden? Und — falls relevant — liegt die Bewertung nach MDCG 2020-3 vor, die zeigt, dass das bestehende Zertifikat weiterhin gilt? Wer auf alle Fragen mit Belegen antworten kann, hat Änderungsmanagement als Steuerungsprozess etabliert — nicht nur als Ablage-Pflicht.
Zum Thema Lenkung nicht-konformer Produkte nach §8.3 gibt es ein eigenes Stück: Nichtkonformitäten und Änderungen haben einen direkten Berührungspunkt — nicht-konforme Produkte, die durch Rework korrigiert werden, lösen immer auch eine §7.3.7-Bewertung aus, wenn der Rework eine Abweichung vom Standarddesign bedeutet. Ebenso relevant: MDR-Meldepflicht nach Art. 87 — Feldkorrekturen nach erkannten Mängeln sind oft kombiniert aus §8.3-Ereignis, CAPA nach §8.5.2 und Change-Record nach §7.3.7.
Lenkung nicht-konformer Produkte: Quarantäne, Dispositionsentscheid und CAPA-Gate →
Vigilanz · EU-MDR Art. 87MDR-Meldepflicht: wann wird ein Feld-Ereignis zum meldepflichtigen Vorfall? →
QIMS Modul 12Änderungsmanagement im QIMS-Programm: Change-Record, Impact Assessment, Freigabe →
Änderung
beantragt.
Bewertet.
Freigegeben.
In einer Demo zeigen wir, wie QIMS Modul 12 den Change-Prozess von der Anforderungserfassung über das Impact Assessment bis zur befugten Freigabe abbildet — inklusive MDCG-2020-3-Bewertung für den MDR-Übergang, Verbindung zu betroffenen Validierungen und vollständigem Change-Register für die Audit-Frage.
Kein Pitch. Kein Abschlussgespräch nach dem Termin.