Design Change: Beispiele und Anforderungen

Dienstag 24. März 2020

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 eine 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 Changes. 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 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. neuste 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 meldepflicht 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 202-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 Kryptographie-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) 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.

e) 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.

5. Fazit und Zusammenfassung

Die MDCG bietet mit ihrem Dokument 2020-03 eine gute Hilfestellung, um zwischen signifikanten und nicht-signifikanten Design Changes 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 lässt eine weltweite Harmonisierung wünschen.

War dieser Artikel hilfreich? Bitte bewerten Sie:
1 vote, average: 5,00 out of 51 vote, average: 5,00 out of 51 vote, average: 5,00 out of 51 vote, average: 5,00 out of 51 vote, average: 5,00 out of 5

Autor des Beitrags " Design Change: Beispiele und Anforderungen

Johner Institut Gmbh

Logo Johner Institut klein

Bewertung 5 von 5 bei 1 Bewertungen


Kategorien: Regulatory Affairs

6 Kommentare über “Design Change: Beispiele und Anforderungen”

  1. Andreas schrieb:

    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ß

  2. Prof. Dr. Christian Johner schrieb:

    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

  3. Natalie Gudd schrieb:

    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

  4. Prof. Dr. Christian Johner schrieb:

    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

  5. Helmut Steiner schrieb:

    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

  6. Prof. Dr. Christian Johner schrieb:

    Sie haben absolut Recht, lieber Herr Steiner!

    Die neue Version lade ich gleich hoch.

    Besten Dank!

    Herzliche Grüße, Christian Johner

Kommentar schreiben