Prof. Dr. Christian Johner

Autor: Prof. Dr. Christian Johner

Inhaber der Johner Institut GmbH

Decision Support Systeme als Medizinprodukt

Dienstag 19. Dezember 2017

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.

Der Hype um die künstliche Intelligenz, insbesondere das Machine Learning, und Anwendungen wie Watson wecken Hoffnungen an die Leistungsfähigkeit von Decision Support Systemen.

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.

Decision Support Systeme: Definition und Beispiele

Definition

Definition: Decision Support System

„Unter einem Decision Support System (DSS), übersetzt Entscheidungsunterstützungssystem, versteht man ein Softwaresystem, das Informationen zusammenträgt, aufbereitet und präsentiert, auf Basis derer Menschen operative oder strategische Entscheidungen treffen können.“

Quelle: nach Wikipedia und anderen

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.

Decision Support Systeme - von Daten zur Entscheidung

Abb. 1: Decision Support Systeme stellen mehr als nur Daten bereit.

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

FDA Guidance Document „Clinical and Patient Decision Support Systems”

Die FDA hat für Decision Support Systeme ein eigenes “Guidance Document” als Entwurf 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üht fühlt, diesen für den Fall von DSS zu interpretieren.

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.

Erstes Fazit

Die Einschränkung im vierten Punkt 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.

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.

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.

Regulatorische Anforderungen in Europa

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.

Weiterführende Informationen

Lesen Sie hier mehr darüber, wann Software als Medizinprodukt zu klassifizieren ist.

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:

Definition: Direkte Diagnose

„Ein Produkt wird als Produkt angesehen, das eine direkte Diagnose ermöglicht, wenn es die Diagnose der betreffenden Krankheit oder des betreffenden Gesundheitszustandes selbst liefert oder aber für die Diagnose entscheidende Informationen hervorbringt.“

Quelle: 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.

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.

Weiterführende Informationen

Lesen Sie hier mehr zur Regel 11 gemäß MDR.

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.

Weiterführende Informationen

Lesen Sie hier mehr zum Datenschutz im Gesundheitswesen.

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.

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.


Kategorien: Health IT & Medizintechnik, Regulatory Affairs, Software & IEC 62304
Tags: ,

2 Kommentare über “Decision Support Systeme als Medizinprodukt”

  1. Christian Sauter schrieb:

    Hallo,

    ich habe eine Frage zu dem „Clinical and Patient Decision Support Software“-FDA-Guide. In dem Text hört es sich so an, als ob es da eine fertige Version gäbe. Ich habe nur diesen Draft gefunden, bei dem explizit steht, dass er noch nicht implementiert werden darf: https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM587819.pdf
    Gibt es eine fertige Version? Wo findet man diese?

    viele Grüße
    Christian

  2. Prof. Dr. Christian Johner schrieb:

    Sie haben absolut Recht, das Guidance Document liegt als Draft vor. Das war im Text nicht gut erkennbar. Einen entsprechenden Hinweis habe ich ergänzt.

    Danke für Ihre Anregung!

Kommentar schreiben