Sicherheitsklassen gemäß IEC 62304

Update: Keine Konformitätsvermutung mehr bei Sicherheitsklasse A? Mehr…

Definition der Sicherheitsklassen

Die IEC 62304:2007 unterscheidet drei Sicherheitsklassen:

• Zuerst Klasse A: Keine Verletzung oder Schädigung der Gesundheit ist möglich
• Dann Klasse B: Keine SCHWERE VERLETZUNG ist möglich
• Schließlich Klasse C: Tod oder SCHWERE VERLETZUNG ist möglich

Eine schwere Verletzung definiert die Norm dabei als „Verletzung oder Krankheit, die direkt oder indirekt lebensbedrohend ist, zu einer andauernden Beeinträchtigung einer Körperfunktion oder zu einer andauernden Schädigung des (menschlichen) Körpers führt oder ein medizinisches oder chirurgisches Eingreifen erfordert, um eine andauernde Beeinträchtigung einer Körperfunktion oder eine andauernde Schädigung des (menschlichen) Körpers zu verhindern“.

Obwohl diese Definition klar ist, zählt das Thema Sicherheitsklassen mit zu den meisten Fragen in unserem kostenlosen Micro-Consulting.

Änderungen durch Amendment I

Weshalb die Sicherheitsklassen neu definiert werden mussten

„Endlich“ möchte man sagen, gibt es eine überarbeitete Definition der Sicherheitsklassen. Die IEC 62304:2007 hat dabei ausschließlich den Schweregrad möglicher Schäden betrachtet. Das hat dazu geführt, dass man immer einen beliebig unwahrscheinlichen Fall konstruieren konnte, der zu einem schweren Schaden führt. Damit stuften fast alle Hersteller ihre Software in die Sicherheitsklasse C ein, und die Intention der Norm, Dokumentationsaufwände auf wirklich relevante Bereiche der Software zu konzentrieren, war konterkariert.

Neue Definition der Sicherheitsklassen

Die Sicherheitsklassen definiert die überarbeitete bzw. ergänzte Version der IEC 62304 nun wie folgt:

• Sicherheitsklasse A: Ein Software-System fällt dann in die Klasse A wenn sie nicht zu einer Gefährdungssituation beitragen kann oder (und das ist neu), wenn das Software-System zwar zu einer Gefährdungssituation beitragen kann, das aber nicht zu einem inakzeptablen Risiko führt, spätestens wenn man entsprechende Risikokontrollmaßnahmen ergriffen hat. Diese Risikokontrollmaßnahmen müssen aber außerhalb des Software-Systems liegen.
• Sicherheitsklasse B: Ein Software-System fällt in die Klasse B, wenn es zwar zu einer Gefährdungssituation führen kann, die nach den Risikokontrollmaßnahmen (wieder außerhalb des Software-Systems umzusetzen) zu einem inakzeptablen Risiko führt, aber die möglichen resultierenden Schäden nicht schwer sind.
• Sicherheitsklasse C: Diese Klasse ist definiert wie die Klasse B mit der Ausnahme, dass die möglichen resultierenden Schäden schwer sind oder sogar zum Tod führen können.

Die genannten Maßnahmen müssen Maßnahmen außerhalb des Software-Systems sein. Dazu lesen Sie weiter unten noch mehr.

Änderungen von der IEC 62304:2015 (Amendment 1) zu IEC 62304 „zweite Ausgabe“

Im Entscheidungsbaum der zweiten Ausgabe der IEC 62304  steht nicht mehr wie in der IEC 62304:2015 der fast absurde Satz:

„Does failure of the software result in unacceptable risk?“

Danach hätte es nur Software der Sicherheitsklasse A geben können. Nun heißt es „Considering the external RCM: Can the hazardous situation lead to unacceptable risk?“.

Wirklich großartig ist das noch nicht: Nun steckt die Wahrscheinlichkeit einmal im Risiko und zum anderen im Wort „can“. Das bedarf regelmäßig weiterer Erläuterungen.

100% Wahrscheinlichkeit gilt weiterhin

Nach wie vor sagt die Norm, dass die Wahrscheinlichkeit eines Software-Fehlers mit 100% angenommen werden muss. Das ist missverständlich, weil jeder Hersteller widerspricht, dass seine Software zu 100% fehlerhaft sei. Aber das ist auch nicht die Aussage der Norm.

Die Norm sagt vielmehr: Wenn ein Software-Fehler möglich ist, dann soll man die Wahrscheinlichkeit dessen Auftretens nicht diskutieren, sondern davon ausgehen, dass er auftritt. Die Wahl der Sicherheitsklassen soll ausschließlich anhand der o.g. Entscheidungen erfolgen:

1. Kann durch den Software-Fehler überhaupt eine Gefährdungssituation auftreten?
2. Falls ja: Kann der Software-Fehler zu inakzeptablen Risiken führen?
3. Falls ja: Wie hoch ist der resultierende Schweregrad?

Sie merken es: Keine dieser Fragen hat etwas mit der Wahrscheinlichkeit des Auftretens des Software-Fehlers zu tun. Man geht davon aus, dass er passiert, wenn er passieren kann.

Fazit: Die Annahme der 100% Wahrscheinlichkeit von Software-Fehlern wird bei der Festlegung der Sicherheitsklasse benötigt. Es behauptet niemand, dass Software-Fehler in 100% der Fälle auftreten.

Definition von „Software-System“

Zwar ändert das Amendment I die Definition des Begriffs Software-System nicht. Die Formulierungen wie „The MANUFACTURER shall assign to each SOFTWARE SYSTEM a software safety class“ legen nahe, dass das Software-System nicht mehr die Gesamtheit aller Software im Medizinprodukt darstellt, sondern eher pro PESS bzw. pro Prozessor/Speicherbereich zu verstehen ist.

Sinn der Sicherheitsklassen

Sicherheitsklassen haben das Ziel den Dokumentationsaufwand zu steuern.

Tabelle 1: Abhängigkeit der Dokumentation von den Sicherheitsklassen (nach Normkapitel gelistet)

Für Software der Sicherheitsklasse A müssen Hersteller nur die Software-Anforderungen (5.2) und die Software-Freigabe (5.8) dokumentieren, bei Klasse B kommt die Software-Architektur (5.3) und die Software-Verifikation (5.5 bis 5.7) hinzu, und bei Sicherheitsklasse C auch das detaillierte Design (5.4).

Änderung: Seit Amendment I sind die Systemtests auch bei Sicherheitsklasse A vorgeschrieben.

Allerdings hält das Johner Institut viele Diskussionen wegen Klasse B oder C für wenig zielführend. Was sind auch die Unterschiede? Dass man kein detailliertes Design und keine Unit-Tests macht? Das sind Dinge, die Studenten in dritten Semester lernen. Und sobald man Richtung FDA schaut, wird diese Diskussion sogar völlig absurd. Denn dort müssen unabhängig vom Level of Concern alle Dokumente erstellt, nur nicht eingereicht werden.

Reduktion der Sicherheitsklassen

Reduktion gemäß IEC 62304:2007

Die IEC 62304 legt fest: „Wenn das RISIKO des Todes oder einer SCHWEREN VERLETZUNG, das von einem Software-Fehler herrührt, anschließend durch eine Hardware-RISIKOKONTROLL-Maßnahme auf ein vertretbares Maß verringert wird (wie in ISO 14971 definiert), und zwar dadurch, dass die Folgen des Fehlers verringert werden oder dass die Wahrscheinlichkeit des Todes oder einer SCHWEREN VERLETZUNG, die von diesem Fehler herrührt, verringert wird, so kann die Software-Sicherheitsklasse von C auf B herabgesetzt werden.“

Mit Hardware ist entweder Mechanik oder zumindest ein zweites System mit einem unabhängigen Prozessor und Speicherbereich gemeint.

Auch innerhalb eines Software-Systems können einzelne Komponenten eine reduzierte d.h. kleinere Sicherheitsklasse haben, als das übergeordnete Software-System selbst. Das müssen die Hersteller aber begründen, was in der Regel nur mit Hilfe einer dokumentierten und geeigneten Software-Architektur möglich ist.

Beispiel

Rechtfertigt ein Notaus-Schalter, die Sicherheitsklasse einer Software um eine Klasse zu reduzieren, lautet die spannende Frage. Die Frage ist auch deshalb spannend, weil sie das ganze Dilemma der IEC 62304 zeigt: Auf der einen Seite ignoriert die Norm bei den Sicherheitsklassen die Wahrscheinlichkeit, auf der anderen Seite spricht sie bei den Hardwaremaßnahmen von Risiken — die definitionsgemäß Wahrscheinlichkeiten beinhalten:

Das bedeutet, dass sich die Frage nur aus dem Risikomanagement beantworten lässt: Wenn der Notaus-Schalter das Risiko auf ein vertretbares Maß verringert wird — und nur dann(!) — ist die Reduzierung der Sicherheitsklasse vertretbar. Da in den meisten Fällen wie auch diesem die Reduktion des Risikos nur durch eine Reduktion der Wahrscheinlichkeit erfolgt, müssten Sie begründen, um wie viele Größenordnung die Wahrscheinlichkeit abnimmt und dann in Ihrer Risikoakzeptanzmatrix nachsehen, ob Sie dann in einem akzeptablen Bereich landen. Die Definition Ihrer Risikoakzeptanzmatrix, genauer gesagt der Wahrscheinlichkeitsachse, muss daher auch quantitativ erfolgen. Sonst fehlt Ihnen eine Begründung, weshalb Sie die Sicherheitsklasse Ihrer Software von C auf B bzw. von B auf A reduziert haben.

Eigentlich müsste man von einer 100% Fehlerwahrscheinlichkeit der Software ausgehen. D.h. wenn man durch die Maßnahme die Wahrscheinlichkeit um zwei Größenordnungen senken könnte (schon das wird nur schwer argumentierbar sein), hätten man eine 1%-ige Wahrscheinlichkeit, dass das System versagt. Die Wahrscheinlichkeit eines Schadens wird noch niedriger sein. Doch ist die dann erreichte Schadenswahrscheinlichkeit nach der Maßnahme akzeptabel?

Natürlich ist die Annahme der 100% absurd, weshalb ich — in Vorgriff auf die nächste Version der 62304 — bereits heute mit Fehlerwahrscheinlichkeiten kleiner 100% argumentiere.

Reduktion gemäß Amendment I

Amendment I stellt klar, dass risikomininierende Maßnahmen nur dann auch die Sicherheitsklasse des Software-Systems reduzieren können, wenn diese außerhalb des Software-Systems realisiert sind beispielsweise in der System-Architektur.

Das bedeutet, dass eine Reduktion der Sicherheitsklasse bei standalone Software kaum vorstellbar ist. Allerdings könnte eine externe Maßnahme auch eine Maßnahme in der klinischen Routine sein. Das Amendment I spricht nicht mehr von Hardware-Maßnahmen.

Zusammenspiel der Sicherheitsklassen

Sicherheitsklassen und Klassifizierung nach MDD

„Gibt es einen Zusammenhang zwischen der Sicherheitsklasse nach IEC 62304 und der Klassifizierung nach MDD?“ lautet eine häufige Frage.

Es gibt keine ganz strenge Korrelation zwischen der Klassifizierung nach MDD und der Sicherheitsklasse nach IEC 62304. Kann es auch nicht geben. Ein Beispiel:

Wenn Sie ein hochkritisches Gerät haben, sagen wir Klasse IIb, bei dem die Software aber mit dieser Kritikalität nichts zu tun hat, kann diese Software durchaus Klasse A sein. Umgekehrt kann man aber sagen, dass eine Software der Klasse C eher nicht als Klasse I einzustufen ist. Denn Klasse C bedeutet ja, dass es Tod oder schwere Verletzungen explizit geben kann.

Als Faustformel kann man davon ausgehen, dass aktive Therapiegeräte als Klasse IIa eingestuft sind, wenn nichts Schlimmes passieren kann, andernfalls als Klasse IIb. Das ist natürlich nur eine Faustformel, im Einzelfall sind die Klassifizierungsregeln durch zu deklinieren und im Zweifel (was häufig vorkommt) mit der benannte Stelle zu diskutieren.

Die Kurzantwort auf die Frage lautet somit: Aus einer hohen Klassifizierung z.B. IIb kann nicht auf eine hohe Software-Sicherheitsklasse geschlossen werden. Umgekehrt geht das eher, aber nicht mit mathematischer Beweiskraft.

Sicherheitsklassen und Level of Concern

Die Sicherheitsklassen sind nahezu identisch dem Level of Concern definiert. Es gibt aber zwei wesentliche Unterschiede:

1. Der Level of Concern beeinflusst den Umfang der einzureichenden Dokumentation, nicht der zu erstellenden Dokumentation.
2. Der Minor Level of Concern beinhaltet im Gegensatz zu den anderen Level of Concerns und der Sicherheitsklassen den Aspekt der Wahrscheinlichkeit.

Sicherheitsklassen und Funktionen

Hersteller sind erfinderisch: Offensichtlich begeistert von der IEC 62304 kam einer auf die Idee, die Funktionen (UI-Elemente) eines Medizingeräts direkt mit Sicherheitsklassen in Verbindung zu setzen. Damit könne er direkt alle sicherheitskritischen Software-Teile identifizieren, entsprechend verifizieren und das alles tracen. Eine gute Idee?

Leider nein: Bei Funktionen, d.h. Elementen einer Benutzerschnittstelle, unterscheidet man Elemente zu Eingabe, zur Auswahl und zur Anzeige. Das sind beispielsweise Schalter, Knöpfe, Drop-Down-Menüs, Grafiken, Texte oder Eingabefelder.

Es mag noch möglich sein, ohne Kenntnis der Architektur ein Risiko zuzuordnen. Beispielsweise lässt sich auch ohne Kenntnis des Innenlebens eines Geräts abschätzen, wie hoch und wie wahrscheinlich ein Schaden sein wird, wenn Daten für einen falschen Patienten angezeigt oder der Regler einer Infusionspumpe den Fluss einer Infusionslösung falsch entgegen nimmt.

Was man ohne Kenntnis der Architektur aber nicht abschätzen kann, ist der Beitrag, den die Software dazu liefert. Und mit Architektur ist Soft- und Hardwarearchitektur gemeint. Möglicherweise ist die Software gar nicht beteiligt oder ein Fehler in ihr würde durch eine Hardwarekontrollmaßnahme erkannt und beherrscht werden. Dann hätten wir ein hohes Risiko, aber Software der Klasse A.

In anderen Worten: Die Funktionen, also alle Arten von Elementen einer Benutzerschnittstelle, gleich ob diese in Hard- oder Software realisiert sind, lassen u.U. eine Korrelation mit dem Risiko, nicht aber mit einer Softwaresicherheitsklasse zu.

Beispiele: Sicherheitsklassen für bestimmte Produkte

a) Klassifizierung von Überwachungssoftware

Die IEC 62304 erlaubt, dass diese Klassen durch Hardware-Risikokontrollmaßnahmen reduziert werden. Diese Kontrollmaßnahmen dürfen selbst wieder Software enthalten. Doch welche Klasse hat dann diese „überwachende“ Software?

Die Norm schreibt dazu:

Der HERSTELLER muss jedem SOFTWARE-SYSTEM, das zur Implementierung einer RISIKOKONTROLL-Maßnahme beiträgt, eine Software-Sicherheitsklasse zuordnen. Sie basiert auf den möglichen Auswirkungen derjenigen GEFÄHRDUNG, die durch die RISIKOKONTROLL-Maßnahme kontrolliert wird.

Das heißt wiederum, dass die Software, mit der die Risikokontrollmaßnahme realisiert wird, die gleich Sicherheitsklasse besitzt, wie die Software, die damit überwacht/kontrolliert wird.

b) PACS

Eine PACS-Software lässt sich nur in eine Sicherheitsklasse gemäß IEC 62304 einordnen, wenn man die Zweckbestimmung genau beschrieben hat. Wenn die Software beispielsweise dazu eingesetzt werden soll/darf, um den anatomischen Aufbau in Vorbereitung auf eine OP oder eine Bestrahlungsplanung zu vermessen, dann ist (ohne einer dezidierten Risikoanalyse vorgreifen zu wollen) bei einem Softwarefehler eine schwere Verletzung denkbar. Das Softwaresystem wäre folglich Klasse C. D.h. aber nicht, dass alle Komponenten dieses Systems Klasse C wären. Welche das sind, muss in der Architektur beschrieben sein (IEC 62304 Kapitel 5.3).

Eine geschätzte Mitarbeiterin eines Medizintechnikherstellers hat uns auf einen Blogbeitrag aufmerksam gemacht, in dem der Autor zu folgendem Schluss kommt:

„The more you have to rely on software to treat the patient, to monitor its vital constants or to give a diagnosis, the higher the class.”

Was halten Sie davon? Die Einschätzung, dass die Klasse umso höher sei, je größer die Abhängigkeit von dem Produkt, halte ich für problematisch. Der Grad der Abhängigkeit hat Auswirkungen auf die Wahrscheinlichkeit, dass etwas passiert, aber nicht auf den Schweregrad. Für die Sicherheitsklassifizierung nach EN 62304 ist aber nur der maximale Schweregrad relevant.

Weiter heißt es in einem Kommentar zu dem Blogbeitrag im Kontext PACS:

That kind of software is class B because it is not used alone in the diagnosis. It is always inserted in a chain of decisions for example, assessment by pairs, biopsy … The software in its environment can not be the cause of a severe injury. There are always other measures of protection to prevent a problem if it is buggey or crashes.

Der Einschätzung, dass SW eines PACS-Viewers Klasse B sei, kann das Johner Institut ebenfalls nicht folgen. Natürlich kann eine Rechts-Links-Vertauschung zu einer fehlerhaften oder verzögerten Behandlung (OP, Bestrahlung) führen. Das ist ja oft genug vorgekommen. Dass PACS Klasse IIb sind, dürfte ebenfalls ein Indiz sein. Die Tatsache, dass es „measures of protection to prevent“ gibt, reduziert nur die Wahrscheinlichkeit und rechtfertig daher nicht eine andere Klassifizierung als C.

Typische Missverständnisse und Fehler bei den Sicherheitsklassen

Die Sicherheitsklassifizierung von Software gemäß IEC 62304 ist immer wieder ein Thema bei unseren Seminaren, Inhouse-Workshops und Beratungen. Die Teilnehmer bzw. Firmen sind von dem Wunsch beseelt, die Sicherheitsklasse möglichst zu senken.

Lesen Sie hier mehr zu den Fallen, die Sie speziell bei Software der Sicherheitsklasse A unbedingt vermeiden sollten.

a) Annahme, die Sicherheitsklassen entsprächen dem Level of Concern

In der Tat scheinen sich die Definitionen von Sicherheitsklassen und Levels of Concern zu decken. Allerdings haben die Levels of Concern im Gegensatz zu den Sicherheitsklassen das Ziel, den Umfang der einzureichenden(!) Dokumentation zu steuern, nicht(!) der zu erstellenden.

b) Annahme, die Sicherheitsklasse ließe sich aus MDD Klasse ableiten

Eine der Argumentationen, die ich dann höre lautet wie folgt: Das Produkt ist ja nur Klasse I, d.h. die Software kann nicht Klasse C sein. Das stimmt in dieser Form nicht. Es gibt Produkte der Klasse I, die bei Fehlverhalten im ungünstigsten Fall zu einer schweren Verletzung führen. Das „im ungünstigsten Fall“ ist eine Aussage zur Wahrscheinlichkeit und damit zum Risiko. Die Sicherheitsklassifizierung berücksichtigt aber keine Wahrscheinlichkeiten. Daher ist sie eine Sicherheits- und keine Risikoklassifizierung.

c) Annahme, man könne bei Klasse B viel Dokumention sparen

Die nächste Annahme besteht darin, dass man bei Klasse B deutlich weniger machen/dokumentieren müsse. Auch das stimmt nur sehr bedingt. Im Vergleich zu einer Klasse C spart man sich nur das detailliertere Design – das keinesfalls bis auf Methoden- oder gar Methodensignaturebene erfolgen muss – und die dynamischen Komponententests. Aber mit Verlaub: Welche Entwicklungsabteilung, die auch nur einen Hauch an Professionalität hat, wird auf Unit-Tests verzichten?

d) Klassifizierung durch die Entwicklungsabteilung

Einen weiteren Fehler beobachte ich darin, dass das Software-Entwicklungsteam die Sicherheitsklasse bestimmt. Eine Software hat per se keine Sicherheitsklasse. Diese ergibt sich im Sinne einer FTA durch eine Analyse der Folgen eines nach außen „sichtbaren“ Gerätefehlers und der Analyse wie ein PESS (programmierbares elektrisches Subsystem) zu solch einem Gerätefehler beitragen kann. Die Sicherheitsklasse bestimmen also Risikomanager und Systemarchitekt, aber nicht die Software-Entwicklungsabteilung.

Das Ergebnis hängt sehr vom Nutzungskontext ab. Von den Anwendern, der Art der Benutzung usw. Ohne Kenntnis dieses Kontexts können Sie keinesfalls eine Sicherheitsklasse festlegen.

e) Annahme, Komponenten hätten eine bestimmte Sicherheitsklassen

Wie eben geschrieben, ist es nicht Ihre Aufgabe von Ihnen als Entwickler(in), die Sicherheitsklassifizierung der Software (Klassen A, B, C gemäß IEC 62304) durchzuführen. Ich schreibe das, weil mich regelmäßig Software-Ingenieure fragen, wie sie dabei vorgehen sollen. Insbesondere werden diese aufgefordert, die Sicherheitsklasse von Komponenten zu bestimmen.

Um es ganz klar zu sagen: Einer Software-Komponente lässt sich niemals per se eine Sicherheitsklasse zuweisen. Weder einer dll noch einer sonstigen Komponente.

Die Sicherheitsklasse leitet sich aus dem umgebenden Software-System ab. Und die Klasse des Softwaresystems aus der Risikoanalyse.

Lassen Sie mich wissen (z.B. via Webformular), wenn ich Ihnen bei der Sicherheitsklassifizierung helfen kann. Das tue ich gerne, schnell, vertraulich und meist sogar kostenlos.

f) In Architektur nicht nachvollziehbare Segregation

Was uns weiter auffällt, ist eine eher „legere“ Begründung, weshalb einzelne Komponenten eines Softwaresystems eine niedrigere Sicherheitsklasse als das Softwaresystem insgesamt haben. Ohne eine dokumentierte, der Realität entsprechende Architektur lässt sich das überhaupt nicht argumentieren.

g) Annahme, Software sei zu 100% fehlerhaft

Oft gibt es Diskussionen darüber, wie es sein kann, dass man im Rahmen der Risikoanalyse mit Wahrscheinlichkeiten arbeiten darf, man innerhalb der Software (gemäß IEC 62304) aber immer von 100% ausgehen müsse. Eine gute Frage!

Ein Risiko ist definitionsgemäß die Kombination aus Schweregrad und Wahrscheinlichkeit eines Schadens. Die IEC 62304 kennt in der Tat keine Wahrscheinlichkeiten, sondern nur die Sicherheitsklassen A (keine Verletzung möglich) bis C (schwere Verletzung oder Tod möglich).  Natürlich ist die Wahrscheinlichkeit eines Softwarefehlers nicht 100%. Die IEC 62304 will auch gar nicht die Risiken diskutieren. Sie will vielmehr die Hersteller dabei unterstützen, den Aufwand für die Dokumentation und das Testen von Software auf die sicherheitskritischen Bereiche der Software zu konzentrieren. Und dieser Aufwand soll nur von der Sicherheitsklasse, also den möglichen Folgen eines Fehlers innerhalb der Software, und nicht von der Wahrscheinlichkeit abhängen. Mehr sagt die IEC 62304 nicht.

Im Rahmen einer Risikoanalyse (z.B. auf FMEA oder FTA basierend) kann man durchaus auch andere Wahrscheinlichkeiten als 100% annehmen. Auch innerhalb der Software! Es sind zwei verschiedene Philosophien, die sich nicht gegenseitig verbieten.

h) Annahme, Sicherheitsklasse habe etwas mit in/direkten Schäden zu tun

Auch bei meinem Treffen mit den benannten Stellen diskutierten wir darüber. So ging es darum, ob der Grad der Direktheit, in dem eine Software zu einem Schaden beitragen kann, eine Auswirkung auf die Sicherheitsklasse hat.

Beispielsweise hat die Software eines Defibrilators einen hohen Grad der Direktheit, die Software zur Berechnung von Wechselwirkungen von Medikamenten einen niedrigeren Grad. Ein Auditor meinte, er würde darauf achten, dass die Medizinproduktehersteller die Ärzte nicht zu „Alibi man in the middle“ erklären, die in Wirklichkeit gar nicht richtig überblicken würden, was das Gerät macht.

Ich stimme zu, dass es unterschiedliche Grade der Direktheit gibt. Dass diese aber eine Auswirkung auf die Sicherheitsklasse haben, möchte ich hinterfragen. Der Grad der Direktheit hat eine Auswirkung auf die Wahrscheinlichkeit, dass ein Software-Fehler zu einem Schaden führt. Aber genau diese Wahrscheinlichkeit soll bei der Sicherheitsklassifizierung nicht betrachtet werden, sondern nur der Schweregrad.

Wie Sie tricksen können

Die IEC 62304 definiert ziemlich klar die verschiedenen Sicherheitsklassen für Software. Sie legt auch fest, dass die Sicherheitsklassen durch Hardware-Maßnahmen um eine Klasse von C auf B bzw. von B auf A reduziert werden kann. Trotzdem berichten uns die benannten Stellen, wie Hersteller einen „Gestaltungsspielraum“ suchen und finden.

Stellen Sie sich dazu folgendes Szenario vor:

Szenario 1: Maßnahme vor Sicherheitsklassifizierung

Ein Hersteller bringt ein Medizinprodukt in Verkehr, bei dem durch ein spezielles Design in Form einer Hardware ein Softwarefehler zu keinerlei Schäden für Patienten und Anwender führen kann. Die Software hat dann definitionsgemäß Sicherheitsklasse A.

Szenario 2: Maßnahme nach Sicherheitsklassifizierung

Ein Hersteller bringt das identische Medizinprodukt in Verkehr. Dieses Mal stellt er aber fest, dass ein Softwarefehler zu einem schweren Schaden führen kann. Die Software ist also Klasse C. Um das Risiko zu minimieren, wählt er dieselbe Maßnahme in Form einer Hardware, die einen Schaden für Patienten und Anwender ausschließt. Der Hersteller darf deshalb die Sicherheitsklasse der Software auf B reduzieren.

Reihenfolge entscheidend bei Klassifizierung gemäß IEC 62304?

Ist also bei der Festlegung der Software-Sicherheitsklassen gemäß IEC 62304 die Reihenfolge entscheidend und damit nur die Wahl der Argumentation? Die Vertreter der benannten Stellen, die bei mir zu Gast waren, haben sich auf folgende Linie geeinigt:

Wenn eine Maßnahme so offensichtlich ist, dass sie jeder Absolvent eines Studiums der Elektrotechnik oder des Maschinenbaus so wählen würde, kann man gemäß Szenario 1 argumentieren. Andernfalls handelt es sich um eine wirklich Maßnahme, die man im Übrigen auch in der Risikoanalyse explizit aufgeführt sehen will.

Typische Fallen beim Arbeiten gemäß Sicherheitsklasse A

Die IEC 62304 meint es gut mit uns Entwicklern medizinischer Software: Unkritische Komponenten — die der Sicherheitsklasse A — können wir nahezu undokumentiert lassen. Keine Architektur, keine Code-Reviews, keine dokumentierten Tests. Das ist wunderbar, oder? Doch Vorsicht! Das großzügige Unterlassen jeglicher Dokumentation bei Komponenten der Sicherheitsklasse A halte ich aus mehreren Gründen für problematisch.

Falle 1: Erfüllung der grundlegenden Anforderungen

MDD / IVD

Die Medizinprodukterichtlinie und damit das Medizinproduktegesetz verlangen eindeutig, dass die Hersteller Software-Lebenszyklusprozesse einhalten. Es gibt benannte Stellen, die der Meinung sind (ich übrigens auch), dass eine Software-Entwicklung, die auf die Erhebung und Dokumentation der Software-Anforderungen, auf das Modellieren einer Architektur, auf Code-Reviews oder Tests verzichtet, nicht diesem Anspruch genügt (Software-Lebenszyklusprozesse einzuhalten). Unabhängig davon, ob die Software in die Sicherheitsklasse A fällt.

Wenn eine Software-Komponente der Sicherheitsklasse A später einem anderen Kontext wiederverwendet wird und dadurch in eine höhere Sicherheitsklasse fällt, müssen Sie die komplette Dokumentation für diese Komponente nachholen. Das ist aufwendiger als das initial gewesen wäre.

MDR / IVDR

Die Medizinprodukteverordnung MDR und die In-Vitro Diagnostik Verordnung IVDR gehen einen Schritt weiter. Beide verlangen Folgendes:

1. IT-Sicherheit nach Stand der Technik
2. Software Verifizierung
3. Software Validierung (auch in der vorgesehenen Nutzungsumgebung, auch in der vorgesehenen technischen Umgebung (z.B. Hardware, Betriebssystem, Netzwerk)
4. Anforderungen an die technische Umgebung insbesondere an Netzwerke, Hardware, Betriebssysteme
5. Gebrauchsanweisung, die diese Anforderungen benennt
6. Beschreibung der Software und der Datenverarbeitung v.a. der Algorithmen (spezielle Forderung der IVDR)
7. Darstellung der Auslegungsphasen („Design Phases“)
8. Beschreibung der Produkte und Komponenten

Falle 2: Sicherheitsklassifizierung und Risikoanalyse

Wenn Sie eine Software, konkret ein Softwaresystem, sicherheitsklassifizieren, dann muss dem eine Risikoanalyse vorausgegangen sein. Es ist zwar nicht zwingend notwendig, die Wahrscheinlichkeiten genau zu betrachten, aber definitiv den Schweregrade möglicher Schäden. Nur wenn das Ergebnis dieser Analyse ergibt, dass gar keine Schäden durch die Software verursacht werden können, dann rechtfertigt das definitionsgemäß die Sicherheitsklasse A.

Aber gibt es wirklich keinen denkbaren Fall, bei dem etwas passieren könnte? Bei stand-alone Software der Sicherheitsklasse A sollte man sich fragen, ob man sicher sei, dass es sich überhaupt um ein Medizinprodukt handelt…

Sie müssen das Risikomanagement vor der Sicherheitsklassifizierung beginnen, es endet aber nicht damit. Beispielsweise müssen Sie im Rahmen einer Produktnachverfolgung im Feld überwachen, dass die eigenen Abschätzungen, die beispielsweise die Sicherheitsklasse A begründen, korrekt waren. Das versäumen die Firmen oft.

Falle 3: Sicherheitsklasse A versus Minor Level of Concern

Die FDA kennt keine Sicherheitsklasse A und v.a. keinen völlig undokumentierten und ungetesteten Code. Das wäre im Auditfall nicht nur eine „minor non-conformity“. Der Minor-Level-of-Concern, der der Sicherheitsklasse etwa entspricht, regelt den Umfang der einzureichenden Dokumentation, nicht der zu erstellenden! D.h. wenn Sie Ihr Produkt in den USA verkaufen wollen, gibt es für Sie keine Sicherheitsklasse A. Lesen Sie hier mehr zum Level of Concern.

Falle 4: Software-Qualität

Eine Architektur zu dokumentieren, Code zu testen und zu reviewen, all das sind Aktivitäten, die nicht nur dazu dienen sollten, regulatorische Anforderungen zu erfüllen. Es sind vielmehr bewährte Best Practices. Wer glaubt, wegen einer Sicherheitsklasse A darauf verzichten zu können, entwickelt entweder nur triviale Programme oder hat von professioneller Software-Entwicklung keine Ahnung. Die Konsequenzen dieses Vorgehens sind offensichtlich:

• Die Architektur wird mangelhaft sein, Änderungen an der Software werden überproportional aufwendig, die Konsequenzen sind kaum absehbar und führen häufig zu Fehlern.
• Die Software wird fehlhaft sein, was insbesondere bei Medizinprodukten zu Frust bei den Anwendern oder zu Risiken für Patienten führen — was bei Sicherheitsklasse A aber nicht der Fall sein dürfte.
• Die Entwicklung wird länger dauern, weil ein Try-Error beim Kodieren nie so effizient sein wird wie ein sorgfältiges Erheben (und Dokumentieren) der Anforderungen und Modellieren der Architektur.

Falle 5: Einhalten der IEC 62304?

Manche Firmen unterteilen die Software in verschiedene Sicherheitsklassen — ganz im Sinne der IEC 62304. Aber: Wissen Ihre Entwicklerkollegen überhaupt, welche Sicherheitsklasse die Komponente hat, an der sich gerade arbeiten? Manche Firmen hadern damit, dass die Entwickler überhaupt die eigenen Vorgaben beispielsweise der Software-Entwicklungs-SOP verstehen einhalten. Und jetzt sollen diese das abhängig von der Sicherheitsklasse können?

Fazit

Wenn Sie Software entwickeln, die Sie verkaufen möchten, dann entwickeln Sie allen Code gemäß Sicherheitsklasse C. Manchmal dauert der Streit über die richtige Sicherheitsklasse länger, als die Dokumente zu erstellen. Die meisten verstehen nur nicht, wie wenig Aufwand eine IEC 62304 und FDA-konforme Dokumentation bedeuten kann und v.a. wie viel Zeit man damit letztlich spart.

Wünschen Sie Unterstützung dabei, Ihre Software schnell und IEC 62304 bzw. FDA-konform zu entwickeln und zu dokumentieren? Mein Team und ich helfen gerne! Nehmen Sie Kontakt auf!

Kontakt aufnehmen