Wie bringen Sie Ihre medizinische Software als Software as a Medical Device regulatorisch konform und ohne Zulassungsschleifen in den Markt?
Wir begleiten softwarebasierte Medizinprodukte von der Klassifizierung über die nach IEC 62304 strukturierte Entwicklung und das Risikomanagement nach ISO 14971 bis zur Konformitätsbewertung unter der Medical Device Regulation (EU) 2017/745 oder zur FDA-Submission. Der entscheidende Hebel liegt nicht im Code, sondern in der Software-Sicherheitsklassifizierung: Wird sie zu spät festgelegt, fehlt die Lebenszyklus-Dokumentation, die genau für diese Klasse nachträglich kaum noch sauber rekonstruierbar ist.
- MedTech
- IVD
Überblick
Was macht Software zu einem Medizinprodukt und welche Anforderungen folgen daraus?
Begleitung von SaMD-Projekten entlang des Lebenszyklus · IEC 62304, ISO 14971, IEC 62366-1, MDR (EU 2017/745)
Zuletzt aktualisiert: 2026-06-13
Software ist ein Medizinprodukt, sobald sie eine eigenständige medizinische Zweckbestimmung erfüllt, also nicht nur Daten speichert oder weiterleitet, sondern zur Diagnose, Therapie oder Entscheidungsunterstützung beiträgt. Ab diesem Punkt gelten dieselben grundlegenden Anforderungen wie für physische Produkte, ergänzt um softwarespezifische Normen. Die Hebel, an denen SaMD-Projekte am häufigsten hängenbleiben:
- Klassifizierung: Unter der MDR (EU) 2017/745 stuft Regel 11 in Anhang VIII eigenständige medizinische Software je nach Schwere der unterstützten Entscheidung ein; die meisten SaMD landen damit oberhalb der Selbstzertifizierung und benötigen eine Benannte Stelle. Diagnostiknahe Software kann stattdessen unter die IVDR (EU) 2017/746 fallen, deren Klassifizierungsregeln in Anhang VIII über die Risikoklassen A bis D entscheiden.
- Software-Sicherheitsklassifizierung nach IEC 62304: Die Klasse A, B oder C bestimmt den Umfang der geforderten Lebenszyklus-Aktivitäten und Dokumentation. Sie leitet sich aus der Risikobeurteilung ab und kann nicht nachträglich nach unten korrigiert werden, ohne die Risikoanalyse zu verändern.
- Risikomanagement nach ISO 14971 als verbindende Klammer: Die softwarebezogenen Gefährdungen müssen in dieselbe Risikoakte einfließen, aus der sich Klassifizierung und Verifikationstiefe ergeben. Software-Risiken getrennt vom Produktrisiko zu führen erzeugt Lücken.
- Gebrauchstauglichkeit nach IEC 62366-1: Bedienfehler sind bei Software eine zentrale Gefährdungsquelle; die Usability-Akte muss die sicherheitskritischen Bedienschritte und ihre Validierung belegen.
- Cybersecurity über den Lebenszyklus: Für vernetzte Software erwarten Benannte Stellen und die FDA einen dokumentierten Secure-Development-Lifecycle inklusive SBOM, Schwachstellenmanagement und Update-Strategie über die Marktphase hinaus.
Leistungen
Wie wir Sie unterstützen
Klassifizierung & Abgrenzung
Bewertung der Zweckbestimmung, Abgrenzung Medizinprodukt versus Nicht-Medizinprodukt und Klassifizierung unter MDR (EU 2017/745) oder IVDR (EU 2017/746). Deliverable: dokumentierte Klassifizierungsbegründung und festgelegter Konformitätsbewertungsweg.
Software-Lebenszyklus nach IEC 62304
Aufbau der nach IEC 62304 geforderten Lebenszyklus-Prozesse passend zur Software-Sicherheitsklasse A, B oder C, von Anforderungsanalyse und Architektur über Implementierung bis Verifikation. Deliverable: Software-Entwicklungsplan und prüffähige Lebenszyklus-Akte.
Risikomanagement & Gebrauchstauglichkeit
Integration der Software-Gefährdungen in das Risikomanagement nach ISO 14971 und Aufbau der Usability-Akte nach IEC 62366-1. Deliverable: konsolidierte Risikoakte und Usability-Engineering-Datei mit validierten sicherheitskritischen Bedienschritten.
Cybersecurity & SBOM
Etablierung eines Secure-Development-Lifecycle nach IEC 81001-5-1 mit Software-Bill-of-Materials, Schwachstellen- und Update-Management. Deliverable: Cybersecurity-Dokumentation für die Technische Dokumentation und den Marktbetrieb.
AI/ML-Governance für lernende Systeme
Festlegung eines Frameworks für Software mit KI- oder Machine-Learning-Komponenten: Datenmanagement, Versionskontrolle der Modelle und Change-Control für Modellaktualisierungen. Deliverable: dokumentiertes Lifecycle- und Change-Framework für die ML-Komponente.
Mehr erfahren →Technische Dokumentation & Submission
Zusammenführung der Software-Akten in die Technische Dokumentation für die MDR-Konformitätsbewertung oder die Aufbereitung als FDA-Submission. Deliverable: einreichfähiges Dokumentationspaket inklusive Verifikations- und Validierungsnachweisen.
Wie wir zusammenarbeiten
Worauf es ankommt
Bei Software as a Medical Device entscheidet selten der Code über den Zulassungserfolg, sondern die Reihenfolge der regulatorischen Festlegungen. Am Anfang steht die Zweckbestimmung: Sie bestimmt, ob die Software überhaupt ein Medizinprodukt ist und unter welche Verordnung sie fällt: die MDR (EU) 2017/745 oder bei diagnostiknaher Auswertung die IVDR (EU) 2017/746. Aus der Zweckbestimmung und der Risikobeurteilung nach ISO 14971 ergibt sich die Software-Sicherheitsklasse nach IEC 62304, und diese Klasse legt fest, wie tief Architektur, Detaildesign und Verifikation dokumentiert werden müssen. Wer diese Kette zu spät schließt, baut Software ohne die Nachweise, die genau für ihre Klasse gefordert sind.
Der Engpass ist deshalb fast immer die nachträgliche Rekonstruktion: Eine zu spät erkannte höhere Sicherheitsklasse oder eine unscharfe Zweckbestimmung zwingt dazu, Lebenszyklus-Dokumentation, Risikoakte und Usability-Nachweise nach IEC 62366-1 rückwirkend aufzubauen, und zwar zu einem Zeitpunkt, an dem die Entwicklungsentscheidungen längst getroffen sind. Wir setzen darum vor der Implementierung an: Klassifizierung, Sicherheitsklasse und Cybersecurity-Strategie nach IEC 81001-5-1 werden früh festgelegt und mit dem QM-System nach ISO 13485:2016 verzahnt, damit die Technische Dokumentation am Ende jede Anforderung mit einem belastbaren Software-Nachweis belegt statt mit einer Erinnerung.
Unser Vorgehen
Unser Vorgehen
Schritt
Ergebnis
Klassifizierung & Strategie
Dokumentierte Zweckbestimmung, bestätigte Produktklasse unter MDR oder IVDR und festgelegte Software-Sicherheitsklasse nach IEC 62304.
Lebenszyklus-Setup
Software-Entwicklungsplan nach IEC 62304 mit definierten Aktivitäten passend zur Sicherheitsklasse, verknüpft mit dem QM-System nach ISO 13485:2016.
Risiko & Usability
Konsolidierte Risikoakte nach ISO 14971 und Usability-Akte nach IEC 62366-1, durchgängig auf die Software-Anforderungen bezogen.
Verifikation & Cybersecurity
Verifikations- und Validierungsnachweise sowie Cybersecurity-Dokumentation nach IEC 81001-5-1 inklusive SBOM.
Technische Dokumentation
Zusammengeführte Technische Dokumentation, in der jede grundlegende Anforderung mit einem Software-Nachweis belegt ist.
Einreichung & Marktbetrieb
Eingereichter Antrag bei Benannter Stelle oder FDA und ein laufendes Update- und Schwachstellenmanagement für die Marktphase.
Typische Stolperfallen
Woran Projekte häufig scheitern
Die Software-Sicherheitsklassifizierung nach IEC 62304 wird zu spät festgelegt.
Wird erst nach Abschluss der Entwicklung erkannt, dass eine höhere Klasse gilt, fehlen die für diese Klasse geforderten Lebenszyklus-Aktivitäten und Nachweise; sie lassen sich rückwirkend kaum prüffähig rekonstruieren.
Die Zweckbestimmung ist zu unscharf formuliert.
Eine vage Beschreibung macht die Klassifizierung unter MDR (EU 2017/745) angreifbar und führt im Audit zu Diskussionen darüber, ob es sich überhaupt um ein Medizinprodukt handelt und unter welche Regel es fällt.
Software-Risiken werden getrennt vom Produktrisikomanagement geführt.
Wenn die softwarebezogenen Gefährdungen nicht in die Risikoakte nach ISO 14971 einfließen, fehlt die Verbindung zwischen Risiko, Sicherheitsklasse und Verifikationstiefe, was Benannte Stellen regelmäßig beanstanden.
Eingesetzte Fremd- und Open-Source-Komponenten (SOUP) werden nicht systematisch erfasst.
Ohne Bill-of-Materials und Schwachstellenbewertung fehlt die Grundlage für die Cybersecurity-Dokumentation und das Update-Management über die Marktphase.
KI- oder ML-Komponenten werden ohne Change-Control für Modellaktualisierungen betrieben.
Wer Modelle nach der Zulassung ändert, ohne den Änderungsumfang gegen die zugelassene Zweckbestimmung zu bewerten, riskiert eine wesentliche Änderung, die eine erneute Konformitätsbewertung auslöst.
FAQ
Häufige Fragen
Quellen
- Verordnung (EU) 2017/745 (MDR), Primärtext, Klassifizierungsregeln für Software
- Verordnung (EU) 2017/746 (IVDR), Primärtext
- IEC 62304, Software-Lebenszyklus-Prozesse für Medizinprodukte-Software
- ISO 14971, Anwendung des Risikomanagements auf Medizinprodukte
- IEC 62366-1, Anwendung der Gebrauchstauglichkeit auf Medizinprodukte
- IEC 81001-5-1, Cybersecurity im Software-Lebenszyklus
- https://theentourage.de/clinical-medical-affairs/software-development-samd/ (bestehender Seiteninhalt, überarbeitet)
Life Science Journal
Regulatorische Updates, direkt ins Postfach.
Neue Anforderungen, Behördenentscheidungen und Praxishinweise. Einmal monatlich, jederzeit abbestellbar.
Referenzprojekte
Wie das in der Praxis aussieht
Passende Insights
Alle Insights →Berücksichtigte Verordnungen & Normen
- EU 2017/745 (MDR)
- EU 2017/746 (IVDR)
- IEC 62304 (Software-Lebenszyklus für Medizinprodukte-Software)
- ISO 14971 (Risikomanagement)
- IEC 62366-1 (Gebrauchstauglichkeit / Usability Engineering)
- ISO 13485:2016 (QM-System)
- IEC 81001-5-1 (Cybersecurity im Software-Lebenszyklus)
- ISO/IEC 27001 (Informationssicherheits-Managementsystem)
Angrenzende Themen
EU AI Act →
Regulatorischer Rahmen für KI- und ML-Komponenten in Medizinprodukten
Cybersecurity für Medizinprodukte →
Secure-Development-Lifecycle und Schwachstellenmanagement für vernetzte Software
MDR-Konformität →
Konformitätsbewertung der Software unter der MDR (EU 2017/745)
Verification & Validation →
Verifikations- und Validierungsnachweise als Kern der Software-Akte
Dazu ein konkretes Vorhaben?
Schildern Sie uns kurz Ihre Ausgangslage. Wir melden uns mit einer ersten Einschätzung, in der Regel innerhalb eines Werktags.
Lieber direkt? +49 89 4161170-0
info@theentourage.de
- Antwort i.d.R. innerhalb eines Werktags
- 4 Standorte: DE · CH · IT · US
- 100% Life Sciences