AAMI TIR 36: Validierung von Prozesssoftware

Der AAMI TIR 36 ist ein Best Pratice Guide, der den Titel “Validation of software for regulated processes“ trägt.

Dieser Artikel fasst Ihnen das 111-seitige Dokument zusammen und stellt Ihnen das zentrale Prozessdiagramm als Download zur Verfügung.

AAMI TIR 36: Wer das Dokument lesen sollte

Zielgruppe

Den AAMI TIR 36 sollten die Personen lesen, die mit der Validierung von Prozesssoftware bei Medizinprodukteherstellern befasst sind. Beispiele dafür sind:

• Mitarbeiter der IT, die Prozesssoftware bereitstellen, konfigurieren und prüfen müssen
• Entwickler, die Werkzeuge wie Compiler oder Werkzeuge für das Software-Testing, das Build-, Versions– oder Application-Life-Cycle-Management einsetzen
• Personen, die Produktionsprozesse automatisieren
• Menschen, die die Automatisierung von Prüfplätze in der Qualitätssicherung verantworten
• Externe und interne Auditoren sowie Berater, die unterstützen möchten, die regulatorischen Forderungen zu erfüllen, und Abweichungen identifizieren möchten
• Mitarbeitende beispielsweise im Qualitätsmanagement und der Forschung, die mit selbstentwickelnden Excel-Dateien qualitätsrelevante Parameter berechnen und verwalten

Der TIR 36 wendet sich nicht primär an Personen, die Software validieren, welche Teil eines Medizinprodukts wird.

Firmen, die im einen FDA-Kontext arbeiten, sollten den „Technical Report“ unbedingt lesen. Er wird ihnen helfen, die Anforderungen des 21 CFR part 11, 21 CFR part 820 – insbesondere part 820.70 – zu erfüllen. Auch der Gamp 5 nimmt für sich in Anspruch, beachtet werden zu müssen.

Firmen, die „nur“ EU-Vorgaben erfüllen müssen, ist er empfohlen, insbesondere wenn sie auf ISO 13485:2016 umstellen, weil diese die CSV fordert.

Leitfragen zum Herausfinden, ob regulatorische Anforderungen zu beachten sind

Zuerst sollen die Hersteller anhand folgender Leitfragen feststellen, ob die Software-Validierung überhaupt unter die regulatorischen Anforderungen fällt:

1. Könnte ein Fehler der Software die Sicherheit oder Leistungsfähigkeit eines Medizinprodukts beeinträchtigen?
2. Automatisiert die Software einen Prozess oder Aktivitäten, die vom Qualitätsmanagementsystem geregelt werden?
3. Erzeugt oder verwaltet die Software Daten, die für eine Einreichung relevant sind?
4. Erzeugt oder verwaltet die Software Aufzeichnungen, die regulatorisch gefordert sind (z.B. Design History File)?
5. Wird die Software genutzt, um geforderte elektronische Aufzeichnungen oder Unterschriften zu erzeugen oder zu verwalten?

Was der TIR 36 sagt: Übersicht über den Technical Report

Der „Technical Report“ hat 111 Seiten, von denen die meisten auf die Beispiele im Anhang C entfallen. Er umfasst sechs Kapitel, die wir Ihnen im Folgenden kurz vorstellen.

Abb. 1: Kapitelstruktur des AAMI TIR 36 als Mindmap. Zum Vergrößern klicken.

1. Kapitel: Allgemeines

Das erste Kapitel stellt den Anwendungsbereich und das Ziel des Dokuments vor. Ersteren finden Sie bereits oben beschrieben, das Ziel weiter unten in diesem Artikel.

2. Kapitel: Regulatorischer Kontext

Im zweiten Kapitel legen die Autoren dar, auf welche regulatorischen Anforderungen sich der TIR 36 bezieht. Diese haben wir Ihnen bereits oben vorgestellt.

3. Kapitel: Diskussion Software Validierung

Im dritten Kapitel nähert sich das Dokument zuerst dem Begriff Software-Validierung. Die Autoren machen aber klar, dass sie ihn nicht nur als einen Aspekt des Testens verstehen. Sie definieren ihn als alle Aktivitäten, die dazu dienen, sich zu vergewissern, dass die Software ihre Zweckbestimmung erfüllt und dass sie vertrauenswürdig und zuverlässig ist. Dazu zählen auch Tätigkeiten im Rahmen der Verifizierung.

Weiter sagt das dritte Kapitel, dass man die bewährte „Toolbox“ aus Anhang A sowie eine kritische Denkweise nutzen sollte, die das nächste Kapitel vorstellt.

4. Kapitel Software-Validierung und kritische Denkweise

Das zentrale vierte Kapitel macht klar, dass die Validierung ein Prozess über den gesamten Lebenszyklus von der Entwicklung über die Wartung bis zur Außerbetriebnahme ist.

Abb. 2: Die vom AAMI TIR36 geforderten Aktivitäten. Zum Vergrößern klicken.

Der wesentliche Teil des TIR 36 besteht darin, die in der Abbildung 2 gezeigten Aktivitäten im Kapitel 4 zu erläutern.

Laden Sie sich dieses zentrale Schaubild als PDF herunter:

PDF herunterladen

Dabei müssen die Hersteller folgende Entscheidungen treffen:

1. Aufwand, den man z.B. für das Dokumenten-Review treiben muss
2. Umfang und Inhalt dieser Dokumente
3. Auswahl der Werkzeuge und Methoden aus der „Toolbox“
4. Aufwand für das Anwenden dieser Werkzeuge

Diese Festlegungen sind risikobasiert zu treffen.

5. Kapitel: Dokumentation

Das fünfte Kapitel betont die Notwendigkeit von Dokumentation, ohne konkrete Anforderungen daran zu spezifizieren.

6. Kapitel: Vorausgesetzte Prozesse

Im sechsten Kapitel betonen die Autoren die Bedeutung eines Qualitätsmanagementsystems. Dem Anspruch, die notwendigen Prozesse zu nennen, werden sie nicht gerecht. Sie erwähnen zwar beispielsweise das Infrastrukturmanagement, einen Software-Entwicklungsprozess hingegen nicht.

Anhang A: Toolbox

Im Anhang A stellt der TIR 45 eine „Toolbox“ vor. Für jede der in Abbildung 2 genannten Phasen möchten die Autoren Hilfsmittel vorstellen. Diesem Anspruch werden sie aber nur bedingt gerecht (siehe Kritik).

Die Toolbox besteht aus Tabellen mit folgenden Spalten:

• Aktivität: Diese Aktivitäten beziehen sich teilweise auf die Aktivitäten, die in Abbildung 2 genannt sind, teilweise aber nicht. Das erschwert die Zuordnung.
• Definition: Hier finden sich nur teilweise Definitionen, aber ebenso Hinweise wie man die Aktivitäten durchführen soll. Sind das die Tools?
• Wert: Hier soll angeblich der Nutzen der jeweiligen Aktivität genannt werden. Dies gelingt teilweise.

Anhang C

Anhand von insgesamt 14 Beispielen zeigen die Autoren auf, wie sie den TIR 36 in der Praxis angewendet sehen möchten. Diese Beispiele reichen von der einfachen Excel-Tabelle über einen C-Compiler und ein Software-Test-System bis hin zu einer Software zur automatischen Konfektion von Blutschläuchen.

Was Sie noch über diesen Technical Report wissen sollten

Verbindlichkeit

Wie alle „Technical Information Reports“ der AAMI formuliert der TIR 36 keine rechtsverbindlichen Anforderungen. Das bleibt den Gesetzen (z.B. MPG, 21 CFR part 820) und im Falle Europas den EU-Verordnungen (wie der MDR) vorbehalten.

Der AAMI TIR 36 gewährleistet nicht, dass Firmen, die konform damit arbeiten, automatische die regulatorischen Anforderungen erfüllen. In der Praxis dürfte das aber der Fall sein.

Die „Technical Information Reports“ der AAMI sind mit Normen vergleichbar.

Ziel

Der TIR 36 möchte dabei helfen,

• die regulatorischen Anforderungen zu erfüllen
• die Software-Validierung als ein Werkzeug nutzbar zu machen, das der Wertsteigerung dient,
• Risiken durch fehlerhafte Software für Menschen (z.B. Patienten), Firmen und Prozesse zu minimieren und
• unnötige Aufwände für die Software-Validierung zu vermeiden.

Er möchte explizit nicht dazu dienen, einen Satz zusätzlicher Mindestanforderungen zu definieren, wie das beispielsweise die FDA Guidance Documents tun.

Alternative Ansätze

In Europa verfolgt die ISO 80002-2 mit dem Titel „Validierung von Prozesssoftware“ ein vergleichbares Ziel wie der AAMI TIR 36.

Zusammenfassung und Kritik

Der AAMI TIR 36 zeigt einige Stärken, aber leider auch viele Schwachpunkte:

Stärken

• Die Beispiele sind umfangreich und repräsentativ und helfen zu verstehen, was die Autoren gemeint haben.
• Die Übersichtsgrafik (hier Abbildung 2) verschafft einen Rahmen, auf den die Kapitel des Technical Reports Bezug nehmen.
• Auf die regulatorischen Anforderungen wird gut Bezug genommen.

Schwachpunkte

• Präzise Definitionen fehlen.
• Vermischung von Begrifflichkeiten. Beispielsweise diskutiert der TIR im Kapitel zur Zweckbestimmung der Software (auch) deren Anforderungen.
• Kanonische Konzepte wie die ISO 25010 werden ignoriert.
• Die Prozessdiagramme sind unvollständig und inkonsistent.
• Dem Anspruch „Toolbox“ wird das Kapitel nicht gerecht: Methoden werden nur teilweise genannt, echte Werkzeuge oder Werkzeugklassen überhaupt nicht. Das schmälert den Nutzen sehr. Verweise auf andere Normen oder Trivialitäten (FMEA für Risikoanalyse) ändern daran nichts.
• Die Toolbox mischt in der Spalte „Aktivitäten“ die Aktivitäten, die sie selbst in der Übersicht eingeführt hat, mit Teilaufgaben, die innerhalb dieser Aktivitäten zu erledigen sind.

Fazit und Empfehlung

Der TIR 36 ist sicher nicht der stärkste Technical Report der AAMI. Falls Sie Medizinprodukte in den USA in Verkehr bringen, ist das Dokument dennoch ein „Must Read“. Die Wahrscheinlichkeit, dass Ihr Auditor das Thema Computerized System Validation adressiert und dabei Bezug auf den TIR 36 nimmt, ist hoch.

Allen anderen sei Folgendes empfohlen:

1. Holen Sie sich für Ihre SOPs und Software-spezifischen Validierungspläne Anregungen aus den Kapiteln 4 und der Toolbox. Die obigen Abbildungen helfen Ihnen beim Navigieren im 111-seitigen Technical Report.
2. Prüfen Sie, ob der Anhang C ein Beispiel enthält, das Ihrer Software ähnelt. Falls dies der Fall ist, bedienen Sie sich dort und erstellen Ihren Validierungsplan entsprechend.