 |
Problemlösungsprozess für Software
Freitag 20. November 2015
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.
Problem mit Redundanzen beim Problemlösungs- und Wartungsprozess?
Im Kapitel 6.2.1.2 (Software-Wartungsprozess) fordert die IEC 62304, dass für jedes Problem ein Problembericht aufgezeichnet werden muss.
In Kapitel 9.1. (Problemlösungsprozess für Software) fordert die Norm fast wortgleich, dass der Hersteller für jedes Problem einen Problembericht erstellen muss.
Ähnliches gilt für die Bewertung dieser Problemberichte: Laut Kapitel 6.2.1.3 müssen die Problemberichte evaluiert werden, laut Kapitel 9.2 untersucht werden.
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.
Damit ist zumindest die Intention klar. Ob die Forderungen an Problemlösungsprozess und Wartungsprozess denn dadurch verständlicher werden, steht auf einem anderen Blatt. Die Redundanzen lösen diese Erklärungen damit 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 Spalten zeigt, wie Sie damit „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.1.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. 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, das Sie nutzen können, um das Zusammenspiel von Problemlösungsprozess und Wartungsprozess zu illustrieren und damit Ihre entsprechenden SOPs schneller und normenkonform zu formulieren. Damit Sie im Audit oder 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 :-):
Kategorien: Software & IEC 62304