Level of Concern: Was die FDA damit erreichen möchte

Mittwoch 29. Juli 2015

Die FDA unterscheidet drei sogenante „Levels of Concern“, die sehr an die Sicherheitsklassen der IEC 62304 erinnern. Allerdings gibt es Unterschiede, die immer wieder zu Problemen bei Inspektionen oder 510(k)-Zulassungen führen.

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.

Der Level of Concern bestimmt sich anhand eines Entscheidungsbaums

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.

Prof. Dr. Christian Johner
Wünschen Sie sich Unterstützung dabei, eine „FDA-konforme“ Software-Dokumentation zu erstellen? Professor Johner und sein Team helfen gerne! Nehmen Sie Kontakt auf!

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!

  1. 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.
  2. 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


Kategorien: FDA Zulassung - die U.S. Food and Drug Administration
Tags:

4 Kommentare über “Level of Concern: Was die FDA damit erreichen möchte”

  1. Philipp Ott schrieb:

    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

  2. Prof. Dr. Christian Johner schrieb:

    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.

  3. Robert Prueckl schrieb:

    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!

  4. Prof. Dr. Christian Johner schrieb:

    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.

Kommentar schreiben