Die IEC 62304 fordert in Kapitel 9 einen Problemlösungsprozess. Doch vieles, was da beschrieben steht, findet sich auch im Kapitel 6 zum Wartungsprozess. Benötigen Sie als Hersteller jetzt einen oder zwei Prozesse? Lesen Sie hier, wie Sie redundante Arbeit und QM-Bürokratie vermeiden und dennoch die Forderungen der Norm erfüllen.
Problemlösungsprozess versus Wartungsprozess: Das sind die Ziele
Beim Wort Problemlösungsprozess denken viele an die Lösung des Problems in Form eines Bug-Fixes. Doch genau das – die Änderung der Software – ist nicht Gegenstand des Problemlösungsprozesses, sondern des Wartungsprozesses.
Der Problemlösungsprozess verfolgt vielmehr die Ziele
- herauszufinden, ob es überhaupt ein Problem gibt,
- herauszufinden, was die Ursache des Problems ist,
- zu entscheiden, ob das Problem behoben werden muss und ob weitere Maßnahmen notwendig sind (z.B. Behördenmeldungen),
- zu entscheiden, in welcher Form das Problem beseitigt werden soll,
- sicherzustellen, dass das Problem wirklich behoben ist und
- sicherzustellen, dass das Problem künftig nicht mehr auftritt.
Problem mit Redundanzen beim Problemlösungs- und Wartungsprozess?
Die Norm verlangt im Software-Wartungsprozess und im Problemlösungsprozess ähnliche Tätigkeiten:
| Problemlösungsprozess | Software-Wartungsprozess |
| 9.1 Problembericht erstellen, Kritikalität des Problems bewerten, Informationen zur Problembeseitigung sammeln | 6.2.1.2 Problembericht erstellen (s. 9.1) |
| 9.2 Problem analysieren, Ursachen finden, Auswirkungen auf die Sicherheit analysieren, entscheiden, ob und welche Maßnahmen notwendig sind | 6.2.1.3 Auswirkungen des Problems auf die Sicherheit analysieren |
| 9.3 Betroffene informieren (z.B. Behörden, Anwender, Kollegen) | 6.2.5 Mit Anwendern und Behörden kommunizieren |
| 9.4 Mögliche Änderungen genehmigen (Schnittstelle zum „Change Control Process“) | 6.2.4 Änderungen genehmigen |
| 9.5 Aufzeichnungen aufbewahren | |
| 9.6 Trends analysieren | |
| 9.7 Verifizieren, dass das Problem gelöst ist und (negative) Trends umgekehrt sind | |
| 9.8 Re-Testing (Regression Testing) vollständig dokumentieren |
Was soll das? Völlige Redundanz? Doppelte Arbeit?
Problemlösungsprozess und Wartungsprozess: So erklärt das die Norm
Dass diese Forderungen zu Fragen führen werden, scheint den Autoren selbst klar gewesen zu sein. Daher findet sich im informativen Anhang zumindest der Versuch einer Erklärung. So schreibt die Norm:
Es ist wichtig, zwischen der Software-Wartung und der Software-Problemlösung zu unterscheiden. Der Fokus des Software-Wartungs-PROZESSES liegt auf einer angemessenen Antwort auf Rückmeldungen, die nach der Freigabe des SOFTWARE-PRODUKTS entstehen. […] Der Fokus der Software-Problemlösung liegt auf dem Betrieb eines umfangreichen Kontroll-SYSTEMS, das Problemberichte analysiert, …
IEC 62304:2015 B.6.2
Damit ist zumindest die Intention klar. Ob die Forderungen an Problemlösungsprozess und Wartungsprozess dadurch verständlicher werden, steht auf einem anderen Blatt. Die Redundanzen lösen diese Erklärungen jedenfalls noch nicht auf.
Redundanzen vermeiden: Das ist unsere Empfehlung
Tabellarische Darstellung
Natürlich sollten Sie jede Form von doppelter Arbeit vermeiden. Die folgende Tabelle beschreibt Schritt für Schritt die Aktivitäten, die Sie gemäß IEC 62304 ausführen müssen. Übernehmen Sie diese Schritte in Ihre entsprechende SOP(s).
Die rechte Spalte zeigt, wie Sie mit der Tätigkeit „automatisch“ die Forderungen der Norm erfüllen – sowohl den Problemlösungsprozess als auch den Wartungsprozess betreffend!
| Schritt | Tätigkeit | Normenkapitel |
|---|---|---|
| 1 | Interne und externe Rückmeldungen erfassen | 6.2.1.1, 6.2.1.2 |
| 2 | Problembericht erstellen | 6.2.1.1, 9.1 |
| 3 | Problem evaluieren und über Notwendigkeit von Änderungen entscheiden | 6.2.1.2, 6.1.2.4, 9.2 |
| 4 | Änderungen genehmigen | 6.2.4, 9.4 |
| 5 | Änderungen und Probleme kommunizieren (z.B. an Behörden, Anwender, Dritte) | 6.2.4, 9.3 |
| 6 | Änderungen implementieren und verifizieren und System freigeben | 6.3.1, 6.3.2, 9.7 |
| 7 | Trend analysieren, Preventive Actions festlegen und Umsetzung prüfen | 9.6, 9.7; übrigens auch Forderung der ISO 13485 und FDA |
Grafische Darstellung
Wir haben ein Prozessschaubild erstellt, um das Zusammenspiel von Problemlösungsprozess und Wartungsprozess zu illustrieren. Sie können es nutzen, um Ihre entsprechenden SOPs schneller und normenkonform zu formulieren – damit Sie im Audit oder in der FDA-Inspektion bei diesem schwierigen Thema auf sicherem Boden stehen.
Sie können das Schaubild über unser Micro-Consulting anfordern. Oder Sie nutzen diese Darstellung 😉
Könnte man sagen, der Software-Problemlösungs-Prozess entspricht einem „Software-CAPA Prozess“, und der Software Maintenance Prozess einem „Software-PMS Prozess“?
Hallo Herr Buttgereit,
ich kann Ihrem Gedanken folgen, finde es aber etwas zu stark vereinfacht. Hier meine Gedanken dazu:
Im Rahmen des Software-Maintenance Prozess geht es darum Feedback zu sammeln und zu dokumentieren, zu evaluieren, ob es Probleme gibt, Risiken abzuschätzen und daraus abgeleitete Änderungen kontrolliert einzubringen. Die ISO 13485 und MDR sehen dafür bereits Prozesse vor (Support und Kundenreklamation, Risikomanagement, Änderungsmanagement, Entwicklungsprozess, PMS). In der Regel lassen sich die Anforderungen der IEC 62304 durch die genannten Prozesse abbilden und es wird kein gesonderter Maintenance Prozess als eigene SOP aufgesetzt. Der Software-spezifische Punkt SOUP (6.1.f)) sollte dabei aber nicht vergessen werden.
Im Rahmen der Problemlösung geht es um das kontrollierte und dokumentierte Lösen von Problemen. Das hat es zwar mit CAPA gemein, allerdings liegt der Fokus hier stärker auf der Korrektur als auf Korrekturmaßnahmen und Vorbeugemaßnahmen. Ich wäre vorsichtig, das mit dem CAPA-Prozess zu vereinen, da dieser meist etwas schwergewichtiger ist als die „reine Problemlösung“. Auch sind die Adressaten des Prozesses eher andere.
Hallo Herr Reinsch, Dank für’s Feedback. Ich stimme Ihnen zu — die Frage war aber auch nicht so gemeint, das der Software-Problemlösungs-Prozess mit dem CAPA Prozess abgedeckt würde, oder da integriert würde. Entsprechend nicht der Maintenance Prozess durch PMS … War mehr die Frage, ob das von der Idee her vergleichbar ist. So wie wir beim CAPA ja auch prüfen, ob es ein Problem (CAPA) ist, wenn ja die Ursache suchen, erneutes Vorkommen verhindern, eine Schnittstelle zur Erfassung von potentiellen Problemen stellen… Und beim Maintenance Prozess eben nicht passiv auf Feedback warten, sondern aktiv nach neuen Informationen suchen, die sich auf die aktuelle Risikobewertung, Umsetzung, Verwendung, Missbrauch und Vorkommnisse bei vergleichbaren Produkten… beziehen.
Ich könnte mir vorstellen, die Erfassung der Inputs über die genannten Prozesse zu verbinden. Danach geht es aber hoch softwarespezifisch in eigenen Prozessen weiter. Oder in beiden — ein Software-Problem könnte ja auch ein CAPA sein, etwa wenn in der Software-Planung ein Punkt übersehen wurde (wird). Typischerweise wird es aber — so wie sie es auch ausführen — so Software-spezifisch sein, dass ein „default-handling“ im CAPA Prozess kontraproduktiv wäre.
Also, definitiv zwei eigenständige, spezifische Prozesse …