Wann wird Software zum Medizinprodukt?

Entscheidend ist nicht die Technologie, sondern der Zweck. Software gilt als Medizinprodukt, wenn sie medizinische Informationen verarbeitet, bewertet oder bereitstellt, um diagnostische oder therapeutische Entscheidungen zu unterstützen. Darunter fallen Anwendungen, die Gesundheitsdaten analysieren, Risiken einstufen, physiologische Prozesse überwachen oder medizinische Fachpersonen bei relevanten Entscheidungen unterstützen.

Massgeblich dafür ist der sogenannte «intended purpose» – die vom Hersteller definierte Zweckbestimmung. Diese zieht sich durch die gesamte Produktbeschreibung: von der technischen Dokumentation über die Gebrauchsanweisung bis zur Vermarktung. Für Entwickler bedeutet das: Bereits in frühen Projektphasen muss präzise geklärt werden, welchen medizinischen Nutzen die Software hat und welche regulatorischen Konsequenzen daraus entstehen.

Was die MDR verändert

Seit dem 26. Mai 2021 gilt die EU-Medizinprodukteverordnung (MDR, Verordnung EU 2017/745) als verbindliche Grundlage für das Inverkehrbringen von Medizinprodukte auch in der Schweiz, welche die MDR-Anforderungen ins nationale Recht überführt hat. Für bestehende Produkte gelten je nach Risikoklasse Übergangsfristen bis Ende 2027 bzw. 2028.

Die MDR verfolgt ein klares Ziel: mehr Patientensicherheit, mehr Transparenz, mehr Nachvollziehbarkeit. Für Softwarehersteller ist die Verordnung besonders relevant, weil viele Softwareanwendungen unter der MDR strenger bewertet werden und neu in eine höhere Risikoklasse fallen können. Wer sich tiefer in die Struktur der Verordnung, ihre Kapitel, Anhänge und Anforderungen, einlesen möchte, findet beim Johner Institut eine fundierte Übersicht: Medical Device Regulation MDR – alles, was Sie wissen müssen.

Zentrales Element ist Regel 11 der MDR: Software, die Informationen für diagnostische oder therapeutische Entscheidungen liefert, wird grundsätzlich mindestens als Klasse IIa eingestuft. Bei potenziell schwerwiegenden Folgen kann sie in Klasse IIb oder III fallen. Standalone-Software der Klasse I, früher ein gängiges Modell, wird es kaum noch geben.

Was das praktisch bedeutet: Sobald ein Produkt nicht mehr in Klasse I fällt, ist eine benannte Stelle für die Konformitätsbewertung erforderlich. Das Produkt muss nachweisbar sicher, leistungsfähig und über den gesamten Lebenszyklus dokumentiert und kontrolliert sein.

Die wichtigsten Neuerungen der MDR auf einen Blick:

• Höhere Anforderungen an klinische Bewertung und technische Dokumentation
• Erweiterte Herstellerverantwortung: End-to-end-Verantwortung für Konformität und Rückverfolgbarkeit
• Breitere Definition von Medizinprodukten: Standalone-Software für medizinische Zwecke ist explizit einbezogen
• EUDAMED-Datenbank: Zentralisierte Informationen zu Produkten, Unternehmen und klinischen Studien
• UDI-Pflicht: Eindeutiger Produktidentifikator für lückenlose Rückverfolgbarkeit
• Post-Market Clinical Follow-up (PMCF): Systematische Datenerhebung nach Markteinführung

Was MDR-Zertifizierung in der Praxis bedeutet

Die MDR-Zertifizierung ist kein administrativer Abschlussschritt. Sie ist das Ergebnis eines durchgängigen Entwicklungs- und Qualitätsprozesses und muss von Beginn an mitgedacht werden.

Hersteller müssen nachweisen, dass ihr Produkt die grundlegenden Sicherheits- und Leistungsanforderungen erfüllt, Risiken systematisch identifiziert und beherrscht werden und die technische Dokumentation vollständig sowie stets aktuell ist.

Konkret umfasst das:

• Klare Zweckbestimmung und nachvollziehbare Klassifizierung

• Qualitätsmanagementsystem nach ISO 13485
• Technische Dokumentation gemäss MDR-Anforderungen
• Risikomanagement über den gesamten Produktlebenszyklus
• Softwareentwicklung nach EN IEC 62304
• Usability Engineering nach EN IEC 62366
• Datenschutz, Informationssicherheit und Cybersecurity
• Klinische Bewertung und Nachweis des medizinischen Nutzens
• Systematische Marktüberwachung nach Inverkehrbringen

Gerade bei Software ist es entscheidend, regulatorische Anforderungen nicht als nachträgliche Dokumentationsübung zu behandeln. Jede Funktion, jede Änderung, jedes Update kann Auswirkungen auf Risikoklasse, Validierung, Gebrauchstauglichkeit und Dokumentation haben. Ein agiles Vorgehen bleibt möglich. Dafür braucht es aber klare Prozesse, definierte Rollen, konsequente Versionierung und lückenlose Rückverfolgbarkeit.

Wo die grössten Herausforderungen liegen

Für Hersteller liegt die eigentliche Herausforderung darin, medizinische, regulatorische, technische und nutzerbezogene Anforderungen zusammenzuführen. Softwareentwicklung im Medizinprodukteumfeld ist per se interdisziplinär. Sie verlangt nicht nur solide Programmierung, sondern regulatorisches Verständnis, medizinische Fachkompetenz, wissenschaftliche Evidenz, Qualitätsmanagement und konsequente Dokumentation.

Besonders anspruchsvoll sind fünf Bereiche:

1. Frühe regulatorische Einordnung Die Zweckbestimmung muss frühzeitig festgelegt werden. Wird sie später angepasst, kann sich die Klassifizierung ändern. Dies wiederum hat direkte Auswirkungen auf Entwicklungsaufwand, Dokumentation, klinische Bewertung und Zertifizierungsweg.
2. Technische Dokumentation Die MDR verlangt eine deutlich detailliertere Dokumentation als frühere Regelwerke. Sie muss nicht nur zum Zeitpunkt der Zertifizierung vorliegen, sondern kontinuierlich gepflegt werden. Anforderungen, Risiken, Tests, Releases und Änderungen müssen jederzeit nachvollziehbar sein.
3. Balance zwischen Agilität und Regulierung Software entwickelt sich laufend weiter, aber im Medizinprodukteumfeld darf Geschwindigkeit nicht zulasten der Sicherheit gehen. Jede Änderung muss bewertet, getestet, dokumentiert und freigegeben werden.
4. Datenschutz und Cybersecurity Gesundheitsdaten gehören zu den sensibelsten Datenkategorien überhaupt. Datenschutz, Zugriffskonzepte, Informationssicherheit und Cybersecurity müssen von Beginn an Teil der Architektur sein und nicht nachträglich ergänzt werden. Die Europäische Kommission führt Cybersecurity ausdrücklich als relevante Leitlinie für Medizinprodukte-Software auf.
5. Nutzerorientierung und Gebrauchstauglichkeit Software als Medizinprodukt muss so gestaltet sein, dass sie sicher und verständlich genutzt werden kann. Von medizinischen Fachpersonen ebenso wie von Case Managerinnen, HR-Verantwortlichen oder Führungskräften. Eine klare Benutzerführung reduziert Fehlinterpretationen und stärkt die Qualität der Entscheidungen, die auf Basis des Tools getroffen werden.

Regulierung als Chance: Was ein MDR-konformer Prozess wirklich bringt

So anspruchsvoll die Anforderungen sind – sie schaffen auch echten Mehrwert. Ein normenkonformer Entwicklungsprozess zwingt dazu, Anforderungen sauber zu erfassen, Risiken systematisch zu bewerten und Qualität kontinuierlich zu überprüfen. Das verbessert nicht nur das Medizinprodukt selbst, sondern häufig die gesamte Softwareentwicklungskultur im Unternehmen.

Klare Prozesse führen zu besseren Produkten: weniger Fehler, mehr Transparenz, höhere Nachvollziehbarkeit. Für Anwenderinnen und Anwender entsteht Vertrauen und die Gewissheit, dass ein Tool nicht nur technisch funktioniert, sondern nach definierten Qualitäts- und Sicherheitsstandards entwickelt wurde.

Expertise, die an der Schnittstelle entsteht

Die Entwicklung von Software als Medizinprodukt verlangt Erfahrung an mehreren Schnittstellen gleichzeitig: Medizinische Anforderungen müssen in digitale Prozesse übersetzt, regulatorische Vorgaben in Entwicklungsabläufe integriert und Nutzerbedürfnisse in verständliche Oberflächen überführt werden.

Software entfaltet ihren Nutzen nicht isoliert. Sie muss in reale Prozesse passen, fachlich abgestützt sein und den Menschen im Mittelpunkt behalten. Professionelle Softwareentwicklung im Medizinprodukteumfeld bedeutet deshalb mehr als Code schreiben: Es bedeutet, Verantwortung für Qualität, Sicherheit, Nachvollziehbarkeit und letztlich für Wirkung zu übernehmen.