Decision Support Systeme als Medizinprodukt

Decision Support Systeme, zu Deutsch Entscheidungsunterstützungssysteme, finden auch in der Medizin zunehmend Anwendung. Handelt es sich dabei um Medizinprodukte, müssen diese die gesetzlichen Anforderungen (z.B. die grundlegenden Anforderungen) erfüllen.

Dieser Artikel stellt die besonderen Herausforderungen vor, welche Hersteller von Decision Support Systemen bewältigen müssen, und gibt Tipps, wie diese Herausforderungen gemeistert werden können. Er erläutert auch das entsprechende Guidance Document der FDA.

1. Decision Support Systeme: Definition und Beispiele

a) Definition

b) Abgrenzungen

Viele klassische Management-Informationssysteme und Data-Warehouses bereinigen und konsolidieren Daten und stellen diese in Form von Dashboards oder OLAP-Würfeln bereit. Die Zielgruppe dieser Systeme ist regelmäßig das Management.

Decision Support Systeme (DSS) verfolgen zwar ähnliche Ansätze, basieren aber meist auf Modellen oder fortgeschrittenen mathematischen Verfahren. Sie haben den Anspruch, nicht nur Informationen, sondern entscheidungsrelevantes Wissen zu präsentieren. Viele DSS setzen daher auf Data Warehouses auf. Sie verwenden bei der Weiterverarbeitung der Daten, besonders in der Medizin, Verfahren der künstlichen Intelligenz.

c) Beispiele in der Medizin

Decision Support Systeme in der Medizin, auch als „Clinical Decision Support Systems“ CDSS bezeichnet, dienen allen Facetten medizinischen Handelns wie z.B.:

• Diagnoseunterstützung
  • Interpretation radiologischer Bilder insbesondere bei onkologischen und neurologischen Fragestellungen sowie der Infektionsdiagnostik
  • Pathologie und Histologie nicht nur im onkologischen Kontext
  • Dermatologie: z.B. Beurteilung von Hautläsionen
  • Ophthalmologie: Diagnose u.a. von Glaukomen
  • Differenzialdiagnostik auf Basis von Befunden, der Klinik und weiteren Parametern
• Therapieunterstützung
  • Arzneimitteltherapie z.B. Prüfung von Kontraindikationen und Wechselwirkungen oder die Auswahl der Medikamente z.B. Antibiotika oder Zytostatika.
  • Abwägung von Therapiealternativen oder Kombinationen (z.B. Chemotherapie versus Bestrahlung versus Operation versus palliative Versorgung)
  • Bestrahlungsplanung
  • Triage, Entscheidung über Priorität und nächste Schritte
• Monitoring
  • Alarmierung bei Intensivpatienten z.B. bei PDMS
  • Überwachung von Patienten zuhause

2. FDA Guidance Document „Clinical Decision Support Software”

a) Einführung

Die FDA hat für Decision Support Systeme 2017 ein eigenes “Guidance Document” als ersten, 2019 als zweiten Entwurf und 2022 final veröffentlicht. Wer allerdings erhofft, darin Hilfestellungen zu finden, wie die regulatorischen Anforderungen für diese Produkteklasse zu erfüllen sind, wird enttäuscht. Das Dokument grenzt lediglich ab – allerdings sehr ausführlich – wann ein DSS zum Medizinprodukt wird.

Dazu stützt sich die FDA auf die Definition des Gesetzestextes, den Artikel 520(o)(1)(E) des Food, Drug and Cosmetic Acts, kurz FD&C. Leider ist dieser Text so verkorkst geschrieben, dass sich die FDA nun bemüßigt fühlt, diesen für den Fall von DSS zu interpretieren.

b) Interpretation des Gesetzestextes

Demnach ist eine Software nur dann kein Medizinprodukt, wenn alle der folgenden Bedingungen erfüllt sind:

1. Sie dient NICHT der Erfassung, Verarbeitung oder Analyse von
   1. medizinischen Bildern,
   2. Signalen, die von einem IVD Gerät stammen
   3. (physiologischen) Signalen wie z.B. EKGs oder EEGs und zugehörige Auswertesoftware.
2. Sie dient (nur) der Anzeige, Analyse oder dem Ausdruck medizinischer Informationen über einen Patienten oder der Anzeige anderer medizinischer Informationen wie Bücher, klinischer Veröffentlichungen oder Leitlinien, Medikamentenbeipackzettel oder Behördenempfehlungen, selbst dann, wenn das medizinische Fachpersonal diese Informationen für die Entscheidung über Vorbeugemaßnahmen, Diagnosen und Behandlungen nutzt.
3. Sie dient der Unterstützung des medizinischen Fachpersonals, in dem sie Empfehlungen gibt zur Vermeidung, Diagnose oder Behandlungen von Krankheiten.
   Dies ist interessant, den genau dies würde die Software in Europa als Medizinprodukt klassifizieren. Die FDA geht noch weiter und kündigt an, auch bei Software, die sich nicht an das Fachpersonal, sondern an Patienten wendet, die Einhaltung der regulatorischen Anforderungen nicht einzufordern.
   Allerdings schränkt der nächste Absatz diese Großzügigkeit wieder substanziell ein:
4. Die Software gibt diese Empfehlungen in einer so transparenten Art und Weise, dass die Anwender selbst zu diesen Empfehlungen kommen können, ohne sich primär auf die Software verlassen zu müssen. Das setzt Folgendes voraus:
   1. Die Zweckbestimmung der Software(-Funktion) ist klar benannt.
   2. Die Nutzergruppe ist klar bestimmt (z.B. Ultraschalltechniker, Gefäßchirurg).
   3. Die Inputs, auf denen die Empfehlungen basieren, sind genannt und auch öffentlich verfügbar.
   4. Das logische Grundprinzip und die Herleitung der Empfehlung ist transparent gemacht. Die FDA besteht auch darauf, dass diese Informationen nicht nur öffentlich verfügbar sind (z.B. in der medizinischen Fachliteratur), sondern dass die vorgesehenen Nutzer, diese Information auch verstehen und die Empfehlung nachvollziehen können.

Die FDA hat versucht, einen Teil dieser Entscheidungen in eine Tabelle zu übertragen:

Is the intended user a healthcare professional?	Can the user independently review the basis?	Is it Device CDS?
yes	yes	no, it is Non-Device-CDS because it meets all of section 520(o)(1) criteria
yes	no	yes, it is Device-CDS
no, it is a patient or caregiver	yes	yes, it is Device-CDS
no, it is a patient or caregiver	no	yes, it is Device-CDS

Die FDA unterscheidet der Aktualisierung des Guidance Documents zwischen Device-CDS und Non-Device-CDS.

c) Mapping mit dem IMDRF Dokument

Die FDA fühlt sich auch bemüßigt, ihre Abgrenzung mit dem Framework des IMDRF zu Software as a Medical Device abzustimmen. Sie kennen vielleicht diese Tabelle:

State of health care situation or condition	significance of information provided by SaMD to healthcare decision
	Treat or diagnose	Drive clinical management	Inform clinical management
Critical	IV	III	II
Serious	III	II	I
Non-serious	II	I	I

Die FDA sieht die Non-CDS nur im Bereich der Spalte „Inform Clinical Management“. Die beiden anderen Spalten schließt die FDA aus:

SaMD functions that drive clinical management are not CDS, as defined in the Cures Act and used in this guidance […]

SaMD functions that treat or diagnose are not CDS, as defined in the Cures Act and used in this guidance […]

Clinical Decision Support Software – Draft Guidance for Industry and Food and Drug Administration Staff

d) Erstes Fazit

Die Einschränkung im vierten Punkt des FD&C relativiert das Delta zu den Europäischen Regularien, das sich im dritten Punkt auftat, deutlich. Dennoch wäre ein Entscheidungsunterstützungssystem, das einen Entscheidungsbaum abbildet, der in einer klinischen Leitlinie veröffentlicht ist, in den USA kein Medizinprodukt, in Europa hingegen ggf. schon, zumindest wenn der Hersteller erklären würde, das System diene der (Verbesserung der) Behandlung.

Mit der Aktualisierung des Guidance Documents im Jahr 2019 klassifiziert die FDA Clinical Decision Support Systems, die „drive clinical management“ oder gar der Diagnose oder Behandlung dienen, als Medizinprodukt. Die Behörde fasst das wie folgt zusammen:

IMDRF Risk Categorizsation	Can the User Independently Review the Basis	Intended User is HCP	Intended User is Patient or Caregiver
inform X critical	yes	not a device	oversight focus
inform X critical	no	oversight focus	oversight focus
inform X serious	yes	not a device	oversight focus
inform X serious	no	oversight focus	oversight focus
inform X non-serious	yes	not a device	enforcement discretion
inform X non-serious	no	enforcement discretion	oversight focus

Tabelle 1: Nur unter wenigen Bedingungen klassifiziert die FDA CDS nicht als Medizinprodukt.

In der finalen Version aus 2022 liefert die Leitlinie viele Beispiele und Interpretationen für jeden dieser vier Punkte. Sie enthält zudem Beispiele für „Non-Device CDS Software Functions“ und „Device Software Functions“.

Sie spezifiziert, dass nur wenn vier Bedingungen erfüllt sind, die FDA CDS nicht als Medizinprodukt klassifiziert:

1. Sie dienen nicht(!) der Sammlung, Verarbeitung und Analyse von Bilddaten, Daten von IVDs oder anderen Signalen z. B. Biosignalen.
2. Sie dienen der Anzeige, Analyse oder dem Ausdruck medizinischer Informationen zu Patienten, Leitlinien oder der klinischen Fachliteratur.
3. Sie dienen der Unterstützung von Professionals bei der Verhütung, Diagnose oder Behandlung von Krankheiten oder Gesundheitszuständen.
4. Sie erlauben es den Professionals, die Ergebnisse dieser Empfehlungen unabhängig zu überprüfen.

Ein Beispiel für solch eine „Function“, die eine Software nicht(!) zum Medizinprodukt macht, wären „Drug-drug interaction and drug-allergy contraindication notifications to avert adverse drug reactions“.

In Europa wäre dies ein Medizinprodukt zumindest der Klasse IIa, eher IIb

e) Beispiele

Decision Support Systeme, die kein Medizinprodukt sind

Zu den Beispielen für Decision Support Systeme, die kein Medizinprodukt sind, zählt Software, die

• zu einer bereits bestehenden Diagnose passende klinische Leitfäden auflistet,
• vor Arzneimittel- Wechselwirkungen und Kontraindikationen warnt, wenn(!) diese auf „FDA-approved“ Medikamentenwarnhinweisen (z.B. in Beipackzetteln) beruhen,
• eine Untersuchung basierend auf klinischen Leitfäden vorschlägt, z.B. dass ein Arzt erst einen Leberfunktionstest anordnet, bevor er Statine (ein Arzneimittel) verschreibt,
• Vorschläge für eine Chemotherapie auf Basis der Anamnese und Testergebnissen unterbreitet z.B. eine bestimmte Chemotherapie für BRCA-positive Patienten,
• Ernährungspläne berechnet,
• für Beatmungspatienten basierend auf den Blutgasen eine Hilfestellung beim Einstellen der Beatmungsparameter gibt – nicht aber diese Einstellung gleich vornimmt oder
• basierend auf Laborwerten wie HbA1c, Glukose usw. eine Aussage trifft, ob dieser Patient gemäß etablierter Guidelines ein Diabetiker ist.

Decision Support Systeme, die ein Medizinprodukt sind

Zu den Beispielen für Decision Support Systeme, die ein Medizinprodukt sind, zählt Software, die

• der Bestrahlungsplanung dient, die auf CT-Daten basiert,
• der Auswertung von medizinischen Bilddaten dient oder zur 3D-Rekonstruktion dieser Bilder,
• basierend auf Bilddaten hilft, einen Katheter richtig zu platzieren,
• physiologische Signale von Medizinprodukten analysiert z.B. Herzfrequenz, mit dem Ziel zu überwachen, ob der Patient einen Schlaganfall oder Narkolepsie hat,
• Schallsignale auswertet, um daraus eine Bronchitis zu diagnostizieren,
• auf einem Bild eine Läsion und die umgebende Haut auswertet, um daraus Rückschlüsse über die Gut- oder Bösartigkeit dieser Läsion zu geben (z.B. Melanom),
• der Differenzialdiagnose dient z.B. der Abgrenzung einer Ischämie von einem Hirnschlag,
• aus der Atmung auf Apnoe schließt,
• aus der CSF (cerebrospinal fluid spectroscopy) Rückschlüsse über eine tuberkulöse Meningitis oder eine virale Meningitis zieht,
• in der Pathologie die Anzahl von Zellen bestimmt oder
• basierend auf einem proprietären Algorithmus anhand des Blutdrucks bestimmt, ob eine blutdrucksenkendes Medikament effektiv war.

f) Zweites Fazit

Der amerikanische Gesetzgeber definiert so unverständlich, wann eine Software ein Medizinprodukt ist, dass sich die FDA gezwungen sieht, dies in einem eigenen Guidance Document zu klären.

Viele Hersteller mögen es als Vereinfachung empfinden, wenn sie DSS ohne vorherige Clearance durch die FDA in den Verkehr bringen können. Das setzt aber u.a. voraus, dass die Algorithmen in der wissenschaftlichen Fachliteratur veröffentlicht und als valide bewiesen wurden.

Der Nachweis der klinischen Validität ist aber nicht ausreichend, um die Sicherheit der Patienten zu beweisen. Daher ist es verwunderlich, dass der amerikanische Gesetzgeber (nicht primär die FDA) an manchen Stellen großzügiger als die europäische Rechtssprechung ist.

3. Regulatorische Anforderungen in Europa

a) Grundlegende Anforderungen (MDD, MDR)

Einige Interpretationshilfen geben Hilfestellungen, wann eine Software als Medizinprodukt zu klassifizieren ist. Aber weder die Medizinprodukterichtlinie MDD, noch die Medizinprodukteverordnung MDR stellen konkrete Anforderungen an Decision Support Systeme. Dies ist verständlich, weil Gesetzestexte nicht für jede Produktklasse spezifische Anforderungen formulieren können. Dass die MDR dies für mobile Plattformen doch getan hat, zählt zum Reigen der Inkonsistenzen und Verirrungen dieser EU-Verordnung.

b) Klassifizierung gemäß MDD

Klinische Decision Support Systeme zählen zu den aktiven Produkten. Dienen sie der Diagnoseunterstützung, greift Regel 10 dann, wenn sie beispielsweise eine direkte Diagnose oder Kontrolle von vitalen Körperfunktionen ermöglichen. Dann fallen diese Produkte in die Klasse IIa, sonst greift Regel 12: „Alle anderen aktiven Produkte werden der Klasse I zugeordnet.“

Was eine „direkte Diagnose ist“, verrät die MDD nicht, dafür die MDR:

Klinische DSS können aber auch der Therapie dienen. Dann hängt die Klassifizierung davon ab, ob und welche therapeutischen Produkte direkt oder indirekt beeinflusst werden.

c) Klassifizierung gemäß MDR

Die Decision Support Systeme dienen wie der Name sagt der Entscheidungsunterstützung. D.h. sie liefern Informationen, die die Entscheidungen über Diagnosen, Therapien, Überwachung oder Vorbeugung von Krankheiten und Verletzungen betreffen.

Damit fallen diese Produkte gemäß Regel 11 der MDR mindestens in die Klasse IIa.

4. Weitere regulatorische Anforderungen

Medizinische bzw. klinische Entscheidungsunterstützungssysteme benötigen medizinische Daten, darunter auch Daten, die Patienten direkt zugeordnet werden können. Entsprechend sind diese Daten besonders schutzwürdig. Hersteller müssen die Anforderungen an den Datenschutz berücksichtigen.

5. Decision Support Systeme: Herausforderungen

Hersteller von klinischen DSS stehen vor Herausforderungen, denn nicht alles, was technisch machbar erscheint, ist technisch, regulatorisch und ethisch möglich.

Herausforderung 1: Zweckbestimmung

Die Hersteller müssen klar den Zweck und die versprochene Leistungsfähigkeit (die „Claims“) benennen. Das betrifft beispielsweise die Sensitivität und Spezifität bei Diagnosen. Das betrifft die Abhängigkeit dieser Claims von Randbedingungen wie Patientenkollektiv (Alter, Geschlecht, Co-Morbiditäten usw.).

Genau diese Klarheit können oder wollen viele Hersteller nicht schaffen.

Herausforderung 2: Leistungsnachweise, Verifizierung

Tests können nie die Korrektheit einer Implementierung bzw. eines Produkts nachweisen. Aber bei klassischen Algorithmen wie Entscheidungsbäumen lassen sich die erwarteten Ergebnisse spezifizieren.

Bei vielen Verfahren der künstlichen Intelligenz, insbesondere bei neuronalen Netzwerken sind diese Ergebnisse nicht mehr deterministisch. Dies gilt auch, wenn die Datenbasis, auf der die Algorithmen operieren, nicht konstant ist oder die Software diese sogar selbständig erweitert. Die Vorhersagbarkeit und Wiederholbarkeit von Testergebnissen ist zumindest erschwert.

In diesen Fällen gelingt es Herstellern häufig nicht, pass-fail-Kriterien zu definieren und zu begründen.

Herausforderung 3: Risikomanagement

Falls die Ergebnisse von Decision Support Systemen nicht deterministisch sind, wenn insbesondere nicht ausgeschlossen werden kann, dass diese sogar völlig falsche Empfehlungen geben, sind auch die Risiken kaum vorherzusagen.

Die Argumentation vieler Hersteller, dass ja noch ein Arzt die Ergebnisse prüfen würde, greift zu kurz. Die Ärzte werden hoffentlich die Wahrscheinlichkeit verringern, dass eine falsche Empfehlung zu einem Schaden führt. Aber das Risiko besteht dennoch, und der Nachweis, dass Ärzte die Wahrscheinlichkeit tatsächlich verringern, ist zu führen.

Auch die Nutzenargumentation mancher Hersteller ist angreifbar. Dies gilt besonders dann, wenn mit ökonomischen Einsparungen argumentiert wird. Hilfreicher ist eine Nutzenberechnung, die auf der Reduktion menschlicher Fehlhandlungen beruht. Aber auch diese gilt es zu beweisen z.B. mit Hilfe der klinischen Fachliteratur.

Herausforderung 4: Validierung, klinische Bewertung

Die klinische Bewertung muss den Nachweis erbringen, dass der versprochene Nutzen erreicht wird und dass keine Risiken vorliegen, die nicht bereits bekannt und als akzeptabel bewertet wurden. Dieser Nutzennachweis setzt ein Nutzenversprechen voraus, das oft nicht ausreichend konkret ist (siehe Herausforderung 1).

Der Nutzen misst sich als Verbesserung gegenüber dem Stand der Technik. Doch was ist dieser Goldstandard? Viele Hersteller vergleichen die Ergebnisse des DSS mit den Empfehlungen, die Ärztinnen und Ärzte geben würden. Doch ist das wirklich der Goldstandard? Dies gilt es zu begründen.

6. Fazit

Die klinischen Entscheidungsunterstützungssysteme haben seit den Siebzigerjahren viele „Hypes“ mit überzogenen Erwartungen erlebt, die immer einer Ernüchterung gewichen sind. Doch mit jeder technischen Innovation wie aktuell dem „Machine Learning“ kommt man dem Ziel näher, menschliche Intelligenz durch Computersysteme zu unterstützen, manchmal sogar zu ersetzen.

Werbung wie die von IBM für Watson weckt Erwartungen, die bei betroffenen Patienten zu tiefer Enttäuschung führen kann. Wie verantwortlich so ein Handeln ist, mag jeder für sich beantworten. Denn weder die technologischen, noch die regulatorischen, noch die medizinischen Hürden sind so gemeistert, dass diese Systeme in die breite Regelversorgung Einzug halten können.

---

Versionshistorie:

• 2022-09-30: Finalen Entwurf des FDA-Guidance-Dokuments Clinical Decision Support Software ergänzt