IEC 62304 2. Ausgabe: Alle Anwendungsbereiche und Änderungen

IEC 62304 2. Ausgabe: Selbst der Name der neusten Ausgabe der Norm ist derzeit noch unklar:

Historie der IEC 62304 2. Ausgabe

Die erste Version der Norm wurde als IEC 62304:2006 veröffentlicht. Die Norm blieb von einer redaktionellen Korrektur im Jahr 2008 abgesehen fast 10 Jahre unverändert. Erst 2015 folgte das Amendement 1 (A1:2015). Die konsolidierte und aktuelle Version der Norm ist die IEC 62304:2015. Diese Version wurde zwar noch nicht harmonisiert, stellt aber den Stand der Technik dar.

Das Normungsgremium stellte inzwischen auch die IEC 82304-1 fertig. Deren Ziel besteht darin, auch Health-Software, die kein Medizinprodukt oder ein Teil dessen ist, zu adressieren.

Parallel schrieb das Normenkomitee an der 2. Ausgabe der IEC 62304. Deren Status wurde jedoch zum Jahreswechsel 2021/2022 als „gelöscht“ markiert.

Damit gibt es folgende Normen:

• IEC 62304:2006 (mit Korrektur im Jahr 2008)
• IEC 62304:2015 (IEC 62304:2006 + Korrektur im Jahr 2008 + Amendement I im Jahr 2015). Diese Version wird auch als „Version 1.1“ bezeichnet.
• IEC 62304 2. Ausgabe. Diese Version lag zunächst als IEC/DIS 62304 2. Ausgabe als Entwurf vor. Der Status wurde jedoch auf „gelöscht“ geändert.

Anwendungsbereiche der IEC 62304 2. Ausgabe („2nd edition“)

Im Gegensatz zu den Vorgängernormen wendet sich die 2. Ausgabe an „Health Software“ und nicht mehr nur an „Medical Device Software“.

Die Health Software stellt eine Übermenge der Medical Device Software dar und beschränkt sich nicht auf Medizinprodukte.

Medical Device Software kann Software als Teil eines Medizinprodukts sein oder selbst ein Medizinprodukt darstellen (stand-alone Software).

Änderungen durch die 2. Ausgabe der IEC 62304

Die Kapitelstruktur lässt bereits erkennen, dass die Änderungen überschaubar bleiben:

Diese Übersicht lässt erkennen, dass keine Kapitel weggefallen, dafür einige Unterkapitel ergänzt worden sind. Zu den Änderungen zählen v.a. die folgenden:

Anwendungsbereich

Die „2nd edition“ der IEC 62304 soll weiterhin für standalone und embedded Software (also als Medizinprodukt oder Teil eines solchen) anwendbar bleiben. Allerdings soll sie zusätzlich auch für Health Software generell Anwendung finden. D.h. für Software in Fitnessgeräten und standalone Software wie Fitness-Apps beschreibt die IEC 62304 2. Ausgabe den Stand der Technik.

Für die Medizinproduktehersteller sind daher die Änderungen endlich.

Konsequenterweise ändert sich der Titel der Norm von „Medical Device Software“ auf „Health Software“.

Sicherheitsklassen

Die Definition der Sicherheitsklassen, wie sie bereits im Ammendment I der IEC 62304 veröffentlicht sind, finden Eingang in die IEC 62304 2nd edition. Eine kleine Änderung gibt es aber, die wir weiter unten diskutieren.

Neue Anforderungen an die Anforderungen

Die Software-Anforderungen (Kapitel 5.2) müssen die Aspekte Safety undSecurity explizit berücksichtigen. Das beinhaltet Anforderungen, um die Cyber-Security zu gewährleisten. Neu in diesem Zusammenhang ist der Begriff „Security Threat Management„.

Auch dem Thema Usability wird ein eigenes Unterkapitel gewidmet.

Risikomanagement

Die normative Forderung nach einem Risikomanagement nach ISO 14971 gibt die IEC 62304 2. Ausgabe auf. Der Hersteller kann andere Vorgehensmodelle begründen. Ob die benannten Stellen mitgehen, ist natürlich eine andere Sache.

Kritik

Die Änderungen in der „IEC 62304 2. Ausgabe“ sind überschaubar. Das vereinfacht den Umstieg sehr. An bewährten Konzepte hält die neuste Version der Norm fest. An alten Probleme leider auch.

Alte Probleme bleiben bestehen

a) Begriffsdefinitionen

Die Begriffe „Software Item“ und „Software Unit“ sind wir noch immer nicht los. Entwickler haben ein anderes Verständnis von „Software Unit“ und vermissen den Begriff der Software-Komponente. Aber vielleicht hätte eine Änderung zu viel „Unruhe“ verursacht.

b) Software-Sicherheitsklassifizierung

Die Regeln zum Bestimmen der Sicherheitsklasse wurden mit dem Amendement 1 deutlich verbessert. Leider enthält die Norm noch immer der Satz „Probability of a software failure shall be assumed to be 1.“ Den erläuternden Satz dazu (es geht nur darum, die Sicherheitsklasse zu bestimmen) überlesen Hersteller gerne.

c) Reihenfolgen

Sowohl die Abbildung 1 also auch die Kapitelreihenfolge legen dem Leser nahe, dass es eine Reihenfolge der folgenden Aktivitäten gibt:

1. Software-Entwicklungsplan erstellen
2. Software-Anforderungen bestimmen
3. Software-Architektur entwerfen

Das erscheint auf den ersten Blick als sinnvoll. Doch wie will man im Entwicklungsplan Werkzeuge festlegen, bevor die Anforderungen und die technische Umsetzung (Architektur) klar sind? Natürlich ist ein iteratives Vorgehen erlaubt. Aber manche Anforderungen wären in anderen Kapiteln besser aufgehoben.

Das gilt nicht nur für Werkzeuge wie zur Code-Analyse, sondern genauso auch für die zum Konfigurations- und Versionsmanagement.

d) Software-Anforderungen

Die IEC 62304 belässt das unsägliche Kapitel 5.2 unverändert. Die ursprünglichen Autoren hatten sich der ISO 9126 bedient. Dabei zerstörten Sie die Logik der ISO 9126 weitgehend. Dadurch ist ein Kapitel entstanden, das eine konzeptionelle Integrität vermissen lässt und teilweise irreführend ist. Beispiele:

• Funktionale und Performance Anforderungen sind orthogonal zueinander. Anforderungen an die Laufzeitumgebung ebenfalls. Die IEC 62304 wirft das wild durcheinander.
• Zählen die Interfaces zu anderen Systemen nicht zu den Inputs und Outputs?
• Anforderungen an „Data definition and databases“ gehören nur in den seltensten Fällen zu den Software-Anforderungen. Das sind Aspekte des Lösungsraums, konkret der Software-Architektur.
• Regulatorische Anforderungen zählen zu den Stakeholder-Anforderungen. Nur in Ausnahmefälle sollten diese unverändert in eine Software Requirements Specification (Software-Anforderungen) übernommen werden.

Die Auswirkungen dieses suboptimalen Kapitels, die wir täglich in der Praxis beobachten, sind:

• Vermischung von Stakeholder- und Produkt-/Software-Anforderungen. Die ISO 13485 weiß das zu unterscheiden.
• Vermischung von Software-Anforderungen und Software-Architektur
• Software-Anforderungen, die regulatorische Anforderungen einfach nur referenzieren
• Software-Anforderungen, die zwar die Aspekte der IEC 62304 abdecken, aber für eine Entwicklung als Input unbrauchbar sind. Teilweise schreiben selbst große Konzerne diese Dokumentation doppelt: Eine für die Auditoren und eine für die Entwickler.
• Unlogischer Aufbau der Software Requirements Specification und/oder eine Kapitelstruktur, die sich an der des Kapitels 5.2. orientiert

e) „Software Detailed Design“

Weiterhin fordert auch die 2. Ausgabe der IEC 62304 ein „detailed Design“ für jede Software-Einheit zu entwickeln. Wie soll das funktionieren? Eine Software-Einheit ist eine Software-Komponente, die der Hersteller nicht weiter zerlegt. Nun soll er für diese Komponente ein detailliertes Design entwickeln. Ein Design entspricht einer Fein-Architektur. Und Architektur ist definiert als die Zerlegung eines Systems in Komponenten und eine Beschreibung der Schnittstellen dazwischen.

Was erwartet die IEC 62304 von den Herstellern in Kapitel 5.4.2?

f) Akzeptanzkriterien für Software-Einheiten

Die Arbeiten an der IEC 62304 begannen vor weit mehr als 10 Jahren. Dass sich in dieser Zeit die Programmiersprachen weiterentwickelt haben, scheint an der Liste der Akzeptanzkriterien in Kapitel 5.5.4 vorbeigegangen zu sein. Ein Blick in den TIOBE-Index könnte hilfreich sein, um die wichtigsten Programmiersprachen zu identifizieren – und etwas spezifischere und zeitgemäßere Akzeptanzkriterien vorzuschlagen.

Ob eine Norm überhaupt solche technischen Details wie die Initialisierung von Variablen adressieren sollte, steht auf einem ganz anderen Blatt.

g) Agilität

Die Agilität ist bei den meisten Software-Entwicklungsabteilungen gelebte Realität. In den unterschiedlichsten Ausprägungen. Die FDA versucht zumindest mit dem TIR 45 eine Handlungsleitung zu geben. Die IEC 62304 (2. Ausgabe) erwähnt dieses Dokument nicht einmal.

Was macht sie stattdessen? Sie erwähnt zwar die Möglichkeit des agilen Entwickelns, verwendet aber das (fehlerhafte) Bild mit dem V-Model aus der IEC 60601-1. Was die Hersteller daraus schließen, liegt auf der Hand.

h) Problemlösungs- und Wartungsprozess

Das Zusammenspiel von Problemlösungsprozess, Wartungsprozess und Konfigurationsmanagementprozess beschreibt die Norm nicht wirklich gut. Erst im informativen Anhang wird klar, wie die Autoren die Abgrenzung insbesondere von Problemlösungs- und Wartungsprozess gemeint haben.

Viele Hersteller verstehen nicht wirklich, weshalb beide Prozesse Anforderungen an die Problemberichte stellen. Es ist ihnen unklar, im Rahmen welches Prozesses diese Berichte zu erstellen, auszuwerten und zu berücksichtigen sind.

Neue Probleme werden eingeführt

Leider führt die neuste Version der Norm neue Probleme ein:

a) Begriffsdefinitionen

Nachdem das Amendement I endlich die Definitionen der Begriffe wie Schaden, Gefährdung und Gefährdungssituation aus der ISO 14971 übernommen hatte, fällt der Normenentwurf wieder auf die ISO/IEC Guide 51:2014 zurück. Das macht es den Herstellern nicht einfacher.

b) Security Risk Management

Weshalb das Risikomanagement in ein Risikomanagement und ein „Security Risk Management“ zerlegt wird, erschließt sich nicht sofort. Natürlich wird dieser Aspekt immer wichtiger. Aber so lässt sich die Forderung missverstehen, als ob ein zweites Risikomanagement notwendig sei.

Genauso ist der Verweis auf die ISO 27000 irreführend. Auch wenn sich die Konzepte überlappen: Die IT-Security eines Produkts ist nicht das Gleiche wie die IT-Security einer Organisation.

c) Risikomanagement nach ISO 14971 verbindlich?

Einerseits besteht die neue IEC 62304 nicht in jedem Fall auf einer Konformität mit der ISO 14971. Andererseits müssen die Maßnahmen zur Risikobeherrschung in Übereinstimmung mit der ISO 14971 festgelegt, implementiert und dokumentiert werden.

Verbesserungen

Die 2. Ausgabe hält einige Verbesserungen für die Hersteller bereit:

a) Regularien

Die Änderungen rücken die 2. Ausgabe der IEC 62304 noch näher an die Anforderungen der FDA.

Das Usability Engineering wird nun explizit gefordert. Gleichzeitig wird die IEC 62366 nicht normativ gefordert. Das ergibt Sinn, da sich die 2. Ausgabe der IEC 62304 nicht nur an Medizinprodukte-Software wendet.

b) Sicherheitsklassifizierung

Im Entscheidungsbaum steht nicht mehr 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 wird weiterer Erläuterungen bedürfen. Oder einer besseren Version 2.0.

Danke an Dr. Markus Bentrup für die Anregung!

Zeitschiene

Ob das Gremium (u.a. DKE) es 2016 schaffen wird, die Arbeiten an der IEC 62304 2. Ausgabe abzuschließen, steht noch nicht ganz fest, ist aber geplant. Dann wäre mit einer Fertigstellung der Norm nicht vor 2017 zu rechnen.

Und ob sich Brüssel aufraffen kann, überhaupt wieder Normen zu harmonisieren, ist derzeit offen.

Da die Änderungen insgesamt endlich sind und die Hersteller viele Aspekte wie die neuen Sicherheitsklassen oder das Thema Cybersecurity bereits heute beachten sollten, halte ich ein geduldiges Abwarten für die beste Strategie.

Fazit

Von einer 2. Ausgabe der IEC 62304 zu sprechen ist vielleicht etwas hoch gegriffen. Die Änderungen durch das Amendement 1 waren bedeutsamer. Aber Version 1.2 hört sich nicht ganz so ambitiös wie Version 2 an.

Wer den Scope auf Health Software ausdehnen will, sollte mehr leisten, als den Begriff „Medical Device Software“ durch „Health Software“ zu ersetzen. Die Norm zielt mit dem weitgehend gleichen Instrumentarium auf Software, die ein Medizinprodukt oder ein Teil dessen ist, und auf sonstige Software. Das scheint meiner Meinung nach entweder noch nicht ganz ausgegoren oder etwas undifferenziert zu sein.

Weil die Änderungen so überschaubar sind, wird den Herstellern das Upgrade relativ schnell und einfach gelingen. Die Chancen auf einen Quantensprung und auf eine Behebung alter Probleme scheint die 2. Ausgabe der IEC 62304 zu vertun. Es bleibt trotzdem meine Lieblingsnorm.

Wir unterstützen Sie dabei, Ihre Software gesetzeskonform zu entwickeln sowie schnell und sicher durch die Zulassung zu bringen. Nehmen Sie direkt Kontakt auf!

Kontakt aufnehmen

Versionshistorie:

• 6.1.2022: Hinweis zum Stand aktualisiert