Software als Medizinprodukt (MDR): Checkliste für Digital-Health-Teams

Ist meine Software ein Medizinprodukt?

Software ist ein Medizinprodukt, wenn sie nach der Zweckbestimmung des Herstellers einem medizinischen Zweck dient: Diagnose, Verhütung, Überwachung, Vorhersage, Prognose, Behandlung oder Linderung von Krankheiten, Verletzungen oder Behinderungen. So definiert es Artikel 2 der Medizinprodukteverordnung (EU) 2017/745, kurz MDR. Für Digital-Health-Teams ist diese Frage die wichtigste im ganzen Projekt, denn sie entscheidet über Aufwand, Zeitplan und Budget.

Massgeblich ist die Zweckbestimmung, also das, was Sie in Gebrauchsanweisung, Marketing, App-Store-Text und Verkaufsgesprächen über Ihr Produkt sagen. Dieselbe Software kann ein Medizinprodukt sein oder nicht, je nachdem, wie Sie sie positionieren. Eine App, die Schritte zählt, ist ein Lifestyle-Produkt. Dieselbe App mit der Aussage, sie erkenne Herzrhythmusstörungen, ist ein Medizinprodukt.

Der wichtigste Leitfaden für die Abgrenzung ist MDCG 2019-11 der Medical Device Coordination Group, in der jeweils aktuellen Fassung. Er enthält einen Entscheidungsbaum und Beispiele. Grob gilt:

• Software, die Daten nur speichert, archiviert, kommuniziert oder einfach sucht, ist in der Regel kein Medizinprodukt.
• Software, die Daten für einen einzelnen Patienten verarbeitet, analysiert, berechnet oder interpretiert, um eine medizinische Aussage zu stützen, ist es in der Regel schon.
• Software, die ein Medizinprodukt steuert oder beeinflusst, fällt ebenfalls unter die Regulierung.

Beispiele zur Orientierung

Die folgenden Beispiele zeigen die Richtung, nicht die verbindliche Einstufung. Die Beurteilung hängt immer von der konkreten Zweckbestimmung ab.

• Terminbuchung für eine Arztpraxis: verwaltet Termine, verarbeitet keine medizinischen Daten zu einer Aussage. In der Regel kein Medizinprodukt.
• Elektronisches Tagebuch, das Symptome nur erfasst und anzeigt: in der Regel kein Medizinprodukt, solange keine Auswertung mit medizinischer Aussage erfolgt.
• App, die aus Symptomen und Messwerten eine Empfehlung zur Therapieanpassung ableitet: in der Regel ein Medizinprodukt.
• Algorithmus, der Bilddaten auswertet und Auffälligkeiten markiert: in der Regel ein Medizinprodukt.
• Web-Portal, über das Fachpersonen Messwerte eines Medizinprodukts auswerten: häufig Teil des Medizinprodukts oder selbst eines.

Achten Sie auch auf Module. Eine Plattform kann aus Teilen bestehen, die Medizinprodukt sind, und solchen, die es nicht sind. MDCG 2019-11 beschreibt, wie sich solche Module abgrenzen lassen. Das kann den regulierten Umfang deutlich verkleinern, setzt aber eine saubere technische Trennung voraus.

Die Grenze ist in der Praxis oft unscharf, besonders bei digitalen Gesundheitsanwendungen im Bereich Prävention, Wellbeing oder Therapiebegleitung. Dokumentieren Sie Ihre Abgrenzung schriftlich und begründet. Wenn Sie unsicher sind, klären Sie die Frage früh mit Fachleuten für Regulatory Affairs.

MDR Regel 11 und die Klassen

Ist die Software ein Medizinprodukt, bestimmt Regel 11 in Anhang VIII der MDR die Risikoklasse:

• Klasse IIa: Software, die Informationen liefert, die für Entscheidungen zu diagnostischen oder therapeutischen Zwecken herangezogen werden.
• Klasse IIb: wenn diese Entscheidungen eine schwerwiegende Verschlechterung des Gesundheitszustands oder einen chirurgischen Eingriff verursachen können.
• Klasse III: wenn diese Entscheidungen den Tod oder eine irreversible Verschlechterung des Gesundheitszustands verursachen können.
• Klasse IIa: Software zur Überwachung physiologischer Prozesse.
• Klasse IIb: Software zur Überwachung vitaler physiologischer Parameter, wenn Änderungen dieser Parameter zu einer unmittelbaren Gefahr für den Patienten führen können.
• Klasse I: alle übrige Software, die ein Medizinprodukt ist.

Die Folge: Unter der MDR landen die meisten Software-Medizinprodukte in Klasse IIa oder höher. Damit ist eine benannte Stelle an der Konformitätsbewertung beteiligt. Unter der alten Richtlinie war vieles Klasse I und konnte selbst deklariert werden. Das hat sich grundlegend geändert. Der Leitfaden MDCG 2019-11 enthält auch zur Anwendung von Regel 11 Erläuterungen und Beispiele.

Sonderfall KI-gestützte Software

Software mit Machine-Learning-Komponenten fällt unter dieselben Regeln. Eine KI-gestützte Empfehlung für eine Diagnose ist nach Regel 11 mindestens Klasse IIa. Zusätzlich verlangen benannte Stellen Nachweise zu Trainings- und Testdaten, Leistungskennzahlen, Verzerrungen und dem Umgang mit Modell-Updates. In der EU kommt die KI-Verordnung (EU) 2024/1689 hinzu, die KI-Systeme in Medizinprodukten, die eine Konformitätsbewertung durch eine benannte Stelle benötigen, als Hochrisiko-KI einstuft. Die Anwendungsfristen und das Zusammenspiel mit der MDR sollten Sie mit Ihren Regulatory-Fachleuten klären.

Die Schweiz: MepV, Swissmedic, EU-Bevollmächtigter

In der Schweiz regelt die Medizinprodukteverordnung (MepV) das Inverkehrbringen. Sie wurde 2021 inhaltlich weitgehend an die MDR angeglichen. Zuständige Behörde ist Swissmedic.

Wegen des nicht aktualisierten Abkommens über die gegenseitige Anerkennung (MRA) mit der EU gilt die Schweiz aus Sicht der EU für Medizinprodukte als Drittstaat. Das hat Folgen (Stand 2026, prüfen Sie den aktuellen Status):

• Schweizer Hersteller brauchen für den EU-Markt einen Bevollmächtigten mit Sitz in der EU.
• Ausländische Hersteller brauchen für den Schweizer Markt einen Bevollmächtigten in der Schweiz.
• Schweizer Hersteller haben Registrierungspflichten bei Swissmedic.
• Die Schweiz anerkennt CE-Zertifikate aus der EU weiterhin einseitig, während die EU umgekehrt keine Schweizer Konformitätsbewertungen anerkennt.

Die politische Lage kann sich ändern. Verlassen Sie sich bei diesen Punkten auf die aktuellen Informationen von Swissmedic und auf Ihre Regulatory-Fachleute, nicht auf diesen Artikel.

Die Checkliste

Diese Liste zeigt, was ein Digital-Health-Team in der Regel bearbeiten muss. Sie ersetzt keine regulatorische Beratung und ist nicht abschliessend.

Zweckbestimmung und Klassifizierung

1. Zweckbestimmung schriftlich formulieren: medizinischer Zweck, Patientenpopulation, Anwender, Einsatzumgebung, Kontraindikationen.
2. Qualifizierung als Medizinprodukt begründen, gestützt auf MDCG 2019-11.
3. Risikoklasse nach Regel 11 bestimmen und die Begründung dokumentieren. Bei Unsicherheit früh mit der benannten Stelle klären.
4. Marktstrategie festlegen: EU, Schweiz, weitere Märkte, und welche Bevollmächtigten und Registrierungen dafür nötig sind.

Qualitätsmanagement und Lebenszyklus

5. QMS nach ISO 13485:2016 aufbauen, passend zur Grösse des Unternehmens. Mehr dazu im Artikel ISO 13485 für agile Software-Teams.
6. Verantwortliche Person für die Einhaltung der Regulierungsvorschriften nach Artikel 15 MDR benennen. Für Klein- und Kleinstunternehmen darf dies auch eine externe Person sein, die dauerhaft zur Verfügung steht.
7. Software-Lebenszyklus nach IEC 62304 definieren, inklusive Software-Sicherheitsklasse. Details im Artikel IEC 62304 in der Praxis.
8. SOUP und Open-Source-Komponenten erfassen und bewerten, inklusive Software-Stückliste pro Release.

Risiko, Usability, Sicherheit

9. Risikomanagement nach ISO 14971:2019 aufsetzen und über den ganzen Lebenszyklus führen.
10. Gebrauchstauglichkeit nach IEC 62366-1 nachweisen, inklusive summativer Evaluation mit repräsentativen Anwendern.
11. Cybersecurity nach Anhang I MDR planen, orientiert an MDCG 2019-16 und IEC 81001-5-1: Bedrohungsmodell, sichere Entwicklung, Schwachstellenmanagement, Informationen für Betreiber.
12. Datenschutz nach DSGVO und nDSG: Datenschutz-Folgenabschätzung, Auftragsverarbeitung, Datenstandort, Löschkonzept.

Klinische Bewertung und Dokumentation

13. Klinische Bewertung planen und durchführen. Für Software gibt MDCG 2020-1 die Struktur vor: valide klinische Assoziation, technische Leistung und klinische Leistung.
14. Technische Dokumentation nach Anhang II und III MDR zusammenstellen: Produktbeschreibung, Auslegung, Herstellung, grundlegende Sicherheits- und Leistungsanforderungen, Nutzen-Risiko-Analyse, Verifikation und Validierung.
15. Kennzeichnung und Gebrauchsanweisung erstellen, gegebenenfalls als elektronische Gebrauchsanweisung, sowie die UDI-Anforderungen für Software umsetzen.
16. Konformitätsbewertungsverfahren mit der benannten Stelle planen. Kapazitäten sind knapp, frühe Kontaktaufnahme lohnt sich.

Nach dem Inverkehrbringen

17. Post-Market-Surveillance-Plan erstellen, inklusive Berichtswesen (Bericht bzw. PSUR je nach Klasse).
18. Vigilanzprozess für schwerwiegende Vorkommnisse und Sicherheitskorrekturmassnahmen einrichten.
19. Änderungsmanagement definieren: Welche Software-Updates sind wesentliche Änderungen, die die benannte Stelle bewerten muss?

Was Startups am häufigsten unterschätzen

• Die Zeit bis zum Zertifikat. QMS aufbauen, Dokumentation erstellen, Termine bei der benannten Stelle erhalten: Das dauert. Planen Sie Finanzierung und Meilensteine entsprechend.
• Die klinische Bewertung. Viele Teams konzentrieren sich auf die Technik und merken spät, dass sie klinische Daten brauchen, die sie nicht haben.
• Updates nach dem Launch. Häufige Releases sind möglich, aber jede Änderung braucht eine dokumentierte Bewertung. Ohne schlanken Prozess wird die Wartung zum Engpass.
• Scope Creep in der Zweckbestimmung. Eine zusätzliche Funktion, etwa eine KI-gestützte Empfehlung, kann die Klasse erhöhen und den Aufwand deutlich vergrössern.
• Cybersecurity und Datenschutz. Beides wird geprüft, beides lässt sich schlecht nachrüsten.
• Die Rolle der Dokumentation im Alltag. Die technische Dokumentation ist kein einmaliges Projekt. Sie wird mit jedem Release fortgeschrieben und muss zum ausgelieferten Produkt passen.
• Lieferanten. Cloud-Anbieter, externe Entwickler und Dienstleister müssen im QMS bewertet und gesteuert werden.

Wie ein Entwicklungspartner helfen kann und wo seine Grenzen liegen

Ein erfahrener Entwicklungspartner kann viel beitragen: eine Architektur, die sicherheitsrelevante Teile sauber trennt, eine Entwicklung nach IEC 62304 mit automatisierter Traceability, Testnachweise aus der CI/CD-Pipeline, eine gepflegte SOUP-Liste und eine Arbeitsweise, die sich in Ihr QMS einfügt. Softverse hat eine MDR-zertifizierte Medizinprodukte-Plattform mit Backend, Web-App und Mobile App entwickelt und dabei nach IEC 62304 und ISO 13485 im QMS des Herstellers gearbeitet.

Fragen Sie einen möglichen Partner konkret: Hat er bereits in einem QMS eines Herstellers gearbeitet? Wie erzeugt er Traceability und Testnachweise? Wie dokumentiert er SOUP? Wie geht er mit Änderungen nach dem Release um? Die Antworten zeigen schnell, ob Erfahrung vorhanden ist oder nur Bereitschaft.

Die Grenzen sind ebenso klar. Die regulatorische Verantwortung bleibt beim Hersteller. Zweckbestimmung, Klassifizierung, klinische Bewertung und Konformitätsbewertung liegen bei Ihnen, Ihren Regulatory-Fachleuten und der benannten Stelle bzw. Swissmedic. Ein Entwicklungspartner entwickelt so, dass die Dokumentation für die Zertifizierung vorliegt. Er kann die Zertifizierung nicht garantieren. Mehr zu unserer Arbeit im regulierten Umfeld finden Sie unter MedTech.

Wenn Sie klären möchten, wie Ihr Vorhaben technisch und organisatorisch aufgesetzt werden kann, sprechen Sie mit uns im kostenlosen Erstgespräch.

Dieser Artikel ist eine allgemeine Einführung und ersetzt keine Rechts- oder Regulierungsberatung.