.svg)
Risikoklassifizierung einer Herzfrequenz-App: Was das OLG Hamburg für die MedTech-Branche bedeutet – und wo die Rechtslage noch offen ist
Eine App erfasst kontinuierlich die Herzfrequenz, archiviert die erhobenen Daten und weist auf mögliche kardiale Ereignisse, darunter Herzinfarkte und Herzrhythmusstörungen, hin – wobei sie dem behandelnden Arzt ausdrücklich als Entscheidungsgrundlage für diagnostische Zwecke dient.
Der Hersteller klassifiziert sie als Risikoklasse I.
Das bedeutet konkret: Er erklärt die Konformität mit der MDR selbst, erstellt die technische Dokumentation eigenverantwortlich, führt die klinische Bewertung ohne externe Prüfinstanz durch und bringt das Produkt auf den Markt. Die MDR räumt Herstellern von Klasse-I-Produkten das Privileg der Selbstzertifizierung bewusst ein, weil der Gesetzgeber bei diesen Produkten von einem geringen Risikopotenzial ausgeht.
Das OLG Hamburg, 20.06.2024
Das Hanseatische Oberlandesgericht Hamburg hatte sich in seinem Urteil vom 20.06.2024 (Az. 3 U 3/24) mit einer vergleichbaren teledermatologischen Softwareanwendung zu befassen, die vom Hersteller als Klasse-I-Produkt in den Verkehr gebracht worden war. Streitig war, ob in dem Kontext Risikoklasse I oder IIa zutreffend ist.
Das Gericht ordnete die Software als Klasse IIa ein und stützte sich dabei auf zwei Gesichtspunkte: Erstens auf den Wortlaut des Anhangs VIII Regel 11 Unterabsatz 1 MDR, der Software, die dazu bestimmt ist, Daten bereitzustellen, die für Entscheidungen für diagnostische oder therapeutische Zwecke herangezogen werden, mindestens der Klasse IIa zuordnet. Zweitens – und das ist für die Übertragbarkeit entscheidend – darauf, dass die konkrete Software durch eine gezielte Fragenauswahl aktiv die Grundlage für die ärztliche Diagnoseentscheidung beeinflusste, also nicht nur Daten übermittelte, sondern den Anamneseprozess strukturierte.
Der Hersteller hatte argumentiert, seine App leiste keinen eigenständigen diagnostischen Beitrag, sondern übermittle lediglich vom Patienten gelieferte Informationen. Regel 11 Unterabsatz 1 MDR setzt jedoch nicht voraus, dass die Software Daten generiert oder selbst bewertet, sondern dass sie dem Arzt Informationen liefert, die dieser als Kriterium für die individuelle Diagnostik heranzieht.
Das Urteil ist in der Fachwelt nicht unumstritten. Die Frage, wo genau die Grenze zwischen klassifizierungsrelevanter Informationslieferung und bloßer Datenübermittlung verläuft, ist höchstrichterlich – insbesondere durch den EuGH – noch nicht abschließend geklärt. Das mindert die praktische Bedeutung der Entscheidung nicht, sollte aber bei der Einschätzung des eigenen Produkts nicht ignoriert werden.
Was Klasse IIa bedeutet
Ab Klasse IIa entfällt das Privileg der Selbstzertifizierung. Eine Benannte Stelle (eine staatlich akkreditierte, unabhängige Prüforganisation) muss das Qualitätsmanagementsystem nach Anhang IX MDR, die vollständige technische Dokumentation sowie die klinische Bewertung extern auditieren und bestätigen, bevor das Produkt in den Verkehr gebracht werden darf. Hinzu kommen regelmäßige Überwachungsaudits, die verpflichtende Erstellung eines Periodic Safety Update Reports – bei Klasse IIa alle zwei Jahre, bei Klasse IIb und III jährlich – sowie die Meldepflicht bei signifikanten Produktänderungen.
Wer diese Anforderungen im Go-to-Market-Prozess nicht frühzeitig einplant und das Produkt dennoch als Klasse I in den Verkehr bringt, setzt sich Marktüberwachungsmaßnahmen nach Art. 94 ff. MDR aus sowie Sanktionen nach nationalem Medizinprodukterecht, in Deutschland insbesondere nach dem MPDG.
Zweckbestimmung und objektives Leistungsvermögen – eine unterschätzte Divergenz
Der häufigste Fehler ist kein strategischer, sondern ein konzeptioneller: Hersteller unterschätzen, dass nicht die technische Komplexität der Software die Risikoklasse bestimmt, sondern ihre Zweckbestimmung – und dass selbst eine sorgfältig formulierte Zweckbestimmung keinen verlässlichen regulatorischen Schutz bietet, wenn sie mit dem objektiven Leistungsvermögen des Produkts divergiert.
Art. 2 Nr. 12 MDR definiert die Zweckbestimmung als die vom Hersteller angegebene Verwendung. Das klingt nach Gestaltungsspielraum. Die MDR-Systematik setzt dieser Gestaltungsfreiheit jedoch Grenzen: Nach dem EU Blue Guide 2022 umfasst der vorgesehene Verwendungszweck nicht nur die Herstellerangaben, sondern auch die übliche Nutzung entsprechend Entwurf und Bauweise des Produkts. MDCG 2019-11 zur Software-Klassifizierung konkretisiert dies für Software: Maßgeblich sind nicht allein Kennzeichnung und IFU, sondern auch der Kontext, in dem das Produkt vermarktet und eingesetzt wird. Fachkommentare zur MDR bestätigen entsprechend, dass ein formulierter Ausschluss – etwa „das Produkt liefert keine Informationen für diagnostische Zwecke" – regulatorisch unwirksam sein kann, wenn das Produkt objektiv genau das tut.
In der Beratungspraxis zeigt sich das regelmäßig an folgendem Muster: Die Zweckbestimmung einer Herzfrequenz-App wird so gefasst, dass die Daten ausdrücklich nicht der Diagnosefindung dienen sollen, sondern lediglich Anzeichen kardial auffälliger Datenverläufe anzeigen sollen, um eine rechtzeitige oder prophylaktische Intervention zu ermöglichen. Denn die App erkennt kardiale Auffälligkeiten, stellt sie dem behandelnden Arzt dar, und dieser trifft auf dieser Grundlage eine Entscheidung. Dass dieser Vorgang als Risikohinweis statt als Diagnoseunterstützung bezeichnet wird, ändert seine Einordnung nicht: Jede Intervention setzt eine Entscheidung voraus, und jede Entscheidung, die auf den Ausgabedaten der App beruht, macht diese zur Informationslieferantin im Sinne der Regel 11 Unterabsatz 1 MDR. Eine Zweckbestimmung, die hinter dem objektiven Leistungsvermögen zurückbleibt, wird spätestens im Konformitätsbewertungsverfahren oder im Streitfall zum strategischen Risiko.
Fazit
Präventive Regulatorik beginnt nicht bei der Benannten Stelle. Sie beginnt beim ersten Satz der Zweckbestimmung.