Ein Design Change ist eine Änderung der Auslegung eines Produkts. Es ist wichtig zu verstehen, wann solch eine Änderung als Significant Design Change zählt. Denn bei einem „Significant Design Change“ müssen meist Behörden und Benannte Stellen informiert und das Produkt muss neu zugelassen werden.

Bei einem „Significant Design Change“ können sich Hersteller in Europa nicht mehr auf die Übergangsfristen berufen, die die MDR im Artikel 120 gewährt.

Ebenso sind die Hersteller von bisherigen Klasse-I-Produkten betroffen, die unter der MDR erstmalig eine Benannte Stelle einbeziehen müssen.

Lesen Sie hier, welche Designänderungen als signifikant gelten. Damit vermeiden Sie Gesetzesverstöße, die sogar mit Freiheitsstrafen geahndet werden!

Kostenlose Infografik

Infografik zum kostenlosen Download! Damit Sie schnell und sicher entscheiden können, ob ein Design Change signifikant ist. Mit diesem Wissen vermeiden Sie Ärger mit Behörden!

1. Design Change: Was darunter zu verstehen ist

a) Definition

Die deutsche Ausgabe der Richtlinie übersetzt „Design Change“ als „Änderung der Auslegung“ des Produkts. D.h. immer dann, wenn sich am Entwurf des Medizinprodukts etwas ändert, liegt eine Designänderung vor.

Unter Design Change versteht man somit nicht (nur) die Änderung des (grafischen) Designs eines Produkts. Vielmehr versteht man darunter jede Änderung des Entwurfs eines Produkts nach dessen jeweiliger Freigabe – unabhängig davon, ob diese meldepflichtig ist.

Vorsicht!

Beachten Sie, dass die MDR auch bei einer Änderung der Zweckbestimmung von Design Change spricht, selbst wenn das Produkt völlig unverändert bleibt.

b) Beispiele

Von einem Design Change bzw. einer Designänderung spricht man beispielsweise, wenn der Hersteller das Folgende ändert:

  • Layout einer Platine
  • Benutzer-Produkt-Schnittstelle (das User Interface)
  • Funktionen, die das Produkt anbietet (weil dadurch etwas an der Auslegung geändert werden muss)
  • Leistungsangaben, z.B. die Genauigkeit eines diagnostischen Geräts oder die Energieabgabe eines HF-Chirurgiegeräts
  • Materialien, aus denen das Produkt gefertigt ist

Wenn ein Softwareentwickler beim Unit-Testen einen Bug korrigiert, spricht man nicht von einem Design Change. Wenn er oder sie hingegen feststellt, dass die bereits freigegebene Architektur einen Fehler enthält und diese ändert (implizit im Code oder/und explizit im Architekturdokument), dann liegt ein Design Change vor.

Die MDR zählt auch eine geänderte Zweckbestimmung als Design Change, z.B. neue Indikationen oder eine andere Anwendergruppe.

c) Betroffene Dokumente

Ein Design Change betrifft somit nicht nur System- und Softwarearchitekturen, sondern ebenso Änderungen an der Mechanik, an der Elektronik, an Materialien und selbst am Design Input inklusive der Zweckbestimmung!

Änderungen der Geometrie, Oberflächenstruktur, Farbe oder des Materials bedingen zwingend eine Neubewertung z.B. der Biokompatibilität (ISO 10993), Effizienzkontrolle der Aufbereitung (ISO 17664), Endreinigung (ISO 19227) und ggf. sogar der Sterilisation.

Je nach Intensität und Auswirkung des Changes müssen die Prozesse und Konformitäten im schlimmsten Fall komplett neu validiert bzw. belegt werden.

2. Regulatorische Anforderungen

a) Anforderungen der FDA an Design Changes

Die FDA hat festgestellt, dass man bei Problemlösungen oft neue Probleme einführt. Deshalb fordert sie, dass die Hersteller diese „Lösungen“ (Änderungen) sehr sorgfältig bewerten, bevor sie sie realisieren.

Konkret heißt es im Paragrafen 21 CFR § 820.30(i) „Design changes“:

Each manufacturer shall establish and maintain procedures for the identification, documentation, validation or where appropriate verification, review, and approval of design changes before their implementation.

In der Diskussion dieses Paragrafen weist die FDA auf Folgendes hin:

  1. Stellen Sie sicher, dass die Dokumente entsprechend überarbeitet und gelenkt (z.B. versioniert und freigegeben) werden.
  2. Stellen Sie durch Verifizierung und Validierung sicher, dass das Problem, das mit diesem Design Change gelöst werden soll, auch wirklich gelöst ist.
  3. Achten Sie darauf, dass die Änderungen genehmigt sind und dass bewertet wird, ob neue Probleme durch die Änderung verursacht wurden und ob die bisherigen Anforderungen weiterhin erfüllt werden.
  4. Kommunizieren Sie die Änderungen, damit andere Entwicklungsabteilungen, die Produktion, der Vertrieb und die Kunden darüber Bescheid wissen.
Weiterführende Informationen

Lesen Sie hier mehr zum Thema Guidance Document „Deciding When to Submit a 510(k) for a Change to an Existing Device“.

b) ISO 13485 zu Design- und Entwicklungsänderungen

Auch in Europa gibt es Anforderungen an den Umgang mit Designänderungen. So fordert die ISO 13485 in Kapitel 7.3, die Design- und Entwicklungsänderungen zu lenken.

Die Forderungen gleichen denen der FDA: Die Änderungen müssen

  • genehmigt,
  • bewertet,
  • verifiziert und validiert sowie
  • dokumentiert werden.

c) MDR

Die EU-Medizinprodukte-Verordnung MDR geht an mehreren Stellen auf Designänderungen ein, beispielsweise in:

  • Artikel 10 (9): „Changes in device design […] shall be adequately taken into account in a timely manner.“
  • Anhang VI, Teil C, 6.5.2 (Software): „A new UDI-DI shall be required whenever there is a modification that changes the original performance; the safety or the intended use of the software; interpretation of data. Such modifications include new or modified algorithms, database structures, operating platform, architecture or new user interfaces or new channels for interoperability.“
  • Anhang IX, 4.10: „Changes to the approved device shall require approval from the notified body which issued the EU technical documentation assessment certificate where such changes could affect the safety and performance of the device or the conditions prescribed for use of the device.“  

Auch im Kontext der Übergangsregelungen spielen die Designänderungen eine Rolle:

By way of derogation from Article 5 of this Regulation, a device with a certificate that was issued in accordance with Directive 90/385/EEC or Directive 93/42/EEC and which is valid by virtue of paragraph 2 of this Article may only be placed on the market or put into service provided that from the date of application of this Regulation it continues to comply with either of those Directives, and provided there are no significant changes in the design and intended purpose

MDR, Artikel 120

Vielen Herstellern fällt die Abschätzung schwer, wann eine Designänderung (ein Design Change) signifikant und meldepflichtig ist. Auch deshalb hat die MDCG die Leitlinie 2020-03 veröffentlicht (s.u.).

d) Health Canada

Zwar schon etwas älter, aber dennoch hilfreich, aktuell und sehr umfangreich sind die Vorgaben von Health Canada. Die Behörde hat bereits 2011 das „GUIDANCE DOCUMENT for the Interpretation of Significant Change“ veröffentlicht.

Bemerkenswert sind die Flussdiagramme zu den IVDs und zu den Änderungen an der Produktion, den Einrichtungen und dem Labeling.

3. Signifikante Design Changes: Wann eine Änderung meldepflichtig ist

a) Guidance Document der NBOG

Die Notified Body Operations Group (NBOG) hat einen „Guidance for manufacturers and Notified Bodies on reporting of Design-Changes and Changes of the Quality System“ publiziert, der etwas mehr Klarheit schaffen soll.

Darin beschreiben die Autoren, wann eine Designänderung als wesentlich („substantial“) zu bewerten und damit meldepflichtig ist. Das wäre jede Änderung am Produkt, die die Konformität mit den grundlegenden Anforderungen oder den vom Hersteller festgelegten Anwendungsbereich bzw. Kontraindikationen beeinflussen könnte.

Konkret benennt das Dokument Änderungen

  • der Zweckbestimmung, Indikation, Kontraindikation,
  • von Leistungsmerkmalen,
  • eines Zulieferers(!),
  • aufgrund von Risiken, die noch nicht betrachtet wurden,
  • von Warnungen,
  • der vorgesehenen Nutzergruppen,
  • der vorgesehenen Nutzung,
  • von Charakteristiken, die durch die klinische Bewertung noch nicht berücksichtigt sind,
  • als Folge von Überlegungen, die aus der Marktbeobachtung stammen inklusive aus Zwischenfällen, Rückrufen oder Beschwerden,
  • getrieben durch State-of-the-Art-Entwicklung (z.B. neueste Technologien),
  • die die Produktion beeinflussen, und
  • die die Sicherheit und Leistungsfähigkeit des Produkts betreffen.

b) MDCG 2020-03

Im März 2020 hat die MDCG die Leitlinie MDCG 2020-03 mit dem Titel „Guidance on significant changes regarding the transitional provision under Article 120 of the MDR with regard to devices covered by certificates according to MDD or AIMDD“ veröffentlicht.

Diese Leitlinie erläutert, wann ein Design Change meldepflichtig ist und wann nicht.

Nicht meldepflichtige Änderungen

Die MDCG stellt zunächst fest, worunter sie keinen meldepflichtigen Design Change versteht:

  • Administrative Änderungen
    • Name und Adresse des Herstellers
    • Rechtsform, z.B. von GmbH nach GmbH & Co. KG
    • Bevollmächtigter
  • Organisatorische Änderungen
    • Neue Fertigungsstätten, Umzug von Fertigungsstätten
    • Neue oder geänderte Lieferanten und Dienstleister
    • Im gewissen Umfang auch Änderungen am QM-System
  • Einschränkung der Zweckbestimmung
  • Korrekturmaßnahmen
  • Nicht-signifikante Änderungen am Produkt

Laut MDCG 2020-03 können sich Hersteller von den Benannten Stellen bestätigen lassen, dass eine Designänderung nicht signifikant ist. Das stellt aber kein ergänzendes Zertifikat dar.

Meldepflichtige Designänderungen

Die MDCG definiert folgende Änderungen als „signifikant“:

  • Erweiterung und Änderungen der Zweckbestimmung, z.B. neue Indikationen, neue Patientenpopulation, andere klinische Anwendung
  • UI-Änderungen, die weiterer Usability-Daten bedürfen
  • Änderungen der Leistungsspezifikation, insbesondere wenn neue klinische Daten berücksichtigt werden müssen
  • Designänderungen, die entweder Risiken erhöhen oder bestehende risikominimierende Maßnahmen betreffen, z.B. Alarme
  • Austausch oder Änderungen von Materialien, es sei denn, sie stammen von bestehenden Lieferanten und finden innerhalb unveränderter Spezifikationen statt
  • Änderungen am Sterilisationsprozess oder an der Verpackung, die einen Einfluss auf die Sterilität haben können
  • Viele Softwareänderungen
Weiterführende Informationen

Lesen Sie hier mehr zum Thema Design Changes bei Software und zu Beispielen für meldepflichtige Softwareänderungen.

Die MDCG beschreibt die Änderungen in Form von Flussdiagrammen. Die Infografik des Johner Instituts fasst diese Diagramme auf einer Seite zusammen und ergänzt sie um Beispiele.

Ausschnitt aus der Infografik, die die Vorgaben der MDCG zusammenfasst
Abb. 1: Ausschnitt aus der Infografik, die die Vorgaben der MDCG zusammenfasst

Sie können diese Infografik kostenlos herunterladen:

Kritik

Das MDCG-Dokument ist hilfreich. Es scheint aber keiner abschließenden Qualitätskontrolle unterzogen worden zu sein. Man hat das CAMD-Dokument „Joint Industry Position on Significant Changes According to MDR Article 120(3)“ weitgehend unverändert übernommen. Dazu zählt auch teilweise kaum lesbarer Text.

Das MDCG-Dokument leidet an manchen Stellen unter fehlenden Leerzeichen
Abb. 2: Das MDCG-Dokument leidet an manchen Stellen unter fehlenden Leerzeichen

Das Dokument lässt naturgemäß Fragen offen. Besonders zu den folgenden Fragen hätte man sich eine Antwort gewünscht:

  • Wie sollen Hersteller bei Änderungen am Produktionsverfahren entscheiden? Mit Ausnahme der Sterilisation gibt die MCDG keine Hilfestellung.
  • Welche Korrekturmaßnahmen (wohlgemerkt Korrekturmaßnahmen, nicht Korrekturen) will man durchwinken? Gilt das auch für eine meldepflichtige Korrekturmaßnahme, die mit einer nennenswerten Änderung am Design einhergeht? Die Reihenfolge des Flussdiagramms lässt genau das vermuten.
  • Weshalb will man Korrekturmaßnahmen durchwinken, Korrekturen aber nicht? Bei der Software deklariert man Bugfixes nicht als „signifikant“.
  • Umfasst „new user or patient population“ auch „changed user or patient population“? Vermutlich ja.
  • Soll „existing risks negatively affected“ ausdrücken, dass die bestehenden Risiken höher sind?
  • Muss wirklich jede Änderung an einer risikominimierenden Maßnahme als „significant design change“ gewertet werden? Selbst eine vorbeugende Maßnahme wie die wirksamere Auslegung einer solchen Maßnahme? Das könnte falsche Impulse setzen.
  • Soll jede Änderung an einer „database structure“ als signifikant eingestuft werden? Jede neue Spalte in einer Datenbank?
  • Welche Änderungen am User Interface (bei Software) sind nun signifikant? Selbst wenn man im Text die fehlenden Leerzeichen ersetzt, bleibt er unklar.
  • Welche Änderungen zur Verbesserung der IT-Security wollen die Autoren? Wenn die Änderung ein „major change of a component“ wäre, dann wäre dies nicht erlaubt. Der Austausch einer Kryptografie-Bibliothek bzw. eines entsprechenden Verfahrens wäre sicher „major“. Die Entscheidung C6 kommt zu einem anderen Ergebnis.

c) Guidance der Benannten Stellen (NB-MED)

Konkrete Definitionen und Beispiele für meldepflichtige und nicht-meldepflichtige Design Changes enthält das Dokument NB-MED/2.5.2/Rec2.

d) Positionspapier des TEAM-NB

Im Dezember 2020 hat das Team-NB ein „Position paper for the interpretation of device related changes in relation to a Notified Body Opinion as required under Article 117 of Medical Device Regulation (EU)2017/745“ veröffentlicht.

Dieses Dokument hat als Anwendungsbereich aber „nur“ Komponenten eines „drug device combination products“. Damit bezieht es sich auch nicht auf diese Typen an Änderungen:

  • Changes with respect to the Quality Management System
  • Changes to co-packaged devices
  • Organizational or administrative changes, e.g. manufacturing site, distributor, subcontractor, including their name, address and respective legal status

Dieses Positionspapier schreibt:

To facilitate a harmonized judgement of the substantial of changes, the following flowcharts (see Part II) have
been developed.

Positionspapier des TEAM-NB auf Seite 4

Diese Flowcharts ähneln jedoch sehr stark jenen im bereits vorgestellten Dokument MDCG 2020-3. Eine Referenz darauf findet sich im Team-NB-Dokument nicht. Das entspricht nicht guter wissenschaftlicher Praxis.

e) FAQ der CAMD

In seinen FAQ geht die CAMD (Competent Authorities for Medical Devices) auch auf die Fragestellung ein, wann eine Designänderung „signifikant“ ist. Wirklich Neues im Vergleich zum MDCG-Dokument enthält die Antwort auf Frage 17 aber nicht.

f) Scope des Zertifikats

Entscheidend ist zudem der Anwendungsbereich des Zertifikats: Falls Sie Ihr Produkt, das Sie über Anhang II der MDD bzw. über Anhang IX der MDR in den Verkehr bringen, so ändern, dass es nicht mehr in den Scope fällt, müssen Sie die Benannte Stelle einbeziehen.

Die Zertifikate erlauben Ihnen als Hersteller gerade, Produkte innerhalb des Zertifikats zu entwickeln und in den Verkehr zu bringen, ohne die Benannte Stelle um Erlaubnis zu fragen. Allerdings verlangen die Benannten Stellen häufig, informiert zu werden.

4. Sonderfall Software

Dieses Kapitel fasst die gesetzlichen Anforderungen und Leitlinien für Software zusammen.

Meldepflichtige Softwareänderungen

Eine Designänderung wäre bei Software wahrscheinlich dann meldepflichtig, wenn eine der folgenden Bedingungen vorliegt:

  • Es gibt eine Änderung an der Zweckbestimmung einschließlich
    • vorgesehener Nutzungsumgebung,
    • vorgesehener Nutzergruppen,
    • neuer oder anderer Indikationen,
    • weniger Kontraindikationen (also eine Erweiterung der Zweckbestimmung).
  • Sie beseitigen einen Fehler in der Software oder der zugehörigen Gebrauchsanweisung, um Risiken zu minimieren (> Rückruf).
  • Sie ändern die Benutzer-Produkt-Schnittstelle (unwesentliche Änderungen wie Korrektur von Rechtschreibfehlern ausgenommen). Das trifft insbesondere dann zu, wenn Sie
    • Warnmeldungen hinzufügen, ändern oder entfernen,
    • neue, sicherheitsbezogene Use Scenarios einfügen,
    • kritische UI-Elemente (ehemals Hauptbedienfunktionen) ändern.
  • Sie verwenden eine neue Technologie, z.B. ein neues Framework, neue SOUPs (gemeint ist nicht eine neue Version) oder gar eine andere Programmiersprache.
  • Die Software soll in einer anderen Laufzeitumgebung (Betriebssystem oder Version, Prozessor, Bildschirmgröße/-auflösung) eingesetzt werden.
  • Die Software muss eine neue Datenschnittstelle bedienen.
  • Die Entwickler fügen in der Datenbank neue Tabellen oder Fremdbeziehungen ein.
  • Die Entwickler ändern einen zentralen Algorithmus, z.B. zur Berechnung von Medikamentendosen, zur Bestrahlungsplanung oder für die Bildbearbeitung. Das betrifft insbesondere den Austausch von konventionellen Algorithmen durch KI-Algorithmen bzw. den Austausch eines KI-Modells (z.B. neuronales Netzwerk durch ein Boosting-Verfahren).

Nicht-meldepflichtige Softwareänderungen

Üblicherweise zählt man die folgenden Änderungen an einer Software nicht als meldepflichtig:

  • Bugfixes
  • Security Patches
  • Update einer SOUP durch eine neuere Version
  • Kleine Refactorings, z.B. innerhalb einer Methode
  • Änderungen an unkritischen Teilen des User Interfaces
  • Hinzufügen eines Attributs zu einer Datenbank oder Änderung des Datentyps eines Attributs
  • Anpassung der Software, um mit neuen Versionen einer bestehenden Schnittstellenspezifikation arbeiten zu können (z.B. Update von HL7 V2.7 auf 2.8)
  • Kleine Designänderungen am User Interface
  • Kleine Maßnahmen zur Verbesserung nicht-funktionaler Eigenschaften wie der Robustheit (z.B. zusätzliche Werteüberprüfung)

Allgemeine Tipps

Das Johner Institut empfiehlt, im Zweifelsfall mit der Benannten Stelle eine klare Absprache zu treffen. Die o.g. Liste sollte dabei eine Hilfe sein. In eingeschränktem Umfang steht Herstellern, Behörden und benannten Stellen für solche Einschätzungen das kostenlose Micro-Consulting zur Verfügung.

Die Unterscheidung der MDR und der IVDR zwischen Softwareänderungen, die eine Änderung der UDI-DI bedingen, und denen, die „nur“ eine Änderung der UDI-PI zur Folge haben, mag bei der Unterscheidung zwischen meldepflichtigen und nicht-meldepflichtigen Änderungen dienlich sein: Eine Änderung der UDI-PI ist üblicherweise nicht meldepflichtig.

Vorsicht!

Beachten Sie, dass viele Benannte Stellen in den Zertifizierungsverträgen die Hersteller verpflichten, alle Änderungen an den Produkten zu melden. Ob die Benannte Stelle dann auch prüft, ist eine andere Frage. Einen Vorbehalt von den Ergebnissen dieser Prüfungen sehen die Gesetze nicht vor, solange der Hersteller unter dem Anwendungsbereich seines Zertifikats handelt.

Die Hersteller sollten in diesem Zusammenhang den Anhang IX Absatz 2.4 der MDR beachten. Demnach müssen die Hersteller ihre Benannte Stelle über wesentliche Änderungen an Produkten und dem QMS unterrichten.

5. Fazit und Zusammenfassung

Die MDCG bietet mit ihrem Dokument 2020-03 eine gute Hilfestellung, um zwischen signifikanten und nicht signifikanten Designänderungen zu unterscheiden.

In einer zweiten Version des Dokuments sollten die Autoren

  • die offensichtlichen Fehler entfernen (uns Herstellern würde man so etwas nicht durchgehen lassen),
  • mit weiteren Beispielen und Erläuterungen zu den Entscheidungspunkten noch mehr Klarheit schaffen (wie z.B. in MDCG 2019-11),
  • fehlende Referenzen ergänzen, z.B. auf das CAMD-Dokument,
  • Hilfestellungen auch im Bereich der Produktionsänderungen, der IVD oder des Labelings ergänzen und
  • überprüfen, ob die Auswirkungen, die sich u.a. durch die Reihenfolge der Fragen ergeben, wirklich so gewünscht waren.

Wie sehr sich die Hersteller und die Benannten Stellen an die Vorgaben der MDCG halten, wird sich zeigen. Manchmal scheint es angesichts der Überlastung beider Seiten einen stillschweigenden Konsens zu geben, dass manch ein Design Change nicht so signifikant ist.

Die Vielzahl der regulatorischen Vorgaben führt zu dem Wunsch einer weltweiten Harmonisierung.


Änderungshistorie

  • 2021-06-06: In Poster Entscheidung bei „Materialien von neuem Lieferanten innerhalb der Spezifikation“ korrigiert (Danke an O. Tan für Hinweis!)
  • 2021-03-27: In Poster Hinweis auf „Competent Authority“ ergänzt
  • 2021-01-20: Unterkapitel zu TEAM-NB Dokument zu „drug device combination products“ ergänzt
  • 2020-01-26: Hinweis direkt über Kapitel 5 ergänzt

Wie hilfreich war dieser Beitrag?

Bitte bewerten Sie:

Durchschnittliche Bewertung 4.8 / 5. Anzahl Bewertungen: 19

Geben Sie die erste Bewertung!


Kategorien: Regulatory Affairs

12 Kommentare

  1. Andreas | Montag, 16. Juli 2018 um 09:51 Uhr - Antworten

    Guten Tag,

    Vielen Dank für Ihren Artikel, allerdings stellt sich mir eine Frage: Welche Änderungen sind dann kein Design Change wenn auch z.b. die Farbe der Verpackung eine Designänderung wäre?

    Vielen Dank für Ihre Antwort.

    MFG
    Dr. Breß


    • Prof. Dr. Christian Johner | Dienstag, 17. Juli 2018 um 17:19 Uhr - Antworten

      Sehr geehrter Herr Dr. Breß,

      wie groß eine Änderung sein darf, damit Sie nicht als Design Change gilt, hängt vom Risikomanagement und der Art der Änderung ab. Beispielsweise gibt Ihnen die MDR bei SW einen Hinweis: Die Änderungen, die nur einer neuen Product Identification bedürfen, aber keiner neuen Design Identification, könnte man als ausreichend klein charakterisieren.

      Beste Grüße, Christian Johner


  2. Natalie Gudd | Montag, 3. Februar 2020 um 14:00 Uhr - Antworten

    Sehr geehrter Herr Johner,
    zu Ihrer Antwort vom Dienstag 17. Juli 2018 um 17:19 bräuchte ich eine Aufklärung: Was meinen Sie mit der „Design Identification“? In der MDR kommt dieser Begriff nicht vor. Nur „Device Identifyer“. Eine neue UDI-DI braucht man schon, wenn sich die Version der SW ändert. Und die ändert sich bereits bei kleinster Änderung.
    Wo befindet sich dieser Hinweis für SW in der MDR?

    Für eine Rückmeldung wäre ich sehr dankbar.

    Mit freundlichen Grüßen
    Natalie Gudd


    • Prof. Dr. Christian Johner | Montag, 3. Februar 2020 um 20:20 Uhr - Antworten

      Sehr geehrte Frau Gudd,

      da scheine ich mich vertippt zu haben. Ich meinte natürlich mit DI den Device Identifier.

      Die Hinweise auf sie Software finden Sie im Anhang VI, Teil C 6.5.

      Beste Grüße, Christian Johner


  3. Helmut Steiner | Dienstag, 24. März 2020 um 17:46 Uhr - Antworten

    Sehr geehrter Herr Johner,
    Vielen Dank für die ausführliche Zusammenfassung!
    Leider ist Ihnen beim Erstellen des Design-Change Posters ein Fehler unterlaufen. Die Beschriftung der Pfeile abgehend von Software-Änderungen?->Kleine Änderung? ist genau andersrum. Kleine Änderungen sind, wie im Artikel richtig beschrieben, nicht signifikant.
    Mit freundlichen Grüßen,
    Helmut Steiner


    • Prof. Dr. Christian Johner | Dienstag, 24. März 2020 um 18:22 Uhr - Antworten

      Sie haben absolut Recht, lieber Herr Steiner!

      Die neue Version lade ich gleich hoch.

      Besten Dank!

      Herzliche Grüße, Christian Johner


  4. Lisa Borchert | Mittwoch, 10. März 2021 um 13:43 Uhr - Antworten

    Guten Tag,

    gilt die Änderung des Produktnamens nach 26.05.2021 als signifikant? Dadurch ergeben sich einige nötige Anpassungen, allerdings bleibt das unter MDD zertifizierte Produkt ansonsten identisch.
    Vielen Dank,
    L. Borchert


    • Prof. Dr. Christian Johner | Donnerstag, 11. März 2021 um 20:58 Uhr - Antworten

      Sehr geehrte Frau Borchert,

      die MDCG 2020-03 ist hier ein relevantes Dokument. Sie erfüllen keine der dort genannte Kriterien. Damit ist der Change als nicht signifikant einzuordnen.

      Allerdings wäre dieser in der EUDAMED zu hinterlegen.

      Ich würde mir die Änderung von Ihrer Benannten Stelle schriftlich bestätigen lassen, um späteren Ärger zu vermeiden, da auf dem Zertifikat ein anderer Produktname steht.

      Viele Grüße, Christian Johner


  5. Daniel Grabner | Mittwoch, 24. März 2021 um 08:26 Uhr - Antworten

    Guten Morgen Herr Johner,

    In Ihrer Infografik Design Change v6 ist dargestellt, das alle Designänderungen im Rahmen einer Korrekturmaßnahme als nicht siginifkant zu bewerten sind. Laut MDCG-2020-03 müssen diese Korrekturmaßnahmen aber von der zuständigen Competent Authority akzeptiert worden sein. Zu einer solchen Bewertung durch die Competent Authority kommt es meiner Meinung nach nur bei einer Korrekurmaßnahme im Feld auf Grundlage eines Vorkomnisses.

    Mit freundlichen Grüßen
    Daniel Grabner


    • Prof. Dr. Christian Johner | Mittwoch, 24. März 2021 um 21:02 Uhr - Antworten

      Sehr geehrter Herr Grabner, danke für Ihren Hinweis!
      Ihr Hinweis betraf die Anmerkung im MDCG-Dokument zu den „competent authorities“. Diesen habe ich im Poster ergänzt.
      Nochmals vielen Dank!
      Viele Grüße, Christian Johner


  6. Olaf Kessel-Deynet | Freitag, 11. Juni 2021 um 15:48 Uhr - Antworten

    Sehr geehrter Herr Johner,

    herzlichen Dank für die gute Zusammenfassung!

    Ich habe eine Frage bzgl. dem Bewertungsbaum in der MDCG 2020-03, speziell zu den Materialänderungen.

    Die Frage D4 „Ingredient ormaterial from new suppliermeetsexisting specification“ (Originaltext !) verzweigt bei Beantwortung mit ja zurück in die Bewertung B bei Vorliegen eines „Design or performance change“.

    Mir erschließt sich der Sinn dieser Rückverweisung nicht, denn falls ich einen Change hätte, auf den Chart B zutrifft, wäre ich doch beim Abarbeiten des Main Charts eh schon in diesen eingetreten? Welchen Sinn hat dann diese Doppelbewertung?

    Oder habe ich da ein grundlegendes Verständnisproblem?

    Herzlichen Dank & freundliche Grüße
    Olaf Kessel-Deynet


    • Prof. Dr. Christian Johner | Sonntag, 13. Juni 2021 um 10:48 Uhr - Antworten

      Sehr geehrter Herr Kessel-Deynet,

      eine ausgezeichnete Frage! Was genau in den Köpfen der Autoren vor sich ging, weiß ich auch nicht. Daher kann ich nur spekulieren.

      Möglicherweise wollten die Autoren, dass man für den neuen Supplier nochmals überlegt, ob es Risiken gibt, die speziell für diesen Supplier untersucht oder/und beherrscht werden müssen. Beispielsweise hat der Supplier ein anderes Fertigungsverfahren oder ein anderes QS-System. Dann müsste man die Risikoüberlegung nochmals anstellen.

      Ihr Gedanke, dass man sich diese Überlegungen auch beim ersten Durchlauf bereits hätte machen könnte, ist dennoch logisch.

      Viele Grüße, Christian Johner


Hinterlassen Sie einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.