IVDR und IVD-Software: Wie Sie Ihre Software richtig qualifizieren und klassifizieren können

Seit dem Inkrafttreten der EU-Verordnung (EU) 2017/746 (IVDR) im Mai 2022 hat sich die Welt der In-vitro-Diagnostik (IVD) radikal verändert. Eine der wichtigsten Änderungen: die nunmehr entscheidende Rolle der benannten Stellen. Schätzungen zufolge müssen fast 80 % der IVD-Produkte von einer benannten Stelle bewertet werden, um die CE-Kennzeichnung zu erhalten

In diesem Zusammenhang wirft die in der IVD verwendete Software viele Fragen auf:

• Ist jede Software betroffen?
• Wann ist eine Software als IVD-Medizinprodukt zu betrachten?
• Welche Fehler sollten vermieden werden, um eine Blockade bei der Bewertung zu verhindern?

Dieser Artikel fasst diese Fragen auf der Grundlage des Positionspapiers zusammen, das von Team-NB, der Europäischen Vereinigung der benannten Stellen, am 17. Juni 2025 veröffentlicht wurde.

1. Wichtige rechtliche Hinweise

Ein kurzer Blick zurück: Vor der IVDR sah die Richtlinie 98/79/EG eine relativ begrenzte Beteiligung der Benannten Stellen vor. Die neue Verordnung hingegen stützt sich bei der Klassifizierung von Produkten auf die mit dem Verwendungszweck verbundenen Risiken - und die Software steht dabei im Mittelpunkt.

Im Jahr 2019 hat die MDCG (Medical Device Coordination Group) einen Leitfaden(MDCG 2019-11) herausgegeben, der die Qualifizierung und Klassifizierung von Software sowohl unter der MDR als auch unter der IVDR klarstellt. Dennoch haben viele Hersteller immer noch Schwierigkeiten, diese Texte auf ihre eigenen Fälle anzuwenden. Deshalb ist das Team-NB-Positionspapier so hilfreich: Es stellt klar, was die Benannten Stellen erwarten.

2. Was ist IVD-Software im Sinne der IVDR?

MDSW, oder Medical Device Software, bezieht sich auf jede Software, die für einen medizinischen Zweck gemäß der Definition in der IVDR bestimmt ist:

• Eigenständig (z. B. eine eigenständige NGS-Analyse-App).
• Integriert in ein System (z. B. Analysegerät-Firmware).
• Oder als Modul oder Zubehör.

Wichtigster Punkt: Manche Software kombiniert Module mit einem medizinischen Zweck und andere ohne (z. B. Bestandsmanagement, reine Archivierung). Jedes Modul muss klar abgegrenzt und dokumentiert werden.

3. 3 Szenarien zur Qualifizierung Ihrer Software

Das Positionspapier bietet ein klares Entscheidungsflussdiagramm, um die richtige Entscheidung zu treffen. Hier ist eine vereinfachte Version:

➊ Software, die ein Gerät steuert oder beeinflusst

z. B. Firmware, Motorsteuerungsmodul. In diesem Fall wird die Software als integraler Bestandteil des IVD-Systems bewertet. Keine separate Klassifizierung.

➋ Eigenständige IVD-Software

z. B. NGS-Anwendung, Bildanalysesoftware für die Krebsvorsorge. In diesem Fall ist die Software ein eigenständiges IVD. Sie muss entsprechend ihrem Verwendungszweck klassifiziert werden und über eine eigene technische Dokumentation verfügen.

➌ Zubehörsoftware

z. B. Middleware, Bildformatkonverter für die KI-Analyse. Hier hat die Software keinen direkten medizinischen Zweck, sondern unterstützt ein IVD-Gerät. Sie wird als Zubehör eingestuft und unterliegt dennoch den IVDR-Anforderungen.

Merke: Ihr Verwendungszweck ist der rote Faden.

4. Praktische Beispiele: Wie sieht es im wirklichen Leben aus?

Beispiel 1

NGS-Sequenzanalysesoftware zur Erkennung erblicher genetischer Anomalien. Sie liefert direkt ein diagnostisches Ergebnis → eigenständiges IVD-MDSW.

Beispiel 2

Eine mobile App, die Blutzuckerdaten verarbeitet, um Warnungen zu erzeugen und die Insulindosis anzupassen. Diagnostischer oder therapeutischer Zweck → IVD MDSW.

Beispiel 3

Ein Middleware-Modul, das Bilder von Biopsie-Objektträgern für die KI-Verarbeitung konvertiert. Es hat keinen eigenen medizinischen Zweck, sondern ermöglicht den Prozess → Zubehör.

5. Zu vermeidende Irrtümer

• Die Annahme, dass ein Cloud-Software- oder Visualisierungsmodul immer außerhalb des Geltungsbereichs liegt: Es kommt ganz auf den Verwendungszweck an.
• Vermischung von medizinischen und nicht-medizinischen Modulen ohne klare Grenzen: Dokumentieren Sie die Trennung.
• Vergessen, dass die Klassifizierung des gesamten Systems maßgeblich ist: Ein integriertes Modul muss der Klassifizierung des Systems folgen.

6. FAQ - Ihre häufigsten Fragen

Was ist Nicht-IVD-Software?

z. B. LIMS, ERP, Lagerverwaltung: keine Datenverarbeitung für diagnostische Zwecke → außerhalb des Anwendungsbereichs der IVDR.

Fällt ein LIMS unter die IVDR?

Nein, es sei denn, ein Teil des Systems dient der diagnostischen Auswertung. Dann muss dieses Modul als IVD-MDSW qualifiziert werden.

Wie sieht es mit Cloud-basierter Software aus?

Der Standort spielt keine Rolle (Cloud, PC, mobil): nur der Verwendungszweck zählt.

Meine Software wird separat verkauft - was soll ich tun?

Prüfen Sie, ob sie für die eigenständige IVD-Verwendung oder als Teil eines Systems bestimmt ist. Dies bestimmt das Bewertungsverfahren.

Kann ich ein Modul als "nicht medizinisch" qualifizieren?

Ja, aber Sie müssen nachweisen, dass es keine direkte Interaktion mit diagnostischen Daten hat. Die Grenzen und Schnittstellen müssen klar sein.

7. Fazit: Der Schlüssel ist der beabsichtigte Zweck

Um Hindernisse bei der Überprüfung durch die benannte Stelle zu vermeiden, sollten Sie sich immer fragen: " Was ist der eigentliche Verwendungszweck?"Formulieren Sie ihn klar, begründen Sie Ihre Entscheidungen und dokumentieren Sie Ihre Module. Und im Zweifelsfall: Gehen Sie keine unnötigen Risiken ein.

Wenn Sie nicht sicher sind, wie Sie Ihre Software qualifizieren oder klassifizieren sollen, hilft Ihnen CSDmed dabei, Ihre IVDR-Reise zu sichern und Überraschungen in letzter Minute bei der CE-Bewertung zu vermeiden.

Kontaktieren Sie uns, um Ihre Projekte zu besprechen.

Dieser Artikel könnte Sie auch interessieren: Neue MDCG 2025-4 Leitlinie: Anforderungen an Software-Apps für Medizinprodukte auf Online-Plattformen