Die EU-Medizinprodukteverordnung (MDR) ist seit Mai 2021 verbindlich anwendbar und hat die Zulassungslandschaft für Hardware-Produkte im medizinischen Bereich grundlegend verändert. Für Startups, die ein Hardware-Produkt entwickeln wollen, das als Medizinprodukt klassifiziert wird, bedeutet das: höhere Anforderungen, längere Vorlaufzeiten und ein deutlich komplexeres Dokumentationsregime als unter der alten Medical Device Directive. Wer diese Realität unterschätzt, riskiert Verzögerungen von 12 bis 24 Monaten beim Markteintritt.
Dieser Artikel richtet sich an CTOs, Produktmanager und Gründer, die ein IoT-fähiges oder eingebettetes Medizinprodukt zur Marktreife bringen wollen. Die folgenden Abschnitte behandeln die konkreten regulatorischen Änderungen, ihre Auswirkungen auf die Hardware-Entwicklung und die häufigsten Fehler, die Startups in der Praxis machen.
Was sich gegenüber der alten MDD konkret geändert hat
Die MDR ersetzt die Medical Device Directive (93/42/EEC) nicht nur formal, sondern verschärft die Anforderungen in mehreren Kernbereichen substanziell. Drei Änderungen sind für Hardware-Teams besonders relevant.
Erstens wurde der Anwendungsbereich ausgeweitet. Produkte, die unter der MDD als allgemeine Zweckprodukte galten, fallen unter der MDR möglicherweise in den Geltungsbereich, wenn sie diagnostische oder therapeutische Zwecke erfüllen. Das betrifft insbesondere IoT-Geräte mit Vitalwerterfassung oder Entscheidungsunterstützungsfunktionen. Zweitens sind die Anforderungen an klinische Evidenz gestiegen: Post-Market Clinical Follow-up (PMCF) und klinische Bewertungsberichte sind jetzt für nahezu alle Klassen verpflichtend, nicht nur für Hochrisikoklassen. Drittens wurde die Rolle der Benannten Stellen gestärkt. Deren Kapazität ist begrenzt, Wartezeiten für Audits liegen 2026 bei 6 bis 18 Monaten, je nach Klasse und Stelle. Ein Failure Mode, der in der Praxis regelmäßig auftritt: Teams planen die Einreichung bei einer Benannten Stelle zu spät ein und verlieren dadurch das gesamte Markteinführungsfenster.
Risikoklassen unter der EU MDR: Einordnung für Hardware-Produkte
Die Klassifizierung bestimmt den Zertifizierungsaufwand direkt. Unter der MDR gelten vier Klassen: I, IIa, IIb und III. Für Hardware-Produkte mit eingebetteter Software oder Konnektivität ist die Einordnung nicht trivial.
Ein Wearable, das kontinuierlich die Herzfrequenz erfasst und Alarme ausgibt, wird in der Regel als Klasse IIa eingestuft. Das bedeutet: Konformitätsbewertung durch eine Benannte Stelle, vollständige technische Dokumentation, klinische Bewertung und ein zertifiziertes QMS nach ISO 13485. Die Kosten für eine Klasse-IIa-Zertifizierung liegen typischerweise zwischen 50.000 und 150.000 Euro, abhängig von Produktkomplexität und gewählter Benannter Stelle. Klasse-I-Produkte ohne Messfunktion können unter Selbstdeklaration vermarktet werden, was den Aufwand erheblich reduziert, aber die Klassifizierungsentscheidung muss dokumentiert und verteidigbar sein.
Ein häufiger Fehler: Teams nehmen an, dass Software-as-a-Medical-Device (SaMD)-Regeln nicht für ihre Hardware gelten. Sobald jedoch die eingebettete Firmware diagnostische Entscheidungen trifft oder Alarme auslöst, greift Anhang VIII Regel 11 der MDR, was typischerweise eine Hochstufung in Klasse IIa oder IIb auslöst.
Technische Dokumentation und QMS: Anforderungen in der Praxis
Die technische Dokumentation nach Anhang II und III der MDR ist umfangreicher als unter der MDD. Für Hardware-Produkte bedeutet das konkret: vollständige Designhistorie, Risikomanagementsystem nach ISO 14971, Verifizierungs- und Validierungsnachweise für Hardware und Firmware sowie eine klinische Bewertung.
Risikomanagementsystem nach ISO 14971
ISO 14971 verlangt eine systematische Identifikation, Bewertung und Kontrolle von Risiken über den gesamten Produktlebenszyklus. Für eingebettete Systeme bedeutet das: Fehleranalysen (FMEA) auf Hardware- und Firmware-Ebene, Bewertung von Software-Fehlerzuständen und Nachweis residualer Risikokontrolle. Teams, die das Risikomanagement als einmalige Dokumentationsaufgabe betrachten, scheitern regelmäßig beim Audit, weil Designänderungen nicht rückverfolgt wurden.
QMS nach ISO 13485
Ein zertifiziertes Qualitätsmanagementsystem nach ISO 13485 ist für Klasse IIa und höher verpflichtend. Der Aufbau eines QMS von Grund auf dauert typischerweise 6 bis 12 Monate und kostet zwischen 30.000 und 80.000 Euro, bevor das erste Audit stattfindet. Startups, die diesen Aufwand nicht in ihre Produktentwicklungsplanung einbeziehen, unterschätzen die Time-to-Market regelmäßig um ein Jahr oder mehr.
Design for Compliance: Wie MDR-Anforderungen die Hardware-Entwicklung beeinflussen
MDR-Anforderungen müssen in der Hardware-Architektur verankert sein, nicht nachträglich dokumentiert werden. Wer das Compliance-Framework erst nach dem Prototypenstadium einführt, muss in der Regel redesignen.
Konkrete Auswirkungen auf das Hardware-Design: Traceability-Anforderungen verlangen, dass jede Designentscheidung auf eine Anforderung zurückgeführt werden kann. Das bedeutet, Requirements-Management-Tools wie DOORS oder Jama Connect müssen von Beginn an integriert sein. EMV-Tests nach IEC 60601-1-2 für elektrische Medizinprodukte erfordern spezifische Schirmungs- und Filtermaßnahmen auf Schaltplan-Ebene, die nachträglich schwer zu integrieren sind. Wer frühzeitig auf Schaltplan und Simulation setzt, kann diese Anforderungen von Anfang an berücksichtigen. Biokompatibilitätsnachweise nach ISO 10993 müssen für alle körperberührenden Materialien erbracht werden. Das beeinflusst PCB-Beschichtungen, Gehäusematerialien und Klebeverbindungen direkt.
Ein konkretes Failure-Szenario: Ein IoT-Gerät zur Wundüberwachung wird mit einem Standard-BLE-Modul entwickelt, das nicht für den Medizinbereich qualifiziert ist. Beim Audit stellt die Benannte Stelle fest, dass kein Komponentenqualifizierungsnachweis vorliegt. Das Redesign mit einem qualifizierten Modul kostet 8 bis 16 Wochen Entwicklungszeit und verzögert die Zertifizierung entsprechend.
Häufige Fehler von Hardware-Startups bei der MDR-Zulassung
Startups wiederholen in der MDR-Zulassung eine überschaubare Menge an Fehlern mit vorhersehbaren Konsequenzen. Die folgende Liste basiert auf typischen Audit-Findings bei Klasse-IIa-Produkten.
- Klassifizierung zu spät durchgeführt: Die Klassifizierung wird nach Abschluss des Designs vorgenommen. Wenn das Produkt höher eingestuft wird als erwartet, sind Redesign und zusätzliche klinische Evidenz erforderlich.
- Unvollständige UDI-Planung: Das Unique Device Identification System erfordert Infrastruktur für Label, Datenbank-Registrierung (EUDAMED) und Rückverfolgbarkeit in der Produktion. Wird oft erst kurz vor Markteinführung adressiert, was zu Verzögerungen führt.
- Fehlende Post-Market-Surveillance-Struktur: PMS ist unter der MDR kein optionales Add-on. Ohne vorbereitete Feedbackschleifen und Meldesysteme für Vorkommnisse ist die Zertifizierung nicht aufrechtzuerhalten.
- Software-Lifecycle-Dokumentation fehlt: IEC 62304 verlangt eine vollständige Software-Lifecycle-Dokumentation. Firmware, die ohne strukturierten Entwicklungsprozess entstanden ist, muss retroaktiv dokumentiert werden, was den Aufwand verdoppelt.
- Benannte Stelle zu spät kontaktiert: Viele Startups nehmen erst Kontakt auf, wenn die Dokumentation vollständig ist. Frühzeitige Pre-Submission-Gespräche reduzieren das Risiko kostspieliger Überarbeitungen erheblich.
Nächste Schritte: MDR-Zulassung strategisch angehen
Die MDR-Zulassung ist kein linearer Prozess, der am Ende der Entwicklung beginnt. Sie muss parallel zur Hardware- und Firmware-Entwicklung aufgebaut werden, mit klaren Meilensteinen und Verantwortlichkeiten.
Ein realistischer Zeitplan für ein Klasse-IIa-IoT-Medizinprodukt von der Konzeptphase bis zur CE-Kennzeichnung liegt bei 24 bis 36 Monaten, wenn QMS-Aufbau, klinische Bewertung und Benannte-Stelle-Audit eingerechnet werden. Teams, die diesen Zeitrahmen auf 18 Monate komprimieren wollen, müssen entweder auf ein bestehendes ISO-13485-zertifiziertes QMS zugreifen oder mit einem Entwicklungspartner arbeiten, der diese Infrastruktur bereits mitbringt. Die Entscheidung zwischen internem QMS-Aufbau und einem zertifizierten Partner hat direkte Kostenimplikationen: Intern bedeutet 6 bis 12 Monate Vorlaufzeit und 30.000 bis 80.000 Euro Aufbaukosten, extern bedeutet höhere laufende Kosten, aber sofortigen Zugang zur Infrastruktur.
Der kritischste Schritt zu Beginn ist die Klassifizierungsentscheidung. Sie bestimmt den gesamten regulatorischen Pfad, die Wahl der Benannten Stelle und den Umfang der technischen Dokumentation. Wer hier auf eine externe Regulatory-Affairs-Beratung verzichtet, spart kurzfristig 5.000 bis 15.000 Euro und riskiert, später das Dreifache in Redesign und Dokumentationsüberarbeitung zu investieren.
Wie Oxeltech bei der MDR-konformen Hardwareentwicklung unterstützt
Wir bei Oxeltech begleiten Startups und Scale-ups bei der Entwicklung von Medizinprodukten, bei denen regulatorische Anforderungen von Anfang an in das Hardware- und Firmware-Design integriert werden müssen. Unser Ansatz umfasst:
- MDR-konforme Hardware-Architektur: Wir berücksichtigen EMV-Anforderungen nach IEC 60601-1-2, Komponentenqualifizierung und Traceability-Anforderungen bereits im Schaltplan- und PCB-Design.
- Firmware-Entwicklung nach IEC 62304: Unsere Embedded-Software-Entwicklung folgt einem strukturierten Lifecycle-Prozess, der die Dokumentationsanforderungen für Klasse-IIa-Software direkt erfüllt.
- Prototypen mit Zertifizierungsblick: Wir bauen Prototypen, die nicht nur funktionieren, sondern die Validierungs- und Verifikationsanforderungen der technischen Dokumentation bereits adressieren.
- Unterstützung bei der Serienproduktion: Von DFM über EMI/EMC-Optimierung bis zur Begleitung der Produktionsvorbereitung begleiten wir Produkte bis zur Serienreife.
Wenn ein IoT-Gerät oder ein eingebettetes System als Medizinprodukt zertifiziert werden soll, ist der Entwicklungspartner eine regulatorische Entscheidung, nicht nur eine technische. Sprechen Sie uns an und besprechen Sie mit uns, wie wir Ihr Projekt von Beginn an MDR-konform aufsetzen.
Ähnliche Artikel
- IoT Produktentwicklung Kosten: Was ein Hardwareprojekt wirklich kostet
- Wie funktioniert Herzfrequenz-Monitoring in einem Wearable-Gerät?
- Wie funktioniert kontinuierliche Überwachung mit einem Biosensor?
- Wie funktioniert BLE-Konnektivität in tragbaren Geräten?
- Wie integriert man GPS-Tracking energieeffizient in ein Wearable?
