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.
| Inhaltsübersicht |
|---|
| 1. QM-Systeme bei SaMD » |
| 2. Risiken von SaMD » |
| 3. Klassifizierung von SaMD » |
| 4. IMDRF-Codes » |
| 5. Weitere IMDRF-Dokumente » |
| 6. Sonstiges » |
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.
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:
Das IMDRF hat diese Codes publiziert, die beispielsweise für „Incident Reports“ gemäß MDR bzw. MEDDEV 2.12-1 genutzt werden müssen.
Diese 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.
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:
- FDA Guidances zur Cybersecurity
- AAMI TIR57
- UL 2900
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:
Das 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.
Lesen Sie hier mehr zum Thema Medical Device Single Audit Program.
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