--- title: "Grundlegende Anforderungen vs. Grundlegende Sicherheits- und Leistungsanforderungen: Was sich von MDD zu MDR geändert hat" description: "Die MDR hat die Grundlegenden Anforderungen der MDD durch die GSPR ersetzt. Hier die konkreten Änderungen und was sie für Ihre Compliance-Strategie bedeuten." authors: Tibor Zechmeister, Felix Lenhard category: MDR-Grundlagen & Regulatorische Strategie primary_keyword: canonical_url: https://zechmeister-solutions.com/de/blog/grundlegende-anforderungen-vs-gspr source: zechmeister-solutions.com license: Alle Rechte vorbehalten. Inhalte dürfen mit Quellenangabe und Link auf die kanonische URL zitiert werden. --- # Grundlegende Anforderungen vs. Grundlegende Sicherheits- und Leistungsanforderungen: Was sich von MDD zu MDR geändert hat *Von Tibor Zechmeister (EU-MDR-Experte, Lead Auditor Benannte Stelle) und Felix Lenhard.* ## TL;DR - Die MDR hat die Grundlegenden Anforderungen der MDD durch die GSPR ersetzt. Hier die konkreten Änderungen und was sie für Ihre Compliance-Strategie bedeuten. --- Wenn Sie Erfahrung mit dem alten MDD-Rahmen haben oder Dokumentation eines Bestandsprodukts geerbt haben, werden Sie auf Verweise auf „Grundlegende Anforderungen" (Essential Requirements, ERs) stoßen. Die MDR hat diese in Anhang I durch die „Grundlegenden Sicherheits- und Leistungsanforderungen" (GSPR) ersetzt. Das war keine kosmetische Umbenennung. Der Inhalt hat sich erheblich verändert, und die Unterschiede zu kennen ist wesentlich für jeden, der Dokumentation von MDD auf MDR überführt oder eine MDR-Konformitätsstrategie von Grund auf aufbaut. Hier ist, was sich geändert hat, was hinzugekommen ist und was das für Ihr Startup bedeutet. ## Was waren die Grundlegenden Anforderungen der MDD? Die MDD enthielt in Anhang I die Grundlegenden Anforderungen. Sie waren in allgemeine Anforderungen und Anforderungen an Auslegung und Konstruktion gegliedert. Die Struktur war relativ kompakt. Etwa 13 Abschnitte zu allgemeiner Sicherheit, Designanforderungen für bestimmte Produkttypen und Informationen, die mit dem Produkt geliefert werden. Die ERs definierten die fundamentalen Sicherheits- und Leistungserwartungen an Medizinprodukte, ließen aber erheblichen Spielraum für Auslegung. Viele Anforderungen waren breit formuliert und gaben Herstellern viel Flexibilität, wie sie Konformität nachweisen. ## Was sind die Grundlegenden Sicherheits- und Leistungsanforderungen der MDR? Anhang I der MDR ist deutlich detaillierter. Die dreigliedrige Struktur (Allgemeine Anforderungen, Anforderungen an Auslegung und Herstellung, Informationsanforderungen) deckt dasselbe Terrain ab wie die MDD-ERs, aber mit mehr Spezifität, mehr Unteranforderungen und mehreren völlig neuen Bereichen. Wesentliche strukturelle Unterschiede: **Mehr Abschnitte, mehr Detail.** Anhang I der MDR enthält etwa 23 Abschnitte gegenüber den rund 13 der MDD. Die zusätzlichen Abschnitte decken Bereiche ab, die die MDD entweder nur oberflächlich oder gar nicht behandelt hat. **Explizite Unteranforderungen.** Wo die MDD oft ein allgemeines Prinzip festschrieb, bricht die MDR es in konkrete Unteranforderungen herunter. Beispielsweise wird die allgemeine MDD-Anforderung zur biologischen Sicherheit in der MDR auf konkrete Aspekte der Biokompatibilität ausgeweitet, einschließlich chemischer, biologischer und physikalischer Charakterisierung von Materialien. **Neue abgedeckte Bereiche.** Die MDR ergänzt Anforderungen für: - Software und elektronische programmierbare Systeme (detaillierter als MDD) - Mit Netzwerken verbundene oder Netzwerksysteme integrierende Produkte (Cybersicherheit) - Produkte für Laienanwender (spezifische Anforderungen an Gebrauchstauglichkeit) - Produkte mit Nanomaterialien - Produkte mit Diagnose- oder Messfunktion (erweiterte Anforderungen) - Umgebungs- und Nutzungsbedingungen ## Welche Anforderungen wurden ergänzt oder verschärft? ### Software-Anforderungen (Abschnitte 14 und 17) Die MDD behandelte Software nur minimal. Die MDR widmet Software-Anforderungen eigene Abschnitte und reagiert damit auf das explosive Wachstum softwarebasierter Medizinprodukte seit Verfassung der MDD. Abschnitt 14 verlangt, dass Software gemäß dem Stand der Technik entwickelt wird, unter Berücksichtigung von Entwicklungslebenszyklus, Risikomanagement, Informationssicherheit, Verifizierung und Validierung. Für Software auf mobilen Plattformen müssen Hersteller die spezifischen Eigenschaften der Plattform und externe Faktoren der Nutzung berücksichtigen. Das ist eine direkte Reaktion auf den Aufstieg medizinischer Apps und Cloud-basierter Medizinprodukte, die es bei Verfassung der MDD noch nicht gab. ### Cybersicherheit und vernetzte Produkte (Abschnitt 17.4) Die MDD hatte keine expliziten Cybersicherheitsanforderungen. Die MDR schließt diese Lücke und verlangt, dass Produkte mit elektronischen programmierbaren Systemen, einschließlich Software, sowie reine Software-Produkte so ausgelegt sind, dass Wiederholbarkeit, Zuverlässigkeit und Leistung im Einklang mit der Zweckbestimmung gewährleistet sind. Für vernetzte Produkte verlangt die MDR geeignete Maßnahmen gegen unbefugten Zugriff. ### Nutzen-Risiko-Bewertung (Abschnitte 1-8) Die MDD verlangte ein vertretbares Risiko-Nutzen-Verhältnis, ohne aber zu spezifizieren, wie es zu bestimmen ist. Die MDR ist präskriptiver und verlangt eine strukturierte Nutzen-Risiko-Bewertung, die berücksichtigt: - Zweckbestimmung und vorhersehbarer Fehlgebrauch - Stand der Technik - Verfügbare alternative Lösungen - Vorgesehene Patientengruppe und Nutzerprofil - Eliminierung oder Reduzierung von Risiken so weit wie möglich, ohne das Nutzen-Risiko-Verhältnis nachteilig zu beeinflussen ### Produkte mit Diagnosefunktion (Abschnitt 14.2) Für Produkte mit Diagnosefunktion verlangt die MDR ausreichende Genauigkeit, Präzision und Stabilität, um die Zweckbestimmung zu erfüllen. Konkret fordert die MDR, dass Sensitivität und Spezifität bestimmt werden und Einschränkungen der Genauigkeit dem Anwender kommuniziert werden. Die MDD war bei der Leistungscharakterisierung von Diagnoseprodukten weniger spezifisch. ### Anforderungen für Laienanwender (Abschnitt 5) Die MDR ergänzt explizite Anforderungen für Produkte, die für Laienanwender (Nicht-Fachpersonal) bestimmt sind. Diese Produkte müssen so ausgelegt und hergestellt sein, dass sie ihre Zweckbestimmung angemessen erfüllen, unter Berücksichtigung der Fähigkeiten und der Mittel der Laienanwender sowie der Auswirkungen, die durch zu erwartende Schwankungen in Anwendungstechnik und Umgebung entstehen. Für Startups, die patientennahe Medizinprodukte bauen, ist das wesentlich. Sie müssen nachweisen, dass Ihr Produkt sicher und wirksam ist, wenn es von ungeschulten Anwendern in nicht-klinischen Umgebungen genutzt wird. ### Umgebungsbezogene Anforderungen Die MDR ergänzt Anforderungen an die Berücksichtigung der Umgebungsbedingungen, unter denen Produkte verwendet werden. Transport, Lagerung, Betriebsbedingungen einschließlich Temperatur, Feuchtigkeit, Druck und Lichtexposition. Die MDD hatte ähnliche, aber weniger detaillierte Anforderungen. ## Wie wirkt sich das auf Ihre GSPR-Bewertung aus? Wenn Sie Ihre GSPR-Bewertung von Grund auf erstellen (was bei den meisten Startups der Fall ist), bedeuten die erweiterten Anforderungen: **Mehr Abschnitte zu adressieren.** Sie müssen jeden Abschnitt und Unterabschnitt von Anhang I adressieren, nicht nur jene, die in der MDD enthalten waren. Auch wenn ein Abschnitt nicht für Ihr Produkt gilt, müssen Sie begründen, warum. **Konkretere Evidenz erforderlich.** Da die Anforderungen detaillierter sind, muss auch Ihre Evidenz konkreter sein. „Konform mit Biokompatibilitätsanforderungen" reicht nicht. Sie müssen Konformität mit jeder konkreten Unteranforderung zu Materialcharakterisierung, Biokompatibilitätstests und Bewertung von Restrisiken nachweisen. **Neue Dokumentationsbereiche.** Enthält Ihr Produkt Software, brauchen Sie einen dokumentierten Software-Entwicklungslebenszyklus gemäß EN 62304. Verbindet sich Ihr Produkt mit Netzwerken, brauchen Sie eine Cybersicherheits-Risikoanalyse und Maßnahmendokumentation. Wird Ihr Produkt von Laien verwendet, brauchen Sie Evidenz zur Gebrauchstauglichkeit gemäß EN 62366-1 mit besonderer Berücksichtigung von Laienszenarien. ## Wie überführen Sie MDD-Dokumentation auf MDR? Wenn Sie technische Dokumentation eines bestehenden MDD-Produkts geerbt haben und diese auf MDR-Konformität überführen müssen, hier der praktische Ansatz: **1. Alte ERs auf neue GSPR mappen.** Die Europäische Kommission hat eine Korrelationstabelle veröffentlicht, die MDD-Grundlegende Anforderungen auf MDR-GSPR abbildet. Nutzen Sie diese als Ausgangspunkt. **2. Lücken identifizieren.** Die GSPR ohne korrespondierende ER sind Ihre Lückenbereiche. Diese erfordern neue Dokumentation, neue Evidenz und eventuell neue Tests. **3. Tiefe vorhandener Evidenz bewerten.** Auch dort, wo MDD-ERs auf MDR-GSPR mappen, kann die MDR detailliertere Evidenz fordern. Eine Konformitätsaussage, die unter MDD reichte, kann unter MDR unzureichend sein. **4. Nach Risiko priorisieren.** Adressieren Sie zuerst die risikoreichsten Lücken. Software-Lebenszyklus, Cybersicherheit, klinische Evidenz und Nutzen-Risiko-Bewertung sind die Bereiche, auf die Auditoren am stärksten fokussieren. ## Der praktische Unterschied für Startups Aus Startup-Sicht bedeutet der Wechsel von ERs zu GSPR eines: Die Latte liegt höher, aber die Erwartungen sind klarer. Die Grundlegenden Anforderungen der MDD waren manchmal vage genug, dass Hersteller mit minimaler Evidenz Konformität behaupten konnten. Die GSPR der MDR sind spezifisch genug, dass Sie genau wissen, was erwartet wird. Was die Konformitätsplanung tatsächlich vereinfacht, auch wenn die Umsetzung mehr Arbeit ist. Tibors Rat ist konsistent: Sehen Sie die GSPR nicht als Hindernisse, Sehen Sie sie als Spezifikationsblatt Ihres Produkts, wenn Ihr Produkt jede zutreffende GSPR erfüllt, ist es sicher, erbringt seine Leistung und liefert die nötigen Informationen. Das ist keine regulatorische Last. Das ist gutes Produktdesign. Die Startups, die scheitern, behandeln die GSPR-Bewertung als separate Compliance-Übung, losgelöst vom Engineering. Die Startups, die gewinnen, integrieren GSPR-Bewusstsein vom ersten Tag an in ihren Designprozess. Wenn Ihr Engineer eine Designentscheidung trifft, sollte er wissen, auf welche GSPR sich diese Entscheidung bezieht. Wenn Ihr Qualitätsteam einen Test dokumentiert, sollte es wissen, welche GSPR dieser Test stützt. Bauen Sie GSPR-Bewusstsein in Ihr Team ein, nicht nur in Ihre Dokumente. Weiter: [Wer sind die Schlüsselakteure im MDR-Ökosystem? Zuständige Behörden, Benannte Stellen und mehr](/de/blog/mdr-oekosystem-akteure). --- *Dieser Beitrag ist Teil des Clusters [MDR-Grundlagen & Regulatorische Strategie](https://zechmeister-solutions.com/de/blog/category/mdr-fundamentals) im [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/de/blog). Für eine Beratung zur EU-MDR-Zertifizierung siehe [zechmeister-solutions.com](https://zechmeister-solutions.com).*