Risk Based Approach – Risikobasierter Ansatz: Mit 5 Beispielen erklärt

Viele Behörden und Regularien sprechen von einem risk-based Approach, auf deutsch risikobasierter Ansatz. Allerdings definieren sie diesen Begriff nicht und nennen auch keine Beispiele.

Dieser Artikel verschafft einen Überblick darüber, was ein „risk-based Approach“ ist und gibt konkrete Hinweise dazu, wie

• Firmen diese regulatorischen Anforderungen erfüllen können und
• wie Gesetze und Normen Anforderungen formulieren sollten, um ihrem Anspruch, risk-based zu regulieren, gerecht zu werden.

1. Risk Based Approach – um was es geht

a) Um welche Risiken / Schäden es geht

Die ISO 14971 definiert den Begriff „Risiko“ als die Kombination der Wahrscheinlichkeit eines Schadens und des Schweregrads dieses Schadens. Unter Schäden versteht die Norm v.a. physische Verletzungen und Beeinträchtigungen der Gesundheit. Aber auch Schäden für Güter oder die Umwelt zählt sie dazu.

Beim risikobasierten Ansatz sind hingegen neben den körperlichen Schäden für Patienten, Anwender und Dritte auch die Schäden bzw. Folgen aufgrund regulatorischer „Non-Compliance“ ergeben wie:

1. Zertifikatsentzug
2. Abweichungen im Audit
3. Eine verzögerte oder verhinderte Ausstellung eines neuen Zertifikats

b) Anpassen der Aufwände an die Risiken

Beim risikobasierten Ansatz geht es darum, dass die Firmen die Aufwände im Rahmen des Qualitätsmanagements an die Risiken anpassen. Dies dient den folgenden Zielen:

1. Unnötige Aufwände und Qualitätsbürokratie vermeiden
2. Die Ressourcen auf die „kritischen“ Aspekte fokussieren
3. Die Sicherheit (z.B. der Patienten) sowie Gesetzeskonformität erhöhen

Beispiele für einen Risk-Based Approach sind:

• Das Risk-Based Auditing
• Das Risk-Based Testing
• Die Risk-Based Maintenance

Der Risk Based Approach lässt sich somit wie folgt
definieren:

2. Regulatorischer Rahmen für einen risikobasierten Ansatz

a) ISO 13485:2016

Was die Norm fordert

Die umfangreichsten Vorgaben an den risikobasierten Ansatz stellt die ISO 13485:2016. Dieser Ansatz muss sich im Qualitätsmanagementsystem wiederfinden:

• Lenkung interner Prozesse (Kapitel 4)
• Lenkung ausgelagerter Prozess und Entscheidung über Auslagerung (Kapitel 4)
• Validierung von computerisierten Systemen (CSV) (Kapitel 4)
• Überprüfung der Wirksamkeit von Schulungen (Kapitel 6.2)
• Entwicklung von Produkten (Kapitel 7.1 – 7.3)
• Beurteilung und Auswahl von Lieferanten (Kapitel 7.4)
• Kontrolle der Lieferanten einschließlich Verifizierung der beschafften Produkte (Kapitel 7.4)
• Validierung von Prozessen und der Computersoftware (Kapitel 7.5 und 7.6)
• Verhindern ungewollter Resultate durch Verbessern des QM-Systems (Kapitel 8)

Was die Norm nicht fordert

Die ISO 13485:2016 stellt keine Anforderungen daran, wie und wo der Hersteller darlegen muss, wie er den risikobasierten Ansatz umsetzt. Insbesondere gibt es keine Anforderung, diesen in jedem Dokument zu diskutieren. Entsprechende Forderungen benannter Stellen entbehren der normativen Grundlage.

Das Johner Institut empfiehlt die Darlegung der Risiken und
des risikobasierten Ansatzes z.B. im Qualitätsmanagementhandbuch. Dazu später
mehr.

b) MDR

Die MDR erwähnt zwar das Konzept eines risikobasierten Ansatzes. Konkrete Anforderungen an die Hersteller formuliert sie aber nicht.

c) USA / FDA

Inspektionen

Die FDA basiert die Auswahl, Intensität und Frequenz von Inspektion bei Firmen ebenfalls auf einem „risk based approach“. Firmen werden mit einer höheren Wahrscheinlichkeit inspiziert,

• deren Produkte hohe Schäden verursachen können,
• die in der Vergangenheit bereits Probleme mit Produkten oder bei Inspektionen hatten.

Mit dem risikobasierten Ansatz schafft es die FDA, bei
begrenzten Mitteln eine möglichst hohe Wirksamkeit zu erreichen.

Risikobasierte Aufwände in den Guidance Documents

Die FDA verlangt in vielen „Guidance Documents“ einen „risk
based approach“. Dieser soll wie bei der ISO 13485 bei QM-relevanten Prozessen
wie der Validierung von Prozessen und Produkten Anwendung finden:

d) Sonderfall ISO 9001

Die ISO 9001 kennt seit der Version 2015 ebenfalls das
Prinzip des risikobasierten Ansatzes. Sie schreibt:

Maßnahmen zum Umgang mit Risiken und Chancen müssen proportional zur möglichen Auswirkung auf die Konformität von Produkten und Dienstleistungen sein.

Quelle: ISO 9001:2015 Kapitel 6.1

Die ISO 9001 hat ein teilweise anderes Verständnis des Begriffs Risiko als die ISO 13485. Ihr geht es auch um Firmenrisiken.

3. Den Risk Based Approach
umsetzen

a) Schritt 1: Risiken pro Prozess identifizieren

Listen Sie z.B. in Ihrem QM-Handbuch alle relevanten Prozesse auf und identifizieren Sie die damit verbundenen Risiken. Sie können dies in tabellarischer Form tun (s. Tabelle 1).

Bedenken Sie sowohl regulatorische Risiken als auch Risiken
im Sinne der ISO 14971 (insbesondere für die körperliche Unversehrtheit).

b) Schritt 2: Maßnahmen festlegen

In einer weiteren Spalte ergänzen Sie die Maßnahmen, mit
denen Sie die Risiken beherrschen wollen. Zu den möglichen Typen an Maßnahmen zählt
die ISO 9001:2015:

• Vermeiden von Risiken
• Akzeptieren von Risiken
• Verringern von Risiken durch Ändern des Schweregrads oder der Wahrscheinlichkeit des Schadens
• Beseitigen von Risiken („inhärente Sicherheit“) z.B. durch Beseitigen der Ursache

Diese Tabelle könnte beispielhaft wie folgt aussehen:

Prozess(bereich)	Verfahrens- und Arbeitsweisungen	Risiken	Maßnahmen
Dokumentenlenkung	VA Lenkung von DokumentenVA Lenkung von Aufzeichnungen	Regulatorische Risiken: Dokumente sind nicht gelenkt. Risiken nach ISO 14971: fehlerhafte Produkte wegen falscher Prüfanweisung	Beide VAs verlangen Einsatz eines DMS. Freigabeprozesse für neue Dokumente
Personelle Ressourcen	VA Aus- und Weiterbildung AA Erfolgskontrolle	Regulatorische Risiken: Schulungen finden nicht statt, sind nicht dokumentiert, Erfolgskontrolle fehlt. Risiken nach ISO ISO 14971: fehlerhafte Produkte, weil Mitarbeiter falsch entwickelt oder produziert	VA verlangt die Erfolgskontrolle und die regelmäßige Überprüfung der Umsetzung
Produktrealisierung	VA Entwicklung VA Beschaffung AA Wareneingang VA Produktion	Entwicklung: fehlerhafte Produkte	VA Entwicklung: Design Review überprüft Einhaltung des Prozesses
		Beschaffung: Nicht-konforme Produkte wegen Komponenten, die nicht Spezifikationen entsprechen	VA Lieferanten verlangt Qualifizierung der Lieferanten AA verlangt Prüfung des Wareneingangs

c) Schritt 3: Festlegen von Risikoklassen

Beim dritten Schritt legen die Hersteller Risikoklassen fest
wie z.B.:

Risikoklasse	Regulatorische Risiken	„Risiken“ nach ISO 14971
A: klein	Minor Non-Conformity	Keine nennenswerten körperlichen Schäden
B: mittel	Major Non-Conformity in Audit	Produktfehler, der zu körperlichen Verletzung oder Beeinträchtigung führen könnte
C: groß	Entzug oder Aussetzung des Zertifikats Gerichtsprozess	Produktfehler, der zu irreversibler Schädigung oder Tod führen könnte

Hinweis: Die beiden rechten Spalten beschreiben streng genommen keine Risiken, sondern Schweregrade von Schäden bei unklarer Wahrscheinlichkeit. Letztere sei als „vernünftigerweise vorhersehbar“ zu verstehen.

d) Schritt 4: Anpassen der Maßnahmen an die Risikoklasse

Nun gilt es, den Umfang der Maßnahmen (rechte Spalte in Tabelle 1) an das Risiko (die Risikoklasse) anzupassen. Dies ist der risikobasierte Ansatz.

Beispiel 1: Design Review

Der Aufwand von Design Reviews lässt sich an die
Risikoklassen anpassen. Dieser Aufwand lässt sich mit Hilfe von Stellschrauben
adaptieren wie:

• Frequenz
• Intensität:
  Dauer, Prüfaspekte
• Beteiligte
• Usw.

Risikoklasse	Frequenz	Intensität	Beteiligte
A: klein	Bei Freigabe der Systemspezifikation sowie zusammen mit Design Transfer	Checkliste A	Entwicklungs- und Projektleiter, Leiter QM, Leiter Produktion
B: mittel	Wie bei A. Zusätzlich bei Freigabe der Systemarchitektur und vor Systemtests	Checklisten A + B	Wie bei A
C: groß	Am Ende jeden Sprints (4-6 Wochen)	Checklisten A, B und C	Wie bei A. Zusätzlich „Product Owner“

Beispiel 2: Qualifizierung von Lieferanten

Der „risk based approach“ muss gemäß ISO 13485:2016 auch bei der Auswahl, Bewertung und Überwachung von Lieferanten Anwendung finden.

Risikoklasse	Zertifiziertes QMS	QSV	Lieferantenaudit	Selbstauskunft
A: klein				X
B: mittel		X	X	X
C: groß	X	X	X	X

Beispiel 3: Validierung von Computersoftware

Bei der Validierung von Computersoftware haben die
Hersteller mehrere Dimensionen, um den Aufwand an die Risiken anzupassen:

1. Funktionalität: Die Validierung kann sich auf „kritische“ Funktionen der Software konzentrieren. Diese Funktionalitäten drücken manche aus in Form von:
   • Benutzungsszenarien oder Use Cases
   • Software-Anforderungen
2. Testverfahren: Abhängig vom Risiko können unterschiedliche Testverfahren zum Einsatz kommen
   • Testen „Happy-Path“ versus fehlerbasiertes Testen
   • Systematisches Ableiten von Testfällen mit Hilfe der Blackbox-Testverfahren wie äquivalenzklassenbasiertes Testen, grenzwertbasiertes Testen, Testen mit Entscheidungstabellen usw.
3. Testabdeckung: Es gibt viele Maße, um die Testabdeckung zu quantifizieren:
   • Anteil der getesteten Use Scenarios
   • Anweisungsabdeckung
   • Zweigabdeckung
   • Prozentsatz der getesteten UI-Elemente
   • U.v.m.
4. Testaspekte nach ISO 25010
   • Funktionalität
   • Portabilität
   • IT Security
   • Gebrauchstauglichkeit
   • Performanz (Zeitverhalten, Ressourcen-Verbrauch)
   • Interoperabilität
   • Robustheit
   • Wartbarkeit
5. Teststufen
   • Unit-Tests
   • Integrationstests
   • Software-Systemtests
   • Tests nach der Installation und Konfiguration in der Zielumgebung
   • Sonstige Validierung z.B. Usability Tests

Beispiel 4: Wareneingang

Beim Wareneingang zählen zu den Stellschrauben für einen „risk
based approach“ beispielsweise:

• Prozentsatz der geprüften Teile
• AQL-Wert
• Anteil der geprüften Eigenschaften eines Teils

Beispiel 5: Software-Entwicklung

Die IEC 62304 setzt den risikobasierten Ansatz in Form der Sicherheitsklassen bereits um. (Die Einschränkungen dabei sind weiter oben beschrieben.) Abhängig davon müssen Hersteller Aktivitäten wie ein detailliertes Design durchführen bzw. dokumentieren.

Hersteller haben die Freiheit, im Entwicklungsplan noch granularer das Risiko des jeweiligen Software-Systems zu berücksichtigen. Zu den möglichen Stellschrauben zählen:

1. Alles im Beispiel 1 (Design Review) Genannte
2. Alles im Beispiel 3 (CSV) Genannte
3. Modellierungstiefe bei der Architektur
4. Entscheidung für Automatisierung von Tests z.B. für die GUI
5. Prozessmodell
6. Anforderungen an die Kompetenz des Teams (explizite Forderung der ISO 13485:2016)
7. Entscheidung über den Einsatz von SOUP und die Auslagerung von Teilen der Entwicklung

4. Typische Fehler

a) Schwergrad-basierte statt risikobasiertes Vorgehen

Gesetzgeber, Behörden, Benannte Stellen und Hersteller behaupten zwar, risikobasiert zu agieren, sie tun es meist aber nicht. Sie treffen ihre Entscheidungen vorwiegend auf Basis des Schweregrads möglicher Schäden. Dabei übersehen sie, dass eine große Anzahl etwas weniger schwerwiegender Schäden weniger vertretbar sein könnte, als ein einziger möglicher schwerer Schaden, der ggf. noch nicht einmal eingetreten ist.

b) Fehlender Referenzrahmen

Um genau diese Szenarien vergleichen und damit bewerten zu können, bedarf es eines Referenzrahmens. Dieser müsste beispielsweise Fragen beantworten:

• Wie quantifiziert man die „Summe aller Risiken“?
• Wie wird der Nutzen der Produkte berücksichtigt? (Es geht ja darum, das Nutzen-Risiko-Verhältnis zu optimieren.)
• Welche Risiken müssen betrachtet werden? (Beispielsweise müsste geklärt werden, wie Risiken durch Medizinprodukte zu bewerten sind, die nicht oder (wegen hoher Kosten) nicht jedem zur Verfügung stehen.)

c) Egozentrischer Blickwinkel

Vorbemerkung: Das Wort egozentrisch ist hier im ursprünglichen Sinne der Bedeutung zu verstehen, nämlich sich in den Mittelpunkt (der Betrachtungen) zu stellen.

Mitarbeiter von Behörden und Benannten Stellen, aber auch von Herstellern lassen sich beim risikobasierten Ansatz (meist unbewusst) dazu verführen, die Risiken für sich selbst in die Entscheidungen einfließen zu lassen.

5. Fazit

Der risk-based Approach gibt den verschiedensten Organisationen die Möglichkeit, ihre Aufwände für das Qualitätsmanagement an die Risiken anzupassen. Beispiele sind:

• Hersteller beim Erstellen von Vorgabedokumenten wie SOPs und Arbeitsanweisungen
• Benannte Stellen bei Audits und Reviews
• Behörden beim „Enforcement“ d.h. dem Erzwingen der Konformität und Festlegen von Maßnahmen
• Gerichte beim Festlegen von Strafen

Damit können die Organisationen die Aufwände auf die relevanten Aspekte – d.h. hohe Risiken – konzentrieren. Von dieser Möglichkeit sollten alle Gebrauch machen.

Dabei sind Hersteller gut beraten, nicht nur bei der analytischen Qualitätssicherung (z.B. Audits, Inspektionen, Testing) risikobasiert vorzugehen, sondern auch bei der konstruktiven Qualitätssicherung (z.B. Entwicklung, Wartung) sowie bei allen Post-Market Aktivitäten.

Der risikobasierte Ansatz darf nie dazu führen, dass Hersteller normative oder gesetzliche Anforderungen nicht erfüllen, zumal dies zu einem regulatorischen Risiko führen würde.

Manchmal lässt sich „risk-based approach“ mit „gesunder Menschenverstand“ übersetzen. Hersteller und Auditoren sollten diesen walten lassen. Die Normen geben uns die Möglichkeit dazu.

---

Änderungshistorie

• 2024-12-20: Kapitel 4 eingefügt, redaktionelle Änderungen
• 2019-02-26: Erste Version veröffentlicht

Ähnliche Beiträge