Tour-Report (Teil 1): Audits bei medizinischer Software
Mit Dr. Wagner vom TÜV Süd habe ich mich über die Zulassung von Software als Medizinprodukt unterhalten. Mich haben zwei Dinge besonders interessiert:
- Wie unterscheidet sich die Zulassung von Software als Medizinprodukt (genau genommen muss man vom Konformitätsbewertungsverfahren sprechen) von der Zulassung anderer Medizinprodukte?
- Was sind die typischen Fehler, welche dem Auditor bei Softwareentwicklungsabteilungen auffallen?
Dr. Wagners Antworten sind kurz und präzise – so wie man das von einem Auditor eben erwartet:
Besonderheiten bei der Zulassung medizinischer Software
Hier gibt es zuerst keine besonderen Forderungen. Wie bei allen Produkten muss der Hersteller die grundlegenden Anforderungen, die in der Medizinprodukterichtlinie 93/42/EC genannt sind, erfüllen. Diesen Nachweis kann der Hersteller besonders einfach erbringen, wenn er die Einhaltung von Normen, besonders von harmonisierten Normen nachweist. Bei Software, die gemeinsam mit Hardware zugelassen wird, zählen zu diesen Normen sicher die Mitglieder der Normenfamilie IEC 60601-1. Besonders zu nennen sind die IEC 60601-1-4 und die IEC 60601-1-6 (Gebrauchstauglichkeit). Demnächste wird eine weitere Norm harmonisiert, die IEC 62304, die den Lebenszyklus von medizinischer Software beschreibt.
Auch beim Konformitätsbewertungsverfahren gibt es ein paar Unterschiede, weil einige Verfahren nicht besonders für Software anwendbar sind. Beispielsweise könnten Medizinprodukte der Klasse I mit Messfunktion nach Anhang VII für die Entwicklung und für die Produktion nach einem der Anhänge IV, V oder VI zugelassen werden. Somit würde die benannte Stelle die Produktion überwachen. Die Produktion beschränkt sich aber auf die Vervielfältigung von CDs, und das stellt nun wirklich nicht das Hauptproblem dar. Auch eine Baumusterprüfung (Anhang III) eignet sich eher für Prüfung der mechanischen oder elektrischen Sicherheit von Medizingeräten und weniger der Überprüfung von Millionen Code-Zeilen. Insofern muss der Entwicklungsprozess und nicht nur das Endprodukt geprüft werden.
Das Konformitätsbewertungsverfahren insgesamt – und das sein nochmals betont – unterscheidet sich nicht.
Typische Fehler
Ich muss gestehen, hier war ich schon neugierig, was ein so erfahrener Auditor typischerweise als Problem findet. So berichtet mit Dr. Wagner:
Speziell bei kleineren Firmen fehlen Ressourcen für Dokumentation.
- Dies wirkt sich dahingehend aus, dass die Spezifikation sowie die Verifikation und Validierung nicht ausreichend dokumentiert sind. Bei letzteren wird nicht dargelegt, was die Inputs, was die Outputs, was die Erwartungswerte und was die Akzeptanzkriterien sind.
- Ebenfalls unzureichend dokumentiert sind in der Software verbliebene Anomalien und die Kriterien für deren Akzeptanz.
- Weiterhin fällt auf, dass mangelndes Konfigurationsmanagement zu nicht konsistenter Dokumentation, speziell des Technical Files, führt. So kann nicht mehr reproduziert werden, welche Version der Unterlagen zum Zeitpunkt der Einreichung und zum jetzigen Zeitpunkt aktuell waren bzw. sind.
- An das oben Gesagte: Bei den Prüfaufzeichnungen fehlen oft Informationen darüber “wer hat geprüft”, “was wurde geprüft”.
- Und schließlich fällt auf, dass nur unzureichend rückverfolgbar ist, ob und wie die Anforderungen und die Risikokontrollmaßnahmen bei der Umsetzung und der Verifikation bzw. Validierung berücksichtigt wurden.
Man kann, so Dr. Wagner, aber keineswegs behaupten, dass kleine Firmen schlechter seien. Die großen Firmen haben aufgrund der zahlreichen internen und externen Schnittstellen, z.B. zu externen Dienstleistern, einen besonderen Dokumentationsaufwand und -bedarf.
Soweit der erste Teil meines Reiseberichts. Demnächst berichte ich über das Thema “Wann wird Software zum Medizinprodukt?”
Bis dann,
liebe Grüße
Euer Christian
Tags: Audit, medizinische Software