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“ (SaMD) vor.
Eine finden hier die Liste aller IMDRF-Dokumente.
1. 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.
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:
- Anforderungen an die Organisation, z.B. die Verantwortlichkeit, qualifiziertes Personal bereitzustellen
- Anforderung, Prozesse zu etablieren wie einen Entwicklungsprozess, Risikomanagementprozess oder Verbesserungsprozess
- 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.
- 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 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.
- 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 die IMDRF-Autoren speziell für Software durchführen, gerade die softwarespezifischen Normen ignoriert.
- 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.
2. 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, die es zu ziehen gilt, 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.
3. IMDRF-Leitfaden zur Klassifizierung und zu den Definitionen von „Software as a Medical Device“
Der Leitfaden des IMDRF reiht sich eine längere Liste von 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.
4. IMDRF Codes
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:
Ausschnitt aus der Taxonomie des IMDRF zu den „Adverse Events“ (zum Vergrößern klicken)Das IMDRF hat diese Codes publiziert, die beispielsweise für „Incident Reports“ gemäß MDR bzw. MEDDEV 2.12-1 genutzt werden müssen.
Screenshot eines Medical Device Incident Reports, der für die Beschreibung des Problems u.a. Codes des IMDRF verlangtDiese Codes 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
- ANNEX G: Medical Device Parts and Component 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.
Vorsicht!
Beachten Sie, dass die IMDRF sowohl 2019 als auch 2020 Codes veröffentlich hat.
Die FDA nutzt für das „Medical Device Report“ (ebenfalls mit MDR abgekürzt) ebenfalls diese Codes.
5. Weitere IMDRF-Dokumente
a) Cybersecurity
Die Leitlinie Principles and Practices for Medical Device Cybersecurity beschreibt auf 46 Seiten ziemlich genau das, was man auch findet in:
Weshalb es dieses weiteren Dokuments bedarf, erschließt sich auch nach mehrmaligem Lesen nicht.
b) Personalized Medical Devices
Die Leitlinie Personalized Medical Devices – Regulatory Pathways hat nicht primär etwas mit personalisierter Medizin zu tun. Vielmehr beschreibt sie, wann Produkte als Sonderanfertigungen gezählt werden dürfen und welche Anforderungen Hersteller in diesem Fall einhalten müssen.
Die Qualitätssicherung beim IMDRF hat hingegen nicht gegriffen: Nicht einmal die Seitenorientierung der Bilder stimmt:
Screenshot des IMDRF Dokuments: Wenn HerstellerDas IMDRF überlässt es den Lesern, die Anforderungen mit denen z.B. der MDR abzugleichen. Das ist besonders deshalb herausfordernd, weil das IMDRF mit „Pathways“ argumentiert, die die MDR so nicht kennt.
„Seek advice from your jurisdiction“ ist ebenso wenig hilfreich. Genau deswegen liest man doch das Dokument.
6. Sonstiges
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 beigetragen.
