EU MDR (Medizinprodukteverordnung) – Ein praktischer Leitfaden für softwaregetriebene Medizinprodukte

Die EU-Medizinprodukteverordnung ist in Kraft getreten und hat die Produktentwicklung in der EU grundlegend verändert. Und dennoch sehen wir auch Jahre nachdem die MDR offiziell die Medizinprodukterichtlinie abgelöst hat immer noch viele Unternehmen, die sie eher als reine Checkbox-Übung behandeln – etwas, das man mit etwas Papierarbeit „abhakt“, statt als den grundlegenden Wandel in der Art und Weise, wie medizinische Software entworfen, entwickelt und gewartet werden sollte.

Ich schreibe diesen Artikel als Gründer eines Softwareunternehmens, das hauptsächlich an Medizinproduktesoftware arbeitet – Embedded Systems und SaMD. Wir leben nun lange genug mit der MDR, um mit Sicherheit sagen zu können: Die MDR ist nicht nur ein rechtliches Problem, sie ist ein technisches Problem.

Ja, es ist eine Verordnung, ja, sie ist umfangreich, und ja, sie kann manchmal wirklich frustrierend sein. Aber im Kern zwingt die MDR Hersteller dazu, sich einige ziemlich schwierige Fragen zu ihren Produkten zu stellen:

• Verstehen wir wirklich, wie sich unsere Software in den Randfällen verhält, die gelegentlich auftreten?

• Können wir jede Sicherheitsanforderung bis zum tatsächlichen Code und den durchgeführten Tests zurückverfolgen?

• Behandeln wir Cybersicherheitsrisiken als Patientensicherheitsproblem oder nur als IT-Problem?

• Können wir unser Produkt sicher aktualisieren, nachdem es in den Verkauf gegangen ist?

Für softwaregetriebene Medizinprodukte ist die MDR besonders anspruchsvoll. Software ist flexibel, schnelllebig und leicht zu ändern – während die MDR starr, risikoorientiert und besessen von Nachverfolgbarkeit ist. Die Spannung zwischen diesen beiden Welten ist der Ursprung der meisten MDR-Probleme.

Erschwerend kommt hinzu, dass viele Teams glauben, sie seien „bereits konform“, weil:

• das Produkt ursprünglich zertifiziert wurde,

• die Software einige Verifikationstests bestanden hat,

• oder die Benannte Stelle bislang keine schwierigen Fragen gestellt hat.

In Wirklichkeit hat die MDR jedoch eine Lebenszyklus-Denkweise eingeführt . Compliance ist nicht länger etwas, das man zum Zeitpunkt der Markteinführung erreicht – sie ist etwas, das kontinuierlich aufrechterhalten werden muss , während sich das Produkt weiterentwickelt, aktualisiert wird, sich mit neuen Systemen verbindet oder neuen Cyberbedrohungen ausgesetzt ist.

Dieser Artikel ist keine juristische Aufschlüsselung der MDR. Wir sind keine Juristen und geben auch nicht vor, es zu sein. Was Sie hier finden, ist die Perspektive eines Softwareingenieurs auf die MDR – von der Architektur über das Risikomanagement bis hin zu den realen Abwägungen, mit denen Medizinproduktehersteller täglich konfrontiert sind.

Wenn Ihr Produkt stark auf Software angewiesen ist (und heutzutage sind das die meisten Medizinprodukte), dann wird die MDR die Art und Weise, wie Sie es entwickeln, prägen – ob es Ihnen gefällt oder nicht.

Wenn Sie:

• Gründer oder CEO eines Medizinprodukteunternehmens sind und unter MDR-Druck strategische Entscheidungen treffen,

• CTO oder Engineering Manage r sind und für Lieferung, Architektur und langfristige Wartbarkeit verantwortlich sind,

• Product Owner oder Technical Lead sind und regulatorische Anforderungen in reale Software übersetzen,

• oder Softwareingenieur sind und an Embedded Systems, SaMD oder vernetzten Medizinprodukten arbeiten,

dann ist dieser Artikel für Sie.

Was ist die EU MDR – auf einer Seite (ohne Juristendeutsch)

Die EU-Medizinprodukteverordnung (MDR) – formal Verordnung (EU) 2017/745 – ist das Regelwerk, das festlegt, wie Medizinprodukte im europäischen Markt entworfen, entwickelt, zertifiziert und instand gehalten werden. Sie ersetzte die alte Medizinprodukterichtlinie (MDD) mit einem klaren Ziel: die Erhöhung der Patientensicherheit und Transparenz über den gesamten Produktlebenszyklus hinweg .

Aus Softwareperspektive hat die MDR drei zentrale Dinge verändert.

Erstens hat sie die Anforderungen an das Risikomanagement deutlich verschärft . Sicherheit betrifft nicht mehr nur das Gerät selbst – Softwareverhalten, Fehlermodi, Cyberbedrohungen und sogar mögliche Fehlanwendungen durch Nutzer sind nun Teil der Sicherheitsbetrachtung.

Zweitens verlangt die MDR eine durchgängige Rückverfolgbarkeit . Anforderungen müssen mit Risiken verknüpft sein, Risiken mit Designentscheidungen, Design mit Code, Code mit Tests und Tests mit Verifikation. Wenn sich etwas nicht zurückverfolgen lässt, existiert es aus Sicht des Auditors praktisch nicht.

Drittens behandelt die MDR Medizinprodukte als „lebende“ Produkte . Die Zertifizierung ist nicht das Ziel – Updates, Fehlerbehebungen und neue Funktionen müssen durch kontrollierte Prozesse eingeführt und durch angemessene Risikobewertungen unterstützt werden.

Kurz gesagt zwingt die MDR Hersteller nachzuweisen, dass ihre Software nicht nur funktional, sondern auch sicher, kontrolliert und über ihren gesamten Lebenszyklus hinweg vorhersehbar ist .

Gilt die MDR für Software?

Kurze Antwort: Ja. Lange Antwort: Es kommt darauf an.

Und in vielen Fällen gilt sie bereits – selbst wenn Hersteller sich dessen nicht vollständig bewusst sind.

Die MDR reguliert Software nicht aufgrund ihrer Herstellungsweise, sondern aufgrund dessen, was sie tut . Wenn Software darauf abzielt:

• zu diagnostizieren,

• zu überwachen,

• vorherzusagen,

• oder klinische Entscheidungen oder Behandlungen zu beeinflussen,

dann ist die MDR mit hoher Wahrscheinlichkeit relevant.

Software kann auf unterschiedliche Weise unter die MDR fallen:

• als eigenständige Software ( Software als Medizinprodukt – SaMD),

• als eingebettete Software , die ein physisches Medizinprodukt steuert oder beeinflusst,

• oder als Software, die eine medizinische Funktion antreibt oder unterstützt , selbst wenn sie in der Cloud läuft.

Medizinische Software wird in eine von vier Klassen eingestuft: Klasse I, IIa, IIb oder III . Einer der wichtigsten und zugleich am häufigsten missverstandenen Aspekte der MDR ist Regel 11 , die bestimmt, wie medizinische Software klassifiziert wird. Unter der MDR wurden viele Softwareprodukte im Vergleich zur alten Richtlinie neu eingestuft und oft direkt in Klasse IIa oder höher eingeordnet.

Das hat reale technische Auswirkungen: strengere Entwicklungsmethoden, formalere Tests und Validierung, umfangreichere Dokumentation sowie die Einbindung einer unabhängigen Drittpartei (der sogenannten Benannten Stelle) sind Teil der MDR-Anforderungen.

Zentrale MDR-Anforderungen, die Software besonders betreffen

Während die MDR das gesamte Medizinprodukt in den regulatorischen Fokus rückt, trägt Software einen überproportional großen Anteil der regulatorischen Last . Eine Reihe von MDR-Anforderungen bereitet in softwaregetriebenen Projekten regelmäßig die größten Schwierigkeiten – nicht weil sie unklar wären, sondern weil sie Disziplin und einen strukturierten Ansatz erfordern.

Allgemeine Sicherheits- und Leistungsanforderungen (Anhang I)

In Anhang I stellt die MDR einen direkten Bezug zwischen Softwareverhalten und Patientensicherheit her. Jede sicherheitsrelevante Softwarefunktion muss begründet, implementiert und im Zusammenhang mit identifizierten Risiken verifiziert werden. Die Annahme, dass „schon alles gut gehen wird“, sowie undokumentierte Verhaltensweisen oder verborgene Abhängigkeiten sind während einer Bewertung schwer zu verteidigen.

Softwarelebenszyklus sowie Verifikation & Validierung

Die MDR erwartet, dass Software gemäß einem strukturierten Lebenszyklus entwickelt wird, typischerweise ausgerichtet an IEC 62304 . Verifikation und Validierung sind keine optionalen Best Practices, sondern regulatorische Anforderungen. Jede Anforderung muss getestet werden, und das Gesamtverhalten der Software muss in Bezug auf ihren vorgesehenen medizinischen Zweck validiert werden.

Die Verifikation und Validierung medizinischer Software endet selten beim eigenen Quellcode. Betriebssysteme, Drittanbieterbibliotheken, Middleware und Open-Source-Komponenten werden unter der MDR ebenfalls Teil der Sicherheitsargumentation. Diese Elemente müssen identifiziert, begründet und über den gesamten Produktlebenszyklus hinweg kontrolliert werden.

Unter der MDR werden solche Komponenten typischerweise als Software unbekannter Herkunft (SOUP – Software of Unknown Provenance) behandelt und entsprechend risikobewertet. In der Praxis ist dies eng mit der Pflege einer genauen Software-Stückliste (Software Bill of Materials – SBoM) verbunden, die es Herstellern ermöglicht zu verstehen, welche Software sie tatsächlich ausliefern und wie sich Änderungen oder Schwachstellen auf Patientensicherheit und Compliance auswirken können.

Usability Engineering für Software

Das Design der Benutzeroberfläche ist unter der MDR nicht nur ein UX-Thema. Die Gebrauchstauglichkeit von Software wirkt sich direkt auf die Patientensicherheit aus und ist eng mit IEC 62366 verknüpft. Designentscheidungen, Mechanismen zur Fehlervermeidung und Benutzerabläufe müssen validiert werden – insbesondere wenn die Software klinische Entscheidungen beeinflusst oder Benutzerhandlungen anleitet.

Cybersicherheit als Sicherheitsanforderung

Die MDR behandelt Cybersicherheitsrisiken als potenzielle Sicherheitsgefahren und nicht nur als IT-Thema. Unbefugter Zugriff, Datenmanipulation oder der Verlust der Verfügbarkeit können zu Patientenschäden führen. Softwareteams müssen daher Sicherheitsdesign, Zugriffskontrollen, Update-Mechanismen und den Umgang mit Schwachstellen in die Kernarchitektur des Systems integrieren.

Klinische Bewertung von Software

Bei medizinischer Software beschränkt sich die klinische Bewertung nicht nur auf klinische Studien. Sie umfasst auch den Nachweis, dass die Software ihren vorgesehenen Zweck sicher erfüllt – auf Basis klinischer Daten, Literatur oder Äquivalenznachweisen. Nicht belegte Behauptungen oder Annahmen zur Softwareleistung sind häufige Ursachen für Nichtkonformitäten.

MDR und der Produktlebenszyklus – vor und nach dem Markteintritt

Eine der größten Veränderungen durch die MDR ist, dass Compliance nicht mit der Markteinführung endet . Für softwaregetriebene Medizinprodukte beginnt der anspruchsvollste Teil oft genau dann, wenn das Produkt bereits im Einsatz ist.

Vor dem Markteintritt

Bevor ein Produkt auf den Markt gebracht werden darf, muss die Software in einem kontrollierten Prozess vollständig entwickelt werden. Dazu gehören finalisierte Anforderungen, im Code implementierte Risikokontrollen, vollständige Verifikation und Validierung sowie eine Dokumentation, die zeigt, dass alles konsistent zusammenwirkt. Aus Softwareperspektive profitieren in dieser Phase Teams, die die MDR von Anfang an berücksichtigt haben, statt sie in letzter Minute anzupassen.

Nach dem Markteintritt

Sobald die Software im Feld ist, bringt die MDR fortlaufende Verpflichtungen mit sich. Marktüberwachung nach dem Inverkehrbringen, Vorfallmanagement und Änderungsmanagement werden Teil des täglichen Geschäfts. Selbst kleinere Softwareupdates – Fehlerbehebungen, Leistungsverbesserungen oder Sicherheits-Patches – müssen hinsichtlich ihrer potenziellen Auswirkungen auf Sicherheit und Compliance bewertet werden.

Bei höher klassifizierter Software führen Updates häufig zu zusätzlicher Verifikation, Regressionstests und Aktualisierungen der Dokumentation. Informelle Release-Praktiken, die in nicht regulierten Branchen funktionieren mögen, werden unter der MDR schnell zu einem Risiko.

Die Konsequenz ist klar: Software muss so entworfen werden, dass sie Änderungen unterstützt . Architekturen, die Impact-Analysen, kontrollierte Updates und vorhersehbares Verhalten ermöglichen, machen langfristige MDR-Compliance handhabbar. Architekturen, die dies nicht tun, sammeln im Laufe der Zeit regulatorische und technische Schulden an.

Häufige MDR-Fallstricke in Softwareprojekten

Obwohl die MDR seit Jahren gilt, tauchen in unterschiedlichen Projekten und Unternehmen immer wieder dieselben softwarebezogenen Probleme auf. Die meisten entstehen nicht durch mangelnden Einsatz, sondern durch ein verspätetes oder unvollständiges Verständnis dafür, wie tiefgreifend die MDR die Softwareentwicklung beeinflusst.

MDR als reine Dokumentationsübung behandeln

Einer der häufigsten Fehler besteht darin, sich auf Dokumente statt auf Prozesse zu konzentrieren. Teams versuchen kurz vor der Zertifizierung, „Lücken zu schließen“, nur um festzustellen, dass fehlende Rückverfolgbarkeit oder unklare Designentscheidungen nicht allein durch Dokumentation behoben werden können.

Auswirkungen der Softwareklassifizierung unterschätzen

Eine falsche Einschätzung der Softwareklassifizierung zu Beginn führt oft später zu schmerzhaften Korrekturen. Wenn Software in eine höhere Klasse eingestuft wird als erwartet, reichen bestehende Entwicklungs- und Validierungspraktiken möglicherweise nicht mehr aus – was Nacharbeit, Verzögerungen oder architektonische Änderungen erzwingt.

Schwache Rückverfolgbarkeit zwischen Anforderungen, Code und Tests

Viele Projekte haben Schwierigkeiten, Sicherheitsanforderungen klar mit Implementierung und Verifikation zu verknüpfen. Dies wird insbesondere bei Audits oder bei Änderungen problematisch, wenn die Auswirkungen auf die Sicherheit schnell und überzeugend nachgewiesen werden müssen.

Es gibt bestimmte Möglichkeiten, dies auf intelligente Weise mit gängigen Softwareentwicklungstools wie Jira umzusetzen, sodass Anforderungen, Codeänderungen, Tests und Berichte miteinander verknüpft sind.

Cybersicherheit als separates Thema behandeln

Cybersicherheit wird noch immer häufig als IT- oder Infrastrukturthema behandelt, getrennt vom Softwaredesign. Unter der MDR hält diese Trennung nicht stand. Sicherheitslücken können sich direkt in Sicherheitsrisiken für Patienten übersetzen, und Auditoren erwarten zunehmend, dass sie auf Softwareebene adressiert werden.

Legacy-Software ohne regulatorische Grundlage

Produkte, die vor der MDR entstanden sind oder von früheren Teams übernommen wurden, weisen häufig nicht die Struktur, Dokumentation und Rückverfolgbarkeit auf, die die MDR heute verlangt. Und seien wir ehrlich – Compliance nachträglich in solche Systeme einzubauen, ist fast immer sehr kostspielig – deutlich teurer, als wenn man es von Anfang an richtig gemacht hätte.

Diese Probleme treten selten zu Beginn eines Projekts zutage, haben aber die unangenehme Eigenschaft, im denkbar ungünstigsten Moment aufzutauchen – während der Zertifizierung, bei Audits oder nach Vorfällen im Markt. Und dann ist es oft zu spät, noch viel daran zu ändern.

MDR aus geschäftlicher Perspektive

Aus geschäftlicher Sicht geht es bei der MDR weniger darum, „konform zu sein“, sondern vielmehr darum, wie viel Risiko man eingeht . Bei softwaregetriebenen Medizinprodukten bleiben regulatorische Lücken nicht lange verborgen – sie äußern sich meist in Verzögerungen, Neuentwicklungen oder Eskalationen unter Einbeziehung der Benannten Stellen.

Softwarebezogene Probleme gehören zu den häufigsten Ursachen für Zertifizierungsverzögerungen. Gemeint sind hier beispielsweise fehlende Rückverfolgbarkeit, unzureichende Verifikation oder unklare Auswirkungen von Änderungen. Dies kann Zeitpläne leicht um Monate verschieben. Für Start-ups kann dies das gesamte Projekt gefährden oder den Markteintritt sowie Investorenmeilensteine blockieren. Für etablierte Hersteller kann es verschobene Produkteinführungen, Umsatzeinbußen und erhöhten operativen Druck bedeuten.

Hinzu kommen die Verpflichtungen nach dem Inverkehrbringen, die das Geschäftsrisiko weiter erhöhen. Unkontrollierte Softwareupdates, schwaches Vorfallmanagement oder mangelhafte Cybersicherheitsmaßnahmen können Korrekturmaßnahmen, zusätzliche Audits oder sogar einen vorübergehenden Marktrückzug auslösen. Und dann wird die Behebung des Problems deutlich teurer, als wenn man es bereits während der Entwicklung adressiert hätte.

Unternehmen, die die MDR als Qualitätsrahmen betrachten , der sowohl für Produkte als auch für Prozesse gilt, erleben tendenziell weniger Überraschungen. Vorhersehbare Softwareentwicklung, kontrollierte Updates und klare Dokumentation tragen wesentlich dazu bei, regulatorische Unsicherheiten zu reduzieren und Produktportfolios leichter zu skalieren. In diesem Sinne ist MDR-Compliance eher eine stabilisierende Kraft als eine wiederkehrende geschäftliche Bedrohung.

Unser Ansatz für MDR-konforme Softwareentwicklung

Wir verfügen über umfangreiche Erfahrung mit der MDR, da wir Software entwickeln, die nicht nur technisch funktionieren muss, sondern auch in r egulierten Umgebungen und unter realen Auditbedingungen bestehen muss.

Wir entwickeln medizinische Software innerhalb von Prozessen, die an ISO 9001:2015 und ISO 13485:2016 ausgerichtet sind. Dies bietet unseren Engineering-Teams einen soliden Rahmen für Risikomanagement, Dokumentation, Rückverfolgbarkeit und kontinuierliche Verbesserung. Dadurch lassen sich MDR-Anforderungen leichter in die tägliche Entwicklung integrieren, anstatt sie als externe Hürde zu betrachten, die es zu überwinden gilt.

Aus technischer Sicht setzen wir auf bewährte und etablierte Technologien , die für langfristige, regulierte Umgebungen geeignet sind. Und das nicht, weil sie gerade im Trend liegen, sondern weil sie wartbare Architekturen, vorhersehbares Verhalten und lange Produktlebenszyklen mit kontrollierten Updates unterstützen.

In der Praxis bedeutet das:

• mit Anforderungen zu beginnen, die ordnungsgemäß risikobewertet und testbar sind,

• Architekturen zu entwerfen, die Rückverfolgbarkeit und Impact-Analysen unterstützen,

• Verifikation, Validierung und Cybersicherheit als zentrale Engineering-Aktivitäten zu behandeln,

• und Software zu entwickeln, die Updates nach dem Inverkehrbringen und Audits von Anfang an berücksichtigt.

Wir arbeiten eng mit den QA- und RA-Teams der Hersteller zusammen, um sicherzustellen, dass unsere Softwareentwicklung mit deren Qualitätsmanagementsystem abgestimmt ist. Unser Ziel ist nicht, „Software für die Zertifizierung vorzubereiten“, sondern Software zu entwickeln, die im Laufe ihrer Weiterentwicklung dauerhaft konform bleiben kann .

Dieser Ansatz hat sich für uns bei Embedded Systems, SaMD und komplexen Produkten bewährt, die Geräte, Cloud-Dienste und Begleitapplikationen kombinieren.

Abschließende Gedanken

Die MDR setzt die Messlatte höher, was von der Entwicklung von Medizinproduktesoftware erwartet wird. Sie verlangt von Teams Offenheit im Umgang mit Risiken, bewusstes Design und Disziplin in der Weiterentwicklung von Software über die Zeit hinweg.

Für Engineering-Teams bedeutet dieser Wandel: Klarheit vor Geschwindigkeit und Struktur vor Improvisation. Software, die modular, rückverfolgbar und mit Blick auf Änderungen entworfen ist, lässt sich nicht nur leichter zertifizieren – sie ist auch einfacher zu warten, zu testen und ihr zu vertrauen.

Die MDR verlangt keine Perfektion; sie verlangt Vorhersehbarkeit . Teams, die diesen Ansatz frühzeitig verstehen, verbringen weniger Zeit damit, auf regulatorischen Druck zu reagieren, und mehr Zeit damit, Software zu entwickeln, die sicher, robust und für den langfristigen Einsatz in klinischen Umgebungen geeignet ist.