 |
Level of Concern: Was die FDA damit erreichen möchte
Mittwoch 29. Juli 2015
| Inhaltsübersicht |
|---|
| Definition des Levels of Concern » |
| Folgen der Klassifizierung » |
| Abgrenzung zu Sicherheitsklassen » |
Definition und Bestimmung des Levels of Concern
Die FDA definiert drei Levels of Concern, in die Software klassifiziert werden muss:
- Minor: We believe the level of concern is Minor if failures or latent design flaws are unlikely to cause any injury to the patient or operator.
- Moderate: We believe the level of concern is Moderate if a failure or latent design flaw could directly result in minor injury to the patient or operator. […].
- Major: We believe the level of concern is Major if a failure or latent flaw could directly result in death or serious injury to the patient or operator. […]
Die FDA nennt im Guidance Document Content of Premarket Submissions for Software Contained in Medical Devices nicht nur diese drei Klassen, vielmehr beschreibt sie dort einen Entscheidungsbaum, wie man diesen Level of Concern bestimmt.
Dazu hat die FDA einen Entscheidungsbaum definiert, der zwei Listen an Fragen enthält. Muss man eine der Fragen mit „ja“ beantworten, so ist der Level of Concern bestimmt. Beispielsweise enthält die erste Liste die folgenden Fragen:
- Ist die Software ein Zubehör zu einem Medizinprodukt, das einen „Major Level of Concern“ hat?
- Kann ein Software-Fehler (vor Risikokontrollmaßnahmen!) zu einem Tod oder einer schweren Verletzung führen, beispielsweise weil die Software eine Behandlung steuert oder dem Vitaldaten-Monitoring in potenziell lebensbedrohlichen Situationen dient?
Level of Concern: Welche Folgen diese Klassifizierung hat
Umfang der einzureichenden Dokumentation
Zum einen steuert der Level of Concern die menge der einzureichenden Unterlagen:
Software-BeschreibungGefährdungsanalyseSoftware-RequirementsSoftware-ArchitekturSoftware Design SpecificationTraceability AnalysisBeschreibung „Software Development Environment“Verifizierung und Validierung
| Dokument | Minor Level of Concern | Moderate Level of Concern | Major Level of Concern |
|---|---|---|---|
| Software Description | ja | ja | ja |
| Gefährdungsanalyse | ja | ja | ja |
| Software Requirements | ja | ja | ja |
| Software-Architektur | nein | ja | ja |
| Software Design Specification | nein | ja | ja |
| Software Development Environment Description | nein | ja | ja |
| Verifizierung und Validierung | verkürzt | ja | ja |
| Traceability Analysis | ja | ja | ja |
Off-the-Shelf Software
Auch bei Off-the-Shelf Software (OTSS) spielt der Level of Concern eine entscheidende Rolle: Er regelt nämlich
- den Umfang der dafür notwendigen Dokumentation (z.B. „Basic Documentation“, „Special Documentation“),
- ob und welche risikomininierenden Maßnahmen dokumentiert werden müssen,
- ob ggf. ein Audit beim Hersteller notwendig ist und
- ob diese Komponente überhaupt eingesetzt werden darf.
Sie als Hersteller sollten diesen FDA „Off-the-Shelf Software Guidance“ kennen und beachten.
Lesen Sie hier mehr zu Gemeinsamkeiten und zum Unterschied zwischen OTS und SOUP.
Sicherheitsklassifizierung gemäß IEC 62304 versus Level of Concern gemäß FDA
Das erinnert an die Sicherheitsklassifizierung von Software-Komponenten der IEC 62304:2007:
- Klasse A: Keine Verletzung oder Schädigung der Gesundheit ist möglich.
- Klasse B: Keine schwere Verletzung ist möglich.
- Klasse C: Tod oder schwere Verletzung ist möglich
Sind damit diese beiden Klassifizierungen äquivalent? Nein!
- Die Klassifizierung der FDA legt fest, welche Unterlagen bei der Zulassung einzureichen sind. Die Klassifizierung nach IEC 62304 legt fest, welche Unterlagen zu erstellen sind.
Für die niedrigen Klassen kann man sich manches ersparen. Beim FDA-Audit müssen hingegen die Unterlagen für alle Komponenten vorliegen. Dass dies besonders bei niedrig klassifizierten Komponenten meist nicht erfolgt, ist eine andere Sache. - Während die Klasse A nur vom Schweregrad abhängt, berücksichtigt der „Minor Level of Concern“ auch die Wahrscheinlichkeit („unlikely“). Damit umgeht die FDA absurde Diskussionen, dass selbst die unkritischste Software im unwahrscheinlichsten Fall eben doch einen großen Schaden verursachen kann und damit eigentlich alle Software Klasse C wird. Dieses Problem ist die IEC 62304 mit dem Ammendment zur Sicherheitsklasse übrigens angegangen.
Lesen Sie hier mehr zu den Änderungen bei der Sicherheitsklassifizierung gemäß IEC 62304
Autor des Beitrags " Level of Concern: Was die FDA damit erreichen möchte
Johner Institut GmbH
Bewertung 0 von 5 bei 0 Bewertungen
Kategorien: FDA Zulassung - die U.S. Food and Drug Administration
Tags: Software-Sicherheitsklasse gemäß IEC 62304
Donnerstag 16. März 2017 um 11:47
Hallo Herr Johner,
vielen Dank für den informativen Artikel. Eine Frage bezüglich des Level of Concern habe ich noch. Kann bei einem Produkt, dass aus meheren Software Systemen besteht (getrennte Hardwarekomponenten mit eigener CPU und Speicher) für jedes Softwaresystem der Level of Concern bestimmt werden und somit die einzureichende Dokumentation verringert werden?
Die IEC 62304 erlaubt ja unterschiedliche Sicherheitsklassen für verschiedene Softwaresysteme bzw. Softwareeinheiten. So ist es auch meiner Sicht möglich für verschiedene Softwaresysteme in einem Produkt unterschiedliche Sicherheitsklassen zu vergeben (ausgehend vom Schweregrad natürlich). Geht das bei dem Level of Concern auch?
Liebe Grüße,
Philipp Ott
Donnerstag 16. März 2017 um 18:58
Die FDA kennt das Konzept so nicht wirklich. Sie weiß zwar, dass ein Produkt mehrere „Softwares“ enthalten kann, spricht aber dann von „Software Components“.
Die FDA wäre verwirrt, wenn man für unterschiedliche Software-Systeme unterschiedliche LoC definiert und entsprechend einreicht.
ABER: Das ist auch gar nicht notwendig, weil die FDA sowieso den „risk-based approach“ propagiert. Insofern unterscheidet sich die Dokumentation nicht wesentlich.
Freitag 2. März 2018 um 10:48
Sehr geehrter Herr Johner,
sie schreiben in
https://www.johner-institute.com/articles/software-iec-62304/safety-classes-level-of-concern/:
„If you market your products in the US the software safety class is irrelevant. You have to document according to class C anyhow. … “
Ich wüsste gerne ob es für diese Behauptung einen weiteren Beleg von Seite der FDA gibt welcher das Vorhandensein der vollständigen Dokumentation beim Audit verlangt. Für Software die laut 62304 in die Klasse A bzw. nach der FDA Guidance Minor Level of Concern ist fällt es sonst schwer für eine vollständige Dokumentation zu argumentieren. Vor allem wenn in der Guidance dann noch steht:
„We believe the documents that we recommend submitting will generally be the same documents that you would normally generate during the development of a Software Device.“
Dass eine vollständige Dokumentation von Vorteil für den Hersteller ist und eine gute Kontrolle des Designs und der Verifikation erlaubt steht natürlich außer Frage.
Vielen Dank!
Freitag 2. März 2018 um 16:46
Sehr geehrter Herr Prueckl,
die FDA definiert den Level of Concern in einem Guidance Document, das den „Content of Premarket Submissions“ regelt. Es geht hier nicht um den Aufbau der SW-Dokumentation. Vielmehr fordert die FDA für SW unabhängig von dem Level of Concern die Design Controls einzuhalten.
Daher müssen Sie damit rechnen, dass ein Inspektor die Software-Akte sehen will um den Software-Lebenszyklus in Gänze zu beurteilen.
Ich widerspreche aber nicht, dass die meisten Inspektoren bei Minor Level Software den Fokus der Inspektion auf andere Teile lenken.
Mittwoch 20. November 2019 um 14:47
Sehr geehrter Herr Johner,
Für eine reine stand-alone SW oder auch eine „Haupt“-SW für ein Medizinprodukt ist der LoC recht klar. Aber wenn eine (weitere) Software als zusätzliche MSicherheitsmaßnahme zu existierenden HW-Sichereheitsmaßnahmen entwickelt werden soll tue ich mich schwer mit dem Ansatz:
Die FDA schreibt: „We recommend that you determine the Level of Concern before any mitigation of relevant hazards.“ aber auch
„We recommend that you indicate the Level of Concern for your Software Device, determined before the effects of any mitigations.“
Wie verhält es sich denn, wenn eine HW schon im Design Sicherheitsmassnahmen (z.B. ein Laser HW-Sicherheitsmassnahmen nach relevanter Lasersicherheitsnorm) mitbringt und nun anschließend für diese HW eine Kontrollsoftware entwickelt werden soll als weitere Sicherheitsmaßnahme. Ist der LoC ohne die HW-Sicherheitsmaßnahmen zu betrachten („before any mitigation“) oder kann hier davon ausgegangen werden, dass es sich um die durch die HW-Sicherheitsmaßnahmen abgedeckten Risiken um keine relevanten Gefährdungen mehr handelt („mitigation of relevant hazards)?
Mittwoch 20. November 2019 um 16:37
Sehr geehrter Herr Thiemann,
danke für die spannende Frage! Die Antwort hängt – wie Sie bereits andeuten – davon ab, wann man eine Maßnahme man als risikominimierend und wann als „selbstverständlich“ klassifiziert. Dazu gibt es keine gesetzliche Regelung, aber eine wie ich finde nützliche Einschätzung eines TÜVs:
Alle Maßnahmen, die ein junger Absolvent bzw. eine junge Absolventin einer einschlägigen Fachrichtung ergreifen würde, zählt man nicht als risikominimierend, sondern als „selbstverständlich“. Alle anderen Maßnahmen sind als risikominimierend zu klassifizieren, auch wenn sie für die Firma selbstverständlich sein mögen.
Wenn eine Firma einen Laser nur so schwach wie notwendig einbaut, dürfte das selbstverständlich sein. Hingegen wäre eine Kontrollsoftware, die Teil einer Überwachungskomponenten ist, eine risikominimierende Maßnahme darstellen. Für diese Kontrollsoftware (und natürlich auch für die kontrollierte Software) wäre somit der LoC zu bestimmen.
In der Hoffnung, mit dieser Faustformel etwas geholfen zu haben, und mit den allerbeste Grüßen, Christian Johner