Der MDR-Pfad für Solo-Entwickler:innen. Regel 11 ohne Compliance-Abteilung lesen.

Wenn eine Solo-Entwicklerin die EU-Medizinprodukte-Verordnung zum ersten Mal liest, setzt eine bestimmte Art von Schrecken ein. Das Dokument umfasst über fünfhundert Seiten. Es spricht von Benannten Stellen, Konformitätsbewertungsverfahren, Technischer Dokumentation, Post-Market Surveillance, Vigilanz, EUDAMED, Kurzbericht über Sicherheit und klinische Leistung, periodischen Sicherheitsberichten. Allein das Vokabular suggeriert eine Branche, die nur Firmen mit eigenen Regulatory-Affairs-Abteilungen zugänglich ist.

Dieser Eindruck stimmt teilweise und teilweise nicht. Ja, die MDR ist schwer. Ja, die volle Konformitätsbewertung für höher-risiko-klassifizierte Produkte ist tatsächlich teuer und langsam. Aber die Verordnung nimmt auch kleinere, risikoärmere Software auf eine Weise auf, die für sorgfältige Solo-Entwickler:innen machbar ist, vorausgesetzt, man liest sie genau und widersteht zwei entgegengesetzten Versuchungen: vorzugeben, die Verordnung gelte nicht, oder vorzugeben, man könne sie unmöglich erfüllen.

Die Frage, die zuerst kommt

Vor allem anderen steht die Frage, ob die Software, die man baut, überhaupt als Medizinprodukt qualifiziert. Artikel 2(1) der MDR definiert ein Medizinprodukt über die Zweckbestimmung. Wenn die Herstellerin es für Diagnose, Prävention, Überwachung, Vorhersage, Prognose, Behandlung oder Linderung von Krankheit vorsieht, ist es ein Medizinprodukt. Wenn es nur für allgemeines Wohlbefinden, Fitness oder Lifestyle gedacht ist, ist es das nicht.

Das ist keine Frage, die man beiläufig beantwortet. Die „Zweckbestimmung” ist das, was die Entwicklerin über das Produkt behauptet: in der Beschreibung für Nutzerinnen, im Marketing, im App-Store-Listing, in Screenshots. Aus einem Wellness-Tracker wird ein Medizinprodukt in dem Moment, in dem die Herstellerin behauptet, er helfe beim Management einer Erkrankung. Die Grenze wird durch Sprache gezogen, ebenso wie durch Funktion.

Für eine Solo-Entwicklerin ist der ehrlichste erste Schritt, die Zweckbestimmung zu entwerfen, bevor eine Zeile Code geschrieben wird, und sie als Rahmendokument zu behandeln. Sie sagt einem, ob man in den Anwendungsbereich der MDR eintritt oder außerhalb bleibt.

Was Regel 11 tatsächlich sagt

Wenn die Software als Medizinprodukt qualifiziert, bestimmen die Klassifizierungsregeln in Anhang VIII ihre Klasse. Regel 11 ist die, die auf die meisten Software-Medizinprodukte zutrifft. Vereinfacht: Software, die Informationen liefert, die für diagnostische oder therapeutische Entscheidungen verwendet werden, ist mindestens Klasse IIa. Software zur Überwachung physiologischer Prozesse kann Klasse IIa oder IIb sein, abhängig von den überwachten Parametern. Software zur allgemeinen, nicht-entscheidungsunterstützenden Dokumentation kann Klasse I sein.

Der praktische Effekt ist, dass der Unterschied zwischen Klasse I und Klasse IIa der Unterschied zwischen Selbstdeklaration und Benannter Stelle ist. Klasse-I-Produkte können durch eigene Konformitätserklärung der Herstellerin, Registrierung bei der nationalen Behörde und die nötige Technische Dokumentation in Verkehr gebracht werden, ohne Einbindung einer Benannten Stelle. Klasse IIa und höher erfordert die Einbindung einer Benannten Stelle, was erhebliche Kosten und Zeit hinzufügt.

Für Solo-Entwickler:innen ist der realistische Pfad daher, die Anwendung so zu gestalten, dass sie so niedrig in der Klassifizierungshierarchie sitzt, wie ehrlich mit ihrer Zweckbestimmung vereinbar. Das geht nicht darum, die Regel zu umgehen. Es geht darum, mit sich selbst und der Regulierungsbehörde klar zu sein, was die Software tut, und den Funktionsumfang entsprechend zu wählen.

Klasse I und Selbstdeklaration ist der Unterschied zwischen einem Sechs-Monats-Prozess und einem Drei-Jahres-Prozess. Wähle den Umfang bewusst.

Wo die Klassengrenze konkret verläuft

Die abstrakte Lesart von Regel 11 wird greifbar, sobald man konkrete Software-Funktionen einordnet. Eine kurze Reihe von Beispielen, wie sie in der Praxis fallen:

Eine App, die Schmerzwerte einer Patientin entgegennimmt, in einer Liste anzeigt und an die behandelnde Ärztin per PDF-Export weitergibt, ist Klasse I. Sie sammelt und dokumentiert, sie schlägt keine Entscheidung vor.

Dieselbe App, ergänzt um eine Warnschwelle (zum Beispiel: bei Schmerzwert über 7 erscheint ein Hinweis, die Hotline anzurufen), rückt an die Klasse-IIa-Grenze heran. Die entscheidende Frage ist, ob die App damit eine Information liefert, die für eine therapeutische Entscheidung verwendet wird. Wenn der Hinweis nur die übliche Verhaltensanweisung wiedergibt, die die Patientin sowieso schon kennt, bleibt es bei Klasse I. Wenn der Hinweis eine Dosis-Anpassung vorschlägt oder eine bestimmte Maßnahme empfiehlt, ist Klasse IIa wahrscheinlich.

Eine App, die Medikamenten-Erinnerungen verschickt, ist in der Regel Klasse I, weil sie eine reine Organisationshilfe ist und keine therapeutische Empfehlung enthält. Eine App, die Medikamenten-Dosen berechnet (etwa Insulin nach Kohlenhydraten und Blutzucker), ist Klasse IIa oder höher, weil das Berechnungsergebnis direkt eine therapeutische Entscheidung trägt.

Ein Symptom-Tagebuch für Patientinnen mit einer chronischen Erkrankung, das die Daten lokal speichert und auf Verlangen ausdruckbar macht, ist Klasse I. Dasselbe Tagebuch mit einer Funktion, die aus den Verlaufsdaten ein Risiko-Profil für die nächste Exazerbation prognostiziert, ist Klasse IIa.

Der Punkt ist nicht, durch geschickte Wortwahl eine Klasse-IIa-App als Klasse I zu deklarieren. Die Zweckbestimmung und die tatsächliche Funktion müssen übereinstimmen. Der Punkt ist, die Funktion bewusst zu wählen. Eine App, die als reines Dokumentationswerkzeug startet und die Entscheidungsunterstützung den Behandelnden überlässt, ist regulatorisch viel handhabbarer als eine App, die selbst die Entscheidung trägt, und sie ist in vielen klinischen Kontexten auch die ehrlichere Wahl.

Die Technische Dokumentation: weniger mysteriös als es klingt

Anhang II der MDR listet auf, was die Technische Dokumentation enthalten muss. Die Liste ist lang, aber die Substanz ist für jeden erkennbar, der durchdacht an einem Softwareprojekt gearbeitet hat: eine Produktbeschreibung, eine Zweckbestimmungs-Erklärung, eine Liste angewandter relevanter Normen, die Konstruktions- und Herstellungsinformationen, die Risikoanalyse, die Verifikations- und Validierungsnachweise sowie Kennzeichnung und Gebrauchsanweisung.

Für eine kleine Entwicklerin kann das schrittweise zusammengestellt werden, während das Produkt reift. Die Risikoanalyse nach ISO 14971 ist das Rückgrat: Sie listet Gefährdungen auf, die das Produkt einführen könnte, bewertet Wahrscheinlichkeit und Schweregrad und dokumentiert die Mitigationen. Die Gebrauchstauglichkeit nach IEC 62366 dokumentiert, wie menschliche Faktoren bedacht wurden. Die Software-Lebenszyklus-Prozesse nach IEC 62304 rahmen die Entwicklung selbst.

Keine dieser Normen ist erfunden, um kleine Teams zu quälen. Sie sind Kodifizierungen der einfachen Frage: Hast du sorgfältig darüber nachgedacht, was schiefgehen könnte, und hast du etwas dagegen getan? Eine Solo-Entwicklerin, die ehrliche Antworten auf diese Fragen schreibt, versionskontrolliert und datiert, ist den meisten Weg gegangen. Eine ergänzende Perspektive zur Architektur-Seite findet sich in Privacy by Design in Gesundheits-Apps.

Die Frage des Qualitätsmanagement-Systems

Die schwerere Anforderung ist das Qualitätsmanagement-System. Für Klasse-I-Produkte ist ein dokumentiertes QMS erforderlich, aber es muss nicht nach ISO 13485 zertifiziert sein. Für Klasse IIa und höher wird typischerweise eine Zertifizierung durch eine Benannte Stelle erwartet.

Für ein Ein-Personen-Studio ist es möglich, ein QMS aufzubauen, das echt, aber proportional ist. Das System muss definieren, wie Designentscheidungen geprüft werden, wie Änderungen kontrolliert werden, wie Lieferantenqualifizierungen gemanagt werden (auch wenn die Lieferanten Open-Source-Library-Maintainer:innen sind), wie Post-Market Surveillance gehandhabt wird und wie die Entwicklerin sicherstellt, dass das Produkt weiter wie behauptet funktioniert. Die Dokumentation muss nicht umfangreich sein. Sie muss gelebt werden.

Eine nützliche Übung ist, das QMS als eine Reihe kurzer Standard Operating Procedures zu schreiben, ein bis zwei Seiten pro Stück, die der tatsächlichen Praxis der Entwicklerin entsprechen. Wenn die SOP etwas anderes sagt als die Praxis, ist eine von beiden falsch.

Einbindung einer Benannten Stelle, wenn nötig

Für Klasse-IIa-Produkte muss eine Benannte Stelle die Konformitätsbewertung durchführen. Benannte Stellen stehen seit Inkrafttreten der MDR unter Kapazitätsdruck. Vorlaufzeiten von vielen Monaten sind üblich. Für eine kleine Entwicklerin beginnt die Einbindung lange vor dem eigentlichen Audit: Pre-Submission-Beratungen sind in der Regel möglich und ihren Preis wert.

Die Arbeitsannahme des Studios ist, dass die Einbindung beginnen sollte, sobald die Technische Dokumentation zu etwa siebzig Prozent vollständig ist. Früher verschwendet man die Zeit der Benannten Stelle und seine eigene. Später riskiert man einen plötzlichen Engpass genau dann, wenn man starten will.

Die Post-Market-Realität

Was Solo-Entwickler:innen oft unterschätzen, sind die Post-Market-Pflichten. Sobald das Produkt im Markt ist, muss die Herstellerin ein Post-Market-Surveillance-System betreiben, einen Periodic Safety Update Report einreichen (für Klasse IIa und höher) und auf Vorkommnisse im Rahmen des Vigilanz-Systems reagieren. Das sind laufende Pflichten, keine einmaligen Hürden.

Für ein Ein-Personen-Studio bedeutet das als Design-Constraint, dass das Produkt mit den verfügbaren Ressourcen unbegrenzt betreibbar sein muss. Ein komplexer Post-Market-Plan, der ein Team zur Ausführung erfordert, ist ein Plan, der scheitern wird. Ein einfacherer Plan, der jedes Quartal ohne Ausfall ausgeführt wird, schlägt einen ausgefeilten Plan, der nach achtzehn Monaten ausläuft.

Wie das in der Praxis aussieht

Das Arbeitsmodell des Studios für ein Klasse-I- oder Grenzfall-IIa-Software-Medizinprodukt ist grob dieses. Die Zweckbestimmung eng definieren und vor dem Coden aufschreiben. Die Anwendung um lokale Datenhaltung und ein Minimum externer Abhängigkeiten bauen. Eine Risiko-Akte ab dem ersten Sprint in Versionskontrolle führen. Designentscheidungen dokumentieren, während sie geschehen, nicht rückwirkend. Gebrauchsanweisung und Kennzeichnung neben der UI schreiben, nicht danach. Externes klinisches und regulatorisches Review bei der 70-Prozent-Marke einbinden. Post-Market Surveillance als Teil des Produkts planen, nicht als am Ende drangeschraubtes Papier.

Nichts davon erfordert eine Compliance-Abteilung. Es erfordert ehrliche, gut getaktete, versionskontrollierte Arbeit. So sieht gute Softwareentwicklung ohnehin aus.

Häufige Fragen

Wann gilt eine App als Medizinprodukt nach der EU-MDR?

Eine App qualifiziert als Medizinprodukt, wenn die Herstellerin sie für Diagnose, Prävention, Überwachung, Vorhersage, Prognose, Behandlung oder Linderung von Krankheit vorsieht (Art. 2(1) MDR). Die Zweckbestimmung wird durch das gezogen, was die Herstellerin behauptet (in App-Store-Listing, Marketing, Beschreibung), nicht durch die Funktion allein.

Was sagt Regel 11 der MDR konkret aus?

Regel 11 (Anhang VIII MDR) klassifiziert Software-Medizinprodukte. Software, die Informationen für diagnostische oder therapeutische Entscheidungen liefert, ist mindestens Klasse IIa. Software zur Überwachung physiologischer Prozesse ist Klasse IIa oder IIb, abhängig von den überwachten Parametern. Software zur reinen Dokumentation ohne Entscheidungsunterstützung kann Klasse I sein.

Was ist der praktische Unterschied zwischen Klasse I und Klasse IIa?

Klasse I erlaubt Inverkehrbringen über die eigene Konformitätserklärung der Herstellerin und Registrierung bei der nationalen Behörde, ohne Einbindung einer Benannten Stelle. Klasse IIa erfordert die Konformitätsbewertung durch eine Benannte Stelle, was deutlich mehr Zeit und Kosten bedeutet (oft Jahre statt Monaten).

Kann eine Solo-Entwicklerin die MDR-Anforderungen erfüllen?

Ja, bei sorgfältiger Planung. Notwendig sind eine eng definierte Zweckbestimmung vor dem Coden, Technische Dokumentation nach Anhang II MDR (schrittweise aufgebaut), Risikoanalyse nach ISO 14971, Gebrauchstauglichkeit nach IEC 62366, Software-Lebenszyklus nach IEC 62304, ein dokumentiertes QMS proportional zur Klasse, und ein Post-Market-Surveillance-System, das langfristig betreibbar ist.