Definition
Software, die eigenständig als Medizinprodukt klassifiziert ist, ohne auf eine Hardware-Komponente angewiesen zu sein. Unterliegt der MDR bzw. IVDR und erfordert ein Software-Lebenszyklus-Management nach IEC 62304. Klassifizierung nach Risiko (I bis III) und Validierung nach EN 62304.
In der Praxis
Bei Software als Medizinprodukt erlebe ich zwei entgegengesetzte Fehler: Die einen merken gar nicht, dass ihre Software ein Medizinprodukt ist — die anderen unterschätzen, wie hoch sie hängt. Der Hebel ist die Zweckbestimmung, und der Klassiker ist die Klassifizierung nach Regel 11 des Anhangs VIII der MDR: Dieselbe Diagnose-App ist Klasse I, wenn sie nur informiert — und Klasse IIb oder höher, sobald ihre Aussagen Entscheidungen mit schweren gesundheitlichen Folgen treiben. Der MDCG-Leitfaden 2019-11 ist dafür die Pflichtlektüre. Zweiter Stolperstein: der Lebenszyklus. Software wird agil entwickelt, in Sprints, mit wöchentlichen Releases — die MDR denkt in dokumentierten Entwicklungsphasen. Die IEC 62304 vermittelt zwischen beiden Welten, aber nur, wenn Sie Versionslenkung, Verifizierung und Änderungsbewertung ernst nehmen. Und der dritte Punkt wird gerade akut: KI-basierte Diagnose-Software erbt zusätzlich zur MDR die Hochrisiko-Logik des EU AI Act — doppelte Dokumentation, doppelte Risikobewertung. Wer SaMD entwickelt, baut am besten von Anfang an auf einem QMS nach ISO 13485 auf; alles andere ist Nachrüstung unter Zeitdruck.
Häufige Fragen zu SaMD
Wann ist Software ein eigenständiges Medizinprodukt — und wann nur Komponente?
Entscheidend ist die Zweckbestimmung, nicht die Technik. Software ist dann ein eigenständiges Medizinprodukt — SaMD —, wenn der Hersteller sie für einen medizinischen Zweck bestimmt und sie diesen Zweck ohne Einbettung in ein Hardware-Medizinprodukt erfüllt: etwa eine App, die aus Patientendaten Therapieempfehlungen ableitet, oder eine Bildanalyse-Software, die Befunde vorschlägt. Software als Komponente dagegen steuert ein Hardware-Produkt oder treibt es an — die Steuerungssoftware eines Infusionsgeräts ist Teil dieses Medizinprodukts und teilt dessen regulatorisches Schicksal. Die Abgrenzung hat weitreichende Folgen: SaMD braucht eine eigene Konformitätsbewertung, eigene Klassifizierung und eigene CE-Kennzeichnung; Komponenten-Software wird im Dossier des Gesamtprodukts mitbewertet. Die Zweckbestimmung im Marketing zu formulieren ist deshalb keine Texterei, sondern eine regulatorische Festlegung mit Zertifikatsfolgen (Verordnung (EU) 2017/745 (MDR), Anhang VIII; MDCG 2019-11).
Welche Normen und Regeln gelten konkret für die Entwicklung von SaMD?
Das Fundament ist die IEC 62304 für den Software-Lebenszyklus: Entwicklungsplanung, Anforderungen, Architektur, Implementierung, Verifizierung, Konfigurations- und Problemlösungsprozesse — gestaffelt nach Software-Sicherheitsklassen. Darum herum liegen das Risikomanagement nach ISO 14971 und die Gebrauchstauglichkeit nach IEC 62366-1, beide sind für Medizinprodukte-Software praktisch unverzichtbar. Für die Klassifizierung der Software unter der MDR ist der Leitfaden MDCG 2019-11 die zentrale Orientierung — er interpretiert insbesondere die Regel 11 des Anhangs VIII, die Diagnose- und Therapie-Software je nach Entscheidungsschwere hochstuft. Läuft im Produkt KI mit, kommt zusätzlich der EU AI Act ins Spiel: KI-Systeme in Medizinprodukten fallen regelmäßig in dessen Hochrisiko-Kategorie. Das QMS-Rückgrat für all das ist die ISO 13485 (IEC 62304; ISO 14971:2019; MDCG 2019-11).
Wie bekommen wir agile Softwareentwicklung und MDR-Dokumentation unter einen Hut?
Der Trick ist, die IEC 62304 nicht als Wasserfall-Korsett zu lesen, sondern als Lebenszyklus-Rahmen, den auch Sprints füllen können. Definieren Sie Ihre Entwicklungsphasen so, dass sie mit Ihrem Release-Rhythmus harmonieren — etwa mit einem dokumentierten Definition-of-Done, das Verifizierung, Risikoaktualisierung und Freigabe je Inkrement enthält. Führen Sie die Software-Anforderungen und ihre Verifizierung in einem Werkzeug mit durchgehender Rückverfolgbarkeit, statt Dokumente nachträglich zu rekonstruieren; das ist bei wöchentlichen Builds die einzige überlebensfähige Variante. Bewerten Sie jede Änderung vor dem Release regulatorisch: neue Funktion, neue Risiken, neue Klassifizierungsfrage? Und halten Sie das Software-Problem-Lösungsverfahren scharf — die MDR erwartet, dass Feldprobleme systematisch in CAPA und PMS münden. Agile heißt nicht undokumentiert; es heißt dokumentiert in kleinen, kontinuierlichen Schritten (IEC 62304; ISO 13485:2016).