Charakterisierung der Risiken von medizinischer Software: Was ist aus dem IMDRF-Leitfaden N81 (2025) zu lernen?

1. Ein neuer Leitfaden zum besseren Verständnis von Softwarerisiken

Die rasche Zunahme medizinischer Software - ob eigenständig (SaMD) oder eingebettet in ein Gerät - erfordert einen neuen Ansatz zur Risikobewertung. Es ist nicht mehr nur das Gerät, das die Versorgung gewährleistet, sondern die Informationen, die es erzeugt, filtert oder empfiehlt. Und diese Informationen können selbst zu einer Risikoquelle werden.

Um die Hersteller bei der Bewältigung dieser zunehmenden Komplexität zu unterstützen, hat die IMDRF im Januar 2025 einen neuen Leitfaden veröffentlicht: IMDRF/SaMD WG/N81 FINAL:2025 mit dem nüchternen Titel "Characterization Considerations for Medical Device Software and Software-Specific Risk".

Dieser Leitfaden enthält mehr als nur die Wiederholung des Offensichtlichen. Er bietet einen Rahmen für eine bessere Beschreibung medizinischer Software, die Identifizierung softwarespezifischer Risikofaktoren und die Unterstützung der regulatorischen Klassifizierungs- und Risikomanagementprozesse.

2. Was der IMDRF-Leitfaden N81 abdeckt (und was nicht)

Der N81-Leitfaden ist als Ergänzung zum IMDRF-Leitfaden N12 aus dem Jahr 2014 gedacht, der einen Rahmen für die Kategorisierung von SaMD nach ihren klinischen Auswirkungen vorschlug. Hier wird der Anwendungsbereich jedoch erweitert: Es geht nicht mehr nur um SaMD, sondern um jede Software, die unter die Definition von Medizinprodukten fällt, einschließlich in Hardware eingebetteter Software.

Was es bringt:

• Eine Methode zur genauen Beschreibung medizinischer Software (Verwendungszweck + Funktionsbeschreibung)
• Eine Checkliste zur Identifizierung spezifischer softwarebezogener Risiken, insbesondere von Informationsrisiken
• Eine gemeinsame Sprache für die Diskussion über die Klassifizierung von Softwarerisiken zwischen den Regulierungsbehörden

Was es nicht ist:

• Ein Klassifizierungswerkzeug
• Ein Standard für das Risikomanagement
• Eine Checkliste mit Anforderungen

Zur Erinnerung:

Der N81-Leitfaden ist ein Hilfsmittel zur Charakterisierung, keine normative Referenz. Er hilft Ihnen bei der Strukturierung Ihrer Überlegungen, nicht bei der Überprüfung Ihrer Konformität.

3. Charakterisierung medizinischer Software: zu berücksichtigende Dimensionen

3.1. Bestimmungsgemäße Verwendung: die 7 Schlüsselelemente

Der Leitfaden schlägt eine klare Strukturierung der beabsichtigtenVerwendung / des beabsichtigten Zwecks vor, die sich auf 7 Elemente stützt:

1. Medizinischer Zweck (Diagnose, Behandlung, Überwachung usw.)

2. Zielkrankheit oder -zustand (Schweregrad, Stadium usw.)

3. Zielpopulation (Alter, Gefährdung...)

4. Zielbenutzer (Kliniker, Patient, Pflegepersonal...)

5. Anwendungsumgebung (zu Hause, im Büro, im Krankenhaus...)

6. Kontraindikationen (falls relevant)

7. Softwarefunktionen: Inputs, Outputs und ihre Rolle im Versorgungspfad

In Anhang A des Leitfadens wird ein Entwurfsmodell vorgeschlagen, das für die Strukturierung der Abschnitte 1 und 3 Ihrer technischen Dokumentation nützlich ist.

3.2. Beschreibung der Software: die 4 vorgeschlagenen Achsen

Darüber hinaus muss die Softwarebeschreibung 4 Schlüsselbereiche abdecken:

• Behandeltes medizinisches Problem (Zweck der Software, Schweregrad, betroffene Population);
• Nutzungskontext (Art des Nutzers, Umgebung, Zeitpunkt der Nutzung im Behandlungspfad);
• Funktion und Verwendung der Software (Art der Ausgabe, Datenquelle, Grad der Autonomie, Erklärbarkeit, Empfänger);
• Änderungsmanagement (Lernen, Aktualisierung, Infrastruktur, Einsatz).

4. Charakterisierung von Software-Risiken: nützliche Konzepte

Der N81-Leitfaden stellt einen grundlegenden Punkt heraus: Software-Risiken sind nicht immer physischer Natur. Sie können sein:

• Informationell (fehlerhafte, fehlende oder falsch interpretierte Daten),
• Indirekt (falsche medizinische Entscheidung aufgrund von Software-Output),
• Bezogen auf verminderte Effizienz (Verzerrungen, Verlust der Interpretierbarkeit, mangelnde Zuverlässigkeit).

Beispiel: Software, die Sensordaten überinterpretiert, kann zu unnötigen Untersuchungen oder sogar unangemessenen Behandlungen führen.

Der Leitfaden unterstreicht auch die Verbindung zur ISO 14971: die Methodik der Risikoanalyse bleibt gültig, aber die Besonderheiten der Software müssen integriert werden.

5. Fallstudien: Wenn die Charakterisierung das Risikoniveau verändert

5.1. Beispiel 1: Diagnose von Prädiabetes mit Hilfe eines Algorithmus

Ein Softwareprogramm analysiert Patientenakten, um einen wahrscheinlichen Prädiabetes zu erkennen. Der Leitfaden zeigt, dass :

• Das Risiko ist moderat, da der Fehler keine unmittelbare Gefahr mit sich bringt.
• Der Ausschluss bestimmter Patienten (die vom Algorithmus nicht erkannt werden) ist jedoch ein Punkt der Wachsamkeit.
• Die Autonomie des Instruments und die Tatsache, dass bestimmte Schwellenwerte nicht sichtbar sind, beeinflussen die Wahrnehmung des Risikos.

Ein gutes Beispiel für ein indirektes, aber reales Informationsrisiko.

5.2 Beispiel 2: Digitale Schmerztherapie

Es werden zwei Szenarien verglichen:

• Szenario 1: Die Software wird als Ergänzung zu Analgetika eingesetzt
• Szenario 2: Die Software ist die einzig mögliche Therapie (medikamentenintolerante Patienten)

Gleiche Funktion, gleicher Zweck, aber sehr unterschiedliche Risiken. Im Falle eines Versagens stellt das zweite Szenario ein deutlich höheres Risiko für den Patienten dar.

6. In der Praxis: Wie Sie diesen Leitfaden als Hersteller nutzen können

Der N81-Leitfaden kann Ihnen dabei helfen:

• Ihr technisches Dossier bereits in den frühesten Entwicklungsphasen zu strukturieren,
• Ihre Risikoanalysen nach ISO 14971, insbesondere für algorithmische Funktionen, zu bereichern
• Ihrer regulatorischen Positionierung mit Behörden oder BS zu klären.

Checkliste zur Erinnerung:

• Definieren Sie Ihren Verwendungszweck klar und deutlich (unter Verwendung der 7 Elemente),
• Vervollständigen Sie die 4 Achsen der Softwarebeschreibung,
• Identifizieren Sie die für die Informationen und den Nutzungskontext spezifischen Gefahren,
• Bewerten Sie die Auswirkungen von Autonomie und Erklärbarkeit,
• Dokumentieren Sie das Änderungsmanagement von Software (Upgrades, AI, Anpassungen).

7. Mini-FAQ

Ersetzt dieser Leitfaden die ISO 14971?

Nein, er ergänzt sie. Er enthält Elemente, die spezifisch für Software sind.

Müssen die Tabellen und Checklisten des Leitfadens befolgt werden?

Nein, der Leitfaden hat keinen verbindlichen rechtlichen Wert. Er ist ein Hilfsmittel zur Strukturierung.

Kann er für eingebettete Software verwendet werden?

Ja, der Anwendungsbereich deckt alle Software ab, die unter die Definition von Medizinprodukts (DM) fällt.

Was ist, wenn sich meine Software ständig weiterentwickelt?

Der Leitfaden enthält einen Abschnitt über das Änderungsmanagement. Darin werden Sie aufgefordert, den Grad der Autonomie und den Umfang der Aktualisierungen zu beschreiben.

Befasst sich der Leitfaden auch mit KI-Algorithmen?

Indirekt, ja. Vor allem durch die Begriffe Erklärbarkeit, Autonomie und skalierbare Leistung.

8. Schlussfolgerung

Der IMDRF-Leitfaden N81 ist weder eine Norm noch eine Vorschrift. Er ist ein unschätzbares Strukturierungsinstrument, das hilft, Software-Risiken detailliert und kontextbezogen zu erfassen und zu dokumentieren.

Bei CSDmed helfen wir Herstellern, diese Best Practices bereits in den ersten Codezeilen zu integrieren, um das Produkt zu sichern und den Austausch mit den Behörden zu erleichtern.

Benötigen Sie Hilfe bei der Charakterisierung oder Dokumentation Ihrer medizinischen Software?

Kontaktieren Sie uns. Wir besprechen mit Ihnen den klinischen Einsatz, die Software-Architektur und die regulatorische Strategie.

9. Verwandte Ressourcen

• ISO 14971 und Start-ups: Wie man mit der Risikoanalyse beginnt, ohne sich zu verirren
• FDA vs. MDR: 5 Unterschiede, die für einen DM-Hersteller wichtig sind
• ISO 13485 für Neugründungen: 3 realistische Ansätze

• Charakterisierung der Risiken von medizinischer Software: Was sollten wir aus dem IMDRF-Leitfaden N88 (2025) lernen?