IMDRF: Neues vom International Medical Device Regulators Forum

Donnerstag 18. Januar 2018

Das IMDRF (International Medical Device Regulators Forum) möchte zur Harmonisierung der international unterschiedlichen Vorschriften beitragen und dadurch die Zulassung von Medizinprodukten vereinheitlichen und vereinfachen. Dazu veröffentlichen die Freiwilligen des IMDRF Leitfäden, die zwar nicht verbindlich sind, aber Hilfestellungen geben. In diesem Artikel stelle ich Ihnen v.a. die Leitfäden mit Bezug zur Software „as a Medical Device“ vor.

 IMDRF Leitfaden zur Anwendung von QM-Sytemen bei standalone Software

In seinem neusten IMDRF Leitfaden „Software as a Medical Device (SaMD): Application of Quality Management System“ möchten die Autoren Medizinprodukteherstellern, die standalone Software entwicklen, Hinweise geben, wie sie den Forderungen insbesondere der ISO 13485 gerecht werden. Ich habe für Sie das Dokument gelesen und fasse das Wichtigste zusammen.

 

IMDRF zur Anwendung der ISO 13485 bei standalone Software

Das IMDRF gibt Hinweise, wie Hersteller von standalone Software (Medizinprodukt) die ISO 13485 einhalten können. (Zum Vergrößern klicken)

Die Autoren des IMDRF gliedern die Anforderungen in drei Bereiche:

  1. Anforderungen an die Organisation wie z.B. die Verantwortlichkeit, qualifiziertes Personal bereitzustellen
  2. Anforderung, Prozesse zu etablieren wie einen Entwicklungsprozess, Risikomanagementprozess oder Verbesserungsprozess
  3. Anforderungen an einzelne Aktivitäten (und damit Methoden) wie das Requirements Engineering oder die Software-Architektur

Das IMDRF Dokument verdient sicher das Prädikat „nützlich“. Gleichzeitig führt dieser IMDRF-Leitfaden in die Irre.

  1. Abdeckung der ISO 13485: Medizinproduktehersteller könnten vermuten, dass sie die Anforderungen der ISO 13485 einhalten, wenn sie konform mit diesem Leitfaden des IMDRF arbeiten. Dieser Leitfaden ist aber gerade nicht vollständig und erhebt auch nicht den Anspruch darauf. Viele Aspekte der Norm berücksichtigt er nicht, wie beispielsweise das für Software-Entwickler entscheidende Thema der Messwerkzeuge/Messmittel.
  2. Abdeckung anderer Normen: Der IMDRF Leitfaden hat nur die ISO 13485 im Blick. Würde man sich „nur“ an dessen Vorgaben halten, wären die Anforderungen insbesondere der IEC 62304 und IEC 62366 nicht erfüllt. Es stellt sich schon die Frage, weshalb das Mapping der ISO-13485-Anforderungen, das ja die IMDRF-Autoren speziell für Software durchführen, gerade die softwarespezifischen Normen ignoriert.
  3. Konzeptionelle Integrität und Korrektheit: Die Unvollständigkeit des Dokuments ist kein Zufall, sondern wahrscheinlich der Tatsache geschuldet, dass die Autoren „nur“ Erfahrungen zusammengetragen haben. Ein Modell (abgesehen von dem der drei Bereiche) ist nicht erkennbar. Das IMDRF-Dokument lässt kein wirkliches Verständnis eines modernen Usability und Requirements Engineerings erkennen. Verschiedene Anforderungsklassen sind nicht getrennt, Aktivitäten wie das UI-Design den falschen Phasen bzw. Rollen zugedacht.

Fazit: Der IMDRF-Leitfaden „Software as a Medical Device (SaMD): Application of Quality Management System“ enthält viele hilfreiche Gedanken. Dem Anspruch, damit eine normenkonforme Software-Entwicklung anzuleiten, wird er aber nur bedingt gerecht.

IMDRF Leitfaden zu Risiken von „Software as a Medical Device“

Ein weiterer Leitfaden des IMDRF versucht sich an einem Klassifizierungsschema für Risiken durch „Software as a Medical Device“. „Possible Framework for Risk Categorization and Corresponding Considerations“ nennen die Autoren ihr Werk.

IMDRF-Klassifizierung-Risiken-Software-Medical-Device

 

Die Gedanken finde ich prinzipiell gut. Nicht ganz klar sind mir aber die Konsequenzen, wenn man die Risiken klassifiziert hat. Für mich gibt es nämlich nur zwei Kategorien von Risiken: Inakzeptable Risiken, und Risiken, die man akzeptiert, nachdem man alle möglichen Maßnahmen zur Reduzierung des Risikos angewendet hat.

IMDRF Leitfaden zur Klassifizierung und zu den Definitionen von „Software as a Medical Device“

Der Leitfaden des IMDRF reiht sich eine längere Liste an Dokumenten ein, die die Frage zu beantworten versuchen, welche Formen von Software es im Kontext von Medizinprodukten gibt und wann eine (standalone) Software als Medizinprodukt zu klassifizieren ist. Daher diskutiere ich diesen IMDRF Leitfaden im Kontext der anderen Dokumente. Lesen Sie hier dazu mehr.

IMDRF und das MDSAP

Das International Medical Device Regulators Forum hat wesentlich zur Entwicklung des Medical Device Single Audit Programs MDSAP mitgewirkt

Weiterführende Informationen

Lesen Sie hier mehr zum Thema Medical Device Single Audit Program

Begriffsdefinitionen bei „Adverse Events“

Der IMDRF hat sich die Arbeit gemacht, die Begrifflichkeiten im Kontext von Zwischenfällen zu definieren und in ein kontrolliertes Vokabular zu überführen, dem sogar Codes zugeordnet werden. Konkret geht es um Begriffe in diesen Domänen:

  • Zwischenfälle
  • Ursachen dafür
  • Resultierende Patientenprobleme
  • Involvierte Komponenten

Die Begriffe sind hierarchisch gruppiert, stellen also eine Taxonomie dar:

IMDRF Terminology

Ausschnitt aus der Taxonomie des IMDRF zu den „Adverse Events“ (zum Vergrößern klicken)


Kategorien: QM-Systeme & ISO 13485, Regulatory Affairs, Software & IEC 62304
Tags:

Ein Kommentar über “IMDRF: Neues vom International Medical Device Regulators Forum”

  1. Peter Knipp schrieb:

    Guten Morgen,
    ich stimme zu, der Leitfaden klingt zunächst spannend, denn er scheint „risk-based“ an eine categorization der Software gehen zu wollen. Er bleibt aber an mehreren Stellen hinter den Erwartungen zurück.

    – Es werden keine klaren Konsequenzen genannt, für keine der angesprochenen Gruppen. Es werden aber sowohl Hersteller als auch Betreiber angesprochen. Einerseits ist das klar, denn das Dokument soll (darf) keine neuen Requirements ausgeben. Was man aber mindestens sagen kann: Die Inhalte aus Kapitel 9 sollten ein Input in das Risikomanagement der Hersteller werden.
    – Referenzen zu ISO 14971 und IEC TR 80002-1 fehlen. Schade, so kann und darf man doch nicht an Risiken mit Software-Medizinprodukten herangehen, dass die konkretesten Normen außer Acht gelassen werden.
    – Die ISO 27001 ist zumindest referenziert, die deutlich besser passende 27799 fehlt.
    – Die FDA-Guidances für Software sind nicht zitiert.
    – Es werden vier Risikoklassen angegeben, die natürlich nicht mit denen nach IEC 62304 oder FDA (level of concern) übereinstimmen können. Schade, sie werden auch nicht in klare Beziehung zueinander gestellt.

    Wir machen uns jetzt einmal den „Spaß“ und zitieren bei den nächsten Zulassungen in DE und USA dieses Papier, wenn wir über die Safety Class (oder LoC) sprechen und argumentieren. Mal sehen, was an Kommentaren zurückkommt. Wenn es öffentlichkeitstauglich ist, berichte ich einmal.

    Beste Grüße
    Peter Knipp

Kommentar schreiben