Die Medical Device Regulation klassifiziert Produkte nach dem Risiko, das sie bergen. Für Software gelten besondere Regeln, vor allem Regel 11 des Anhangs VIII MDR:
Für HealthTech-Startups liegen die meisten Produkte in Klasse IIa. Ein digitales Symptom-Assessment-Tool, das eine Handlungsempfehlung gibt, ist IIa. Ein Diabetes-Management-System mit Insulin-Dosisvorschlag eher IIb oder III — abhängig von der konkreten Logik.
Die Klasse bestimmt, ob eine Benannte Stelle eingeschaltet werden muss (ab Klasse IIa Pflicht) und welchen Umfang die technische Dokumentation hat.
ISO 13485 ist der internationale Standard für Qualitätsmanagementsysteme speziell für die Medizinprodukte-Branche. Sie definiert, wie ein Unternehmen Prozesse, Rollen, Dokumentation, Risikomanagement und kontinuierliche Verbesserung aufbaut, um nachweislich Medizinprodukte verlässlicher Qualität zu entwickeln.
Für ein Startup bedeutet das: ein Qualitätsmanagementhandbuch mit mindestens den folgenden Elementen:
Der Aufbau eines ISO-13485-QMS dauert typischerweise sechs bis neun Monate. Ein spezialisierter Berater beschleunigt den Prozess um zwei bis drei Monate gegenüber dem kompletten Eigenaufbau.
Während ISO 13485 das unternehmensweite QMS regelt, ist IEC 62304 der spezifische Standard für die Softwareentwicklung medizinischer Geräte und reiner Medizinprodukt-Software.
Die Kernanforderungen:
In der Praxis führt IEC 62304 zu einer deutlich stärkeren Dokumentationspflicht als eine vergleichbare B2B-Webanwendung. Das ist nicht Selbstzweck — die Dokumentation ist die Grundlage für die Zertifizierung durch die Benannte Stelle.
Ab Klasse IIa verlangt die MDR eine klinische Bewertung: den Nachweis, dass das Produkt seinen Zweck sicher und wirksam erfüllt. Für Software ohne direkten Patientenkontakt kann der Nachweis über Literaturrecherche geführt werden. Für Software mit diagnostischer oder therapeutischer Funktion sind oft prospektive klinische Untersuchungen nötig.
Die klinische Bewertung ist oft der zeitkritischste Teil der Zertifizierung — Studiendesigns, ethische Freigaben und Rekrutierung dauern. Ein realistisches Zeitfenster: sechs bis zwölf Monate zusätzlich zur technischen Entwicklung.
Für Klasse IIa und darüber muss eine Benannte Stelle (Notified Body) die technische Dokumentation und das QMS auditieren. In Deutschland sind das TÜV SÜD, TÜV Rheinland, DEKRA und einige kleinere Stellen.
Der Ablauf:
Gesamtdauer vom Start der Zusammenarbeit bis zur CE-Zertifizierung: typischerweise sechs bis zwölf Monate. Addiert zu der vorherigen Entwicklungsphase ergibt sich der Zeitrahmen von zwölf bis achtzehn Monaten für ein neues Produkt.
Erster Fehler: QMS-Aufbau wird an das Projektende vertagt. Die Folge: Wenn das MVP fertig ist, muss die komplette Entwicklungsdokumentation rückwirkend erstellt werden — unter Zeitdruck, oft mit Lücken, teuer. Empfehlung: ISO-13485-Basisstrukturen ab Tag eins aufbauen, parallel zur Produktentwicklung.
Zweiter Fehler: Klasse wird zu spät belastbar bestimmt. Viele Startups gehen von Klasse I aus, um schnell auf den Markt zu kommen, und werden von der Aufsichtsbehörde oder der Benannten Stelle auf IIa hochgestuft. Der Rückschritt kostet oft sechs bis zwölf Monate. Empfehlung: Ein erfahrener Regulatory-Affairs-Berater beurteilt die Klasse im ersten Monat.
Dritter Fehler: Entwicklungspartner ohne MedTech-Erfahrung. Die meisten Software-Entwicklungsdienstleister haben Erfahrung mit normalen B2B-Produkten, nicht mit IEC 62304. Die Zusammenarbeit funktioniert, erfordert aber vom Startup selbst ein starkes Regulatory-Know-how. Empfehlung: Bei der Dienstleisterauswahl gezielt nach Erfahrung mit Medizinproduktesoftware fragen.
Unser Vorgehen bei Medizinproduktesoftware: Werkvertrag mit klar abgegrenzten Sprint-Paketen. Dokumentation nach IEC 62304 ab dem ersten Sprint — Anforderungen, Architektur, Tests, Traceability-Matrix. Enge Abstimmung mit dem Regulatory-Affairs-Team des Kunden oder einem externen QMS-Berater.
Produktionsdaten in EU-Regionen, bevorzugt mit HDS-Zertifizierung (Hébergeur de Données de Santé) oder ISO-27001-zertifizierten deutschen Anbietern. Entwicklung mit synthetischen oder pseudonymisierten Daten. Keine personenbezogenen Gesundheitsdaten in Test- oder Entwicklungsumgebungen.
Standardmäßig fünfzehn Tage kostenlose Fehlerbehebung nach jeder Abnahme, danach ein Wartungsvertrag, der explizit auch das Patch-Management nach Freigabe durch die Benannte Stelle umfasst. Regulatorisch heikle Projekte werden im Rahmen unserer Softwareentwicklungs-Leistungen umgesetzt und durch Cybersicherheits- sowie Beratungs- und Schulungsleistungen flankiert — ein QMS-konformer Entwicklungsprozess funktioniert nur als Gesamtpaket, nicht als Einzelmaßnahme.
Wenn Sie ein HealthTech-Produkt in der Planung oder frühen Entwicklung haben, ist der wichtigste frühe Schritt die Klassenbestimmung und der Aufbau einer QMS-Grundstruktur. Vereinbaren Sie eine kostenlose Online-Sondierung — wir bringen Erfahrung in Medizinproduktesoftware mit und ordnen die realistische Zeit- und Ressourcenplanung ein. Ergänzend liefern die Beiträge zu DSGVO-Fallstricken in der Software-Entwicklung und BSI-Grundschutz im Secure SDLC die rechtlich und technisch flankierenden Bausteine, die jede Medizinproduktesoftware gleich zu Beginn braucht.
Ja, wenn sie eine medizinische Zweckbestimmung hat. Eine Schrittzähler-App ohne klinische Interpretation ist in der Regel kein Medizinprodukt. Eine App, die Vorhofflimmern im EKG identifiziert und eine Handlungsempfehlung gibt, ist mit hoher Wahrscheinlichkeit Klasse IIa.
Das ist ein unterschätzter Teil. MDR Artikel 83 bis 86 verlangt eine aktive Überwachung des Produkts nach der Markteinführung — Meldung schwerwiegender Vorfälle, regelmäßige Sicherheitsberichte, Trendanalyse von Kundenfeedback. Operativ bedeutet das ein Team oder ein Prozess, der kontinuierlich läuft, nicht ein Einmalaufwand.
Die Übergangsfristen für bestehende MDD-zertifizierte Produkte wurden mehrfach verlängert. Für Neuentwicklungen gilt die MDR direkt. Ein frühzeitiger Austausch mit Benannter Stelle und einem Regulatory-Berater vermeidet Überraschungen.
Operativ ja, verantwortlich nein. Die Verantwortung für das QMS liegt beim Hersteller (in der Regel beim Geschäftsführer). Externe Unterstützung beim Aufbau und Betrieb ist üblich und sinnvoll — Vollauslagerung funktioniert nicht, weil bestimmte Rollen (Qualitätsbeauftragter) intern besetzt sein müssen.
In einer gut etablierten Struktur rund fünfzehn bis zwanzig Prozent der gesamten Entwicklungsarbeit. Das ist substanziell, aber keineswegs überwiegend. In einer schlecht aufgesetzten Struktur wird dieser Anteil deutlich höher, weil Nacharbeiten und retrospektive Dokumentation überhandnehmen.
© 2026 D'Cloud Software & Digital Agency. Alle Rechte vorbehalten.