Software als Medizinprodukt (SaMD) erklärt: MDR, Regel 11 & ISO Standards

Software als Medizinprodukt (SaMD) gewinnt in Europa zunehmend an Bedeutung. Schätzungen zufolge beträgt der Marktwert 2024 rund 440 Millionen Euro und wird bis 2033 auf etwa 1,4 Milliarden Euro ansteigen. Dies bringt jedoch auch Herausforderungen mit sich: Die MDR-, Regel-11- und Zertifizierungskosten setzen Teams unter Druck.

Dies wirft eine praktische Frage auf:
Wie können MedTech-Unternehmen die Klassifizierung und Einhaltung der Vorschriften für Software as a Medical Device (SaMD) bewältigen, ohne dass es zu Verzögerungen, Unsicherheiten oder unnötigen Kosten kommt?

Dieser Artikel bietet einen strukturierten Überblick über Software als Medizinprodukt (SaMD) gemäß der EU-Medizinprodukteverordnung (MDR). Er erläutert die Terminologie, die Klassifizierung gemäß MDR-Regel 11, die erforderlichen Standards, die Erwartungen an die Entwicklung sowie typische Anwendungen und Herausforderungen.

Was ist Software als Medizinprodukt (SaMD)?

Das Internationale Forum der Medizinprodukte-Regulierungsbehörden (IMDRF) definiert Software als Medizinprodukt (SaMD) als Software, die unabhängig von jeglicher Hardware eine medizinische Funktion erfüllt. Dazu gehören Programme, die auf Allzweck-Hardware wie Computern, Tablets, Smartphones oder Cloud-Systemen ausgeführt werden.

In der Europäischen Union wird der Begriff „SaMD” in der Gesetzgebung jedoch nicht verwendet. Stattdessen werden solche Produkte in der Medizinprodukteverordnung (MDR) als Medizinproduktesoftware (MDSW) klassifiziert. Gemäß MDCG 2019-11 gilt Software als Medizinprodukt, wenn ihr Verwendungszweck der MDR-Definition entspricht, unabhängig davon, ob sie eigenständig ist oder mit einem anderen Gerät verbunden ist.

In der Praxis bedeutet dies, dass alle Diagnosetools, Monitoringanwendungen, therapeutischen Algorithmen und Systeme zur klinischen Entscheidungsunterstützung als Medizinprodukte reguliert sind. Beispiele hierfür sind KI-Bildgebung, Apps zur Symptombewertung und Software zur Entscheidungsunterstützung.

-> Kurz gesagt: SaMD ist eine eigenständige Software, die einen regulierten medizinischen Zweck gemäß der EU-Medizinprodukteverordnung (MDR) erfüllt.

Software als Medizinprodukt (SaMD) gemäß der EU MDR: Regel 11

Die EU-MDR regelt Software als Medizinprodukt unter dem Oberbegriff „Medizinprodukt-Software“ (MDSW). In MDR-Regel 11 des Anhangs VIII ist festgelegt, wie Software unter Berücksichtigung ihres vorgesehenen medizinischen Zwecks und des klinischen Risikos der von ihr beeinflussten Entscheidungen klassifiziert wird. Die meisten SaMD werden als Klasse IIa oder höher eingestuft, sodass eine Regulierung eher die Regel als die Ausnahme ist.

Die meisten SaMD-Produkte fallen in Klasse IIa oder höher, sodass die Einbeziehung des "Notified Bodies" die Regel ist. Höhere Klassifizierungen wie Klasse IIb und Klasse III sind üblich, wenn die Software klinische Entscheidungen beeinflusst oder die Patientensicherheit beeinträchtigt. Daher ist eine frühzeitige regulatorische Planung unerlässlich.

Bevor eine Software als Medizinprodukt (SaMD) auf dem europäischen Markt eingeführt werden kann, muss sie eine CE-Kennzeichnung erhalten. Dazu sind Nachweise über Sicherheit und klinische Leistung, Risikomanagement sowie eine Dokumentation gemäß den IEC- und ISO-Normen erforderlich. Zudem ist ein strukturierter Plan zur Überwachung nach dem Inverkehrbringen notwendig. Laut der Guideline MDCG 2019-11 Rev. 1 (2025) muss jede Software den MDR-Pfad durchlaufen, unabhängig davon, ob sie eigenständig ist oder mit einem Gerät verbunden.

-> Kurz gesagt: Fast jede Software als Medizinprodukt fällt in die MDR-Klasse IIa oder höher und erfordern eine "Notified Body" Bewertung.

Konformität und Standards für Software als Medizinprodukt (SaMD)

Bei der Entwicklung von Software als Medizinprodukt müssen die MDR-Anforderungen hinsichtlich Sicherheit, Leistung und Lebenszyklusmanagement erfüllt werden. Die Einhaltung internationaler Standards gewährleistet zuverlässige Software, die behördlichen Kontrollen im Rahmen der CE-Kennzeichnung standhält. Diese Standards sind:

IEC 62304

Legt fest, wie medizinische Software geplant, entwickelt, implementiert, getestet, freigegeben und gewartet werden muss. Auf der Grundlage des potenziellen klinischen Schadens weist es eine Sicherheitsklasse (A, B oder C) zu, die bestimmt, wie viele Nachweise die Hersteller vorlegen müssen.

ISO 13485

Legt die Anforderungen an das Qualitätsmanagement für die Entwicklung und Wartung von Medizinprodukten fest. Es stellt sicher, dass alle Prozesse, von der Designkontrolle bis hin zum Änderungsmanagement, dokumentiert und konsistent sind. Dies ist bei Audits durch „Notified Bodies” von entscheidender Bedeutung.

ISO 14971

Legt fest, wie Hersteller Risiken während des gesamten Software-Lebenszyklus identifizieren, bewerten und kontrollieren müssen. Dadurch wird sichergestellt, dass sicherheitsrelevante Entscheidungen gerechtfertigt und nachvollziehbar sind. Dies ist eine zentrale Erwartung der MDR.

IEC/TR 80002-1

Erläutert, wie die ISO 14971 speziell auf Software angewendet werden kann. Softwarespezifische Gefahren werden in klare Anforderungen an die Risikokontrolle übersetzt. Somit unterstützt die Norm die MDR-Anforderungen an eine strukturierte Verifizierung und Überwachung nach dem Markteintritt.

Schritt für Schritt zur MDR-konformen Software als Medizinprodukt

Für die Entwicklung von Software als Medizinprodukte ist vor der Entwicklungsbeginn eine strukturierte Vorbereitungsphase nötig. Die folgenden Schritte geben einen Überblick darüber, welche Erwartungen die MDR-Regulation hat und wie Unternehmen in der Praxis vorgehen sollten.

Schritt 1: Definition des Verwendungszwecks und Bestätigung der MDR-Klasse

Die MDR-Klassifizierung hängt vollständig von dem vorgesehenen, medizinischen Zweck sowie dem klinischen Risiko der von der Software als Medizinprodukt beeinflussten Entscheidungen ab. Gemäß MDR-Regel 11 werden die meisten SaMDs als Klasse IIa oder höher eingestuft, sodass die Einbeziehung eines "Notified Bodies" notwendig ist.

-> Dokumentieren Sie die medizinische Leistung der Software genaustens. Dies ist entscheidend für dessen Klassifizierung und den regulatorischen Aufwand.

Was genau ist zu tun?

Definieren Sie den Verwendungszweck in ein bis zwei Sätzen.
Überprüfen Sie anhand der MDR-Regel 11, ob es sich um ein Produkt der Klasse IIa, IIb oder III handelt.
Dokumentieren Sie Ihre Begründung für die zukünftige Zertifizierung.

Schritt 2: Frühzeitig die MDR-Regulierung strukturiert planen

Die MDR-Regulierungsplanung umfasst die Frage, ob ein „Notified Body“ kontaktiert werden muss, den erforderlichen Regulierungsumfang und die Überprüfung des CE-Kennzeichnungsprozesses.

-> Sie müssen klarstellen, welcher Regulierungsprozess befolgt und wer Ihr Gerät genehmigen muss.

Was genau ist zu tun?

Stellen Sie fest, ob eine benannte Stelle erforderlich ist (fast immer für SaMDs).
Erstellen Sie einen Plan für die CE-Kennzeichnung und die erforderlichen Unterlagen.
Erstellen Sie einen realistischen Zeitplan, der auch Verzögerungen bei der "Notified Bodies" Prüfung berücksichtigt.

Schritt 3: Das Qualitätsmanagementsystem gemäß ISO 13485 einrichten

Die ISO 13485 gewährleistet, dass die Prozesse in den Bereichen Designkontrolle, Dokumentation, Lieferantenmanagement und Änderungsmanagement wiederholbar und überprüfbar sind. Dies muss in das Qualitätsmanagementsystem integriert werden.

-> Ihre internen Prozesse müssen den MDR-Anforderungen entsprechen. Andernfalls wird ein Produkt nicht zugelassen.

Was genau ist zu tun?

Sie stellen sicher, dass Ihr QMS der ISO 13485 Norm entspricht, oder planen Sie eine Aktualisierung.
Legen Sie die Zuständigkeiten für regulatorische, qualitative, technische und klinische Aktivitäten fest.
Richten Sie Workflows für die Dokumentenkontrolle und -freigabe ein.

Schritt 4: Den Software-Lebenszyklus gemäß IEC 62304 definieren

Die Norm IEC 62304 beschreibt die erforderlichen Entwicklungs-, Prüf-, Freigabe- und Wartungsaktivitäten für Software als Medizinprodukt, die nach Sicherheitsklassen kategorisiert sind. Dies muss als Software-Lebenszyklus integriert werden.

-> Sie benötigen einen strukturierten Entwicklungsplan, der zeigt, wie die Software entwickelt und getestet wird.

Was genau ist zu tun?

.Definieren Sie Ihr Lebenszyklusmodell gemäß IEC 62304.
Weisen Sie die Software-Sicherheitsklasse (A, B oder C) zu.
Planen Sie die für Ihre Klasse erforderliche Dokumentation und den Testumfang.

Schritt 5: Den Risikomanagementprozess (ISO 14971) festlegen

Die ISO 14971 schreibt die systematische Identifizierung, Bewertung, Kontrolle und Überprüfung softwarebezogener Risiken während des gesamten Produktlebenszyklus vor. Diese Risikokontrolle ist Pflichtteil der MDR-Zertifizierung.

-> Sie müssen nachweisen, dass Ihre Software weder Patient*innen noch Ärzt*innen schadet.

Was genau ist zu tun?

Definieren Sie Ihren Risikomanagementprozess.
Verwenden Sie IEC/TR 80002-1 als Leitfaden für die softwarespezifische Gefahrenanalyse.
Aktualisieren Sie Ihre Risikodateien kontinuierlich, vor allem sich die Software weiterentwickelt.

Schritt 6: Definition der klinischen Bewertungsstrategie

Auch Software als Medizinprodukt erfordert klinische Nachweise, die die Sicherheit und Leistungsfähigkeit gemäß MDR-Richtlinien belegen. Diese können aus der Literatur, aus klinischen Daten oder aus Beobachtungen in der Praxis stammen.

Sie müssen die Sicherheit, die Funktionsfähigkeit und den klinischen Nutzen der Software nachweisen.

Was genau ist zu tun?

Entscheiden Sie, wie Sie Ihre Nachweise erbringen werden (Studien, Literatur, Bewertungen).
Passen Sie Ihre Aussagen an Ihre verfügbaren Daten an.
Planen Sie, wie Sie Ihre Nachweise nach der Markteinführung aktualisieren werden.

Schritt 7: Cybersicherheit, Interoperabilität und DSGVO behandeln.

Software als Medizinprodukt muss Cybersicherheitskontrollen, Datenschutzmaßnahmen sowie Interoperabilitätsrahmenwerke wie HL7 FHIR umfassen. Ein großer Teil dieser Maßnahmen betrifft die Sicherheit.

Ihre Software muss sicher und ordnungsgemäß verbunden sein sowie den Datenschutzbestimmungen entsprechen.

Was genau ist zu tun?

Dokumentieren Sie Maßnahmen zur Cybersicherheit (Zugriffskontrolle, Verschlüsselung, Protokollierung).
Planen Sie die Handhabung von Updates und Patches.
Stellen Sie die Einhaltung der DSGVO für alle vom Gerät verarbeiteten, personenbezogenen Daten sicher.

Schritt 8: Die technische Dokumentation vorbereiten

Die technische Dokumentation (auch als Konstruktionsunterlagen bezeichnet) muss Informationen zu Softwarearchitektur, Risikomanagement, Verifizierung, klinischen Nachweisen, Cybersicherheit und PMS-Plänen enthalten. Dies ist die Basis der regulationsrelevanten Dokumentation.

-> Während der Softwareentwicklung müssen Sie Ihre alle relevanten technischen Dokumente sammeln.

Was genau ist zu tun?

Legen Sie frühzeitig die Struktur Ihrer technischen Dokumentation fest.
Entscheiden Sie, welche Tools Sie für die Nachvollziehbarkeit und Dokumentation verwenden möchten.
Füllen Sie die Dokumentation schrittweise während der Entwicklung durch.

Bonus: Typische Fehler bei der MDR-konformen Softwaredokumentation

Werden diese Vorbereitungsschritte nicht frühzeitig und konsequent durchgeführt, treten während der Entwicklung und Zertifizierung zwangsläufig Probleme auf.

Es gibt kein klares Ziel oder eine MDR-Klasse.
Die Dokumentation wird bis zum Ende des Projekts aufgeschoben.
Es herrschen Missverständnisse über die Nachweise von MDR-Regel 11 für SaMD.
Es fehlen Risikokontrollen oder die Architekturdokumentation ist unvollständig.
Die klinische Bewertung wurde nicht frühzeitig geplant.

Fazit: MDR-konforme Software als Medizinprodukt (SaMD)

Software als Medizinprodukt bietet zwar ein großes Potenzial für Diagnose, Überwachung und Behandlung, bringt aber auch regulatorische Verpflichtungen mit sich, die von vielen Organisationen unterschätzt werden. So verlangt die MDR einen klaren Verwendungszweck, eine korrekte Klassifizierung sowie einen strukturierten Entwicklungsprozess, der durch Nachweise und Risikomanagement unterstützt wird.

Für eine vorhersehbare Zulassung müssen Geräte frühzeitig vorbereitet werden. Dazu zählen die Definition der Geräte sowie die Anpassung der Entwicklung an IEC- und ISO-Normen. Zudem sind Dokumentationen im Zuge der Softwareentwicklung erforderlich. Sind diese Elemente von Anfang an vorhanden, wird die Zertifizierung überschaubarer und Verzögerungen sind weniger wahrscheinlich.

MedTech-Unternehmen, die Software als Medizinprodukt als kontinuierlichen Lebenszyklus und nicht als einmalige Entwicklung betrachten, sind besser in der Lage, die Compliance zu gewährleisten, Updates sicher zu veröffentlichen und eine langfristige PFlege zu unterstützen. Mit der richtigen Vorbereitung ist die zertifizierte Software als Medizinproduktentwicklung für den europäischen Markt sicher.