Regulatorische Anforderungen an Medizinprodukte mit Machine Learning

Die Einbindung von KI bei Medizinprodukten hat große Fortschritte gemacht, z. B. bei der Diagnose von Krankheiten. Hersteller von Produkten mit Machine Learning stehen vor der Herausforderung, die Konformität ihrer Produkte nachweisen zu müssen.

Auch wenn Sie die Gesetzte kennen – welche Normen und Best Practices sind zu berücksichtigen, um die Nachweise zu führen und mit Behörden und Benannten Stellen auf Augenhöhe zu sprechen?

Dieser Artikel gibt eine Übersicht über die wichtigsten Regularien und Best Practices, dies Sie unbedingt berücksichtigen sollten. Sie können sich das Recherchieren und Lesen von hunderten Seiten ersparen und perfekt auf das nächste Audit vorbereiten.

1. Gesetzliche Anforderungen an den Einsatz von Machine Learning bei Medizinprodukten in der EU

a) MDR und IVDR

Derzeit gibt es keine Gesetze und harmonisierte Normen, die speziell den Einsatz des Machine Learnings in Medizinprodukten regulieren. Offensichtlich müssen diese Produkte aber die bereits bestehenden regulatorischen Anforderungen wie MDR und IVDR erfüllen, z. B.:

• Hersteller müssen den Nutzen und die Leistungsfähigkeit der Medizinprodukte nachweisen. Bei Produkten, die der Diagnose dienen, bedarf es z. B. des Nachweises der diagnostischen Sensitivität und Spezifität.
• Die MDR verpflichtet die Hersteller, die Sicherheit der Produkte zu gewährleisten. Dazu zählt, dass die Software so entwickelt wurde, dass Wiederholbarkeit, Zuverlässigkeit und Leistungsfähigkeit gewährleistet sind (s. MDR Anhang I, 17.1 bzw. IVDR Anhang I, 16.1).
• Hersteller müssen eine präzise Zweckbestimmung formulieren (MDR/IVDR Anhang II). Sie müssen ihre Produkte gegen die Zweckbestimmung und die Stakeholder-Anforderungen validieren und gegen die Spezifikationen verifizieren (u. a. MDR Anhang I, 17.2 bzw. IVDR Anhang I, 16.2). Hersteller sind auch verpflichtet zur Beschreibung der Methoden, mit denen sie diese Nachweise führen.
• Basiert die klinische Bewertung auf einem Vergleichsprodukt, muss technische Äquivalenz gegeben sein, was die Bewertung der Software-Algorithmen explizit einschließt (MDR Anhang XIV, Teil A, Absatz 3). Dies ist bei der Leistungsbewertung von In-vitro-Diagnostika (IVD) noch weitaus schwieriger. Nur in gut begründeten Fällen kann auf eine klinische Leistungsstudie verzichtet werden (IVDR Anhang XIII, Teil A, Absatz 1.2.3).
• Die Entwicklung der Software, die Teil des Produkts wird, muss die „Grundsätze des Software-Lebenszyklus, des Risikomanagements einschließlich der Informationssicherheit, der Verifizierung und der Validierung berücksichtigen“ (MDR Anhang I, 17.2 bzw. IVDR Anhang I, 16.2).

b) KI-Verordnung der EU (AI Act)

i) Der Rahmen

Auf ihrer Webseite Neue Vorschriften für künstliche Intelligenz – Fragen und Antworten kündigt die EU an, KI in allen Branchen risikobasiert regulieren und die Einhaltung der Vorschriften überwachen (lassen) zu wollen.

Die EU sieht die Chancen des Einsatzes von KI, aber auch deren Risiken. Sie erwähnt explizit die Gesundheitsversorgung und möchte durch eine EU-weite Regulierung die Fragmentierung des Binnenmarkts verhindern.

Die Regulierung soll sowohl Hersteller als auch Anwender betreffen. Die umzusetzenden Vorschriften hängen davon ab, ob das KI-System als Hochrisiko-KI-System eingestuft wird oder nicht. Produkte, die unter die MDR oder IVDR fallen und für die Beteiligung einer Benannten Stelle gefordert ist, gelten als Hochrisikoprodukte.

Ein Schwerpunkt der Regulierung wird die biometrische Fernidentifizierung betreffen.

Die Regulierung sieht auch eine Überwachung und Auditierung vor; zudem erstreckt sie sich auf importierte Produkte. Die EU plant ein Zusammenspiel dieser Regulierung mit der neuen Maschinenverordnung (wohlgemerkt: Verordnung), die die bisherige Maschinenrichtlinie ablösen würde.

Es soll ein spezieller Ausschuss gegründet werden: „Der Europäische Ausschuss für künstliche Intelligenz soll sich aus hochrangigen Vertretern der zuständigen nationalen Aufsichtsbehörden, des Europäischen Datenschutzbeauftragten und der Kommission zusammensetzen.“

ii) Die Kritik

Wie immer betont die EU, dass der Standort gefördert werden soll und KMU nicht über Gebühr belastet werden dürfen. Diese Aussagen finden sich auch in der MDR. Aber keine der Verordnungen scheint diesem Anspruch gerecht zu werden.

Inhalt der KI-Verordnung	Unerwünschte Konsequenzen
Zu den Verfahren der künstlichen Intelligenz zählen nicht nur das maschinelle Lernen, sondern auch: „– Logik- und wissensgestützte Konzepte, einschließlich Wissensrepräsentation, induktiver (logischer) Programmierung, Wissensgrundlagen, Inferenz- und Deduktionsmaschinen, (symbolischer) Schlussfolgerungs- und Expertensysteme; – Statistische Ansätze, Bayessche Schätz-, Such- und Optimierungsmethoden“	Dieser bereite Anwendungsbereich kann dazu führen, dass viele Medizinprodukte, die Software enthalten, in den Anwendungsbereich der KI-Verordnung fallen. Jeder in Software gegossene Entscheidungsbaum wäre demnach ein KI-System.
Die KI-Verordnung wendet sich explizit an Medizinprodukte und IVD.	Es gibt eine Dopplung an Anforderungen. MDR und IVDR fordern bereits Cybersecurity, ein Risikomanagement, die Post-Market Surveillance, ein Meldesystem, eine technische Dokumentation, ein QM-System usw. Hersteller müssen demnächst die Konformität mit zwei Verordnungen nachweisen!
Die Verordnung gilt unabhängig davon, wofür die KI im Medizinprodukt eingesetzt wird.	Selbst eine KI, mit der ein verschleißärmerer Betrieb eines Motors realisiert werden soll, würde unter die EU-Verordnung fallen. Als Konsequenz werden Hersteller sich genau überlegen, ob sie von KI-Verfahren Gebrauch machen. Das kann sich nachteilig auf die Innovation, aber auch auf die Sicherheit und Leistungsfähigkeit von Produkten auswirken. Denn i. d. R. setzen die Hersteller KI ein, um die Sicherheit, Leistungsfähigkeit und Wirksamkeit von Produkten zu verbessern. Andernfalls dürften sie KI gar nicht verwenden.
Die Verordnung fordert: „Hochrisiko-KI-Systeme werden so konzipiert und entwickelt, dass sie während der Dauer der Verwendung des KI-Systems – auch mit geeigneten Werkzeugen einer Mensch-Maschine-Schnittstelle – von natürlichen Personen wirksam beaufsichtigt werden können.“	Mit dieser Forderung ist der Einsatz von KI in Situationen ausgeschlossen, in denen Menschen nicht mehr ausreichend schnell reagieren können. Dabei könnte genau in diesen Situationen der Einsatz von KI besonders hilfreich sein. Wenn wir neben jedes Gerät eine Person setzen müssen, die den Einsatz der KI „wirksam beaufsichtigt“, bedeutet dies das Ende der meisten KI-basierten Produkte.
Die Verordnung definiert den entscheidenden Begriff „Sicherheitskomponente“, indem sie den nicht definierten Begriff einer Sicherheitsfunktion verwendet: Eine „Sicherheitskomponente eines Produkts oder Systems“ ist ein „Bestandteil eines Produkts oder Systems, der eine Sicherheitsfunktion für dieses Produkt oder System erfüllt oder dessen Ausfall oder Störung die Gesundheit und Sicherheit von Personen oder Sachen gefährdet;“ Auch andere Begriffe definiert die KI-Verordnung nicht in Übereinstimmung mit der MDR, z. B. „Post-Market Monitoring“ oder „serious inicident“.	Es wird Streit darüber geben, was eine Sicherheitsfunktion ist. Beispielsweise könnte es eine Funktion sein, die die Sicherheit von Patienten gefährdet, wenn sie sich nicht spezifikationsgemäß verhält. Es könnte aber auch eine Funktion gemeint sein, die eine risikominimierende Maßnahme implementiert. Definitionen, die nicht abgestimmt sind, erhöhen die Aufwände der Hersteller für das Verstehen und Abgleichen der verschiedenen Konzepte und der damit verbundenen Anforderungen.
Ein Produkt zählt als Hochrisiko-KI-System, falls die beiden folgenden Bedingungen erfüllt sind: „a) das KI-System soll als Sicherheitskomponente eines unter die in Anhang II aufgeführten Harmonisierungsrechtsvorschriften der Union fallenden Produkts verwendet werden oder ist selbst ein solches Produkt; b) das Produkt, dessen Sicherheitskomponente das KI-System ist, oder das KI-System selbst als Produkt muss einer Konformitätsbewertung durch Dritte im Hinblick auf das Inverkehrbringen oder die Inbetriebnahme dieses Produkts gemäß den in Anhang II aufgeführten Harmonisierungsrechtsvorschriften der Union unterzogen werden.“	Medizinprodukte fallen unter die in Anhang II aufgeführten Vorschriften, da diese die MDR und IVDR nennen. Medizinprodukte der Klassen IIa und höher müssen ein Konformitätsbewertungsverfahren durchlaufen. Sind sie somit Hochrisikoprodukte? Die unglückliche Regel 11 teilt Software – unabhängig vom Risiko – in den allermeisten Fällen in die Klassen IIa oder höher ein. Damit gelten für Medizinprodukte die umfangreichen Anforderungen an Hochrisikoprodukte. Die negativen Auswirkungen dieser Regel 11 werden durch die KI-Verordnung verstärkt.
In Artikel 10 fordert die KI-Verordnung „training, validation, and testing data sets shall be relevant, representative, free of errors and complete.“	Real-World-Daten sind selten fehlerfrei und vollständig. Es bleibt auch unklar, was mit „complete“ gemeint ist. Müssen alle Datensätze vorliegen (was auch immer das bedeutet) oder alle Daten eines Datensatzes?
Artikel 64 der KI-Verordnung verlangt von den Herstellern, den Behörden einen vollständigen Remote-Zugriff auf die Trainings-, Validierungs- und Testdaten zu verschaffen, sogar durch eine API.	Vertrauliche Patientendaten über einen Remote-Zugriff zugänglich zu machen steht im Konflikt mit der gesetzlichen Forderung nach Data Protection by Design. Gesundheitsdaten zählen zur besonders schützenswerten Kategorie personenbezogener Daten. Eine externe API zu den Trainingsdaten zu entwickeln und bereitzustellen, bedeutet für die Hersteller einen zusätzlichen Aufwand. Dass Behörden mit diesem Zugriff die Daten bzw. die KI mit vertretbarem Aufwand und in vertretbarer Zeit herunterladen, analysieren und bewerten können, ist unrealistisch. Bei anderen, oft sogar kritischeren Daten und Informationen zum Produktdesign und zur Produktion (z. B. Source-Code oder CAD-Zeichnungen) würde niemand ernsthaft verlangen, dass die Hersteller den Behörden einen Remote-Zugriff gewähren müssen.

Das Johner Institut hatte eine Stellungnahme mit diesen Bedenken an die EU eingereicht.

iii) Aktuelles zum AI Act

Ein neuer Entwurf des AI Acts steht seit Oktober 2022 bereit. Dieser löst viele Inkonsistenzen auf und beseitigt unklare Anforderungen. Doch Kritikpunkte, die auch wir der EU gemeldet haben, bleiben bestehen:

• Zu breiter Anwendungsbereich des Gesetzes (aufgrund der Definition von „artificial intelligence systems“) 
• Dopplungen und Inkonsistenzen mit den Anforderungen von MDR und IVDR

Dass nun ausgerechnet öffentliche Institutionen wie Strafverfolgungsbehörden von der Pflicht zur Registrierung der KI-basierten Produkte ausgenommen werden sollen, könnte Argwohn erzeugen.

Es ist allerdings zu begrüßen, dass KI-Systeme, die ausschließlich der Forschung dienen, von der Regulierung ausgenommen sind.

Zum Jahresende 2023 konnte die EU einen Kompromiss erzielen. Dieser Kompromiss liegt nun in einem noch schwer lesbaren, fast 900-seitigen Dokument vor.

Im März 2024 wurde der AI Act veröffentlicht.

c) (Harmonisierte) Normen ohne spezifischen Bezug zum Machine Learning

MDR und IVDR erlauben es, mithilfe harmonisierter Normen und Common Specifications den Konformitätsnachweis zu führen. Im Kontext von Medizinprodukten, die Verfahren des Machine Learnings verwenden, sollten Hersteller v. a. die folgenden Normen beachten:

• ISO 13485:2016
• IEC 62304
• IEC 62366-1
• ISO 14971
• IEC 82304

Diese Normen enthalten spezifische Anforderungen, die auch für Medizinprodukte mit Machine Learning relevant sind, z. B.:

• Die Entwicklung von Software für die Sammlung und Aufbereitung der Daten, für das Labeling sowie für das Training und die Prüfung der Modelle muss validiert sein (Computerized Systems Validation (CSV) gemäß ISO 13485:2016 4.16).
• Hersteller müssen vor der Entwicklung die Kompetenz der daran beteiligten Personen bestimmen und gewährleisten (ISO 13485:2016 7.3.2 f).
• Die IEC 62366-1 verlangt, dass die Hersteller die vorgesehenen Nutzer und die vorgesehene Nutzungsumgebung genau charakterisieren, ebenso die Patienten inklusive Indikation und Kontraindikation.
• Hersteller, die Software-Bibliotheken verwenden (was bei Software mit Machine Learning fast immer der Fall sein dürfte), müssen diese Bibliotheken als SOUP/OTS spezifizieren und validieren (IEC 62304).

2. Gesetzliche Anforderungen an den Einsatz von Machine Learning bei Medizinprodukten in den USA

a) Unspezifische Anforderungen

Die FDA stellt vergleichbare Anforderungen, v. a. in 21 CFR part 820 (u. a. part 820.30 mit den Design Controls). Es gibt zahlreiche Guidance-Dokumente, u. a. zur Software Validation, zum Einsatz von Off-the-shelf-Software (OTSS) und zur Cybersecurity. Diese sind Pflichtlektüre für Firmen, die in den USA Medizinprodukte verkaufen wollen, die Software sind oder enthalten.

b) Spezifische Anforderungen Teil 1 (Framework 2019 – inzwischen veraltet)

Die FDA veröffentlichte im April 2019 einen Entwurf Proposed Regulatory Framework for Modifications to Artificial Intelligence/Machine Learning (AI/ML)-Based Software as a Medical Device (SaMD).

Darin spricht sie über die Hausforderungen bei kontinuierlich lernenden Systemen. Sie stellt fest, dass die bisher zugelassenen Medizinprodukte, die auf Verfahren der KI basieren, mit „locked algorithms“ arbeiten.

Für die Änderungen der Algorithmen möchte die Behörde darlegen, wann sie

• keine Neueinreichung erwartet, sondern nur die Dokumentation der Änderungen durch den Hersteller,
• zumindest über die Änderungen und die Validierung einen Review durchführen möchte, bevor der Hersteller das geänderte Produkt auf den Markt bringen darf,
• auf einer (komplett) neuen Einreichung bzw. Zulassung besteht.

Bestehende Ansätze

Das neue „Framework“ basiert auf bekannten Ansätzen:

• Risikokategorien des IMDRF für Software as Medical Device (SaMD)
• Das „benefit-risk framework“ der FDA
• Überlegungen der FDA, wann Software-Änderungen eine Neuzulassung bedingen (Software Changes)
• Zulassungsverfahren einschließlich Pre-Cert-Programm der FDA, de-Novo-Verfahren usw.
• FDA Guidance zur Klinischen Bewertung von Software

Welche Ziele die Änderungen eines Algorithmus verfolgen können

Gemäß den Regeln der FDA muss ein im Einsatz selbst- bzw. weiterlernender Algorithmus einer erneuten Überprüfung und Zulassung unterzogen werden. Das scheint selbst der FDA zu rigide. Daher untersucht sie die Ziele einer Änderung des Algorithmus und unterscheidet:

• Verbesserung der klinischen und analytischen Leistungsfähigkeit: Diese Verbesserung ließe sich durch ein Trainieren mit mehr Datensätzen erreichen.
• Änderung der „Input-Daten“, die der Algorithmus verarbeitet. Das können zusätzliche Labordaten sein oder Daten eines anderen CT-Herstellers.
• Änderung der Zweckbestimmung: Als Beispiel nennt die FDA, dass der Algorithmus anfangs nur einen „Confidence Score“ berechnet, der die Diagnose unterstützen soll, und später die Diagnose direkt berechnet. Auch eine Änderung der der vorgesehenen Patientenpopulation zählt als eine Änderung der Zweckbestimmung.

Abhängig von diesen Zielen möchte die Behörde über die Notwendigkeit von Neueinreichungen entscheiden.

Säulen eines Best-Practice-Ansatzes

Die FDA nennt vier Säulen, mit denen die Hersteller über den Produktlebenszyklus hinweg die Sicherheit und den Nutzen ihrer Produkte auch bei Änderungen gewährleisten sollen:

1. Qualitätsmanagementsystem und „Good Machine Learning Practices“ (GMLP)
   Die FDA erwartet, dass die klinische Validität gewährleistet ist. (Was das ist, erfahren Sie in diesem Artikel.) Diese Forderung ist aber nicht spezifisch für KI-Algorithmen. Konkrete GMLP nennt die FDA nicht. Sie spricht nur von einer angemessenen Trennung von Training, „Tuning“ und Testdaten sowie von einer angemessenen Transparenz über den Output und die Algorithmen.
2. Planung und initiale Bewertung bezüglich Sicherheit und Leistungsfähigkeit
   Im Vergleich zu „normalen“ Zulassungen erwartet die FDA u. a. „SaMD Pre-Specifications“ (SPS), in der die Hersteller darlegen, welche Kategorien von Änderungen (s. o.) sie antizipieren. Zusätzlich sollen sie Änderungen gemäß einem „Algorithm Change Protocol“ (ACP) vornehmen. Damit ist kein Protokoll, sondern ein Verfahren gemeint. Was Gegenstand dieses Verfahrens ist, zeigt Abb. 1.
3. Ansatz, um Änderungen nach der initialen Freigabe zu bewerten
   Wenn Hersteller bei der initialen Zulassung keinen SPS und kein ACP eingereicht haben, müssen sie künftige Änderungen erneut der Behörde vorlegen. Andernfalls entscheidet die Behörde, ob sie eine erneute Einreichung erwartet, ob sie „nur“ ein „fokussiertes Review“ vornimmt oder ob sie vom Hersteller erwartet, dass er die Änderungen dokumentiert. Die Entscheidung hängt davon ab, ob der Hersteller dem „genehmigten“ SPS und ACP folgt und/oder ob sich die Zweckbestimmung ändert (s. Abb. 2).
4. Transparenz und Überwachung der Leistungsfähigkeit im Markt
   Die FDA erwartet regelmäßige Berichte über die Überwachung der Leistungsfähigkeit der Produkte im Markt gemäß SPS und ACP. Auch die Anwender wären zu informieren, welche Änderungen der Hersteller mit welchen Auswirkungen z. B. auf die Leistungsfähigkeit durchgeführt hat.
   Mit Transparenz meint die FDA somit nicht die Darlegung, wie z. B. die Algorithmen „unter der Haube“ funktionieren, sondern Offenheit darüber, was der Hersteller mit welchem Zweck und welchen Auswirkungen geändert hat.

Beispiel, unter welchen Umständen die Behörde bei Änderungen (nicht) involviert werden muss

Die FDA nennt Beispiele dafür, wann ein Hersteller den Algorithmus einer Software ändern darf, ohne die Behörde um Genehmigung zu fragen. Das erste dieser Beispiele ist eine Software, die in einer Intensivstation basierend auf Monitor-Daten (z. B. Blutdruck, EKG, Pulsoximeter) drohende Instabilitäten des Patienten vorhersagt.

Der Hersteller plant, den Algorithmus zu ändern, z. B. um Fehlalarme zu minimieren. Wenn er dies im SCS bereits vorsah und zusammen mit dem ACP von der Behörde genehmigt ließ, darf er diese Änderungen ohne erneute „Zulassung“ vornehmen.

Wenn er allerdings behauptet, dass der Algorithmus 15 Minuten vor einer physiologischen Instabilität warnt (er spezifiziert jetzt zusätzlich eine Zeitdauer), wäre das eine Erweiterung der Zweckbestimmung. Diese Änderung würde eine Zustimmung der FDA voraussetzen.

Zusammenfassung

Die FDA diskutiert, wie man mit kontinuierlich lernenden Systemen umgehen soll. Dabei ist noch nicht einmal die Frage beantwortet, was Best Practices sind, um einen „eingefrorenen“ Algorithmus, der auf Verfahren der KI basiert, bewerten und zuzulassen.

Es fehlt weiterhin ein Leitfaden, der „Good Machine Learning Practices“, wie es die FDA nennt, festlegt. Das Johner Institut entwickelt deshalb gemeinsam mit einer Benannten Stelle solch einen Leitfaden.

Das Konzept der FDA, auf Basis von vorab genehmigten Verfahren zu Änderungen der Algorithmen auf eine Neueinreichung ggf. zu verzichten, hat seinen Charme. Soviel Konkretheit sucht man auf Seiten der europäischen Gesetzgeber und Behörden vergeblich.

c) Spezifische Anforderungen Teil 2 (Framework 2023)

Zur Pflichtlektüre zählt auch das „Proposed Regulatory Framework for Modifications to Artificial Intelligence/Machine Learning (AI/ML)-Based Software as a Medical Device (SaMD)“ der FDA. Dieses hat die FDA im April 2023 in ein Guidance-Dokument mit dem Titel „Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence/Machine Learning (AI/ML)-Enabled Device Software Functions“ überführt.

Ein weiteres Guidance-Dokument der FDA zur radiologischen Bildgebung adressiert KI-basierte Medizinprodukte nicht direkt; es ist dennoch hilfreich. Zum einen arbeiten viele KI-/ML-basierte Medizinprodukte mit radiologischen Bilddaten, und zum anderen nennt das Dokument Fehlerquellen, die insbesondere auch für ML-basierte Produkte relevant sind:

• Patientencharakteristiken
  Demografische und physiologische Charakteristiken, Bewegungsartefakte, Implantate, räumlich heterogene Verteilung des Gewebes, Verkalkungen usw.
• Aufnahmecharakteristiken
  Positionierung, spezifische Eigenschaften der Medizingeräte, Aufnahmeparameter (z. B. Sequenzen bei MRTs oder Röntgendosen bei CTs), Algorithmen zur Rekonstruktion der Bilder, externe Störquellen usw.
• Bildverarbeitung
  Filterung, verschiedene Software-Versionen, manuelle Selektion und Segmentierung von Bereichen, Fitting von Kurven usw.

Die FDA, Health Canada und die britische Medicines and Healthcare Products Regulatory Agency (MHRA) haben in Zusammenarbeit die “Good Machine Learning Practice for Medical Device Development: Guiding Principles” veröffentlicht. Das Dokument enthält zehn Leitprinzipien, die man beim Einsatz von maschinellem Lernen in Medizinprodukten beachten sollte. Aufgrund der Kürze von nur zwei Seiten geht das Dokument nicht ins Detail, bringt aber die wichtigsten Prinzipien auf den Punkt.

Ergänzung

Wertvoll sind die aktualisierten „Guiding Principles“ für Medizinprodukte, welche Verfahren des maschinellen Lernens verwenden. Diese hat die FDA gemeinsam mit Health Canada entwickelt. Damit gibt es zwei Listen an „Guiding Principles“:

1. Good Manufacturing Learning Practices: Guiding Principles
2. Transparency for Machine Learning-Enabled Medical Devices: Guiding Principles

Das zweite und neue Dokumente ist somit das speziellere, das die Prinzipien 7 und 9 aus dem ersten Dokument genauer ausführt.

3. Gesetzliche Anforderungen an den Einsatz von Machine Learning bei Medizinprodukten in anderen Ländern

a) China: NMPA

Die chinesische NMPA hat den Entwurf „Technical Guiding Principles of Real-World Data for Clinical Evaluation of Medical Devices“ zur Kommentierung freigegeben.

Dieses Dokument ist derzeit aber nur auf Chinesisch verfügbar. Wir haben das Inhaltsverzeichnis automatisiert übersetzen lassen. Das Dokument adressiert:

• Anforderungsanalyse
• Datensammlung und -aufbereitung
• Entwurf des Modells
• Verifizierung und Validierung (auch klinische Validierung)
• Post-Market Surveillance

Die Behörde rüstet personell auf und hat eine „AI Medical Device Standardization Unit“ gegründet. Diese kümmert sich um die Standardisierung von Terminologien, Technologien und Prozessen für die Entwicklung und Qualitätssicherung.

b) Japan

Das japanische „Ministry of Health, Labour and Welfare“ arbeitet ebenfalls an AI-Standards. Den Fortschritt dieser Bemühungen veröffentlicht die Behörde leider nur auf Japanisch. (Übersetzungsprogramme helfen aber weiter.) Konkrete Ergebnisse stehen derzeit noch aus.

4. Für das Machine Learning relevante Normen und Best Practices

a) „Artificial Intelligence in Healthcare“ des COICR

Von April 2019 stammt das Dokument Artificial Intelligence in Healthcare des COICR. Es liefert keine konkreten neuen Anforderungen, sondern verweist auf bestehende und empfiehlt die Entwicklung von Normen.

Fazit: Wenig hilfreich

b) IEC/TR 60601-4-1

Der Technical Report IEC/TR 60601-4-1 gibt Vorgaben für „Medizinische elektrische Geräte und medizinische elektrische Systeme mit einem Maß an Autonomie“. Diese Vorgaben sind allerdings nicht spezifisch für Medizinprodukte, die Verfahren des Machine Learnings verwenden.

Fazit: Bedingt hilfreich

c) „Good Practices“ der Xavier University

Von der Xavier University stammen die „Perspectives and Good Practices for AI and Continuously Learning Systems in Healthcare”.

Wie der Titel bereits klarmacht, geht es (auch) um kontinuierlich lernende Systeme. Dennoch lassen sich viele der genannten Best Practices auch auf nicht kontinuierlich lernende Systeme übertragen:

• Bereits initial die Anforderungen an die Performance festlegen
• Informationen sammeln und Verständnis erreichen, wie das System über die Zeit lernt
• Professionellen Software-Entwicklungsprozess inklusive Verifizierung und Validierung befolgen
• Neue Daten, mit denen das System (weiter)lernen soll, einer systematischen Qualitätskontrolle unterziehen
• Grenzen festlegen, innerhalb derer sich der Algorithmus über die Zeit ändern darf
• Festlegen, was Änderungen des Algorithmus auslösen dürfen
• Das System so entwickeln, dass es seine eigene Performanz zeitnah und dem Benutzer die Ergebnisse in regelmäßigen Abständen berichtet
• Den Benutzern die Möglichkeit verschaffen, die Aktualisierung eines Algorithmus abzulehnen oder/und zu einer früheren Version zurückzukehren
• Die Benutzer informieren, wenn das Lernen eine signifikante Änderung des Verhaltens verursacht hat, und diese Änderung klar beschreiben
• Nachvollziehbar machen, wie ein Algorithmus sich weiterentwickelt hat und wie er zu einer Entscheidung kam

Besonders diese Nachvollziehbarkeit/Interpretierbarkeit stellt für viele Hersteller eine Herausforderung dar.

Das Dokument diskutiert auch spannende Fragen, z. B. ob Patienten informiert werden müssen, wenn ein Algorithmus sich weiterentwickelt hat und ggf. nachträglich zu einer besseren oder gar anderen Diagnose kommt.

Vorgaben dieses Dokuments werden in den AI-Leitfaden des Johner Instituts übernommen.

Fazit: Hilfreich insbesondere bei kontinuierlich lernenden Systemen

d) „Building Explainability and Trust for AI in Healthcare“ der Xavier University

Dieses Dokument der Xavier University, an dem auch das Johner Institut mitgewirkt hat, adressiert v. a. Best Practices im Bereich der Explainability. Es enthält nützliche Hinweise dazu, welche Informationen z. B. für die „technical stakeholder“ bereitgestellt werden müssen, um den Anforderungen an diese Explainability gerecht zu werden.

Fazit: Zumindest teilweise hilfreich

e) „Machine Learning AI in Medical Devices“ von BSI und AAMI

Der Titel dieses BSI-/AAMI-Dokuments klingt vielversprechend. Letztlich ist es aber nur ein Positionspapier, das Sie sich aus dem AAMI Store kostenfrei herunterladen können. Das Positionspapier fordert die Entwicklung weiterer Standards, an denen sich das BSI und die AAMI beteiligen. Ein Standard ist die Norm BS/AAMI 34971:2023-06-30, die im Unterkapitel 4.r) vorgestellt wird.

f) DIN SPEC 92001-1:2019-04

Sogar kostenfrei verfügbar ist die Norm DIN SPEC 92001 „Künstliche Intelligenz – Life Cycle Prozesse und Qualitätsanforderungen – Teil 1: Qualitäts-Meta-Modell“.

Sie stellt ein Meta-Model vor, nennt aber keine konkreten Anforderungen an die Entwicklung von AI/ML-Systemen. Das Dokument ist völlig unspezifisch und nicht auf eine bestimmte Branche ausgerichtet.

Fazit: Wenig hilfreich

g) DIN SPEC 9200-2 (noch in Entwicklung)

Der „Teil 2: Robustheit“ ist derzeit noch nicht verfügbar. Er enthält im Gegensatz zum ersten Teil konkrete Anforderungen. Diese zielen v. a. auf das Risikomanagement. Sie sind jedoch unspezifisch für Medizinprodukte.

Fazit: Zu beobachten, aussichtsreich

h) ISO/IEC CD TR 29119-11

Die Norm ISO/IEC TR 29119-11 „Software and systems engineering – Software testing – Part 11: Testing of AI-based systems“ befindet sich noch in der Entwicklung.

Wir haben diese Norm für Sie gelesen und bewertet.

Fazit: Ignorieren

i) Curriculum des koreanischen „Software Testing Qualification Board“

Das „International Software Testing Qualification Board“ (ISTQB) stellt einen Lehrplan zum Testen von KI-Systemen mit dem Titel „Certified Tester AI Testing (CT-AI) Syllabus“ zum Download bereit.

In den Kapiteln 1 bis 3 werden Begriffe und Konzepte erläutert. Kapitel 4 spricht explizit das Datenmanagement an. Kapitel 5 definiert Performance-Metriken. Ab Kapitel 7 gibt der Lehrplan Hinweise zum Testen von AI-Systemen.

Darüber hinaus enthält das Dokument im Kapitel 9 Vorgaben für das Blackbox-Testing von AI-Modellen wie das kombinatorische Testen und das „Methamorphic Testing“. Auch Tipps für das Testen neuronaler Netzwerke wie das „Neuron Coverage“ und Werkzeuge wie DeepXplore sind nennenswert.

Fazit: Empfehlenswert

j) ANSI/CTA-Standards

Die ANSI hat gemeinsam mit der CSA (Consumer Technology Association) mehrere Standards/Normen veröffentlicht:

• Definitions and Characteristics of Artificial Intelligence (ANSI/CTA-2089)
• Definitions/Characteristics of Artificial Intelligence in Health Care (ANSI/CTA-2089.1)

Die Normen liefern – wie der Titel vermuten lässt – Definitionen. Nicht mehr und nicht weniger.

Die CSA arbeitet derzeit an weiteren und konkreten Normen, u. a. zur „Trustworthiness“.

Fazit: Nur als Sammlung von Definitionen hilfreich

k) Normen der IEEE

Eine ganze Familie an Normen ist bei der IEEE in Entwicklung:

• P7001 – Transparency of Autonomous Systems
• P7002 – Data Privacy Process
• P7003 – Algorithmic Bias Considerations
• P7009 – Standard for Fail-Safe Design of Autonomous and Semi-Autonomous Systems
• P7010 – Wellbeing Metrics Standard for Ethical Artificial Intelligence and Autonomous Systems
• P7011 – Standard for the Process of Identifying and Rating the Trustworthiness of News Sources
• P7014 – Standard for Ethical considerations in Emulated Empathy in Autonomous and Intelligent Systems
• 1 – Standard for Human Augmentation: Taxonomy and Definitions
• 2 – Standard for Human Augmentation: Privacy and Security
• 3 – Standard for Human Augmentation: Identity
• 4 – Standard for Human Augmentation: Methodologies and Processes for Ethical Considerations
• P2801 – Recommended Practice for the Quality Management of Datasets for Medical Artificial Intelligence
• P2802 – Standard for the Performance and Safety Evaluation of Artificial Intelligence Based Medical Device: Terminology
• P2817 – Guide for Verification of Autonomous Systems
• 1.3 – Standard for the Deep Learning-Based Assessment of Visual Experience Based on Human Factors
• 1 – Guide for Architectural Framework and Application of Federated Machine Learning

Fazit: noch zu früh, weiter beobachten

l) ISO-Normen, die in Entwicklung sind

Auch bei der ISO arbeiten mehrere Arbeitsgruppen an AI/ML-spezifischen Normen:

• ISO 20546 – Big Data – Overview and Vocabulary
• ISO 20547-1 – Big Data reference architecture – Part 1: Framework and application process
• ISO 20547-2 – Big Data reference architecture – Part 2: Use cases and derived requirements
• ISO 20547-3 – Big Data reference architecture – Part 3: Reference architecture
• ISO 20547-5 – Big Data reference architecture – Part 5: Standards roadmap
• ISO 22989 – AI Concepts and Terminology
• ISO 24027 – Bias in AI systems and AI aided decision making
• ISO 24029-1 – Assessment of the robustness of neural networks – Part 1 Overview
• ISO 24029-2 – Formal methods methodology
• ISO 24030 – Use cases and application
• ISO 24368 – Overview of ethical and societal concerns
• ISO 24372 – Overview of computations approaches for AI systems
• ISO 24668 – Process management framework for Big data analytics
• ISO 38507 – Goveranance implications of the use of AI by organizations.

Erste Normen sind bereits fertiggestellt (wie die im Folgenden vorgestellte).

Fazit: Noch zu früh, weiter beobachten

m) ISO 24028 – Overview of Trustworthiness in AI

Die ISO/IEC TR 24048 trägt den Titel „Information Technology – Artifical Intelligence (AI) – Overview of trustworthiness in artificial intelligence”. Sie ist unspezifisch für eine bestimmte Domäne, nennt aber Beispiele auch für das Gesundheitswesen.

Die Norm fasst sowohl wichtige Gefährdungen und Bedrohungen zusammen als auch übliche Maßnahmen zur Risikominimierung (s. Abb. 3).

Die Norm bleibt aber auf allgemeinem Niveau, gibt keine konkreten Empfehlungen und stellt auch keine spezifischen Anforderungen. Als Übersicht und Einstieg sowie als Referenz auf weitere Quellen ist sie nützlich.

Fazit: Bedingt empfehlenswert

n) ISO 23053 – Framework for AI using Maschine Learning

ISO 23053 ist ein Leitfaden für einen Entwicklungsprozess von ML-Modellen. Er enthält keine konkreten Anforderungen, stellt aber den Stand der Technik dar.

Fazit: Bedingt empfehlenswert

o) AI4H-Leitfaden der WHO/ITU

Spezifisch für das Gesundheitswesen entwickeln WHO und ITU (International Telecommunication Union) ein Framework für den Einsatz von AI im Gesundheitswesen, insbesondere für Diagnose, Triage und Behandlungsunterstützung.

Diese AI4H–Initiative umfasst mehrere Topic Groups aus verschiedenen medizinischen Fakultäten sowie Working Groups, die sich Querschnittsthemen annehmen. Das Johner Institut ist aktives Mitglied der Working Group zu regulatorischen Anforderungen.

Diese Arbeitsgruppe entwickelt einen Leitfaden, der auf dem bisherigen Leitfaden des Johner Instituts aufsetzt und diesen möglicherweise ablösen wird. Eine Abstimmung dieser Ergebnisse mit dem IMDRF ist geplant.

Wenn Sie mehr über diese Initiative erfahren wollen, wenden Sie sich an das ITU oder das Johner Institut.

Fazit: Künftig sehr empfehlenswert

p) Leitfaden der Benannten Stellen

Die Benannten Stellen haben einen Leitfaden zur künstlichen Intelligenz entwickelt, der auf dem Leitfaden des Johner Instituts basiert. Da dieser von den Benannten Stellen herausgegeben und verwendet wird, ist er zumindest für deutsche Hersteller ein Must-Read.

Fazit: Sehr empfehlenswert

q) Key Terms and Definitions des IMDRF

Das International Medical Device Regulators Forum (IMDRF) hat am 16. September 2021 ein Dokument mit Schlüsselbegriffen und Definitionen für „Machine Learning-enabled Medical Devices – A subset of Artificial Intelligence-enabled Medical Devices“ vorgeschlagen. Die Konsultationsfrist endet am 29. November 2021.

Fazit: Könnte durch Vereinheitlichung der Begriffe hilfreich werden

r) BS/AMMI 34971:2023

Seit Mai 2023 ist die BS/AAMI 34971 verfügbar. Sie trägt den Titel „Application of ISO 14971 to machine learning in artificial intelligence“ und ist beispielsweise über Beuth für über 250 EUR zu beziehen.

Die Norm folgt streng dem Aufbau der ISO 14971 (s. Abb. 4). Spezifisch sind die Kapitel auf der dritten Ebene. Diese sind unterhalb des Kapitels 5.3 („Identification of characteristics related to safety“) zu finden.

Was gefällt

Die Norm richtig sich streng an der der ISO 14971 aus. Das erleichtert (theoretisch) die Zuordnung.

Die Beispiele, die die Norm nennt, sind sehr umfangreich. Sie können damit als wertvolle Checkliste dienen, um mögliche Ursachen für Gefährdungen zu erkennen und zu beseitigen.

Auch nennt die Norm hilfreiche Maßnahmen zur Risikobeherrschung und listet beispielsweise im Anhang konkrete Anforderungen an die Kompetenz des Personals.

Was wir uns anders gewünscht hätten

Für den Preis können die Autoren nichts. Dennoch hätten wir uns gewünscht, dass die BS/AAMI 34971 nicht teurer ist als die Norm, auf die sie sich bezieht.

Es wirkt, als würden die Autoren der BS/AAMI 34971 manche Konzepte anders verstehen als die Autoren der ISO 14971.

Beispielsweise umfasst das Kapitel „Identification of characteristics related to safety“ Dutzende Beispiele, die aber keine Sicherheitsmerkmale darstellen, sondern Ursachen für Gefährdungen (z. B. der Bias bei den Daten). Das ist sehr bedauerlich, weil

• damit zur Verwirrung beigetragen wird, was sich negativ auf die Effizienz und Effektivität von Audits und Reviews auswirken kann und die Abbildung in Algorithmen erschwert,
• dies genau den Fehler zu wiederholen scheint, den Hersteller von ML-basierten Produkten immer wieder begehen: Sie versäumen es, aus der Zweckbestimmung zunächst die wesentlichen Leistungsmerkmale bzw. sicherheitsbezogenen Merkmale abzuleiten und erst daraus die Anforderungen an die ML-Modelle.

An anderer Stelle wird behauptet, Tabelle B.2. der BS/AAMI 34971 würde der Tabelle C2 der ISO 14971 entsprechen. Erste ist überschrieben mit „Events and circumstances“ (?!?), die zweite mit „Hazards“. Weshalb führen die Autoren der BS/AAMI 34971 neue Begriffe und Konzepte ein, die sie nicht definieren, sondern scheinbar definierten Begriffen gleichsetzen?

Weiter ist bedauerlich, dass Erklärungen und Anforderungen nicht präzise getrennt sind. Es wirkt, als wären die Konzepte „Ground Truth“ und „Gold Sstandard“ nicht sauber unterschieden. Der Begriff „ML validation test“ erschließt sich nur aus dem Kontext. Für ML-Experten sind „validation“ und „test“ zwei unterschiedliche Aktivitäten.

Über risikominimierende Maßnahmen wie ein „denoising of data“ werden sich Statistiker sicher ihre eigene Meinung bilden.

Fazit: Wenn 250 EUR keine Hindernis sind, die Norm kaufen und als Checkliste und Inspirationsquelle nutzen.

s) ISO/NP TS 23918

Noch in der Entwicklung ist die ISO/NP TS 23918 „Medical devices — Guidance on the application of ISO 14971 — Part 2: Machine learning in artificial intelligence“. Ihr Anwendungsbereich scheint dem der AAMI/BS 34971 sehr zu gleichen. Auch hier geht es um die Anwendung der ISO 14971 im Kontext von KI-basierten Medizinprodukten.

t) BS 30440:203

Ebenfalls vom BSI stammt die Norm BS 30440:2023 mit dem Titel „Validation framework for the use of artificial intelligence (AI) within healthcare. Specification”.

Interessant ist, dass diese Norm nicht nur die Hersteller, sondern auch die Betreiber, Krankenversicherungen und Anwender als Leser sieht.

u) ISO/IEC 23894

Im Februar 2023 erschien die ISO/IEC 23894. Sie trägt den Titel „Artificial intelligence — Guidance on risk management“. Die Norm ist ohne die ISO 31000:2018 (das ist die Norm zum „allgemeinen Risikomanagement“, also nicht medizinproduktspezifisch) nicht nutzbar. Sie versteht sich eher als ein Delta, das die AI-spezifischen Aspekte ergänzt. Eine wirkliche Hilfestellung für Firmen, die in ihren Medizinprodukten AI anwenden, lässt sich nicht unmittelbar entdecken.

Fazit: Nicht kaufen

v) ISO/IEC 42001:2023

Die Norm ISO/IEC 42001:2023 trägt den Titel „Information technology — Artificial intelligence —
Management system“.

Damit wird der Scope klar: Es geht um die Anforderungen an ein Management-System. Zum Anwendungsbereich der Norm zählen sowohl die Anwendung von KI innerhalb einer Organisation als auch KI-basierte Produkte einer Organisation. Die Norm ist aber nicht spezifisch für Medizinprodukte(hersteller).

Insgesamt ist die Norm sehr „high-level“ und insbesondere für die Entwicklung KI-basierter Produkte zu unspezifisch. Das ist nicht überraschend, weil die Norm eine Prozess- und keine Produktnorm ist.

Viele der Forderungen erfüllen Organisationen bereits, die konform mit den Anforderungen der ISO 13485 und der ISO 14971 arbeiten.

In dem Maß, in dem KI Einzug in den Alltag der unternehmen hält, wird die Norm an Bedeutung gewinnen. Der Ansatz eines „AI system life cycles“ ist sicher der richtige.

w) IMDRF

Das auch die IMDRF einen Leitfaden zur Anwendung der KI bei Medizinproduktenveröffentlicht hat, überrascht kaum.

Bemerkenswerter ist, dass es auch hier einen engen Schulterschluss zwischen der FDA und Health Canada gibt. Nordamerika führt eine „De facto Standardisierung“ durch, und Europa schaut zu.

5. Fragen, auf die Sie im Audit vorbereitet sein sollten

a) Allgemeines

Noch haben sich die Benannten Stellen und die Behörden nicht auf ein einheitliches Vorgehen und auf gemeinsame Anforderungen bei Medizinprodukten mit maschinellem Lernen geeinigt.

Daher tun sich Hersteller regelmäßig schwer mit dem Nachweis, dass die an das Produkt gestellten Anforderungen z. B. bezüglich Genauigkeit, Korrektheit und Robustheit erfüllt sind.

Dr. Rich Caruana, einer der führenden Köpfe bei Microsoft im Bereich der künstlichen Intelligenz, riet sogar vom Einsatz eines von ihm selbst entwickelten neuronalen Netzwerks ab, das Patienten mit Lungenentzündung die passende Therapie vorschlagen sollte:

„I said no. I said we don’t understand what it does inside. I said I was afraid.”

Dr. Rich Caruana, Microsoft

Dass es Maschinen gibt, die ein Anwender nicht versteht, ist nicht neu. Man kann eine PCR anwenden, ohne sie zu verstehen; es gibt auf jeden Fall Menschen, die die Funktionsweise und das Innenleben dieses Produkts kennen. Bei der künstlichen Intelligenz ist das jedoch nicht mehr gegeben.

b) Leitfragen

Zu den Fragen, die Auditoren Herstellern von Produkten mit Machine Learning stellen sollten, zählen beispielsweise:

Leitfrage	Hintergrund
Weshalb glauben Sie, dass Ihr Produkt dem Stand der Technik entspricht?	Klassische Einstiegsfrage. Hier sollten Sie auf technische und medizinische Aspekte eingehen.
Wie kommen Sie zur Annahme, dass Ihre Trainingsdaten keinen Bias haben?	Andernfalls wären die Ergebnisse falsch bzw. nur unter bestimmten Voraussetzungen richtig.
Wie haben Sie ein Overfitting Ihres Modells vermieden?	Sonst würde der Algorithmus nur die Daten richtig vorhersagen, mit denen er trainiert wurde.
Was veranlasst Sie zur Annahme, dass die Ergebnisse nicht nur zufällig richtig sind?	Beispielsweise könnte es sein, dass ein Algorithmus korrekt entscheidet, dass auf einem Bild ein Haus zu erkennen sei. Der Algorithmus hat aber kein Haus, sondern den Himmel erkannt. Ein weiteres Beispiel zeigt die Abb. 5.
Welche Voraussetzungen müssen Daten erfüllen, damit Ihr System sie richtig klassifiziert bzw. die Ergebnisse richtig vorhersagt? Welche Randbedingungen sind einzuhalten?	Da das Model mit einer bestimmten Menge an Daten trainiert wurde, kann es nur für Daten, die aus der gleichen Grundgesamtheit stammen, korrekte Vorhersagen treffen.
Wären Sie mit einem anderen Modell oder mit anderen Hyperparametern nicht zu einem besseren Ergebnis gekommen?	Hersteller müssen Risiken weitestgehend minimieren. Dazu zählen auch Risiken durch falsche Vorhersagen suboptimaler Modelle.
Weshalb gehen Sie davon aus, dass Sie ausreichend viele Trainingsdaten verwendet haben?	Das Sammeln, Aufbereiten und „Labeln“ von Trainingsdaten ist aufwendig. Je größer die Datenmenge ist, mit der ein Modell trainiert wird, desto leistungsfähiger kann es sein.
Welchen Standard haben Sie beim Labeling der Trainingsdaten verwendet? Weshalb betrachten Sie den gewählten Standard als Gold-Standard?	Besonders wenn die Maschine beginnt, den Menschen überlegen zu sein, wird es schwierig, festzulegen, ob ein Arzt, eine Gruppe von „normalen“ Ärzten oder die weltweit besten Experten einer Fachrichtung die Referenz sind.
Wie können Sie die Reproduzierbarkeit gewährleisten, wenn Ihr System weiter lernt?	Besonders bei Continuously Learning Systems (CLS) muss gewährleistet bleiben, dass durch das weitere Training die Leistungsfähigkeit zumindest nicht abnimmt.
Haben Sie Systeme validiert, die Sie zum Sammeln, Vorbereiten und Analysieren der Daten sowie zum Trainieren und Validieren Ihrer Modelle verwenden?	Ein wesentlicher Teil der Arbeit besteht darin, die Trainingsdaten zu sammeln und aufzubereiten sowie das Modell damit zu trainieren. Die dazu notwendige Software ist nicht Teil des Medizinprodukts. Sie unterliegt aber den Anforderungen an die Computerized Systems Validation.

Die o. g. Fragen sind typischerweise auch im Rahmen des Risikomanagements nach ISO 14971 und der klinischen Bewertung gemäß MEDDEV 2.7.1 Revision 4 (bzw. Leistungsbewertung von IVD) zu erörtern.

6. Typische Fehler von KI-Startups

Viele Startups, die Verfahren der künstlichen Intelligenz (KI) insbesondere Machine Learning nutzen, beginnen die Produktentwicklung mit den Daten. Dabei unterlaufen ihnen häufig die gleichen Fehler:

Fehler	Folgen
Die Software und die Prozesse zum Sammeln und Aufbereiten der Trainingsdaten sind nicht validiert. Regulatorische Anforderungen sind bestenfalls in Ansätzen bekannt.	Im schlimmsten Fall können die Daten und Modelle nicht genutzt werden. Das wirft die ganze Entwicklung wieder auf den Anfang zurück.
Die erklärte Performance der Produkte leiten die Hersteller nicht aus der Zweckbestimmung und dem Stand der Technik ab, sondern aus der Leistungsfähigkeit der Modelle.	Die Produkte scheitern in der klinischen Bewertung.
Menschen, deren wirkliche Leidenschaft die Data Science oder die Medizin ist, versuchen sich als Unternehmensentwickler.	Die Produkte schaffen es nie auf den Markt oder treffen den tatsächlichen Bedarf nicht.
Das Geschäftsmodell bleibt zu lange zu vage.	Die Investoren halten sich zurück oder/und das Unternehmen trocknet finanziell aus und scheitert.

Startups können sich bei uns melden. In wenigen Stunden können wir helfen, diese fatalen Fehler zu vermeiden.

7. Fazit und Zusammenfassung

a) Regulatorische Anforderungen

Die regulatorischen Anforderungen sind eindeutig. Doch Herstellern und teilweise auch Behörden und Benannten Stellen bleibt unklar, wie diese für Medizinprodukte, die Verfahren des Machine Learnings nutzen, zu interpretieren und konkret umzusetzen sind.

b) Zu viele und nur bedingt hilfreiche „Best Practice Guides“

Daher fühlen sich viele Institutionen berufen, mit „Best Practices“ zu helfen. Leider sind viele diese Dokumente nur bedingt hilfreich:

• Sie wiederholen Lehrbuchwissen über die künstliche Intelligenz im Allgemeinen und das Machine Learning im Speziellen.
• Die Guidance Dokumente ergehen sich in Selbstverständlichkeiten und Banalitäten.
  Wer nicht bereits vor dem Lesen dieser Dokumente wusste, dass das Machine Learning zu Fehlklassifizierungen und Bias führen und damit Patienten gefährden oder benachteiligen kann, sollte keine Medizinprodukte entwickeln.
• Viele dieser Dokumente beschränken sich darauf, die für das Machine Learning spezifischen Probleme aufzulisten, die die Hersteller adressieren müssen. Es fehlen Best Practices, wie man diese Probleme minimiert.
• Wenn es Empfehlungen gibt, sind diese meist wenig konkret. Sie bieten keine ausreichende Handlungsleitung.
• Es dürfte den Herstellern und Behörden schwerfallen, aus Textwüsten wirklich prüfbare Anforderungen zu extrahieren.

Leider scheint keine Besserung in Sicht zu sein, im Gegenteil: Es werden immer mehr Richtlinien entwickelt. Beispielsweise empfiehlt die OECD die Entwicklung von AI/ML-spezifischen Standards und erarbeitet derzeit selbst einen. Gleiches gilt für die IEEE und das DIN und viele weitere Organisationen.

Fazit:

• Es gibt zu viele Normen, um den Überblick behalten zu können. Und es werden kontinuierlich mehr.
• Die Normen überlappen stark und sind überwiegend von eingeschränktem Nutzen. Sie enthalten keine (binär entscheidbaren) Prüfkriterien.
• Sie kommen (zu) spät.

c) Qualität statt Quantität

Hersteller von Medizinprodukten benötigen bei den Best Practices und Normen zum Machine Learning mehr Qualität und nicht mehr Quantität.

Best Practices und Normen sollten handlungsleitend sein und überprüfbare Anforderungen stellen. Dass die WHO den Leitfaden des Johner Instituts aufgreift, gibt Anlass zu vorsichtigem Optimismus.

Es wäre wünschenswert, wenn sich die Benannten Stellen, die Behörden und ggf. auch die MDCG aktiver in die (Weiter-)Entwicklung dieser Standards einbringen würden. Dies sollte in transparenter Weise geschehen. Zu welch bescheidenen Ergebnissen das Arbeiten in Hinterzimmern ohne (externe) Qualitätssicherung führt, haben wir in letzter Zeit mehrfach erfahren.

Mit einem gemeinsamen Vorgehen gelänge es, ein gemeinsames Verständnis davon zu erreichen, wie Medizinprodukte, die maschinelles Lernen verwenden, entwickelt und geprüft werden müssten. Es gäbe nur Gewinner.

---

Benannte Stellen und Behörden sind herzlich eingeladen, an der Weiterentwicklung der Leitfäden mitzuwirken. Eine E-Mail an das Johner Institut genügt.

Hersteller, die Unterstützung bei der Entwicklung und Zulassung ML-basierter Produkte (z. B. bei der Überprüfung der technischen Dokumentation oder bei der Validierung von ML-Bibliotheken) wünschen, können sich gerne via E-Mail oder über das Kontaktformular melden.

---

Änderungshistorie

• 2024-07-08: Im Abschnitt 2.c) die neue Leitlinie der FDA ergänzt, im Abschnitt 4.w) die Leitlinie des IMDRF
• 2024-03-26: Link zum verabschiedeten AI Act eingefügt.
• 2024-01-26: Hinweis zum Kompromissvorschlag zum AI Act ergänzt
• 2024-01-18: Kapitel 4.v) zur ISO 42001 eingefügt
• 2023-11-20: Neues Kapitel 4.s) mit ISO/NP TS 23918 eingefügt
• 2023-11-03: Kapitelstruktur überarbeitet. Anforderungen der FDA ergänzt. Neue BS-Normen erwähnt.
• 2023-10-09: Kapitel 2.n) eingefügt, das die ISO 23053 bewertet.
• 2023-09-07: Kapitel 2.s) einfügt, das die AAMI 34971:2023-05-30 bewertet.
• 2023-07-03: Link auf BS/AAMI 34971:2023-05-30 eingefügt
• 2023-06-27: Abschnitt 1.b) i) ergänzt: AI act gilt für MP/IVD höherer Risikoklassen.
• 2023-06-23: FDA Guidance Document vom April 2023 ergänzt
• 2023-06-08: Kapitel 4 eingefügt
• 2023-02-14: Abschnitt 2.r) eingefügt
• 2022-11-17: Link zum neuen Entwurf des AI Acts ergänzt
• 2022-10-21: Link zu Updates der EU zum AI Act ergänzt
• 2022-06-27: Im Kapitel zur FDA deren Guidance-Dokument für die radiologische Bildgebung und die dort genannten Fehlerquellen eingefügt
• 2021-11-01: Kapitel mit FDAs Guiding Principles eingefügt
• 2021-09-10: Link mit der Stellungnahme für die EU ergänzt
• 2021-07-31: Im Abschnitt 1.b.ii) in der Tabelle zwei Zeilen mit weiteren Kritikpunkten angehängt. In der Zeile mit den Definitionen je einen Abschnitt ergänzt.
• 2021-07-26: Abschnitt 2.n) in Abschnitt 1.b) verschoben. Dort Kritik und Handlungsaufruf ergänzt.
• 2021-04-27: Abschnitt zu Plänen der EU zu neuer KI-Regulierung ergänzt