Prof. Dr. Christian Johner

Autor: Prof. Dr. Christian Johner

Inhaber der Johner Institut GmbH

Klinische Bewertung von Software

Donnerstag 26. Januar 2017

Für die klinische Bewertung von Software gelten die gleichen gesetzlichen Anforderungen wie für die klinische Bewertung aller Medizinprodukte.

Doch die Methoden für die klinische Bewertung von Software unterscheiden sich teilweise. Auch deshalb haben sich die FDA und das IMDRF dazu entschlossen, gemeinsam ein eigenes „Guidance Document“ herauszugeben mit dem Titel „Software as a Medical Device (SaMD): Clinical Evaluation“ (hier zum Download) und als Entwurf veröffentlicht.

Dieser Artikel verschafft Ihnen einen Überblick darüber, wie Sie die klinische Bewertung bei Software konform mit den Anforderungen der europäischen und US-amerikanischen Behörden durchführen können.

Kurze Wiederholung: Was ist eine klinische Bewertung?

Definition: klinische Bewertung

Clinical evaluation is the assessment and analysis of clinical data pertaining to a medical device in order to verify the safety, effectiveness and performance of the device. Clinical evaluation is an ongoing process conducted during the lifecycle of a medical device.

Quelle (FDA) (Link klicken)

Damit werden die Ziele zumindest indirekt genannt:

  • Effektiveness: Prüfen, ob das Gerät den Nutzen stiftet, den der Hersteller verspricht.
  • Safety: Prüfen, ob das Gerät sicher ist und keine Risiken birgt, die in der Risikoanalyse nicht bereits identifiziert und als akzeptabel bewertet wurden.
  • Performance: Prüfen, ob das Gerät die Leistung erbringt, die der Hersteller verspricht. Meist ist das eine Voraussetzung für die „Effectiveness“. Manchmal kann man die Prüfung auf diesen Performanz-Aspekt beschränken (statt die Effektivität explizit zu untersuchen).
Weiterführende Informationen

Lesen Sie hier einen weiteren Artikel über die klinische Bewertung.

Klinische Bewertung bei Software: Die Besonderheiten

Wie sich stand-alone Software von Medizingeräten unterscheidet

Stand-alone Software hat im Gegensatz zu anderen Medizinprodukten nur zwei wesentliche Schnittstellen nach außen:

  1. Benutzer-Produkt-Schnittstelle, oft grafische Benutzungsschnittstelle (GUI)
  2. Produkt-Produkt-Schnittstelle, insbesondere Datenschnittstellen

Während andere Medizingeräte „Outputs“ (=“Schnittstellen“ nach außen) vieler Art haben wie elektrische Energie (z.B. HF-Chirurgie-Gerät), elektromagnetische Energie (z.B. CT) oder mechanische Energie (z.B. Ultraschallgerät), ist der „Output“ der stand-alone Software auf Informationen beschränkt.

Software unterscheidet sich von anderen Medizinprodukten durch die Schnittstellen. Und damit auch die klinische Bewertung von Software.

Software unterscheidet sich von anderen Medizinprodukten durch die Schnittstellen. Und damit auch die klinische Bewertung von Software. Zum Vergrößern klicken.

Den Fall, dass die Software zur Ansteuerung von Medizinprodukten dient, betrachten wir hier nicht. Denn die Software wäre in den meisten Fällen ein Zubehör zu dem jeweiligen Produkt, zu dem bereits eine klinische Bewertung existieren sollte.

Unter dieser Annahme muss die klinische Bewertung von Software prüfen, ob die Software den versprochenen Nutzen liefert, also ob sie z.B. die Anwender zielführend bei der Diagnose oder Therapie unterstützt.

Nutzen von stand-alone Software

Stand-alone Software dient v.a. einem der folgenden Zwecke:

  • Diagnose oder Bereitstellen diagnoserelevanter Informationen
  • Auswahl geeigneter Therapien z.B. Auswahl eines geeigneten Medikaments, Entscheidung ob Chemotherapie oder Bestrahlung
  • Durchführen der Therapie selbst z.B. Berechnung des Einstichwinkels eines chirurgischen Instruments, Bestrahlungsplanung, Dosisberechnung

Klinische Bewertung und Validierung

Bei stand-alone Software stellt sich häufig die Frage, was man klinisch validieren könne. Die Validierung der Gebrauchstauglichkeit ist eine davon unabhängige Validierung. Damit konzentriert sich die klinische Validierung  / Bewertung eher auf die Wirksamkeit von Algorithmen. Beispiele:

  • Lässt ein Bildbearbeitungsalgorithmus Tumore mit ausreichender Wahrscheinlichkeit erkennen?
  • Hilft der Algorithmus eines Arzneimitteltherapie-Sicherheitssystems, Kontraindikationen und Wechselwirkungen zu erkennen und Fehlmedikationen zu vermeiden?

Manchmal sind diese Algorithmen banal. Dann stellt sich die Frage, was eine klinische Bewertung von Software an Erkenntnissen bringen soll. In manchen Fällen kann es ausreichen, anhand von Performance-Daten und Verifizierungsergebnissen zu argumentieren. Falls die Algorithmen hingegen komplexer sind, bedarf es des Beweises, dass sie den versprochen Nutzen bringen, d.h. klinisch valide sind. Zu den Aspekten der klinischen Validität lesen Sie unten mehr.

Aspekte der klinischen Bewertung von Software (laut FDA)

Das fordert, das die Hersteller folgende „Beweise“ erbringen:

  • Wissenschaftliche Validität („scientific validity“)
  • Klinische Leistungsfähigkeit („clinical performance“)
  • Analytische Validität („analytical validity“)
  • Klinische Validität („clinical validity“)

Diese Begriffe stellen Ihnen die folgenden Unterkapitel vor.

a) Wissenschaftliche Validität

Die wissenschaftliche Validität ist der Evidenzbeweis, dass die „Outputs“ des Produkts (hier der Software) mit einem klinischen oder physiologischen Zustand verknüpft sind.

Ein Beispiel stellt die Berechnung eines Scores dar, der wirklich ein Maß für ein bestimmtes Risiko darstellt.

Hersteller werden entweder diese Korrelation als bereits bewiesen ansehen, oder sie müssen diesen Beweis noch antreten, z.B. mit einer klinischen Studie. Im ersten Fall führen Sie den Beweis anhand bestehender Literatur und eventuell eigener Daten. Im zweiten Fall erwartet man oft den Vergleich mit einem Gold-Standard.

b) Klinische Leistungsfähigkeit

Die FDA definiert die klinische Leistungsfähigkeit als Evidenzbeweis, dass das Produkt (die Software) in der Lage ist, mit seinem „Output“ ein klinisch bedeutsames, positives Ergebnis zu liefern. Dieser Aspekt ist v.a. für diagnostische Produkte relevant. Sensitivität und Spezifität sind Attribute der klinischen Leistungsfähigkeit.

c) Analytische Validität

Unter der analytischen Validität versteht man den Evidenzbeweis, dass technische Leistungsmerkmale erfüllt sind z.B. bezüglich Genauigkeit, Zuverlässigkeit und Wiederholbarkeit/Reproduzierbarkeit.

Diese „analytische Validität“, lässt sich bereits im Rahmen der Verifizierung und Validierung beurteilen.

Besonders bei IVDs ist die analytische Validität ein wichtiges Kriterium. Bei Software ist diese Form der Validität z.B. dann ein Thema, wenn die Algorithmen nicht-deterministische Ergebnisse liefern. Auch die Prüfung, dass die Software nur Werte innerhalb eines definierten Bereichs liefert, wäre Gegenstand der analytischen Validierung.

d) Klinische Validität

Die klinische Bewertung von Software hat das Ziel, die klinische Validität zu prüfen. Diese ist kein vierter Aspekt. Vielmehr sieht die FDA die klinische Validität als gegeben, wenn die zuvor genannten Prüfungen erfolgreich verlaufen sind.

klinische Bewertung von Software: 3 Aspekte

Beispielsweise muss bei einem Diagnoseprodukt für die klinische Validität sowohl der Output mit einer klinischen Situation korrelieren (wissenschaftliche Validität), und der Output muss auch eine klinische Bedeutung haben (klinische Leistungsfähigkeit).

Was verlangt das Guidance Document der FDA?

Gemeinsam mit dem IMDRF hat die FDA ein Guidance Document „Software as a Medical Device: Clinical Evaluation“ publiziert.

Es fordert, dass die Hersteller mit der klinischen Bewertung von Software die klinische Validität des Produkts überprüfen. Damit weisen Sie nach, dass die beabsichtigte Zweckbestimmung erfüllt ist und keine inakzeptablen Risiken bestehen.

SOFTWARE AS A MEDICAL DEVICE (SAMD): CLINICAL EVALUATION

Das Guidance Document im Überblick (zum Vergrößern klicken)

Software muss sowohl vor der Inverkehrbringung klinisch bewertet werden als auch in der nachgelagerten Phase in kontinuierlicher Aktualisierung.

Der Aufwand für die klinische Bewertung soll risikobasiert angepasst werden. Die FDA schlägt vor, bei der klinischen Bewertung von Software wie folgt vorzugehen:

Klinische Bewertung von Software: Der Ablauf laut FDA (zum Vergrößern klicken)

Klinische Bewertung von Software: Der Ablauf laut FDA (zum Vergrößern klicken)

Wissenschaftliche Validität

Beim Nachweis der wissenschaftlichen Evidenz sollen die Hersteller Folgendes tun:

  • Literatur-Studie durchführen mit
    • Wissenschaftlicher Fachliteratur („peer reviewed articles“, Konferenzartikel)
    • Empfehlungen der Behörden
    • Wissenschaftliche Datenbanken auch mit Ergebnissen klinischer Studien
    • Expertenmeinungen z.B. in Büchern und Leitfäden
    • Ergebnissen erster Konzeptstudien und klinischer Vorstudien
  • Wissenschaftliche Validität von Daten des Herstellers feststellen anhand von
    • Kundenrückmeldungen, Beschwerden
    • Vorfällen
    • Post-Market-Daten
    • Fehlerdatenbank
  • Wissenschaftliche Studie durchführen (falls notwendig)

Das Guidance Dokument gibt einige wenige Hinweise, wie man bei diesen Studien vorgehen soll.

Analytische Validität

Die analytische Validität beweisen Hersteller im Rahmen der Verifizierung und Validierung. Dabei sollen sie ggf. zurückgreifen auf:

  • Algorithmen, die in der Literatur beschrieben sind
  • Vergleich mit Referenzstandard oder anderen Medizinprodukten
  • Echte Daten, die von den während der Entwicklung genutzten Trainingsdaten zu trennen sind

Üblicherweise referenzieren Hersteller bei der klinischen Bewertung von Software diese V&V-Ergebnisse.

Klinische Leistungsfähigkeit

Den Nachweis der klinischen Leistungsfähigkeit sollen die Hersteller mit Daten führen, die für die ganze Spannbreite der vorgesehenen Patientenpopulation repräsentativ sind.

Diese Daten können ebenso aus vom Hersteller durchgeführten klinischen Studien stammen wie aus der klinischen Literatur. Die Hersteller werden ermutigt, auch auf bestehende Daten von alternativen Verfahren und Produkten zurückzugreifen.

Zum Nachweis der klinischen Leistungsfähigkeit verlangt die FDA nicht notwendigerweise prospektive randomisierte klinische Studien. Sie hält auch Beobachtungsstudien für geeignet. Weshalb die FDA diese Unterscheidung trifft, erschließt sich beim Lesen nicht.

Anpassen der Evidenz-Niveaus

1. Klasse für die Software bestimmen

Die FDA verwendet für die klinische Bewertung von Software eine Klassifizierung aus anderen IMDRF Dokumenten:

Significance of information provided by SaMD to healthcare decision
State of healthcare
situation or condition
Treat or diagnose Drive clinical management Inform clinical management
Critical IV.i III.i II.i
Serious III.ii II.ii I.ii
Non-serious II.iii I.iii I.i

Als Beispiele für die Anwendungsgebiete nennt die FDA:

  • „Treat or diagnose“
    • Treat:
    • Provide therapy to a human 
body using other means;
    • Diagnose;
    • Detect;
    • Screen;
    • Prevent;
    • Mitigate;
    • Lead to an immediate or near 
term action.
  • „Drive clinical management“
    • Aid in treatment:
    • Provide enhanced support to safe and effective use of medicinal products;
    • Aid in diagnosis:
    • Help predict risk of a disease or condition;
    • Aid to making a definitive diagnosis;
    • Triage early signs of a disease or condition;
    • Identify early signs of a disease or condition.
  • „Inform clinical management“
    • Inform of options for treatment;
    • Inform of options for diagnosis;
    • Inform of options for prevention;
    • Aggregate relevant clinical information;
    • Will not trigger an immediate or near term action.

2. Evidenz abhängig von der Klasse nachweisen

Abhängig von der Klasse müssen die Hersteller Folgendes tun:

Grüne Klasse Gelbe Klasse Rote Klasse
Analytische Validität Ja Ja Ja
Wissenschaftliche Validität Ja Ja Ja
Bei neuen Verfahren zusätzliche Anforderungen
Klinische Leistungsfähigkeit Nur bei neuen Verfahren Nur bei diagnostischen Produkten der Klasse II.iii und bei neuen Verfahren Nur bei diagnostischen Produkten und bei neuen Verfahren
Unabhängiges Review (Objektive und kompetente Person außerhalb des Herstellers) Nein Nein Ja

Wie sollte man bei der klinischen Bewertung von Software vorgehen?

1. Schritt: Zweckbestimmung festlegen

Eine präzise formulierte Zweckbestimmung ist die Basis nicht nur für das Risikomanagement, sondern auch für die klinische Bewertung. Die Zweckbestimmung sollte die „Claims“ des Herstellers klar benennen. Denn das Ziel der klinischen Bewertung besteht (auch) darin, den Beweis zu erbringen, dass diese „Claims“, d.h. der Nutzen erreicht wurden.

Häufig stehen bei standalone Software wie bei Patientendaten-Managementsystemen die Risiken und Nebenwirkungen stärker im Vordergrund als der klinische Nutzen durch die Software direkt: Dieser klinische Nutzen bestimmt sich mehr aus der Vermeidung von Risiken, die man mit einer Alternative hätte, beispielsweise bei manueller Medikamentenverschreibung anstatt einer computergestützten.

2. Schritt: Entscheiden, ob klinische Bewertung extern vergeben wird

Eine klinische Bewertung zu erstellen, ist eine anspruchsvolle Aufgabe. Das gilt unabhängig davon, ob die Anforderungen der FDA oder der europäischen Behörden zu erfüllen sind. Das gilt auch unabhängig davon, ob die klinische Bewertung für eine Software oder ein anderes Medizinprodukt zu erstellen ist. Daher besteht die erste Empfehlung darin, externe Expertise hinzuzuziehen,

  1. wenn im eigenen Haus keine Kompetenz in Form eines Arztes und/oder Wissenschaftlers vorhanden ist oder
  2. wenn keine (zeitlichen) Kapazitäten vorhanden sind.

3. Schritt: Notwendige Evidenz bestimmen

Falls der Hersteller über Kompetenzen und Kapazitäten verfügt, besteht der nächste Schritt darin, die notwendige Evidenz festzulegen. Das heißt, der Hersteller sollte anhand der obigen Tabelle entscheiden, welche Nachweise zu erbringen sind:

  • Analytische Validität
  • Wissenschaftliche Validität
  • Klinische Leistungsfähigkeit

4. Schritt: Daten erheben

Nachdem klar ist, welche „Beweise“ zu erbringen sind, gilt es nun, die Methode festzulegen, mit denen die klinischen Daten erhoben werden sollen.

  • Die Literaturrecherche,
  • die Analyse eigener Daten sowie
  • die Verifizierung und Validierung der Software zählen fast immer zu den Methoden.
  • Abhängig von den Ergebnissen und der Klassifizierung der Software gemäß obiger Tabelle sind weitere Verfahren zu ergänzen.
  • Dazu zählen ggf. klinische Studien.

Literaturrecherche

Entscheidend für den Erfolg der Literaturrecherche ist dabei die Suchstrategie. Die Suche sollte sich zum einen auf die Risiken durch die Software konzentrieren (z.B. Fehlmedikation wegen eines Programmierfehlers), zum anderen auf den Nutzen z.B. in Form von Risiken, die ohne die Software bestehen, bzw. die die Software verringert (z.B. Fehlmedikation durch fehlerhafte Berechnung von Hand). Daraus ergibt sich die Suchstrategie.

Ein Teil der Suche könnte darin bestehen, zwei Begriffsklassen zu bilden und beide durch AND zu verknüpfen. Die eine Begriffsklasse umfasst Schlagworte wie Computer, CPOE, App oder Electron*, die andere Schlagworte wie Adverse Event, Problem, Risk oder Safety. Hersteller sollten auch nach Algorithmen suchen.

Klinische Studien / Prüfung

Klinische Studien (am Patienten) bedeuten hohe finanzielle und zeitliche Belastungen. Häufig sind diese bei Software nicht notwendig, weil die bestehende Literatur ausreichend Informationen (klinische Daten) enthält.

5. Schritt: Daten auswerten und klinische Bewertung von Software erstellen

Der nächste Schritt besteht darin, die Daten auszuwerten und die klinische Bewertung zu schreiben. Die MEDDEV 2.7/1 gibt Hinweise zur Struktur dieses Dokuments.

Weiterführende Informationen

Der Auditgarant enthält neben Videos zur klinischen Bewertung auch ein Template mit Beispielen und einer Ausfüll-Anleitung.

6. Schritt: Risikoanalyse aktualisieren

Die klinische Bewertung soll nachweisen, dass

  1. der versprochene (klinische) Nutzen erbracht wird und
  2. nur die in der Risikoanalyse bereits als akzeptabel bewerteten Risiken bestehen.

Falls dieser Nachweis nicht oder nicht in Gänze gelingt, muss die Risikomanagementakte überarbeitet werden:

  • Ggf. Risikoakzeptanz neu bewerten (Risikoakzeptanzmatrix überarbeiten)
  • Fehlende Risiken ergänzen
  • Wahrscheinlichkeiten und Schweregrade möglicher Schäden überarbeiten
  • Bewertung des Nutzen-Risiko-Verhältnisses wiederholen und über Vertretbarkeit neu entscheiden.

Kritik und Fazit am Guidance Document

Der IMDRF hat ein nicht leicht zu verdauendes Werk verfasst. Die Autoren stellen die verschiedenen Aspekte der klinischen Bewertung von Software gut dar. Sie verweisen auf viele weitere Publikationen der gleichen Organisation.

Der Versuch, einen Algorithmus zu entwickeln, wie man bei klinischen Bewertung abhängig von Parametern wie dem Risiko vorgehen soll, bleibt aber teilweise stecken. Manches bleibt vage, und nur dank einiger konkreter Beispiele wird verstehbar, was gemeint ist und wann welcher Aspekt des Dokuments verpflichtend wird und wann nicht.

Mehr und präzisere Definitionen hätten dem Dokument ebenso gut getan wie ein durchgängiges Beispiel.

Das meiste, was das Dokument beschreibt, ist unspezifisch für Software. Ein Abgleich mit der MEDDEV 2.7/1 rev. 4 scheint nicht umfänglich erfolgt zu sein.

Ohne ein wissenschaftlich und medizinisch kompetentes Team sind die Anforderungen des Guidance Documents nur schwer verstehbar und kaum umsetzbar.


Kategorien: FDA Zulassung - die U.S. Food and Drug Administration, Regulatory Affairs, Systementwicklung
Tags:

Kommentar schreiben