Medizinprodukte-Entwicklung: EU-MDR-Leitfaden von der Idee zur CE-Kennzeichnung

Rund drei von vier Medizinprodukte-Entwicklungs-Start-ups erreichen nie den Markt. Laut der Focused Ultrasound Foundation liegt die Ausfallrate bei knapp 75 Prozent.

Meist passieren diese Fehler in der regulatorischen Akte, bei der Design-Dokumentation oder dem Unterschied zwischen Labor-Prototyp und einem Produkt-Audit der benannten Stelle.

Das wirft eine Frage auf:
Wie entwickelt man ein Medizinprodukt von der Idee bis zur CE-Kennzeichnung, MDR-konform und auditbereit, ohne mehrjährigen Umwege oder zu scheitern?

Dieser Leitfaden beschreibt die Medizinprodukte-Entwicklung genau so, wie sie für EU- und DACH-Start-ups tatsächlich abläuft: Fünf Phasen, mit der EU-MDR im Zentrum des Rahmens.

Zunächst zeigen wir, wie der Build-on-Top-Capability-Stack die Reihenfolge verändert. Außerdem erfahren Sie, wo Teams den Großteil ihres Budgets verbrennen und welche regulatorischen Aspekte Sie nicht auf die letzten sechs Wochen verschieben können.

Inhaltsverzeichnis

Warum die meisten Entwicklungs Frameworks die EU Realität verfehlen

Der Begriff „5 Phasen” bezieht sich üblicherweise auf den Design-Control-Ablauf der FDA mit 510(k)-Einreichungen als Rahmen jeder Entscheidung, aud amerikanischer Sicht.

Für ein Start-up in Berlin oder Stockholm, das sein Produkt für den europäischen Markt CE-kennzeichnen möchte, lässt dieser Rahmen jedoch genau die regulatorischen Fragen aus, die über das Projekt entscheiden.

Klassifizierung und benannte Stelle

Die EU-Medizinprodukteverordnung, Verordnung 2017/745, verändert den Pfad auf eignene Weise.

Erstens ist die Klassifizierung anspruchsvoller: Anhang VIII und besonders Regel 11, die Software zur Bereitstellung von Informationen für Diagnose oder Therapie betrifft, schieben beispielsweise einen erheblichen Teil digitaler Gesundheitsprodukte hoch in Klasse IIa oder IIb.
Zweitens wird die benannte Stelle zum zentralen Partner statt zur Randnotiz: Für jedes Produkt über Klasse I wird nämlich sowohl das Qualitätsmanagementsystem als auch die technische Dokumentation geprüft.

Die Vorlaufzeiten liegen dabei typischerweise bei 12 bis 18 Monaten, weshalb die Auswahl einer benannten Stelle in Phase 2 gehört und das lange vor Phase 4.

Klinische Beweise unter MDR

Drittens sind klinische Beweise nach der MDR schwerer zu erbringen als nach der alten MDD oder den FDA-Äquivalenten. Konkret legen Artikel 61 und die dazugehörige MDCG-Leitlinie, darunter MDCG 2020-13 und MDCG 2021-24, einen Pfad für die klinische Bewertung fest.

Folglich sind Äquivalenzansprüche schwerer zu verteidigen. Zudem reichen reine Literaturrecherchen oberhalb von Klasse IIa selten aus.

-> In kurz: Ein generischer 5-Phasen-Rahmen führt zu einem funktionierenden Prototyp. Zu einem CE-gekennzeichneten Produkt führt er jedoch nicht, da die regulatorischen Maßnahmen der ersten Phase ignoriert werden.

Was ist zu tun:

Formuliere in der ersten Woche die Zweckbestimmung und treffen nur daruaf basierende Architekturentscheidungen.
Erstelle außerdem in Phase 2 eine Vorauswahl benannter Stellen. Namen, Kapazität, Scope-Codes und aktueller Rückstand.
Ließ schließlich MDCG 2019-11 und MDCG 2020-3 einmal durch und halte diese anschließend griffbereit.

Phase 1: Discovery und Machbarkeit

In Phase 1 der Medizinprodukte-Entwicklung stellen sich die meisten Projekte entweder gut auf oder legen den Grundstein für eine spätere harte Strecke. Konkret teilt sich die Arbeit in zwei parallele Stränge:

klinische und kommerzielle Validierung
Klassifizierung und regulatorisches Denken

Klinische und kommerzielle Validierung

Auf der Seite der klinischen und kommerziellen Validierung gelten die üblichen Schritte:

den Nutzer definieren
das tatsächliche klinische Problem finden
die bestehenden Lösungen herausarbeiten
mit Klinikern austauschen
die Zahlungsbereitschaft fesstellen

Entscheiden Sie sich zudem für Ihren Einführungsmarkt. Wenn EU, dann grenzen Sie ihn für den ersten CE-Zyklus auf ein oder zwei Mitgliedsstaaten ein.

Medizinproduktespezifisch ist vor allem die Dokumentationsdisziplin. So muss jedes Interview, jede Produktannahme und jede Entscheidung in einem kontrollierten Datensatz landen.

Klassifizierung als frühe Wegweiser

Am meisten wird die Klassifizierung in der Anfangsphase unterschätzt. Unter MDR bestimmt Ihre Zweckbestimmung Ihre Klasse. Diese bestimmt wiederum das Konformitätsbewertungsverfahren, den Umfang der technischen Dokumentation sowie das Niveau der erforderlichen klinischen Beweise.

Ein einziger Satz, etwa ob das Gerät „überwacht" oder „diagnostiziert", kann beispielsweise die Klasse I auf Klasse IIa heben. Anhang VIII hat dafür 22 Klassifizierungsregeln.

Für Software ist Regel 11 die wichtigste. Für Wearables und Sensoren entscheiden hingegen meist die Regeln 9, 10 und 12. Daher sollte die Klassifizierung in Phase 1 als Arbeitshypothese durchgeführt werden und kann dann immer verteidigt werden.

-> In kurz: Phase 1 liefert eine Zweckbestimmung, eine Arbeitsklassifizierung und eine Vorauswahl benannter Stellen. Wird eines davon ausgelassen, dann wird Phase 4 zu einem Jahr teurer Korrekturen.

Was ist zu tun:

Entwirf zuerst die Zweckbestimmung vor allen technischen Spezifikationen.
Führe danach eine vorläufige MDR-Klassifizierung nach Anhang VIII durch und dokumentiere die Begründung.
Erstelle zudem eine Vorauswahl benannter Stellen mit mindestens drei Namen, geordnet nach Scope-Codes und Rückstand.

Phase 2: Konzept und Prototyp

In Phase 2 wird der in Phase 1 festgelegte Bedarf in etwas Greifbares verwandelt. Hier wird getestet, vorgeführt und notfalls weggeworfen und neu gestartet.

Konkret ist das Lieferobjekt ein Proof of Concept: genug funktionierende Hardware und Software, um die riskantesten Annahmen zu testen. Es ist weit entfernt von einer sterilen Produktionseinheit.

Technische Machbarkeit

Der erste Arbeitsschritt ist die technische Machbarkeit.

Für Produkte mit Sensorik ist dies beispielsweise der Moment, Sensorkandidaten, Signalqualität, Power-Budgets sowie den Datentransfer vom Gerät zum Backend zu überprüfen.
Für reine Softwareprodukte ist es der Zeitpunkt, den Algorithmus mit den tatsächlichen Datenquellen zu validieren.

Unabhängig davon ist das Ziel, die technischen Risiken auszuräumen, bevor man sich auf ein vollständiges Design festlegen.

regulatorisches Rahmenwerk

Der zweite Teil der Arbeit ist das regulatorische Gerüst. In Phase 2 beginnt nämlich die Arbeit am QMS, verankert in ISO 13485:2016. Außerdem wird hier mit der Risikoakte gestartet.

ISO 14971:2019 ist dabei die maßgebliche Norm und die erste Risikoanalyse sollte abgeschlossen sein, bevor Code eingecheckt oder eine Platine gefertigt wird.

Hier wird zudem die Vorauswahl benannter Stellen relevant.

Die meisten binden sich formell zwar erst bei einem QMS-Entwurf, dennoch sollte man schon in Phase 2 Kontakt aufnehmen. Einen Slot 12 Monate im Voraus zu buchen, ist unter aktuellen MDR-Bedingungen nämlich normal.

Beispiel: Bewertung der Technischen Machbarkeit

Wir haben das beispielsweise sauber mit einem Gründer im Stealth-Stadium erlebt, der einen 3 mm großen Wearable-Sensor entwickelt, der unter einer Smartwatch sitzt.

Eine Bewertung der Technischen Machbarkeit in Phase 2 fixierte dabei Zweckbestimmung, MDR-Klassifizierung und Sensorbewertung in sechs Wochen statt in den sechs Monaten, die eine offene Discovery gebraucht hätte. Zudem hatte der Gründer eine belastbare Produktplanung für Phase 3 in der Hand.

-> In kurz: In Phase 2 werden technische Risiken ausgeräumt und die regulatorische Dokumentation begonnen. Wenn das QMS-Gerüst und die Risikoakte am Ende von Phase 2 nicht existieren, wird Phase 3 nicht MDR-konform sein.

Was ist zu tun:

Zunächst legst du fest, welche Annahmen der Prototyp validieren muss. Baue dann den kleinstmöglichen Prototypen.
Starte außerdem parallel dazu mit dem QMS und der Risikoakte.
Nimm schließlich ersten Kontakt zu zwei oder drei benannten Stellen aus der Phase-1-Liste auf.

Phase 3: Design und Entwicklung (der Capability-Stack)

Dies ist die größte und längste Phase, in der der Build-on-top-Capability-Stack tatsächlich auftaucht.

Oft wird Phase 3 als ein Block behandelt. Dieser Rahmen verfehlt jedoch die Komplexität moderner Medizinprodukte, da ein Gerät heute in der Regel als mehrere koordinierte Schichten den Patienten erreicht.

Die sieben Schichten des Capability-Stacks

Von unten nach oben gelesen, bringt jede Schicht ihre eigenen Normen mit:

Hardware: Sensoren, Mikrocontroller, Stromversorgung, Gehäuse sowie biokompatible Materialien (IEC 60601, ISO 10993).
Embedded-Firmware: RTOS, Treiber, Kommunikationsstacks (BLE, GSM, Wi-Fi) und Power-Management (IEC 62304, Cybersecurity nach MDR Anhang I).
Sensor-Signalverarbeitung: Filterung, Kalibrierung sowie Feature-Extraktion, oft ein trennbares Modul (IEC 62304 Klasse B oder C).
KI- und ML-Inferenz: Klassifikation, Vorhersage und Drift-Monitoring, mit Predetermined Change Control (PMS) Plan sowie Performance-Monitoring.
Companion-App: die Oberfläche für Patient oder Kliniker, die am häufigsten das Produkt auf Klasse IIa oder höher hebt.
Cloud und klinische Daten: Patientendaten-Backend, Klinikerportal sowie Registry-Feeds, mit DSGVO-Pflichten und ISO-27001-Ausrichtung.
Regulatorischer Mantel: Designänderungsdokument, technische Dokumentation, Bericht zur klinischen Bewertung sowie PMS-Plan, der jede darunterliegende Schicht referenziert.

Warum die Schichtung strategisch ist

Jede hinzugefügte Schicht erhöht die regulatorische Masse. Ein Wearable ohne App hat beispielsweise eine bestimmte regulatorische Gestalt. Fügen Sie die App hinzu, bewegt sich dasselbe Produkt hingegen in eine andere Kategorie.

Wir haben mehrere Projekte gesehen, bei denen die Gründer die Kosten von Schicht 1 und 2 korrekt kalkuliert hatten, jedoch von den Kosten der Schichten 4 bis 7 überrascht wurden. Die richtige Reihenfolge in Phase 3 ist entscheidend.

Erstelle zunächst eine Architektur des vollen Stacks auf als Entwurf. Entscheide anschließend, welche Schichten für die erste CE-Version erforderlich sind und welche auf eine v2 verschoben werden können. Baue schließlich die Schichten nacheinander und validiere jede gegenüber ihren Design-Inputs.

Fallstudie: Everon

Das Everon-Gerät, ein sprachgesteuerter GSM-Kommunikator, der mit einem BLE-Armband für die häusliche Pflege kombiniert ist, ist ein gutes Beispiel für richtig umgesetztes Stack-Denken.

So werden Hardware, Embedded-Firmware, Sensor-Signalverarbeitung (Sturzerkennung), Companion-App und Cloud zu einem einzigen, CE-gekennzeichneten Produkt integriert.

Dabei wurde jede Schicht gegen MDR-konforme Design-Controls spezifiziert und getestet.

Die Lehre steckt zudem ebenso in der regulatorischen Akte wie in der Technik. Jede Schicht der Architektur ist nämlich zugleich eine dokumentierte Einheit in der technischen Akte, der Risikoanalyse und dem Verifizierungsplan.

-> In kurz: Phase 3 sollte um den Capability-Stack herum gestaltet werden. Der Grund, warum die meisten Projekte unterkalkuliert werden, ist, dass sie als einen einzigen Block „Engineering” behandelt werden.

Was ist zu tun:

Erstelle vor jeder Sprint-Planung zunächst einen Capability-Stack und markiere die Schichten entsprechend dem Umfang der ersten CE-Version.
Binde anschließend jede Schicht an die entsprechenden Normen (IEC 62304, IEC 60601, ISO 10993, DSGVO, ISO 27001) an.
Binde zudem Design-Inputs an konkrete Schichten in deinem DHF, um die Rückverfolgbarkeit in Phase 4 sicherzustellen.

Phase 4: Verifizierung, Validierung und der EU-Regulierungspfad

In Phase 4 trifft das in Phase 3 produzierte technische Design auf das Audit.

Zunächst erzeugen Verifizierung und Validierung die erforderlichen Nachweise.
Im Anschluss macht das Konformitätsbewertungsverfahren aus dieser Evidenz eine CE-Kennzeichnung.

Verifizierung und Validierung

Verifizierung beantwortet „Haben wir das Gerät richtig gebaut?" und prüft dabei gegen Design-Spezifikationen. Validierung beantwortet hingegen „Haben wir das richtige Gerät gebaut?" und prüft gegen Anwenderbedürfnisse und Zweckbestimmung.

Hier laufen mehrere Normen zusammen:

IEC 62304 für den Software-Lebenszyklus
ISO 14971 für das Risikomanagement
IEC 60601 für die Elektrosicherheit
ISO 10993 für die Biokompatibilität
ISO 13485 für Ihre QMS-Verfahren

Folglich braucht jede Schicht des Stacks ihre eigenen Beweis.

Klinische Bewertung

Meistens wird die klinische Bewertung unterschätz. Unter MDR Artikel 61 und MDCG 2020-13 geht der Bericht nämlich weit über eine Literaturrecherche hinaus.

Konkret ist hier die Aufgabe ein strukturiertes Argument, dass die Sicherheit und Funktion des spezifischen Geräts und dessen Zweckbestimmung belegt.

Für Klasse IIa können Äquivalenzansprüche das manchmal tragen.
Für Klasse IIb und III braucht man hingegen fast immer Daten aus einer klinischen Prüfung.

Planen Sie das deshalb spätestens als Phase-3-Aktivität, mit parallel laufender Patienteneinschreibung.

Das Konformitätsbewertungsverfahren

Das Verfahren folgt der Klassifizierung.

So erklären selbstzertifizierte Klasse-I-Geräte selbst Konformität und registrieren sich.
Klasse I steril, Klasse I mit Messfunktion sowie Klasse IIa und höher durchlaufen hingegen eine benannte Stelle.
Für Software in Klasse IIa und höher wird außerdem ein vollständiges QMS-Audit mit ISO 13485 und eine Prüfung der technischen Dokumentation erwartet. Der volle Zyklus dauert dabei typischerweise 12 bis 18 Monate.

-> In kurz: Die vierte Phase als „Testen des Geräts” zu bezeichnen, wäre untertrieben. In dieser Phase werden dokumentierte, rückverfolgbare Beweise erstellt. Ohne klinische Bewertung, technische Dokumentation und QMS-Audit gibt es keine CE-Kennzeichnung.

Was ist zu tun:

Baue den Verifizierung und Validierungs-Plan auf Basis der Schicht-Architektur und nicht auf Basis einer generischen Checkliste.
Starte zudem die klinische Bewertung bereits in Phase 3.
Binde schließlich deine benannte Stelle 12 bis 18 Monate vor dem angestrebten CE-Datum ein.

Phase 5: Markteinführung und Überwachung im Nachhinein

Bei Phase 5 der Medizinprodukte-Entwicklung hört vieles auf, doch unter MDR wird es hier noch schwerer.

PMS, PSUR und PMCF

Die Überwachung nach der Markteinführung unterscheidet sich strukturell von den FDA-Post-Market-Pflichten. Konkret verlangen die Artikel 83 bis 86 sowie MDCG 2022-21 mehrere Bausteine:

ein PMS-System als laufenden Prozess
einen PMS-Plan
für Klasse IIa und höher einen Periodic Safety Update Report, den Ihre benannte Stelle bewertet

Post-Market Clinical Follow-up ist zudem für die meisten Geräte über Klasse I verpflichtend.

Der PMCF-Plan ist dabei Teil der bei der Zertifizierung eingereichten Akte zur klinischen Bewertung. Außerdem laufen Aktualisierungen in einer definierten Taktung.

EUDAMED, Vigilanz und Software

EUDAMED, die europäische Datenbank, ist das Rückgrat für Registrierung und Meldung. So fließen Ihre UDI, Ihr Gerät, Ihr Zertifikat, Ihre Vorkommnisse sowie Ihre PMS-Ergebnisse alle durch diese.

Die Fristen für Ereignismeldungen sind dabei eng: schwerwiegende Vorkommnisse innerhalb von 15 Tagen, Todesfälle innerhalb von 2 Tagen.

Für Software-Geräte umfasst die Post-Market-Schicht zudem Cybersecurity-Ereignisse und das Performance-Monitoring von KI oder ML.

Ein Predetermined Change Control Plan erlaubt beispielsweise Modell-Updates ohne Neuzertifizierung, sofern er bei der ursprünglichen Zertifizierung genehmigt wurde. Plane den PCCP deshalb bereits in Phase 3.

-> In kurz: Phase 5 mit MDR läuft als fortlaufende operative Arbeit, mit PMS, PSUR, PMCF und EUDAMED-Meldungen in klarem Takt über die gesamte Produktlebensdauer.

Was ist zu tun:

Stelle zunächst sicher, dass für die PMS-Funktion von Anfang an Verantwortung übernommen wird.
Verbinde die Beschwerdebearbeitung, Ereignismeldungen und das CAPA-System zu einer einzigen Datenquelle.
Plane schließlich die erste PSUR-Prüfung für den 12. Monat (Klasse IIa) bzw. den 6. Monat (Klasse IIb und III).

Wo die Medizinprodukte-Entwicklung tatsächlich Budget verbrennt

Über unsere Projekte hinweg kommen fünf Fehlermuster immer wieder. Keines davon ist selten und alle lassen sich klar vermeiden.

1. Falsch klassifizierte Zweckbestimmung

Während Phase 2 oder 3 verändert sich die Zweckbestimmung, während Funktionen hinzukommen. So schleicht ein Produkt der Klasse IIa in Richtung Klasse IIb. Das Team erfährt davon jedoch erst beim Audit, wenn die Arbeit der letzten sechs bis zwölf Monate neu dokumentiert werden muss.

Die Lösung: Lege die Zweckbestimmung in Phase 1 fest und behandele jede Änderung als formalen Änderungsantrag.

2. Rückwärts gebaute Risikoakte

Die ISO-14971-Gefährdungsanalyse beginnt beispielsweise in Monat 18, weil „wir das vor dem Audit machen". Folglich wird die Risikoakte am Ende aus dem Gedächtnis rekonstruiert. Die Rückverfolgbarkeit hält dann nicht, weshalb die benannte Stelle Lücken findet.

Die Lösung: Eröffne die Risikoakte in Phase 2 vor dem ersten Sprint. Pflege sie zudem als lebendes Dokument.

3. DHF als Dokumentations-Theater

Das Design History File sieht zwar vollständig aus, doch die Rückverfolgbarkeit von Design-Inputs zu Outputs übersteht keine sorgfältige Lektüre zur Verifizierung. Beim Audit zieht der Prüfer an einem Faden und der Rest fällt danach auseinander.

Die Lösung: Pflege die DHF-Rückverfolgbarkeit fortlaufend und nutze ein Tool statt eines Ordners voller Word-Dokumente.

4. MDD-Legacy unter MDR: die Regel-11-Überraschung

Ein unter der alten MDD zertifiziertes Gerät tritt in das MDR-Übergangsfenster ein. So springt die Softwarekomponente, zuvor Klasse I, unter Regel 11 auf Klasse IIa oder IIb. Folglich müssen klinische Bewertung, benannte Stelle und technische Dokumentation überarbeitet werden.

Die Lösung: Klassifiziere jedes Produkt aus der MDD-Ära jetzt unter MDR-Regeln neu, bevor das Zertifikat abläuft.

5. Unterschätzte klinische Prüfung

Das Team plant zunächst eine Literaturrecherche und einen Äquivalenzanspruch. Die benannte Stelle verlangt jedoch echte Daten aus einer klinischen Prüfung. Folglich kommen achtzehn bis sechsunddreißig Monate zum Einführungszeitplan hinzu.

Die Lösung: Validiere die Strategie zur klinischen Prüfung mit der benannten Stelle in Phase 2, spätestens bis zur Einreichung.

-> In kurz: Die fünf Fehlermuster sind gut dokumentiert und einzeln vermeidbar. Schlimm wird es, wenn ein Team zwei oder drei davon parallel ansammelt.

Fazit

Die Medizinprodukte-Entwicklung ist eines der wenigen Ingenieurfelder, in denen das Regulatorische und das Technische gemeinsam entworfen werden müssen. Sie zu trennen, ist der Grund, warum Projekte ein bis zwei Jahre länger laufen. Wer konsistent in den EU-Markt liefert, muss die EU-MDR deshalb als Design-Vorgabe der Phase 1 behandeln.

Wer sich in einer dieser Phasen befinden und ein zweites Paar Augen auf die Klassifizierung, den Capability-Stack oder den regulatorischen Pfad wünscht, ist bei uns richtig: MDR-Beratung und -Bewertung.

FAQs zur Medizinprodukte-Entwicklung

Q1: Wie lange dauert die CE-Kennzeichnung eines Medizinprodukts tatsächlich?

A1: Für ein Klasse-IIa-Gerät, ausgehend von einem funktionierenden Prototyp, dauert es zwölf bis vierundzwanzig Monate von der Einbindung der benannten Stelle bis zum Zertifikat, sofern technische Dokumentation und klinische Bewertung in gutem Zustand sind. Klasse IIb und III laufen hingegen länger, oft zwei bis drei Jahre. Der größte Teil der Varianz liegt dabei in der klinischen Bewertung und der Wartezeit bei der benannten Stelle.

Q2: Wann muss ich eine benannte Stelle einbinden?

A2: Grundsätzlich für jedes Gerät über Klasse I sowie für Klasse-I-Geräte steril und mit Messfunktion. Die erste Einbindung sollte zudem spätestens in Phase 2 erfolgen, weil die Warteschlange lang ist und die Scope-Codes der benannten Stelle Ihre Vorauswahl prägen. Bis Phase 3 sollte Ihre gewählte benannte Stelle folglich Ihr Projekt und Ihren Zeitplan kennen.

Q3: Ist meine Software ein Medizinprodukt?

A3: Wenn sie: Informationen für Diagnose, Vorhersage, Prognose, Therapieüberwachung oder Therapieempfehlung nutzt, dann ist sie unter MDR-Regel 11 mit hoher Wahrscheinlichkeit ein Medizinprodukt. Die meiste Software fällt in Klasse IIa oder höher. MDCG 2019-11 ist dabei die maßgebliche Richtlinie. Beispielsweise qualifizieren sich mobile Apps, Web-Portale sowie KI- und ML-Inferenzschichten unter derselben Regel.

Q4: Was ist der größte Unterschied zwischen MDR und der alten MDD?

A4: Es sind drei Unterschiede. Erstens die Software-Klassifizierung: Regel 11 hebt die meisten digitalen Gesundheitsprodukte um ein oder zwei Klassen. Zweitens die klinische Prüfung: Äquivalenzansprüche sind schwerer zu verteidigen. Für die meisten Klasse-IIb- und alle Klasse-III-Geräte ist zudem eine klinische Prüfung erforderlich. Drittens die Post-Market-Pflichten: PMS-Plan, PSUR, PMCF und EUDAMED-Meldung sind schwerer und stärker strukturiert. Zusammen verändern diese Punkte folglich die Kostengestalt jeder Medizinprodukte-Entwicklung gegenüber der MDD-Ära.