Die FDA unterscheidet drei sogenannte „Level 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.
Beachten Sie, dass die FDA am 04.11.2021 einen Entwurf eines neuen Guidance-Dokuments publiziert hat, das die Level of Concern ablösen wird. Sie erfahren dazu mehr in Kapitel 4.
1. Definition und Bestimmung des Level of Concern
Die FDA definiert drei Level of Concern zur Klassifizierung von Software:
- 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 in ihrem Guidance Document Content of Premarket Submissions for Software Contained in Medical Devices nicht nur diese drei Klassen, sondern gibt auch Hilfestellung, um den Level of Concern zu bestimmen.
Dazu hat die FDA einen Entscheidungsbaum definiert und zwei Listen mit Fragen. Die erste Liste enthält u. a. die folgenden Fragen:
- Ist die Software ein Zubehör zu einem Medizinprodukt, das einen „Major Level of Concern“ hat?
- Kann ein Softwarefehler (vor Risikokontrollmaßnahmen!) zu einem Tod oder zu einer schweren Verletzung führen, beispielsweise weil die Software eine Behandlung steuert oder dem Vitaldaten-Monitoring in potenziell lebensbedrohlichen Situationen dient?
Sobald man eine der Fragen mit „ja“ beantworten kann, ist der Level of Concern bestimmt.
2. Level of Concern: Welche Folgen diese Klassifizierung hat
Umfang der einzureichenden Dokumentation
Der Level of Concern steuert die Menge der einzureichenden Unterlagen:
| 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
- 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 Off-the-Shelf Software Guidance der FDA kennen und beachten.
Lesen Sie hier mehr zu Gemeinsamkeiten und Unterschieden zwischen OTS und SOUP.
3. Sicherheitsklassifizierung gemäß IEC 62304 vs. Level of Concern gemäß FDA
Die Level of Concern erinnern an die Sicherheitsklassifizierung von Software-Komponenten in 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 die absurde Diskussion, dass selbst die unkritischste Software im unwahrscheinlichsten Fall eben doch einen großen Schaden verursachen kann und deshalb eigentlich alle Software der Klasse C angehört. Dieses Problem will die IEC 62304 mit dem Ammendment zur Sicherheitsklasse lösen.
Lesen Sie hier mehr zu den Änderungen bei der Sicherheitsklassifizierung gemäß IEC 62304.
4. Änderungen: Ende des Level of Concern
Am 04.11.2021 hat die FDA den Entwurf eines Guidance-Dokuments Content of Premarket Submissions for Device Software Functions publiziert. Dieses Dokument soll das Guidance-Dokument ablösen, das den Level of Concern einführte.
Dieses neue Guidance-Dokument unterscheidet nur noch zwei Klassen.
a) Bestimmung der Klassen
Die FDA definiert nicht mehr drei „Level of Concern“, sondern zwei „Dokumentationsklassen“:
- Basic Documentation
- Enhanced Documentation
Eine Software verlangt eine „Enhanced Documentation“, wenn mindestens eine der folgenden Bedingungen erfüllt ist:
Das Produkt, das die Software enthält oder die Software ist,
- ist ein Kombinationsprodukt,
- dient dem Einsatz in der Transfusionsmedizin bzw. Organspende (Bestimmung von Organspendern und Empfängern),
- fällt in die Klasse III oder
- kann im Fall eines Fehlers zum Tod oder zu einer schweren Verletzung („serious injury“) führen.
Beim vierten Punkt bezieht sich die FDA auf vernünftigerweise vorhersehbare Risiken.
b) Konsequenz der Klassifizierung
Ähnlich wie die Level of Concern wirkt sich auch die Klassifizierung auf den Umfang der einzureichenden (Software-)Dokumentation aus:
| Element der Software-Dokumentation | Basic Documentation | Enhanced Documentation |
| Bestimmung der Dokumentationsklasse | x | x |
| Beschreibung der Software | x | x |
| System- und Software-Architektur | x | x |
| Risikomanagement | x | x |
| Software Requirements Specification (Software-Anforderungen) | x | x |
| Software Design Specification | — | x |
| Dokumentation der Software-Entwicklung und -Wartung | x | x (erweitert) |
| Software-Testing | x (ohne Details der Unit- und Integrationstest) | x |
| Versionshistorie | x | x |
| Liste und Bewertung der Anomalien | x | x |
Die neuen Anforderungen erinnern sehr an die bisherigen Level moderate und major. D. h., dass Hersteller keine Software-Dokumentation einreichen können, die nur den sehr laxen Anforderungen des minor level of concern entspricht.
c) Bewertung
Die FDA nimmt starken Bezug auf die IEC 62304. Ein Vorgehen gemäß Klasse A erlaubt sie aber spätestens mit der neuen Version des Guidance-Dokuments nicht mehr. Zudem sollten sich Hersteller bewusst sein, dass die Menge der einzureichenden Dokumentation unabhängig ist von der Menge der zu erstellenden Dokumentation.
Das Johner Institut empfiehlt Herstellern daher grundlegend, konform den Anforderungen der Sicherheitsklasse C zu arbeiten und zu dokumentieren.
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!
Änderungshistorie
- 2021-11-08: Kapitel 4 eingefügt
Kategorien: FDA Zulassung - die U.S. Food and Drug Administration
Tags: Software-Sicherheitsklasse gemäß IEC 62304
11 Kommentare
Hinterlassen Sie einen Kommentar
Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.
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
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.
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!
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.
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)?
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
Dear Mr. Johner,
I’m wondering what is the impact to OTS software? (I understand that the FDA is planning to review the OTS Guideline after finalising this Guidance Document). Does it means that OTS/SOUP that has minor LOC should have the basic documentation? If this is the case, it will be a lot of work!
Dear Chia,
unfortunately we don’t know FDAs plans related to the revision of the OTS guidance. However, since the level of concern was removed in the draft software guidance, it will most probably be removed from the OTS guidance, too. Anyhow, also under the current OTS guidance, you always need a basic documentation, even for a minor level of concern OTS software.
Best regards
Luca Salvatore
Dear Luca,
Thank you for your response! You’re right about the basic documentation requirement for minor LoC, except for the following:
– system software architecture
– documentation of software development and maintenance
If these are to be added for minor LoC OTS, it will be a lot of work. Let’s wait for FDA announcement.
Have a good day!
Das in Kapitel 4 vorgestellte Guidancedokument ist immernoch ein Draft und die Submission fordert auch immernoch die Bestimmung des Level of concern.
Macht es Sinn sich schon auf das Guidancedokument zu verlassen? Gerade der Wegfall der Software design specification wäre ja eine enorme Entlastung.
Vielen Dank!
Sehr geehrte Frau Berndt,
das Guidance ist in der Tat noch im draft, d.h. noch nicht anwendbar. Die FDA wird also bis auf Weiteres nach der alten und aktuell gültigen Version von 2005 vorgehen.
Freundliche Grüße
Luca Salvatore