Software-Audit: Auf was es wirklich ankommt

„Findet ein Software-Audit statt?“ lautet eine Frage, die mich über unser Micro-Consulting erreicht. „Und kann ich durch eine geeignete Wahl der Software-Sicherheitsklasse so ein Software-Audit vermeiden?“

Erst ist mir weder klar, was genau mit „Software-Audit“ gemeint, noch was die genaue Befürchtung ist. Doch dann verstehe ich und finde die Frage sehr bedeutsam für alle Medizinprodukte-Hersteller.

Software-Audit: Was das sein könnte

Der Begriff Software-Audit ist nicht eindeutig definiert. Meist verbindet man damit eine der folgenden Aktivitäten:

1. Im Rahmen eines QM-Audits (z.B. ISO 13485 oder FDA 21 CFR part 820) prüft ein Auditor bzw. Inspektor auch den Code entweder des Medizinprodukts oder von Prozess-Software bzw. Software für das QM-System. Für die Validierung letzterer Software gibt die ISO 80002-2 Handlungsleitung.
2. Im Rahmen einer CB-Prüfung (z.B. einer „IEC 62304-Zertifizierungen“) inspiziert ein Experte die Software und zugehörige Entwicklungsdokumentation wie Software-Anforderungen, Software-Architektur und Software-Tests.
3. Der Hersteller prüft selbst seine Software beispielsweise im Rahmen von Code-Reviews oder Design-Reviews.

Im konkreten Fall bezog sich die Anfrage auf das erste, also auf Code-Inspektionen im Audit.

Software im QM-Audit

Befürchtungen der Hersteller

Im konkreten Fall hatte der Hersteller zwei Befürchtungen:

1. Der Auditor sieht unseren Code und erfährt dadurch Firmengeheimnisse.
2. Der Auditor findet Fehler in unserem Code.

Beide Befürchtungen möchte ich ein wenig relativieren.

Weshalb diese Befürchtungen meist unbegründet sind

• Geheimhaltungserklärung
  Zum einen hat Ihr Auditor eine Geheimhaltungserklärung mit Ihnen. Falls diese fehlt, wissen Sie, was Sie zu tun haben. Davon abgesehen halte ich es auch für schwer möglich, dass ein Auditor durch das Lesen einiger Code-Ausschnitte Wesentliches erfährt.
• Kompetenz der Auditoren
  Zum anderen halte ich es für unwahrscheinlich, dass der Auditor Fehler in Ihrem Code findet. Die meisten Auditoren sind keine Informatiker, werden also den Code nur bedingt verstehen.
• Ziel der Audits
  Die Prüfungen beziehen sich weniger auf die Korrektheit des Produkts bzw. des Codes, sondern auf die Korrektheit des Prozesses. Die IEC 62304 ist eine Prozessnorm: Sie stellt Anforderungen an den Prozess, nicht an die Güte des Codes. Mehr zu den regulatorischen Anforderungen finden Sie weiter unten.
• Zur Verfügung stehende Zeit
  Man kann mit einem vertretbaren Aufwand Fehler in einer Software kaum finden. Deshalb konzentriert man sich nicht auf die analytische Qualitätssicherung, sondern (auch) auf die konstruktive. Genau das haben die benannten Stellen in einem MEDDEV auch so formuliert. Aus diesem Grund möchte man auch keine Baumusterprüfungen für Software haben, und genau deshalb fordert die IEC 62304 auch ein QM-System sowie einen Entwicklungsplan, der die Prozesse, Methoden und Werkzeuge benennt. Ob Sie sich an diese Prozesse und Methoden gehalten und die Werkzeuge wie geplant eingesetzt haben, das ist Gegenstand des Audits.

Was mit Bezug zur Software wirklich auditiert wird

Wenn wir Auditoren also den Code ansehen, dann wollen wir prüfen,

• ob Sie Ihre eigenen Forderungen einhalten, die Sie beispielsweise in Codier-Richtlinien formuliert haben.
• Oder wir prüfen exemplarisch, ob bei einer Klasse C die Artefakte wie z.B. das detaillierte Design oder die Unit-Tests vorliegen, die für diese Klasse gefordert sind.
• Zum Klassiker der Prüfungen zählt die Traceability: Sind beispielsweise alle Software-Anforderungen verifiziert?
• Lassen die Datumsstempel von Code (Check-In) und Dokumenten (Anforderungen, Architektur) den Schluss zu, dass der Prozess eingehalten wird – auch in der richtigen Reihenfolge?
• Sehr schnell kann man Firmen aufs Kreuz legen, in dem man bittet, einen alten Test zu reproduzieren. Das bedingt nämlich, dass das Konfigurationsmanagement wirklich funktioniert.
• Es könnte auch sein, dass man sich einen Code zeigen lassen will, um zu prüfen, ob eine risikominimierende Maßnahme tatsächlich implementiert wurde und ob der Hersteller diese Traceability nachweisen kann.

Wir prüfen aber nicht die Güte, weder die der Architektur, noch die des Codes.

Software-Audits: Regulatorische Anforderungen

Die gute Nachricht vorweg: Ein Software-Audit verlangen weder europäische noch US-amerikanische Behörden. Es gibt also i.d.R. keine Prüfung der Software selbst. Auch eine IEC 62304 Zertifizierung ist nicht vorgeschrieben.

Aber: Die Auditoren, benannten Stellen und die FDA-Inspektoren prüfen die Qualität des Software-Entwicklungsprozesses. Und zwar anhand der Dokumentation dieser Software-Entwicklung. Diese Prüfungen finden im Rahmen von ISO 13485-Audits oder beim Einreichen der technischen Dokumentation statt. Beides sind aber kein Software-Audits.

„Software-Audit“: Wo Sie Unterstützung erhalten

Wir unterstützen Medizinproduktehersteller dabei, deren Software normen- und gesetzeskonform zu entwickeln und zu dokumentieren. Denn was in den Normen steht, ist die eine Sache, was im (QM-)Audit bzw. bei der Einreichung geprüft wird, manchmal eine andere. Mein Team und ich (das selbst aus Auditoren besteht) nehmen ständig an Audits und Dokumentenprüfungen teil – auf wechselnden Seiten des Tischs.

1. Angebot: Kostenlose Videotrainings zum sicheren Bestehen von „Software-Audits“

Weil wir an den Audits teilnehmen, wissen wir, auf was es im Audit ankommt, was die typischen Fehler sind, die immer wieder zu unnötigen Problemen, nervigen (und manchmal peinlichen) Abweichungsberichten sowie zu teuren Nacharbeiten führen. Welche das sind, verraten wir Ihnen in einem  kostenlosen (!) Videotraining. So können Sie sich selbst vergewissern, ob Sie diese Probleme betreffen – und diese beheben, falls notwendig. Bevor Ihr Auditor diese Probleme aufdeckt…

Videotraining „Typische Auditfallen“ ansehen

 2. Angebot: Kostenloses Starter-Kit

Holen Sie sich das kostenlose Starter-Kit (E-Book, Tutorial, FAQ), das Ihnen hilft, Ihr „Software-Audit“ sicher zu bestehen.

3. Angebot: Micro-Consulting, die kostenlose Auditsprechstunde

Haben Sie bereits Probleme mit Ihrer Software (Dokumentation) in einem Audit gehabt? Befürchten Sie diese Probleme? Oder haben Sie einfach nur eine kurze Frage dazu, wie Sie Ihre Software-Dokumentation fürs Audit fit machen können?

Dann nehmen Sie einfach Kontakt mit uns auf und nutzen Sie das Micro-Consulting, unsere kostenlose Auditsprechstunde. Ja, das gibt es wirklich 🙂 (Regelmäßig fragen auch die Auditoren hier nach).

4. Angebot: Auditcheckliste

Die Auditcheckliste haben wir für benannte Stellen („TÜVs“) verfasst, die damit die Software-Audits (Sie wissen, dass es eigentlich QM-Audits sind) planen und durchführen.

Mit dieser Checkliste

• können Sie selbst überprüfen, wie normen- und gesetzeskonform Ihre Software dokumentiert ist,
• finden Sie heraus, wo es noch Verbesserungsbedarf gibt (bevor das Ihr Auditor tut und es peinlich und teuer wird),
• und haben Sie die Sicherheit, an alles gedacht zu haben. So vermeiden Sie ein Zuviel an Dokumentation und damit QM-Bürokratie.

5. Angebot: Auditgarant

Der Auditgarant ist eine Serie von Videotrainings, die Ihnen Schritt für Schritt zeigt, wie Sie nicht nur die Software für Ihr Medizinprodukt FDA bzw. IEC 62304-konform dokumentieren, sondern auch wie Sie die Risikomanagement- und Gebrauchstauglichkeitsakte „auditsicher“ erstellen.

Videotrainings im Auditgarant ansehen