IMDRF: Neues vom International Medical Device Regulators Forum

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. Dieser Artikel stellt 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.

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.

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 Codes

Das IMDRF hat eine Liste an Codes publiziert, die beispielsweise für „Incident Reports“ gemäß MDR bzw. MEDDEV 2.12-1 genutzt werden müssen.

Diese Code hat das IMDRF auf seiner Webseite publiziert:

• ANNEX A: MEDICAL DEVICE PROBLEM TERMS AND CODES
• ANNEX B: CAUSE INVESTIGATION – TYPE OF INVESTIGATION TERMS AND CODES
• ANNEX C: CAUSE INVESTIGATION – INVESTIGATION FINDINGS TERMS AND CODES
• ANNEX D: CAUSE INVESTIGATION – INVESTIGATION CONCLUSION TERMS AND CODES
• ANNEX E: HEALTH EFFECT – CLINICAL SIGNS, SYMPTOMS AND CONDITIONS TERMS AND CODES
• ANNEX F: HEALTH EFFECT – HEALTH IMPACT TERMS AND CODES

Sie finden die Codes auf der o.g. Seite, wenn Sie nach „IMDRF/AE WG(PDl)/N43 (Edition 3) FINAL:2019“ suchen.

Die FDA nutzt für das „Medical Device Report“ (ebenfalls mit MDR abgekürzt) ebenfalls diese Codes.

Arbeitsgruppe zur klinischen Bewertung

Bis Juni 2019 bot das IMDRF an, in einer Arbeitsgruppe zur klinischen Bewertung mitzuwirken und Feedback zu einem neuen Dokument zu geben. Die Dokumente finden Sie hier.

IMDRF und das MDSAP

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

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: