Die saubere Einordnung entscheidet über den Aufwand
Ob SaMD oder Software im Produkt: Qualifizierung, Klassifizierung und Sicherheitsklasse bestimmen, wie viel Nachweis wirklich nötig ist.
MDSW · IEC 62304 SaMD & Embedded Software Lebenszyklus & Rückverfolgbarkeit
Medical Device Software (MDSW): die belastbare regulatorische Nachweisstruktur
Hersteller sollten die Softwareentwicklung nicht als einzelne, für sich stehende Dokumentenartefakte sehen, die nur für die Entwicklung nachvollziehbar sein müssen. Die Dokumentation der Software muss Dritten Einblicke in den Einfluss der Software auf Sicherheit und Leistungsfähigkeit des Produkts geben, auf die Elemente der Software und deren Wechselwirkung sowie auf die geplanten und durchgeführten Aktivitäten des Softwarelebenszyklus.
10+
Jahre MDSW-Regulatorik
35+
Software-
Dossiers
Dossiers
35+
IEC 62304 / 82304-1-Projekte
25+
Software-Einreichungen FDA
Worum es geht
Eine Nachweisstruktur statt einzelner Dokumente
Medical Device Software (MDSW) ist der in der MDCG 2019-11 definierte Begriff für Software, die selbst ein Medizinprodukt ist (SaMD), und Software, die Teil eines Medizinprodukts ist.
Metecon unterstützt bei der Einordnung von Software, setzt Entwicklungs-, Änderungs- und Problemlösungprozesse bedarfsgerecht nach IEC 62304 auf, erstellt und verknüpft Anforderungen, identifiziert Risiken im Produktkontext, erstellt die bzw. unterstützt bei der Verifizierungsplanung und -durchführung und erstellt die bzw. unterstützt bei der Software-Release-Dokumentation. So entsteht eine durchgängige Nachweisdokumentation, die Entwicklung, regulatorische Anforderungen und Produktpflege über den gesamten Lebenszyklus verbindet. Der Mehrwert beginnt in der Planungsphase, reicht über Anforderungsphase bis zur Freigabe – und wirkt fortlaufend bei Änderungen aus Marktrückmeldungen und Innovation.
Für wen: Head of Regulatory Affairs, Regulatory Manager mit MDSW-Verantwortung sowie Software- und Entwicklungsverantwortliche mit regulatorischer Mitverantwortung. Geschäftsführungen von SaMD-Herstellern. QM-Verantwortliche und PRRC.
Typische Herausforderungen
Drei Probleme, die ohne durchgängige Dokumentationsstruktur entstehen
Fragmentierter Software-Lebenszyklus
Anforderungen, Architektur, Tests und Freigaben greifen nicht konsistent ineinander. Nachweise werden nicht vollständig und nicht in einer konsistenten Weise erstellt.
Fehlende Rückverfolgbarkeit
Anforderungen und Risiken sind nicht durchgängig mit Tests, Freigaben und Nachweisen verknüpft. Lücken zeigen sich erst im Audit. Vollständige Abdeckung der Anforderungen kann nicht nachgewiesen werden. Durchführung von Regressionstests wird erschwert oder macht sie sogar unmöglich.
Änderungen nicht steuerbar
Neue Versionen und Updates erzeugen zusätzlichen Nachweis- und Abstimmungsaufwand, weil die Datenlage für die Änderungsbewertung nicht nachvollziehbar und hinreichend ist. Dies kann Auswirkungen auf die Durchführung der Änderung und auf die Abnahme der Änderung (Regressionstests) haben.
Drei Konstellationen
SaMD, Software im Produkt und unterstützende Software
MDSW umfasst unterschiedliche Konstellationen mit jeweils eigenen regulatorischen Anforderungen. Die richtige regulatorische Einordnung der Software ist der erste Schritt zur belastbaren Nachweisdokumentation. Dasselbe Vorgehensmodell gilt auch für IVD-Software (nach IVDR): Software für, im und als IVD – mit u. a. einer Leistungsbewertung statt Klinischer Bewertung in der Nachweisdokumentation.
Software als Medizinprodukt (SaMD)
Software im Medizinprodukt (Embedded Software)
Software im Medizinprodukte-Kontext
Software als Medizinprodukt (SaMD)
Eigenständige Standalone-Software, die selbst ein Medizinprodukt ist und nicht Teil eines anderen Produkts ist. Über die Qualifizierung als Medizinprodukt wird die betreffende Software von Nicht-Medizinprodukten abgegrenzt.
Die Klassifizierung über Risikoklassen nach MDR bestimmt die anwendbaren regulatorischen Anforderungen und die daraus abgeleitete Nachweistiefe.
Qualifizierung & Klassifizierung
Medizinprodukt ja/nein und Risikoklasse nach MDR Anhang VIII (insb. Regel 11) bzw. IVDR unter Berücksichtigung der MDCG 2019-11, sauber begründet und dokumentiert.
Produkt vs. Anwendungsumgebung
Klare Identifizierung der Software-Schnittstellen zu anderen Softwaresystemen. Klare Abgrenzung der Software zu anderen Softwaresystemen. Identifizierung der vorgesehenen Laufzeitumgebung der Software (Execution Environment).
Nachweisdokumentation & Zulassung
Anforderungskonforme Software-Nachweise als belastbarer Bestandteil der Technischen Dokumentation (Link: Technische Dokumentation →) und Nachweis der regulatorischen Anforderungen, auch für internationale Einreichungen.
Verteilte Systeme
Bei verteilten Systemen (z. B. Server-Client-Architektur) grenzen wir das Medizinprodukt sauber ab und dokumentieren es entsprechend nach IEC 82304-1 bzw, IEC 62304.
Relevante Grundlagen
- MDR/ IVDR Anhang VIII (MDR: Regel 11)
- MDR Anhang I Art. 17
- MDCG 2019-11 (Qualifizierung & Klassifizierung)
- IEC 62304 (Lebenszyklus)
- IEC 82304-1 (Produktsicherheit Gesundheitssoftware)
- IEC 62366-1 (Gebrauchstauglichkeit)
Software im Medizinprodukt (embedded)
Software als integraler Bestandteil eines Medizinprodukts, eingebettet im Gerät (z. B. Firmware). Architektur, SOUP-Handhabung und Systemschnittstellen prägen die Nachweise. Hier unterstützt Metecon bei einer gesamtheitlichen Abbildung der Software im 60601-1-Kontext (PEMS/PESS) sowohl in der Architekturbeschreibung als auch im Anforderungsraum und bei der Dokumentation der Integration der Software.
Software vs. SOUP als Software-Komponente
Klare Identifizierung der Schnittstelle zwischen SOUP und Software, inkl. Identifizierung und Würdigung der SOUP in Architektur, über Konfigurationsmanagement bis PMS.
Schnittstellen & Cybersecurity
Externe Schnittstellen zur Informationsübermittlung (wie USB- oder Ethernet-Schnittstelle) erfordern eine Betrachtung hinsichtlich Informationssicherheit im Kontext des Produkts. Die Nachweise werden auch zur Erfüllung der regulatorischen Anforderungen herangezogen. (Link: Cybersecurity →)
Verifizierung im Systemkontext
Software-Verifizierung im Zusammenspiel mit dem Gesamtprodukt, konsistent mit Planung, Metriken, Vollständigkeit und einer sauberen Dokumentation, wohl integriert in die Gesamtdokumentation des Produkts.
Relevante Grundlagen
- IEC 62304 (Lebenszyklus, Sicherheitsklassen, SOUP)
- IEC 60601-1 (aktive Geräte)
- IEC 82304-1 (Gesundheitssoftware)
- MDR/IVDR
- MDR/IVDR Anhang I GSPR
- Schnittstelle zu Cybersecurity (IEC 81001-5-1), Risikomanagement (ISO 14971) und Usability Engineering (IEC 62366-1)
Software im Medizinprodukte-Kontext
Software, die Medizinprodukte im medizinischen Kontext unterstützt oder ergänzt. Erst die Qualifizierung und die Klassifizierung klären, ob und in welchem Umfang reguliert wird.
Qualifizierungs-Check
Medizinprodukt ja/nein – auf Basis der Zweckbestimmung und der Klassifizierungsregeln sauber entschieden und begründet.
Intended Purpose sauber gefasst
Eine präzise Zweckbestimmung grenzt Funktion und Verantwortung ab und verhindert teure Fehleinordnungen.
Relevante Grundlagen
- MDCG 2019-11
- Zweckbestimmung / Intended Purpose
- Abgrenzung Nicht-Medizinprodukt
- IEC 82304-1 (Health Software) – sofern als Health Software einzuordnen
Augenmerk auf den Prozess
IEC 62304 regelt den Software-Lebenszyklus-Prozess. Die Integration der Softwareaspekte in die Prozesslandschaft ist ein wesentliches Element zur erfolgreichen Umsetzung der IEC 62304. Metecon kann bei der Ausgestaltung der Prozessschnittstellen unterstützen und so den Austausch zwischen den Abteilungen optimal abbilden.
Der Weg zur Nachweisstruktur
In 7 Schritten den Software-Lebenszyklus belegbar machen
1
Einordnung & Anwendungsbereich
Qualifizierung, Klassifizierung der Software als Produkt und Sicherheitsklasse nach regulatorischen Vorgaben (z. B. EN 62304 oder andere landesspezifische/internationale Regularien) festlegen – die Basis für den richtigen Aufwand.
2
Planung der Software-Entwicklung
Die EN 62304 stellt Anforderungen an die Inhalte, die im Entwicklungsplan erwartet werden. Der Software-Entwicklungsplan bildet die Prozesse und Aktivitäten der Software-Entwicklung, aber auch der nachgelagerten Aktivitäten ab.
3
Risiken & Maßnahmen
Software-Risiken bewerten, Risikokontrollmaßnahmen ableiten und mit dem Risikomanagement nach ISO 14971 verknüpfen.
4
Anforderungen & Architektur: Detailed Design
Softwareanforderungen und Architektur regulatorisch anschlussfähig spezifizieren, inkl. SOUP und Schnittstellen.
5
Anforderungen an die Implementierung
Rückverfolgbarkeit, Vorgabe von Codierrichtlinien, Verankerung von Unittest-Kriterien. Unterstützung bei der Identifizierung und Validierung der eingesetzten Software-Werkzeuge.
6
Verifizierung & Rückverfolgbarkeit
Das Rückgrat der Nachweisstruktur: Anforderungen, Risiken, Tests und Entwicklungsergebnisse durchgängig verknüpfen, sodass jederzeit belegbar ist, dass jede Anforderung und jedes Risiko geprüft und im Release abgedeckt ist. Unterstützung bei Testplanung, Testspezifikation und Testdurchführung. Unterstützung bei der Bewertung von Testergebnissen im regulatorischen Kontext.
7
Release, Änderungen & Updates
Freigaben, Änderungen und Aktualisierungen mit nachvollziehbarer Bewertung der Auswirkungen von Änderungen steuerbar halten, ohne wachsenden Abstimmungsaufwand. Unterstützung bei der Freigabe auch externer Softwareentwicklung.
Rückverfolgbarkeit ist das Rückgrat
Anforderungen ↔ Risiken ↔ Tests ↔ Releases durchgängig verknüpft. Das macht aus Dokumenten eine belastbare, auditfeste Nachweisstruktur.
Warum Metecon
Nachweistiefe statt Doku-Flickenteppich
Vom „Was“ zum belegbaren „Wie“
Wir übersetzen normative Anforderungen in eine praktikable, durchgängige Nachweisdokumentation– kein Flickenteppich einzelner Dokumente.
Nachweisdokumentation und internationale Einreichungen
35+ Software-Dossiers und 25+ FDA-Einreichungen: belastbare Nachweise für EU und USA aus einer Hand.
Schnittstellen im Blick
Risikomanagement, Usability Engineering, V&V, Cybersecurity, KI und Technische Dokumentation greifen in der Nachweisstruktur konsistent ineinander.
15+ Software-Systemverifikationen 5+ Expert:innen für MDSW & QMS 25+ FDA-Einreichungen (international)
Die Auswahlkriterien orientieren sich an den Stärken führender Anbieter: top-aktuelle Normenkenntnis, skalierbare Unterstützung, praxisnahe, domainspezifische Beratung.
Metecon erfüllt diese Benchmarks und verbindet sie mit bedarfsgerechter Nachweisdokumentation für die EU und internationale Märkte.
Eigene Seiten für angrenzende Themen
Cybersecurity, KI-Regulierung (AI Act) und Software-Validierung behandeln wir auf dedizierten Seiten – hier verlinkt als Schnittstellen der MDSW-Nachweisstruktur.
Was wir konkret tun
Leistungen entlang des Software-Lebenszyklus
-
Regulatorische Einordnung & Strategie
Qualifizierung, Klassifizierung und eine tragfähige Zulassungsstrategie für EU (MDR/IVDR) und international (u. a. FDA).
-
Entwicklungsdokumentation nach IEC 62304 & IEC 82304-1 / IEC 60601-1
Software-Lebenszyklusprozesse ausgestalten: von Planung, über Anforderungen, Architektur, Verifizierung und Validierung bis Wartung und PMS.
Schnittstellenbetrachtung bestehender Prozesslandschaft hinsichtlich Softwarelebenszyklus, Risikomanagement, Informationssicherheit, Gebrauchstauglichkeit.
Werkzeugvalidierung: Validierung der verwendeten Werkezeuge im Software-Lebenszyklus (Compiler, Bugtracking, CI-Infrastruktur).
DiGA: Vom BfArM zugelassene digitale Gesundheitsanwendungen, die ärztlich verordnet werden können. DiPA: Digitale Pflegeanwendungen zur Unterstützung im Pflegealltag mit BfArM-Prüfverfahren.
-
GAP-Analyse der bestehenden Technischen Dokumentation
Bestehende Unterlagen auf Lücken gegen MDR/IVDR und relevante Normen prüfen – mit konkreten Handlungsempfehlungen.
-
Kommunikation mit Benannten Stellen & Behörden
Wir begleiten den Austausch mit Benannten Stellen und Behörden in Europa und internationalen Behörden (z. B. FDA) – von der Vorbereitung über Coaching bis zur 360°-Zulassungs- und Auditbegleitung.
-
Workshops & Inhouse-Schulungen
Schulungen und Workshops für Ihre Entwicklungs-, QM- und Regulatory-Teams.
-
Prozesse & QMS anpassen
Entwicklungs-, Software- und QM-Prozesse (ISO 13485) für MDSW belastbar aufstellen und kontinuierlich pflegen.
Unser ganzheitlicher Anspruch
Wir unterstützen Sie in allen regulatorischen Aufgabenstellungen Ihres Entwicklungsprozesses – aus einer Hand, über den gesamten Lebenszyklus.
Schnittstellen
Womit die MDSW-Nachweisstruktur verzahnt ist
Cybersecurity
Security-Anforderungen und Nachweise in die Release-Logik integrieren (IEC 81001-5-1).
Mehr erfahren →
Usability Engineering
UI- und Use-Related Risks sauber anbinden und validieren (IEC 62366-1).
Mehr erfahren →
Risikomanagement
Software-Risiken, Maßnahmen und Restrisiken konsistent dokumentieren (ISO 14971).
Mehr erfahren →
Technische Dokumentation
Software-Nachweise als Bestandteil des Dossiers strukturieren.
Mehr erfahren →
Verifizierung & Validierung
Teststrategie konsistent mit Anforderungen und Risiken verknüpfen.
Mehr erfahren →
KI-Regulierung
KI-basierte Software braucht eine belastbare Nachweisdokumentation für Entwicklung, Änderungen und Überwachung (EU AI Act).
Mehr erfahren →
Thorsten Stumpf
Principal Expert Software & AI · RAC Devices · Metecon GmbHThorsten Stumpf ist einer der Software-Spezialisten im Team Regulatory Affairs & Technical Documentation und in der Branche stark vernetzt zu diesem Thema. Thorsten bringt langjährige Erfahrung in der regulatorischen Einordnung von Medizinproduktesoftware mit, einschließlich der Prüfung von Software-Lifecycle-Dokumentationen nach IEC 62304. Er begleitet Hersteller bei Klassifizierung, regulatorischer Strategie und Technischer Dokumentation für MDSW.
IEC 62304 / 82304-1 • 35+ Software-Dossiers • 25+ FDA-Einreichungen„Nicht die Menge der Dokumente entscheidet über Medical Device Software, sondern deren durchgängige Nachvollziehbarkeit: Anforderungen, Risikomanagement, Verifizierung, Validierung, Releases und PMS – belastbar verknüpft. Diese Struktur bauen wir von Anfang an entlang von IEC 62304, IEC 82304-1 und IEC 60601-1 auf. Für ein System, das über den gesamten Lebenszyklus trägt."
– Thorsten Stumpf · Principal Expert Software & AI · RAC Devices · Metecon
Häufige Fragen zu Medical Device Software
Was unterscheidet Medical Device Software regulatorisch von anderer Software im Medizinprodukt-Kontext?
MDSW ist der EU-Oberbegriff und umfasst Software, die ein eigenständiges Medizinprodukt ist (SaMD), sowie Software, die Teil eines Medizinprodukts ist. Entscheidend ist die Zweckbestimmung: Erst die medizinische Zweckbestimmung macht Software zu einem Medizinprodukt.
Ab welchem Entwicklungsstand sollte die Nachweisstruktur aufgebaut werden?
Idealerweise wird die geplante Nachweisstruktur wie regulatorisch gefordert bereits im Entwicklungsplan abgebildet. Nachgezogene Aktivitäten können enorm kosten- und zeitintensiv sein.
Woran erkenne ich, ob meine Prozesse belastbar oder nur formal dokumentiert sind?
Belastbar ist eine Nachweisstruktur, wenn die regulatorischen Anforderungen ganzheitlich und vollständig beantwortet werden – nicht, wenn Dokumente nur nebeneinander existieren.
Wie wird die Software-Sicherheitsklasse nach IEC 62304 bestimmt?
Die Klasse (A/B/C) orientiert sich am möglichen Schaden bei Softwareversagen – bewertet im Zusammenspiel von Risikokontext, Risiken und Risikokontrollmaßnahmen. Geeignete Maßnahmen können die Software-Sicherheitsklasse reduzieren. Mit einer niedrigeren Klasse werden weniger Inhalte in der Einreichung gefordert.
Wie entsteht nachvollziehbare Traceability?
Indem Anforderungen, Risiken, Tests und Entwicklungsergebnisse konsistent verknüpft werden und die Rückverfolgbarkeit über die Entwicklungsschritte hinweg mit beachtet und durchgeführt wird – so ist belegbar, dass jede Anforderung und jedes Risiko geprüft und im Release abgedeckt ist.
Wie bleiben Releases, Updates und Änderungen steuerbar?
Durch einen definierten Änderungs- und Freigabe-Prozess mit nachvollziehbarem Vorgehensmodell und unter Berücksichtigung des Risikokontextes und der Umsetzbarkeit der Änderung.
Wie werden Schnittstellen zu Risikomanagement, Usability Engineering, Cybersecurity und Klinischer Bewertung / Leistungsbewertung berücksichtigt?
Die Prozessstruktur bindet diese Disziplinen als verknüpfte Ein- und Ausgänge ein: Software-Risiken ins Risikomanagement, gefährdungsbezogene Use-Szenarien aus dem Usability Engineering in die Risikoanalyse, identifizierte Angriffsszenarien aus der Informationssicherheit in die Risikoanalyse, präklinische Erkenntnisse als Grundlage für die Klinische Bewertung / Leistungsbewertung.
Was kostet die regulatorische Begleitung von MDSW bei Metecon?
Der Aufwand hängt von Konstellation, Sicherheitsklasse, Reifegrad der Nachweise, regulatorischen Fähigkeiten und Zielmärkten (z. B. EU/FDA) ab. In einer kostenlosen Erstberatung ordnen wir Ihren Fall ein und nennen einen belastbaren Rahmen.
Medical Device Software regulatorisch absichern
Starten Sie mit einer kostenlosen Erstberatung – wir ordnen Ihre Software ein (SaMD oder Software im Produkt), bestimmen die Sicherheitsklasse und skizzieren die Nachweisstruktur für EU und FDA.
Ihr Ansprechpartner:
Milan Weiß
Sales Manager
T: +49 621 123469-040
milan.weiss@metecon.de
