Software als Medizinprodukt nach MDR

Software als Medizinprodukt nach MDR klassifizieren

Nicht jede Gesundheits-App ist automatisch ein Medizinprodukt. Hier beginnt in vielen Projekten bereits die Unsicherheit. Zwei Softwarelösungen können funktional ähnlich wirken und regulatorisch trotzdem an ganz unterschiedlichen Stellen landen: Das eine bleibt noch ein digitales Gesundheitsprodukt, das andere ist plötzlich Software als Medizinprodukt nach MDR, also Medizinproduktesoftware (“MDSW”).

Die MDR (Medical Device Regulation, EU 2017/745) ist die europäische Verordnung, die seit Mai 2021 verbindlich regelt, welche Anforderungen Medizinprodukte erfüllen müssen, bevor sie in der EU auf den Markt kommen dürfen: Von der Klassifizierung über klinische Bewertung bis zur Marktüberwachung.

Wer bei der Einordnung sofort über Klasse I, IIa oder IIb spricht, greift meist zu früh vor. Vor der Klassifizierung steht erst die Frage, ob die Software überhaupt unter die MDR fällt. Erst wenn diese Qualifizierung sauber geklärt ist, lässt sich die passende Risikoklasse bestimmen.
Die Zulassungsfrage sollte nicht beiläufig geklärt werden, denn die Einordnung wirkt oft schon früh auf Produktdefinition, Claims, Dokumentation, Aufwand, Zeitplan und Budget.

Wann Software oder Apps nach MDR
überhaupt als Medizinproduktesoftware gelten

Software gilt dann als Medizinproduktesoftware, wenn der Hersteller sie für einen medizinischen Zweck im Sinn der MDR bestimmt. Nicht der Gesundheitsbezug allein entscheidet, sondern die medizinische Zweckbestimmung.

Genau hier liegt der Punkt, an dem viele Diskussionen schief starten. Eine App kann sich mit Gesundheit, Prävention oder Versorgung beschäftigen und trotzdem nicht unter die MDR fallen. Umgekehrt kann eine eher unscheinbare Funktion regulatorisch relevant werden, sobald sie medizinische Aussagen trifft oder klinische Entscheidungen mitprägt. Die MDCG 2019-11 Rev. 1 beschreibt diese Grundlogik sehr klar: Erst die medizinische Zweckbestimmung macht aus Software eine echte Medical Device Software im Sinn der MDR (1).

Warum die Zweckbestimmung den Ausschlag gibt

Die Zweckbestimmung ist der rote Faden der Einordnung. Sie beantwortet nicht nur, was die Software technisch leisten kann, sondern wofür sie vom Hersteller bestimmt ist.
Das klingt zunächst nach einem formalen Satz für die Dokumentation. In der Praxis hängt daran aber fast alles.

Eine Anwendung, die Daten speichert und übersichtlich darstellt, ist regulatorisch etwas anderes als eine medizinische Software, die Daten bewertet und daraus diagnostische oder therapeutische Schlüsse ableitet. Dieselbe technische Basis kann deshalb zu einer anderen Einordnung führen, sobald sich die beanspruchte medizinische Funktion ändert.

Wichtig ist auch, dass die Zweckbestimmung nicht isoliert in einem Dokument lebt. Sie zeigt sich in der Produktbeschreibung, in Claims, in der Oberfläche, in der IFU und in der Vermarktung. Genau dort wird die Zweckbestimmung einer Software als Medizinprodukt in der Praxis sichtbar. Die MDCG 2019-11 Leitfaden-Logik greift diese Gesamtschau ausdrücklich auf, und auch das BfArM stellt sie an den Anfang der regulatorischen Bewertung (1,2).

Gerade für Produktteams ist das oft der eigentliche Aha-Moment. Die Frage lautet nicht nur: Was haben wir gebaut? Sie lautet: Was versprechen wir medizinisch mit diesem Produkt? Wer tiefer in diese Grundfrage einsteigen möchte, findet in unserem Beitrag zu Software as a Medical Device eine passende Ergänzung.

Welche Software typischerweise nicht unter die MDR fällt

Reine Dokumentation, Archivierung, organisatorische Unterstützung oder allgemeines Wellness-Tracking reichen in der Regel nicht aus, um Software als Medizinprodukt nach MDR relevant zu machen.

Das heißt nicht, dass solche Produkte regulatorisch immer sicher außerhalb liegen. Pauschale Aussagen greifen auch hier zu kurz. Trotzdem gibt es typische Konstellationen, die meist nicht unter die MDR fallen: eine Terminlogik, eine Kommunikationsfunktion, eine reine Datenablage oder Lifestyle-Funktionen ohne medizinische Zwecksetzung. Auch eine App, die nur Symptome oder Gewohnheiten erfasst, ist noch nicht automatisch Medizinproduktesoftware.

Spannend wird es dort, wo aus Anzeige oder Dokumentation eine inhaltliche Bewertung wird. Ein Symptomtagebuch, das Einträge speichert, liegt anders als eine Anwendung, die aus denselben Daten ein Krankheitsrisiko ableitet. Genau an dieser Grenze trennt sich gesundheitsnahe Software von MDSW. Die MDCG 2019-11 Rev. 1 grenzt diese Fälle bewusst so ab, damit nicht jede digitale Gesundheitslösung vorschnell als Medizinprodukt betrachtet wird (1).

Warum App, Webanwendung oder Cloud-Lösung regulatorisch nichts vorentscheiden

Die Bereitstellungsform entscheidet nicht über die regulatorische Einordnung. Entscheidend bleibt, welche medizinische Funktion die Software erfüllen soll.

Ob eine Lösung als App, Webanwendung, Plattform oder Cloud-Service bereitgestellt wird, ist für die Grundfrage zunächst zweitrangig. Software als Medizinprodukt nach MDR kann auf ganz unterschiedlichen technischen Wegen ausgeliefert werden.

Dasselbe gilt für softwarebasierte Gesamtsysteme. Eine cloudgestützte Anwendung kann also genauso Medizinproduktesoftware sein wie eine lokal installierte Lösung. Hier lohnt sich für den Gesamtzusammenhang auch der Blick auf unseren Beitrag Digital Health verstehen.

Wie die MDR die Klassifizierung von Software als Medizinprodukt regelt

Wenn die Qualifizierung steht, beginnt die eigentliche Klassifizierung. Dann geht es um Anhang VIII der MDR und um die Frage, welche Risikoklasse für das konkrete Produkt passt.

Für die meisten Softwareprodukte ist dabei die MDR-Regel 11 für Software der zentrale Bezugspunkt.
Für die Klassifizierung von Software unter der MDR sind vor allem vier Punkte maßgeblich: die medizinische Funktion, die Art der bereitgestellten Information, ihre klinische Relevanz und die möglichen Folgen von Fehlentscheidungen. Aus diesem Zusammenspiel ergibt sich die passende Risikoklasse.

Wann Software zur Überwachung physiologischer Prozesse MDR-relevant wird

Auch Software zur Überwachung physiologischer Prozesse kann unter Regel 11 fallen. Ausschlaggebend ist, wie kritisch die überwachten Werte im Versorgungskontext sind.
Nicht jede Monitoring-Funktion führt automatisch in eine hohe Klasse. Allgemeines Tracking ist etwas anderes als klinisch relevantes Monitoring.

Eine Anwendung, die Bewegungsdaten oder Schlafmuster abbildet, liegt anders als eine Lösung, die vitale physiologische Parameter überwacht und deren Output ein rechtzeitiges Handeln ermöglichen soll.

Hier kommt es stark auf die mögliche Gefährdung bei Fehlern oder ausbleibender Reaktion an. Werden vitale Parameter überwacht und kann eine relevante Veränderung eine unmittelbare Gefahr für Patient*innen auslösen, rückt Klasse IIb näher. Die MDCG nennt als Beispiele unter anderem Atmung, Herzfrequenz, Blutdruck, Blutgase, Körpertemperatur oder zerebrale Funktionen (1).

Welche typischen Denkfehler bei Software-Medizinprodukten immer wieder auftreten

Die meisten Fehler entstehen nicht beim Lesen des Gesetzestextes, sondern bei der Übersetzung in den Produktalltag.

Wellness- oder Lifestyle-App vs. medizinische Software

Eine Wellness-App ist nicht automatisch medizinische Software oder Software als Medizinprodukt nach MDR.

Das ändert sich aber schnell, sobald aus allgemeinem Gesundheitsbezug eine medizinische Aussage wird.
Eine Anwendung zur Erfassung von Schlaf, Aktivität oder Stimmung kann außerhalb der MDR liegen. Beansprucht dieselbe Anwendung jedoch, Krankheitsrisiken zu bewerten oder therapeutische Empfehlungen zu unterstützen, sieht die Einordnung anders aus. Der Unterschied liegt nicht im Interface, sondern in der medizinischen Funktion, die der Hersteller mit dem Produkt verbindet.

Reine Informationsdarstellung vs. klinisch relevante Informationsverarbeitung

Die Grenze zwischen Anzeige und Bewertung ist in der Praxis besonders wichtig.

Ein Dashboard, das Werte sammelt und übersichtlich darstellt, ist regulatorisch anders zu bewerten als eine Software, die diese Werte interpretiert, priorisiert oder klinisch relevante Schlüsse vorbereitet. Genau hier entstehen viele Missverständnisse, weil die Oberfläche ähnlich bleibt, die innere Logik des Produkts sich aber bereits verschoben hat.

Allgemeines Tracking vs. kritisches Monitoring

Allgemeines Tracking klingt oft harmlos. Kritisches Monitoring ist etwas anderes.

Eine App, die Trainings- oder Alltagsdaten darstellt, ist nicht automatisch Software als Medizinprodukt nach MDR im engeren Sinn. Sobald aber vitale physiologische Parameter überwacht werden und Fehler unmittelbare Folgen haben können, verändert sich die regulatorische Bewertung erheblich.

Warum ähnliche Produkte trotzdem unterschiedlich klassifiziert sein können

Ähnliche Features führen nicht automatisch zur gleichen Risikoklasse.

Zweckbestimmung, Nutzerkreis, klinischer Kontext und potenzieller Schaden im Fehlerfall wirken direkt auf die Einordnung. Zwei Produkte können fast gleich aussehen und regulatorisch dennoch verschieden bewertet werden. helfen Wettbewerbsvergleiche nur begrenzt, solange nicht klar ist, welche medizinische Rolle das jeweilige Produkt tatsächlich beansprucht. Wer hier früher sauber hinschaut, vermeidet viele der klassischen Annahmefehler in der Entwicklung digitaler Lösungen. Passend dazu lohnt sich auch unser Beitrag zu den 5 häufigsten Fehlern bei der Entwicklung einer Digital Health-Lösung.

Warum Bornholdt Lee der richtige Partner ist

Wenn du eine App oder Web-Anwendung im Digital Health-Bereich entwickelst oder planst, begleiten wir dich von der ersten Idee über die technische Umsetzung bis zur erfolgreichen ZPP-Zertifizierung. Strategie, Konzeption, UX/UI, Entwicklung, IT-Sicherheit – alles aus einer Hand.