Hersteller von Medizinprodukten mit maschinellem Lernen (Machine Learning) stehen vor der Schwierigkeit, die Konformität ihrer Produkte nachweisen zu müssen.

Das ist für viele Hersteller herausfordernd. Sie kennen zwar die Gesetze; doch 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 nimmt Ihnen stundenlanges Recherchieren ab. Er verschafft Ihnen eine Übersicht über die wichtigsten Regularien und Best Practices, die Sie kennen sollten. Das erspart es Ihnen, Hunderte Seiten zu lesen.

Wenn Sie diese Regularien berücksichtigen, können Sie sich perfekt auf das nächste Audit vorbereiten.

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

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 der MDR und IVDR erfüllen, z.B.:

  • Die 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 im Anhang I, 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 (u.a. MDR Anhang I, 17.1 bzw. IVDR Anhang I, 16.1).
  • Die Hersteller müssen eine präzise Zweckbestimmung formulieren (MDR/IVDR Anhang II) und die Produkte gegen die Zweckbestimmung und Stakeholder-Anforderungen validieren und gegen die Spezifikationen verifizieren (u.a. MDR Anhang I, 17.2 bzw. IVDR Anhang I, 16.2). Sie sind auch verpflichtet, die Methoden zu beschreiben, 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) (Harmonisierte) Normen ohne spezifischen Bezug zum Machine Learning

MDR und IVDR erlauben es, mit Hilfe 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).
  • Die 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).
Weiterführende Informationen

Bitte beachten Sie den Artikel zur Validierung von ML-Bibliotheken.

c) USA: FDA

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

Zur Pflichtlektüre zählt auch der FDA-Entwurf „Proposed Regulatory Framework for Modifications to Artificial Intelligence/Machine Learning (AI/ML)-Based Software as a Medical Device (SaMD)“.

Weiterführende Informationen

Eine ausführlichere Beschreibung dieses Frameworks finden Sie im Artikel zur „Künstlichen Intelligenz in der Medizin“.

d) 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 Ihnen zumindest die Inhaltsangabe automatisiert übersetzen lassen.

Das Dokument adressiert:

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

Die Behörde rüstet auch 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.

e) Japan

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

2. 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 klar macht, 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.

Weiterführende Informationen

Die Videotrainings im Auditgarant stellen wichtige Verfahren wie LRP LIME, die Visualisierung der Aktivierung von neuronalen Schichten oder Counterfactuals vor.

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. Ergebnisse werden für das Ende des Jahres 2020 erwartet.

Fazit: wenig hilfreich

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“.

Es stellt ein Meta-Model vor, nennet aber keine konkreten Anforderungen an die Entwicklung von AI/ML-Systemen. Das Dokument ist völlig unspezifisch für eine Branche.

Fazit: wenig hilfreich

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

Der Teil 2: Robustsheit 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 CD TR 29119-11 „Software and systems engineering – Software testing – Part 11: Testing of AI-based systems“ befindet sich noch in der Entwicklung.

Fazit: noch zu früh, weiter beobachten

i) Curriculum des koreanischen „Software Testing Qualification Board“

Das koreanische „Software Testing Qualification Board“ stellt ein Curriculum zum Testen von KI-Systemen mit dem Titel „Certified Tester AI Testing Testing AI-Based Systems (AIT – TAI) Foundation Level Syllabus“ zum Download bereit.

Ab Kapitel 3.8 gibt das Curriculum Hinweise zur Qualitätssicherung von AI-Systemen, die sich weitgehend auch im Leitfaden des Johner Instituts finden.

Darüber hinaus enthält das Dokument im Kapitel 6 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:

Die Normen liefern – wir 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 23053 – Framework for AI using ML
  • ISO 23894 – Risk Management (ISO 31000, not 14971)
  • 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. 1).

Die Kapitelstruktur der ISO/IEC TR 24048 als Mindmap
Abb. 1: Die Kapitelstruktur der ISO/IEC TR 24048 als Mindmap (zum Vergrößern klicken)

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

m) Leitfaden der Benannten Stellen

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

Fazit: sehr empfehlenswert

3. Fragen, auf die Sie sich im Audit vorbereiten sollten

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.

Zu den Fragen, die Auditoren Herstellern 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. 3.
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. Mit umJe 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, aufzubereiten und damit das Modell zu trainieren. Die dazu notwendige Software ist nicht Teil des Medizinprodukts. Sie unterliegt aber den Anforderungen an die Computerized Systems Validation.

Tabelle 1: Potenzielle Fragen bei der Überprüfung von Medizinprodukten mit zugehöriger Erklärung

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.

Input-Daten, die nur zufällig wie ein bestimmtes Muster aussehen. Hier am Beispiel eines Chihuahuas und eines Muffins (zum Vergrößern klicken)
Abb. 2: Input-Daten, die nur zufällig wie ein bestimmtes Muster aussehen. Hier am Beispiel von Chihuahuas und Muffins (Quelle) (zum Vergrößern klicken)
Weiterführende Informationen

Hinweise, wie Hersteller diese regulatorischen Anforderungen an Medizinprodukte mit Machine Learning erfüllen können, gibt der Artikel „Künstliche Intelligenz in der Medizin“.

4. Fazit und Zusammenfassung

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.

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 Guidelines 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 sind stark überlappend und meist von eingeschränktem Nutzen. Sie enthalten keine (binär entscheidbaren) Prüfkriterien.
  • Sie kommen (zu) spät.

Qualität statt Quantität

Medizinproduktehersteller 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.

Mit Dank an Pat Baird für hilfreichen Input

Wie hilfreich war dieser Beitrag?

Bitte bewerten Sie:

Durchschnittliche Bewertung 5 / 5. Anzahl Bewertungen: 2

Geben Sie die erste Bewertung!


Kategorien: Regulatory Affairs, Software & IEC 62304

Hinterlassen Sie einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.