Prof. Dr. Christian Johner

Autor: Prof. Dr. Christian Johner

Inhaber der Johner Institut GmbH

IEC 62304 2. Ausgabe: IEC 62304:2015 ~ Alle Anwendungsbereiche und Änderungen

Donnerstag 20. Oktober 2016

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

Heißt sie wieder IEC 62304? Vielleicht IEC 62304 Version 2? Oder wird man sie unter dem Mantel der Health-Software-Normen als IEC 82304-2 publizieren?

Was bereits teilweise feststeht, sind die Änderungen, die die 2. Ausgabe der IEC 62304 vorsieht. Welche das sind, lesen Sie hier.

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.

Weiterführende Informationen

Sie finden hier einen ausführlichen Artikel zur IEC 82304-1.

Parallel schrieb das Normenkomitee an der 2. Ausgabe der IEC 62304, die jetzt als Entwurf vorliegt, den Ihnen dieser Artikel vorstellt. 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 ist noch nicht fertig gestellt und wird vielleicht als IEC 62304:2017 publiziert.)

IEC 62304 2. Ausgabe (2nd edition)

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“.

Definition Health Software“

„Software intended to be used specifically for managing, maintaining or improving health of individual persons, or the delivery of care“

Quelle: IEC 62304, 2. Ausgabe

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

Definition Medical Device Software

„Software system that has been developed for the purpose of being incorporated into the MEDICAL DEVICE being developed or that is intended for use as a medical device“

Quelle: IEC 62304, 2. Ausgabe

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:

IEC 62304 “Version 1.1”
Medical device software – Software life cycle processes
IEC 62304 “Version 2”

Health software – Software life cycle processes

Kommentar
1 Scope 1 Scope Nun „Health Software“, statt „Medical Device Software“
1.1 Purpose 1.1 Purpose
1.2 Field of application 1.2 Field of application
1.3 Relationship to other standards 1.3 Relationship to other standards
1.4 Compliance 1.4 Compliance
2 Normative references 2 Normative references
3 Terms and definitions 3 Terms and definitions Ergänzungen und Änderungen (siehe Kritik)
4 General requirements 4 General requirements
4.1 Legal and regulatory obligations Die Hersteller müssen alle relevanten regulatorischen Anforderungen bestimmen und erfüllen. Das fordert bereits die ISO 13485:2016.
4.1 Quality management system 4.2 Quality management system
4.2 Risk management 4.3 Risk management In begründeten Fällen ist die Konformität mit der ISO 14971 nicht mehr verlangt.
4.4 Security Risk management Security als Teil des Risikomanagements explizit verlangt. (siehe Kritik).
4.5 Usability engineering Hersteller muss Risiken aufgrund mangelnder Gebrauchstauglichkeit beherrschen. Die IEC 62366 ist nicht normativ gefordert.
4.3 Software safety classification 4.6 Software safety classification Kleine aber wesentliche Änderungen. Siehe unten bei Problem und bei Verbesseungen.
4.4 Legacy software 4.7 Legacy software
5 Software development process 5. Software development process
5.1 Software development planning 5.1 Software development planning
5.2 Software requirements analysis 5.2 Software requirements analysis
5.3 Software architectural design 5.3 Software architectural design
5.4 Software detailed design 5.4 Software detailed design
5.5 Software unit implementation and verification 5.5 Software unit implementation
5.6 Software integration and integration testing 5.6 Software integration and integration testing
5.7 Software system testing 5.7 Software system testing
5.8 Software release 5.8 Software release for utilization at a system level
6 Software maintenance process 6. Software maintenance process
6.1 Establish software maintenance plan 6.1 Establish software maintenance plan
6.2 Problem and modification analysis 6.2 Problem and modification analysis
6.3 Modification implementation 6.3 Modification implementation
7 Software risk management process 7 Software safety risk management process
7.1 Analysis of software contributing to hazardous situations 7.1 Analysis of software contributing to hazardous situations
7.2 Risk control measures 7.2 Risk control measures
7.3 Verification of risk control measures 7.3 Verification of risk control measures
7.4 Risk management of software changes 7.4 Risk management of software changes
8 Software configuration management process 8. Software configuration management process
8.1 Configuration identification 8.1 Configuration identification
8.2 Change control 8.2 Change control
8.3 Configuration status accounting 8.3 Configuration status accounting
9 Software problem resolution process 9 Software problem resolution process
9.1 Prepare problem reports 9.1 Prepare problem reports
9.2 Investigate the problem 9.2 Investigate the problem
9.3 Advise relevant parties 9.3 Advise relevant parties
9.4 Use change control process 9.4 Use change control process
9.5 Maintain records 9.5 Maintain records
9.6 Analyse problems for trends 9.6 Analyse problems for trends
9.7 Verify software problem resolution 9.7 Verify software problem resolution
9.8 Test documentation contents 9.8 Test documentation contents

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.

Weiterführende Informationen

Lesen Sie hier mehr zu Software-Einheiten, Software-Komponenten und Software-Systemen.

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.

Weiterführende Informationen

Lesen Sie hier mehr zur Software-Sicherheitsklassifizierung.

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
Weiterführende Informationen

Lesen Sie hier mehr zu Software-Anforderungen.

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?

Weiterführende Informationen

Lesen Sie hier mehr zum Thema Software-Architektur.

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.

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

Kategorien: Software & IEC 62304
Tags:

Kommentar schreiben