Klinische Bewertung von Software: Drei Beweise für die Konformität

Für die klinische Bewertung von Software gelten die gleichen gesetzlichen Anforderungen wie für die klinische Bewertung aller Medizinprodukte. Das heißt, als Hersteller von Medical Device Software (MDSW) müssen Sie genau wie alle anderen Hersteller eine klinische Bewertung für Ihr Produkt erstellen. Für Software, die ein In-vitro-Diagnostikum (IVD) darstellt, muss eine Leistungsbewertung durchgeführt werden.

Das wiederum erfordert klinische Daten zu dem Produkt, vielleicht aus einer klinischen Prüfung bzw. einer klinischen Leistungsstudie, oder zu einem nachgewiesenen Äquivalenzprodukt. Aber für Software ergibt dieser Ansatz oft wenig Sinn.

Doch das MDCG-Dokument MDCG 2020-1: Guidance on Clinical Evaluation (MDR)/Performance Evaluation (IVDR) of Medical Device Software zeigt einen möglichen alternativen Weg für Software-Produkte auf. Die Benannten Stellen haben nun erste klinische Bewertungen von Software akzeptiert, die von uns auf Basis dieses Dokuments erstellt wurden.

1. Kurze Wiederholung: Was ist eine klinische Bewertung bzw. eine Leistungsbewertung?

Damit werden die Ziele zumindest indirekt genannt: Es geht um die Prüfung, ob das Medizinprodukt

• den Nutzen stiftet, den der Hersteller verspricht,
• sicher ist und keine Risiken birgt, die in der Risikoanalyse nicht bereits identifiziert und als akzeptabel bewertet wurden, und
• die Leistung erbringt, die der Hersteller verspricht.

2. Klinische Bewertung von Software: Die Besonderheiten

a) Der wesentliche Unterschied: Die Schnittstellen

Während andere Medizingeräte viele Formen an „Outputs“ (= Schnittstellen nach außen) 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“ von Stand-alone-Software auf Informationen beschränkt.

Software unterscheidet sich von anderen Medizinprodukten also durch die Schnittstellen:

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

Daher muss die klinische Bewertung bei Software prüfen, ob die Informationen dem Anwender einen Nutzen liefern, beispielsweise bei Diagnose oder Therapieauswahl, oder ob sie nützliche Informationen an andere Produkte weitergibt.

Dieses Konzept kommt IVD-Herstellern sicherlich bekannt vor. So liegt der Nutzen eines IVDs stets in der Bereitstellung angemessener medizinischer Informationen (s. IVDR, Erwägungsgrund 64). Der klinische Nachweis wird für die in-vitro diagnostische Software durch die Leistungsbewertung erbracht.

b) Besonderer Nutzen von Stand-alone-Software

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

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

c) Klinische Bewertung bzw. Leistungsbewertung anhand Verifizierung und Validierung

Die klinischen Bewerter und Leistungsbewerter stellen sich bei Softwareprodukten häufig die Frage, welche Aspekte sie überhaupt bewerten müssen. Meistens ist es sinnvoll, sich auf die Algorithmen zu konzentrieren, z.B.:

• 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 bzw. Leistungsbewertung von Software an Erkenntnissen bringen soll. In manchen Fällen kann es ausreichen, anhand von Verifizierungsergebnissen zu argumentieren.

Falls die Algorithmen hingegen komplexer sind, bedarf es des Beweises, dass sie den versprochen Nutzen bringen, d.h. klinisch valide sind. Genau diesen Ansatz verfolgt das MDCG-Dokument MDCG 2020-1.

3. Mit drei Beweisen zur klinischen Bewertung von Software laut MDCG 2020-1

Laut MDCG muss der Hersteller drei Beweise erbringen:

1. Wissenschaftliche Validität („scientific validity“)
2. Technische/analytische Leistungsfähigkeit („technical performance/analytical performance“)
3. Klinische Leistungsfähigkeit („clinical performance“)

Bei der Beweisführung sollte der Hersteller dabei fünf Phasen durchlaufen:

1. Planung
2. Datensammlung
3. Bewertung der Daten
4. Analyse der Daten
5. Dokumentation

Diese drei Beweistypen werden im Folgenden vorgestellt.

a) Beweis 1: Wissenschaftliche Validität

Quelle MDCG 2020-1

Die wissenschaftliche Validität ist also 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 tatsächlich ein Maß für ein bestimmtes Risiko darstellen muss.

Zum Nachweis der wissenschaftlichen Evidenz sollen die Hersteller folgende Quellen nutzen:

• 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

b) Beweis 2: Technische Leistungsfähigkeit

Die Verifizierung der technischen Leistung ist somit die Demonstration der Fähigkeit des Software-Produkts, aus den Eingabedaten genau, zuverlässig und präzise die beabsichtigte Ausgabe zu erzeugen.

Die technische Leistungsfähigkeit beweisen Hersteller im Rahmen der Verifizierung und Validierung (V&V). Dabei sollen sie ggf. zurückgreifen auf:

• 1. Verifizierungsaktivitäten, z.B.:
  • Unit-Tests
  • Integrationstests
  • Systemtests
• 2. Validierungsaktivitäten, z.B. anhand von:
  • Kuratierten Datenbanken oder Registern
  • Referenzdatenbanken
  • Bereits gesammelten Patientendaten

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

IVD-Hersteller bewerten die technische Leistungsfähigkeit der Software abschließend während der analytischen Leistungsbewertung des IVDs und berücksichtigen vorliegende V&V-Ergebnisse.

c) Beweis 3: Klinische Leistungsfähigkeit

Der Hersteller muss bei der klinischen Leistungsfähigkeit eine klinische Relevanz in Bezug auf die Zweckbestimmung des Produkts nachweisen. Die klinische Relevanz einer Medical-Device-Software zeigt sich als positive Auswirkung auf

• die Gesundheit eines Individuums, ausgedrückt in Form von messbaren, patientenrelevanten klinischen Endpunkten einschließlich Endpunkt(en) im Zusammenhang mit der Diagnose, Risikovorhersage, Vorhersage der Behandlungsreaktion(en), oder
• Aspekte, die mit seiner Funktion zusammenhängen, z.B. die der Früherkennung, Überwachung, Diagnose oder Hilfe zur Diagnose von Patienten, oder
• das Patientenmanagement oder zur öffentlichen Gesundheit.

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

Sie sollten z.B. die folgenden Informationen heranziehen, um die klinische Leistungsfähigkeit zu beurteilen:

• Klinische/diagnostische Sensitivität und/oder klinische/diagnostische Spezifität
• Positiver/negativer prädiktiver Wert
• Number needed to treat (Anzahl der Patienten, die aufgrund einer Erkrankung oder präventiv behandelt werden müssen, um ein zusätzliches Ereignis wie (Folge-) Krankheit oder Tod zu vermeiden)
• Number needed to harm (Anzahl der Patienten, die diagnostiziert/behandelt werden müssen, um eine unerwünschte Wirkung auf einen Patienten zu haben)
• Benutzerfreundlichkeit/Benutzeroberfläche
• Konfidenzintervall(e)

d) Zusammenfassung der Schritte für die klinische Bewertung von Software

Das folgende Ablaufschema zeigt noch einmal die wesentlichen Schritte der Erstellung der klinischen Bewertung:

4.  Klinische Bewertung von Software nach der Inverkehrbringung (Post-Market)

Die Hersteller müssen nach der Inverkehrbringung die Sicherheit, die Wirksamkeit und die Leistung des MDSW aktiv und kontinuierlich überwachen.

Wie bei allen Herstellern können die Informationen u.a. Beschwerde, direktes Endbenutzer-Feedback oder neu veröffentlichte Forschungen/Richtlinien umfassen. Ganz besonders relevant für MDSW ist aber die Erfassung von REAL-WORLD PERFORMANCE DATA, da diese mit Software relativ leicht zu gewinnen sind.

Dies ermöglicht sehr schnell und effektiv

• die rechtzeitige Erkennung und Korrektur von Fehlfunktionen,
• die Erkennung von systematischem Missbrauch,
• ein Verständnis der Benutzerinteraktionen und
• die laufende Überwachung der vorgesehenen klinischen Leistung (z.B. Sensitivität, Spezifität).

5. Beurteilung des Evidenz-Niveaus und der Daten

Die Hersteller müssen in erster Linie selbst entscheiden, ob für jeden Schritt das Niveau der Daten ausreichend ist und dies ggf. auch begründen. Hierbei geht es sowohl um die Menge als auch um die Qualität der Daten. Diese Bewertung kann sich an den folgenden Fragen orientieren:

a) Ausreichende Menge

• Unterstützen die Daten den Verwendungszweck, die Indikationen, die Zielgruppen, die klinischen Behauptungen und die Kontraindikationen?
• Sind die klinischen Risiken und die analytische Leistung bzw. klinische Leistung untersucht worden?
• Wurden relevante MDSW-Merkmale wie die Dateneingabe und -ausgabe, die angewandten Algorithmen oder die Art der Zusammenschaltung bei der Generierung der Daten zur Unterstützung der Leistung des Produkts berücksichtigt?
• Wie hoch ist der Innovationsgrad bzw. die Geschichte auf dem Markt (Wie groß ist der Bestand an wissenschaftlichen Erkenntnissen)?

b) Ausreichende Qualität

• Waren die Art und das Design der Studie bzw. des Tests geeignet, die Endpunkte zu erreichen?
• War der Datensatz angemessen und aktuell (Stand der Technik)?
• War der statistische Ansatz angemessen, um zu einer gültigen Schlussfolgerung zu gelangen?
• Wurden alle ethischen, rechtlichen und regulatorischen Erwägungen bzw. Anforderungen berücksichtigt?
• Besteht ein Interessenkonflikt?

c) Nachweis der Konformität ohne klinische Daten

In einigen Fällen, insbesondere bei Medical-Device-Software der niedrigeren Risikoklassen I und IIa, sind klinische Daten zum Nachweis der Konformität oft nicht angemessen. Sowohl die MDR (Artikel 61, Abschnitt 10) also auch das MDCG-Dokument 2020-1 erlauben eine Ausnahme.

Der Nachweis der Übereinstimmung mit grundlegenden Sicherheits- und Leistungsanforderungen kann allein auf der Grundlage der Ergebnisse nichtklinischer Testmethoden einschließlich Leistungsbewertung, technischer Prüfung („bench testing“) und vorklinischer Bewertung erfolgen. Dies muss aber auf jeden Fall begründet werden. Dabei müssen die folgenden Punkte berücksichtigt werden:

• Risikomanagements des Herstellers
• Berücksichtigung der besonderen Merkmale des Zusammenspiels zwischen dem Produkt und dem menschlichen Körper
• Bezweckte klinischen Leistung und Angaben des Herstellers zur Leistung

Auch für In-vitro-Diagnostika gilt, dass, wenn bestimmte Leistungsanforderungen nicht anwendbar sind, diese begründet ausgeschlossen werden können. Die IVD-Hersteller beschreiben ihre beabsichtigte Strategie zur Leistungsbewertung im produktspezifischen Leistungsbewertungsplan. Dort legen sie auch den Stand der Technik dar. Im Leistungsbewertungsbericht werden die Ergebnisse zum klinischen Nachweis und zum Nutzen-Risiko-Verhältnis abschließend zusammengefasst und bewertet.

6.  FDA & IMDRF zur Clinical Evaluation von Software as a Medical Device (SaMD)

Gemeinsam mit dem IMDRF hat die FDA bereits ein sehr ähnliches Guidance-Dokument „Software as a Medical Device: Clinical Evaluation“ publiziert. Es fordert, dass die Hersteller mit der klinischen Bewertung von Medizinprodukte-Software bzw. mit der Leistungsbewertung von IVD-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. Einige der Definitionen weichen von denen der MDCG ab. Das führt unter Umständen zu einem hohen Mehraufwand, falls beide Länder bedient werden müssen.

Die FDA gibt Hinweise, welche Schritte in Abhängigkeit von gewissen Parametern (Risikoklasse, Innovationsgrad etc.) gemacht werden müssen.

a) 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

b) Evidenz abhängig von der Klasse nachweisen

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

	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

c) 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:

1. Analytische Validität
2. Wissenschaftliche Validität
3. Klinische Leistungsfähigkeit

Was sich hinter diesen drei Aspekten verbrigt, finden Sie oben ausgeführt.

d) Daten erheben

Das Erheben der Daten kann genauso erfolgen wie oben beschrieben. Auch bei der FDA zählen zu den üblichen Datenquellen:

• Wissenschaftliche Fachliteratur
• Ergebnisse der Verifizierung und Validierung der Software
• Vorhandene Post-Market-Daten von eigenen und/oder fremden Äquivalenzprodukten
• Ergebnisse klinischer Studien

e) Daten auswerten und klinische Bewertung von Software erstellen

Auch bei der FDA besteht der nächste Schritt darin, die Daten auszuwerten und die klinische Bewertung bzw. (bei IVD) den abschließenden Leistungsbewertungsbericht zu schreiben. Für Medizinprodukte gibt die MEDDEV 2.7/1 Hinweise zur Struktur von klinischen Bewertungen, auch wenn das MEDDEV-Dokument die FDA nicht im Anwendungsbereich hat.

f) Fazit zu den Guidance-Dokumenten von IMDRF bzw. FDA

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

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

7. Zusammenfassung

Mit dem Dokument MDCG 2020-1 zur klinischen Bewertung bzw. zur Leistungsbewertung von Software versucht die europäische Medical Device Coordination Group den besonderen Anforderungen bei Software-Produkten Rechnung zu tragen. Die Autoren stellen die verschiedenen Aspekte der klinischen Bewertung von Software als Medizinprodukt bzw. IVD recht gut dar. Der Ansatz ist sehr viel pragmatischer als der bisherige.

Manches bleibt jedoch noch vage. Dank einiger konkreter Beispiele im Anhang wird verständlich, was gemeint ist sowie wann welcher Schritt des Algorithmus verpflichtend wird und wann nicht. Hier wäre eine genauere Abgrenzung der Notwendigkeiten (z.B. anhand der Einteilung der Funktionalitäten oder Klassifizierung der Software) sehr wünschenswert.

Außerdem fehlt jeglicher Bezug zu anderen MDCG-Guidance-Dokumenten hinsichtlich allgemeiner Aspekte der klinischen Bewertung, z.B. Anforderung an die Autoren.

Die FDA bietet ebenfalls ein Guidance-Dokument an, welches einen sehr ähnlichen Ansatz verfolgt. Hierin wird sehr viel klarer dargestellt, wann welche Nachweisausprägungen benötigt werden.

Wie bei jeder klinischen Bewertung sind die Anforderungen des MDCG-Guidance-Dokuments ohne ein wissenschaftlich und medizinisch kompetentes Team nicht umsetzbar.