Software als Medizinprodukt: Entwicklung nach MDR, IEC 62304 und ISO 13485

Was Softverse in MedTech gemacht hat

Wir haben eine MDR-zertifizierte Medizinprodukte-Plattform entwickelt, bestehend aus Backend, Web-App und Mobile App. Die Entwicklung lief nach IEC 62304 und innerhalb eines QMS nach ISO 13485. Das heisst: Anforderungen, Architektur, Risikobetrachtungen, Tests und Releases wurden so dokumentiert, dass sie der Prüfung durch die benannte Stelle standhalten.

Diese Erfahrung bringen wir in jedes neue MedTech-Projekt ein. Wir wissen, welche Dokumente wann entstehen müssen, welche Fragen Auditoren stellen und wo Teams typischerweise Zeit verlieren.

Was Software zum Medizinprodukt macht

Ob Medizinsoftware als Medizinprodukt gilt, entscheidet nicht die Technologie, sondern die Zweckbestimmung. Software, die vom Hersteller für Diagnose, Vorbeugung, Überwachung, Vorhersage, Behandlung oder Linderung von Krankheiten bestimmt ist, ist nach MDR ein Medizinprodukt. Das gilt für eigenständige Software (Software as a Medical Device) ebenso wie für Software, die ein Gerät steuert.

Für die Klassifizierung ist in der MDR vor allem Regel 11 massgebend:

• Klasse I: alle Software, auf die keine der unten genannten Bedingungen zutrifft. Bei Software ist das seltener, als viele annehmen.
• Klasse IIa: Software, die Informationen für diagnostische oder therapeutische Entscheidungen liefert, oder die physiologische Prozesse überwacht.
• Klasse IIb: Wenn solche Entscheidungen zu einer schwerwiegenden Verschlechterung des Gesundheitszustands führen können oder vitale Parameter überwacht werden, deren Veränderung eine unmittelbare Gefahr bedeutet.
• Klasse III: Wenn eine Fehlentscheidung zum Tod oder zu einer irreversiblen Verschlechterung führen kann.

In der Schweiz gilt die Medizinprodukteverordnung (MepV), die sich eng an der MDR orientiert. Swissmedic ist für die Marktüberwachung zuständig. Seit dem Wegfall der gegenseitigen Anerkennung mit der EU brauchen Hersteller je nach Sitz einen Bevollmächtigten in der Schweiz oder in der EU. Diese Punkte sind für Ihre Markteintrittsplanung wichtig; wir leisten dazu keine Rechtsberatung, kennen aber die Auswirkungen auf die Entwicklung. Eine Übersicht zum Vorgehen finden Sie in unserer Checkliste zu Software als Medizinprodukt nach MDR.

Was das für die Entwicklung bedeutet

Die IEC 62304 teilt Software in Sicherheitsklassen A, B und C ein, je nachdem, ob ein Softwarefehler zu keiner, einer nicht schweren oder einer schweren Verletzung bis hin zum Tod führen kann. Die Klasse bestimmt, wie tief Architektur, Detaildesign und Verifikation dokumentiert werden müssen. Eine kurze Einführung bietet unser Glossareintrag zu IEC 62304.

Konkret bedeutet das für das Projekt:

• Softwareanforderungen werden eindeutig, prüfbar und versioniert festgehalten, abgeleitet aus den Systemanforderungen und der Risikoanalyse.
• Architektur zerlegt die Software in Einheiten mit klaren Schnittstellen und trennt sicherheitsrelevante Teile, wo sinnvoll, vom Rest.
• SOUP (Software of Unknown Provenance), also Bibliotheken, Frameworks und Cloud-Dienste, wird mit Version, Zweck und bekannten Risiken gelistet und bei Updates bewertet.
• Verifikation erfolgt auf Einheiten-, Integrations- und Systemebene, mit dokumentierten Ergebnissen für jedes Release.
• Traceability verbindet Anforderungen, Risikokontrollmassnahmen, Code und Tests in beide Richtungen.
• Risikomanagement nach ISO 14971 läuft parallel zur Entwicklung, nicht als Nachtrag vor dem Audit.
• Usability Engineering nach IEC 62366-1 stellt sicher, dass die Oberfläche auch unter Stress und für ungeübte Nutzer sicher bedienbar ist.

Wie das im Alltag aussieht, beschreiben wir im Artikel IEC 62304 in der Praxis.

Wie wir agil und normkonform arbeiten

Die Norm schreibt kein Wasserfallmodell vor. Sie verlangt nachvollziehbare Aktivitäten und Ergebnisse. Wir entwickeln deshalb in kurzen Zyklen und lassen die Dokumentation aus dem Entwicklungsprozess heraus entstehen:

• Anforderungen und Risiken leben als versionierte Einträge neben dem Code, nicht in losen Word-Dateien.
• Jeder Merge Request verweist auf die betroffene Anforderung. Reviews werden automatisch protokolliert.
• Die CI-Pipeline liefert die Evidenz: Testergebnisse, statische Analyse, SOUP-Inventar und Build-Artefakte werden pro Release archiviert.
• Change Control ist Teil des Workflows: Jede Änderung nach der Freigabe bekommt eine Impact-Analyse, die Auswirkungen auf Risiken und Tests festhält.

So bleibt das Team schnell, und die technische Dokumentation ist zum Release-Zeitpunkt aktuell statt Wochen später. Wie sich ein QMS nach ISO 13485 mit agilen Teams verträgt, zeigt unser Beitrag ISO 13485 QMS für agile Software-Teams.

Datenschutz und Hosting für Gesundheitsdaten

Gesundheitsdaten gelten nach dem Schweizer nDSG als besonders schützenswerte Personendaten. Wir planen deshalb früh, wo Daten liegen, wer darauf zugreift und wie lange sie gespeichert werden. Auf Wunsch betreiben wir die Plattform bei Schweizer Hosting-Anbietern. Daten werden bei der Übertragung und im Ruhezustand verschlüsselt, Zugriffe rollenbasiert vergeben und in einem Audit-Trail protokolliert. Für den EU-Markt berücksichtigen wir zusätzlich die Anforderungen der DSGVO.

Digital Health ohne Medizinprodukt

Nicht jede Gesundheits-App ist ein Medizinprodukt. Wellness- und Präventions-Apps ohne medizinische Zweckbestimmung, Terminbuchung, Praxis-Tools für die Administration oder interne Werkzeuge für Kliniken fallen in der Regel nicht unter die MDR. Hier entwickeln wir mit derselben Sorgfalt bei Datenschutz und Qualität, aber ohne den regulatorischen Mehraufwand. Wichtig ist, dass Marketing und Produkttexte keine medizinischen Versprechen machen, die die Einstufung ändern würden. Für solche Projekte passt unsere App-Entwicklung oder Individualsoftware.

Zusammenarbeit mit Ihrem Regulatory-Team

Wir ersetzen weder Ihre Regulatory-Affairs-Abteilung noch Ihr Qualitätsmanagement. Wir sind das Entwicklungsteam, das deren Sprache spricht. In der Praxis heisst das: Wir stimmen den Softwareentwicklungsplan mit Ihrem QMS ab, liefern Dokumente in Ihren Vorlagen, nehmen an Design Reviews teil und beantworten Fragen der benannten Stelle zur Software.

Zum Einstieg empfehlen wir diese drei Beiträge:

• Software als Medizinprodukt: MDR-Checkliste
• IEC 62304 in der Praxis
• ISO 13485 QMS für agile Software-Teams

Wenn Sie KI-Funktionen in einem Medizinprodukt planen, etwa zur Auswertung von Daten oder zur Unterstützung von Fachpersonen, klären wir in der KI-Beratung, was regulatorisch und technisch sinnvoll ist.

Sie planen Software als Medizinprodukt oder wollen ein bestehendes Projekt auf IEC 62304 bringen? Im Erstgespräch besprechen wir Zweckbestimmung, Zeitplan und die nächsten Schritte.