Viele Behörden und Regularien sprechen von einem Risk-Based Approach (RBA), 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 – worum es geht
a) Um welche Risiken oder 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, z. B.:
- Zertifikatsentzug
- Abweichungen im Audit
- Eine verzögerte oder verhinderte Ausstellung eines neuen Zertifikats
Die MDR strebt laut ihren Erwägungsgründen eine risikobasierte Klassifizierung der Medizinprodukte an. In Regel 11 teilt sie Software aber nur aufgrund des Schweregrads von Schäden ein und berücksichtigt die Wahrscheinlichkeiten dieser Schäden nicht. Damit ist diese Klassifizierungsregel nicht risikobasiert.
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:
- Unnötige Aufwände und Qualitätsbürokratie vermeiden
- Die Ressourcen auf die „kritischen“ Aspekte fokussieren
- 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
Die IEC 62304 legt über die Software-Sicherheitsklassen das Mindestmaß der Software-Dokumentation fest. Da die Sicherheitsklassen nur teilweise risikobasiert bestimmt werden, sind auch die Anforderungen an die Dokumentation nicht konsequent risikobasiert.
Der Risk-Based Approach lässt sich somit wie folgt definieren:
„Ein Vorgehen im Qualitätsmanagement, das die Aufwände zum Minimieren von Risiken an die Größe dieser Risiken anpasst.“
Quelle: Johner Institut
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 Prozesse 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 verlangt in Kapitel 4.1 nicht die risikobasierte Lenkung aller Prozesse, sondern die der geeigneten Prozesse. Welche das zumindest sind, erwähnt die Norm in den jeweiligen Kapiteln. Dies entspricht der oben stehenden Liste mit Ausnahme der Entwicklung.
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,
- wenn ihre Produkte hohe Schäden verursachen können,
- wenn sie 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-Dokumenten
Die FDA verlangt in vielen Guidance-Dokumenten einen risikobasierten Ansatz. Dieser soll (wie bei der ISO 13485) bei QM-relevanten Prozessen wie der Validierung von Prozessen und Produkten Anwendung finden:
- Off-The-Shelf Software Use in Medical Devices: Die Aufwände für die Auswahl und Überprüfung von OTS-Komponenten soll „safety-based“ sein. Die FDA möchte offensichtlich die Aufwände an den möglichen Schwergrad von Schäden adaptieren, nicht an das Risiko.
- General Principles of Software Validation: Aufwände für die Validierung und Re-Validierung von Software sollen abhängig vom Risiko der Software(änderung) sein.
- Applying Human Factors and Usability Engineering to Medical Devices: Auch über die Aufwände für die Validierung (Usability Tests) soll abhängig von den Risiken entschieden werden.
- Content of Premarket Submissions for Management of Cybersecurity in Medical Devices: “employ a risk-based approach to the design and development of medical devices with appropriate cybersecurity protections;”
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. Dies kann in tabellarischer Form erfolgen (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
Ergänzen Sie in einer weiteren Spalte 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 Dokumenten VA Lenkung von Aufzeichnungen | Regulatorische Risiken: Dokumente sind nicht gelenkt Risiken nach ISO 14971: fehlerhafte Produkte wegen falscher Prüfanweisung | Beide VA 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 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 den 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, 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 Verletzungen oder Beeinträchtigungen 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. Er lässt sich mithilfe von Stellschrauben adaptieren, u. a.:
- Frequenz
- Intensität: Dauer, Prüfaspekte
- Beteiligte
| 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“ |
Lesen Sie hier mehr zum Thema Design Review.
Beispiel 2: Qualifizierung von Lieferanten
Der risikobasierte Ansatz 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 stehen den Herstellern mehrere Dimensionen zur Verfügung, um den Aufwand an die Risiken anzupassen:
- 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
- Testverfahren: Abhängig vom Risiko können unterschiedliche Testverfahren zum Einsatz kommen:
- „Happy-Path“ versus fehlerbasiertes Testen
- Systematisches Ableiten von Testfällen mithilfe der Blackbox-Testverfahren wie äquivalenzklassenbasiertes Testen, grenzwertbasiertes Testen, Testen mit Entscheidungstabellen usw.
- Testabdeckung: Es gibt viele Maße, um die Testabdeckung zu quantifizieren, u. a.:
- Anteil der getesteten Use Scenarios
- Anweisungsabdeckung
- Zweigabdeckung
- Prozentsatz der getesteten UI-Elemente
- Testaspekte nach ISO 25010
- Funktionalität
- Portabilität
- IT-Security
- Gebrauchstauglichkeit
- Performanz (Zeitverhalten, Ressourcen-Verbrauch)
- Interoperabilität
- Robustheit
- Wartbarkeit
- Teststufen
- Unit-Tests
- Integrationstests
- Software-Systemtests
- Tests nach der Installation und Konfiguration in der Zielumgebung
- Sonstige Validierung, z. B. Usability Tests
Lesen Sie hier mehr zu den Themen Software-Testing und Computerized Systems Validation (CSV).
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 das Risiko des jeweiligen Software-Systems noch spezifischer zu berücksichtigen. Zu den möglichen Stellschrauben zählen:
- Alles im Beispiel 1 Genannte (Design Review)
- Alles im Beispiel 3 Genannte (CSV)
- Modellierungstiefe bei der Architektur
- Entscheidung für Automatisierung von Tests, z. B. für die GUI
- Prozessmodell
- Anforderungen an die Kompetenz des Teams (explizite Forderung der ISO 13485:2016)
- Entscheidung über den Einsatz von SOUP und die Auslagerung von Teilen der Entwicklung
4. Typische Fehler
a) Schwergrad-basiertes 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 von weniger schwerwiegenden Schäden weniger vertretbar sein könnte als ein einziger möglicher schwerer Schaden, der 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 diese 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 eigenen Risiken in die Entscheidungen einfließen zu lassen.
Die Wahrscheinlichkeit ist gegeben, dass eine Behörde oder eine Benannte Stelle ein negatives Presseecho erlebt oder unter Druck einer Aufsichtsbehörde gerät, wenn sie ein Produkt durchgewinkt hat, das „öffentlichkeitswirksam“ Patienten gefährdet oder gar schädigt.
Hingegen ist die Wahrscheinlichkeit eher gering, dass die gleiche Organisation wegen ihres Handelns für die Krankheit oder gar den Tod von Patienten verantwortlich gemacht wird, weil diese wegen fehlender Produkte nicht angemessen diagnostiziert oder behandelt werden konnten. Denn die Zuordnung der Handlung zu den Folgen der Handlung ist unklar.
Dies sorgt für eine Risikoasymmetrie.
5. Fazit
Der risikobasierte Ansatz (Risk-Based Approach) erlaubt den verschiedenen Organisationen, ihre Aufwände für das Qualitätsmanagement an die Risiken anzupassen. Beispiele sind:
- Hersteller beim Erstellen von Vorgabedokumenten wie SOP und Arbeitsanweisungen
- Benannte Stellen bei Audits und Reviews
- Behörden beim „Enforcement“, d. h. dem Erzwingen der Konformität und dem 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.
Hersteller sind 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
Sehr geehrter Herr Johner,
vielen Dank für Ihren ausführlichen Artikel. Wir hatten bereits viele Aspekte eines risikobasierten Ansatzes für unsere ISO 13485:2016 Rezertifizierung umgesetzt und sind damit gut durch das Audit gekommen. Dadurch motiviert versuchen wir uns nun an einer MDSAP Zertifizierung. Dummerweise scheinen die Regularien für MDSAP und somit auch Auditoren, den den risikobasierten Ansatz komplett zu ignorieren. Siehe
https://www.fda.gov/downloads/MedicalDevices/InternationalPrograms/MDSAPPilot/UCM390383.pdf, Chapter 6, Task 15, Seite 78.
„If the selected process is software controlled or if software is used in production
equipment or the quality management system, verify that the software is validated for its
intended use. “
und
„Production process control software (and any other software used in the organization’s quality system) must be validated for its intended use according to an established protocol.“
Hier fehlen leider risikobasierte Teile “ …. where the resulting output cannot be or is not verified by subsequent monitoring or measurement … “
oder
„The specific approach and activities associated with software validation and revalidation shall be proportionate to the risk associated with the use of the software, ….“
„MDSAP“ scheint hier einen echten Rückschritt mit sich zu bringen, oder übersehe ich hier etwas ?
MfG,
Stefan Otmar Walter
Lieber Herr Walter,
danke für Ihre wichtige Rückmeldung! Sie haben absolut Recht: der Begriff „risk based“ taucht in diesen Dokumenten nicht (überall) auf. Dennoch würde ich „proportionate to the risk“ darunter subsummieren. Da es keine spezifischen Anforderungen an den Umfang und die Intensität z.B bei der CSV gibt, bleibt Ihnen gar nichts anderes übrig, als solche Überlegungen anzustellen. Denn ein vollständiges Testen ist unmöglich.
Da die FDA selbst immer vom risk-based approach spricht und da MDSAP dem auch nicht widerspricht, würde ich den Ansatz weiter verfolgen.
Insofern würde ich hier keinen Rückschritt sehen wollen. MDSAP gibt sogar Freiheiten bei den Auditzeiten und -schwerpunkten, die letztlich auch risk-based genutzt werden sollten.
Mit herzlichen Grüßen, Christian Johner
Hallo.
Herzlichen Dank für diesen ausführlichen Bericht. Aber wie steht es denn um imaginäre (also immaterielle) Schäden bei der Risikobewertung? Wenn ein Produkt (eine Dienstleistungen) nicht den gestellten Anforderungen entspricht, so kann dies ja gravierende Auswirkungen auf das Image eines Unternehmens haben. Dies wird nicht berücksichtigt, oder?
Sehr geehrter Herr Kropp,
Sie können alle Schäden, die der Definition genügen, berücksichtigen. Reputationsschäden wirken sich letztlich auf die Ökonomie des Unternehmens aus. Die passen in die Definition.
Ob man sich damit einen Gefallen macht, weiß ich nicht, denn dadurch muss man Geld und Körperschäden / Tod in eine Skala bringen. Das ist oft ein ethisches Dilemma.
Viele Grüße, Christian Johner
Hallo Herr Prof. Dr. Christian Johner,
in der ISO 13485 heißt es, wie sie beschrieben haben für alle geeigneten Prozessen soll der risikobasierte Ansatz verwendet werden.
Dazu haben Sie im Abschnitt:
„2. Regulatorischer Rahmen für einen risikobasierten Ansatz a) ISO 13485:2016, Was die Norm fordert“
eine Auflistung gemacht, welche Prozesse gemeint sind.
Jedoch im Kapitel:
„3. Den Risk Based Approach umsetzen b) Schritt 2: Maßnahmen festlegen“
haben Sie auch einen zusätzliche Prozess „Dokumentenlenkung“ betrachtet.
Meine Frage ist:
Wie kann ein Unternehmen herausfinden, welches die geeigneten Prozesse für den risikobasierten Ansatz sind?
Über eine Antwort würde ich mich sehr freuen.
Liebe Grüße
Julia
Hallo Herr Prof. Dr. Christian Johner,
zu meiner Frage möchte ich noch ergänzen:
Welche Prozesse müssen laut ISO 13485 mindenstens eine Risikobetrachtung (Risikoanalyse- und bewertung) durchlaufen?
Bzw. anhand von welchen Kriterien kann ein Unternehmen entscheiden, ob eine Risikobetrachtung, für einen Prozess relevant ist?
Von allen Prozessen die ein Unternehmen hat, wie kann man herausbekommen, welche eine Risikobetrachtung benötigen?
Liebe Grüße
Julia
Sehr geehrte Julia,
danke für Ihre Fragen!
Im Kapitel 2 geht es um „interne Prozesse“. Zu denen zählt auch die Dokumentenlenkung. Daher sehe ich keinen Widerspruch.
Sie sollten alle(!) Prozesse daraufhin untersuchen, ob / welche Auswirkungen der Prozess insbesondere auf die Sicherheit und Leistungsfähigkeit von Produkten hat. Das Ergebnis dieser Risikoanalyse ist dann, wie streng die Prozess gelenkt werden müssen.
Konnte ich die Frage beantworten? Falls nicht, dann haken Sie gerne nach.
Viele Grüße, Christian Johner
Hallo Herr Prof. Dr. Christian Johner,
vielen Dank für Ihre hilfreiche Antwort.
Ich habe noch weitere Fragen, und zwar:
1. Um herauszufinden, welche Auswirkung die Prozesse auf die Sicherheit und Leistungsfähigkeit von Produkten haben, muss dazu erstmal die „Zweckbestimmungen und die Merkmale, die mit der Sicherheit des MP/IVD zusammenhängen (wie in ISO 14971 H.2.3)“ aller Medizinprodukte, welche an dem Prozess beteiligt sind bestimmt werden?
2. Bei der Identifizierung von Risiken/Gefährdungen (nach ISO 14971) innerhalb der QMS Prozesse, müssen dazu die Gefährdungen welche im Anhang E (Tabelle E.1) und zusätzlich für IVDs die im Anhang H (H.2.4.3) dargestellt sind, betrachtet werden? Oder muss man die Risiken in den Prozesse nur allgemein betrachten (z. B. Entwicklung –> fehlerhafte Produkte)
3. Gibt es eine bestimmte Methode welche man für die Risikoidentifizierung aller QMS Prozesse verwenden kann? (z. B. die Prozess-FMEA?) oder Checklisten…
3. Sie haben bei „c) Schritt 3: Festlegen von Risikoklassen“, die Schweregrade von Schäden dargestellt. Meine Frage ist, ob für die Risikobewertung bei den Prozessen nach 13485 auch noch die Wahrscheinlichkeit des Auftretens des Schadens betrachtet werden muss? Wenn ja, muss dazu die Wahrscheinlichkeit des Auftretens der Risikoursache betrachtet werden?
Über eine Antwort freue ich mich sehr.
Liebe Grüße,
Julia
Sehr geehrte Julia,
danke für Ihre weiteren Fragen.
ad 1.) Um die Auswirkungen bewerten zu können, sollten Sie auch, aber nicht nur die Zweckbestimmung kennen. Sie müssen herausfinden, wie sich der Prozess auf das Produkt auswirkt und wie ein fehlerhaftes Produkt zu Schäden (inkl. Schweregrad und Wahrscheinlichkeit) führen kann. Ohne Kenntnis der Zweckbestimmung wird das nur schwer gelingen. Die genannten Anhänge sind nicht normativ.
ad 2.) Die Risiken nach ISO 14971 müssen die „Safety-Risiken“ (also physische Schäden für Patienten, Anwender und Dritte) mit betrachten. Eine Beschränkung auf das Produkt wäre nicht ausreichend.
ad 3.) Beide genannte Verfahren sind geeignet.
ad 4.) Die Wahrscheinlichkeit ist ein essenzieller Teil jedes Risikos. Dabei geht es um die Wahrscheinlichkeit der Schäden, nicht die Wahrscheinlichkeit des Auftretens der Ursache. Natürlich beeinflusst die letztere die erstere.
Viele Grüße, Christian Johner