Softwareentwicklung nach EN 62304

Teil 1: Normkonformes Design

22. November 2017, 9:10 Uhr | Mark Pitchford, Technical Specialist bei LDRA
Auch die Software muss Normen erfüllen.
© Pixabay

Mit dem steigenden Anteil der durch Software realisierten Funktionalität in medizinischen Geräten sowie der zunehmenden Interoperabilität zwischen den Geräten wird es immer schwieriger, ihre Sicherheit nachzuweisen. Das gilt insbesondere für die Software selbst

Diesen Artikel anhören

In einer freien Interpretation der EU-Richtlinie ist ein Medizingerät, ein Produkt – Instrument, Apparat, Software, Material, etc. – das zur Diagnose, Behandlung, Überwachung, Untersuchung oder Kompensation von Krankheiten, Verletzungen sowie Behinderungen angewendet wird. Mit Ausnahme von Medikamenten schließt eine solche Definition nahezu den gesamten Markt an Medizinprodukten ein – inklusiver Software. Deren Zuverlässigkeit und die mit der zunehmenden Anzahl an technischen Geräten einhergehend Risiken sind zu einem lebenswichtigen Aspekt geworden.

Als Reaktion hierauf wurde im Jahr 2006 die Funktionssicherheits-Norm IEC 62304  (Medizingeräte-Software – Software-Lebenszyklus-Prozesse) herausgegeben. Sie legt einen Rahmen für die Lebenszyklus-Prozesse (Bild 1) von Medizingeräte-Software fest, die innerhalb eines und zwischen verschiedenen Projektteams verstanden und geteilt werden können. Konkret werden fünf Themenbereiche adressiert: Entwicklung, Wartung, Risikomanagement, Konfigurationsmanagement und Problemlösung. Die Norm gilt für Software, die selbst ein Medizingerät ist, die als Komponente, Teil oder Zubehör genutzt wird oder in der Produktion eines Medizingeräts zum Einsatz kommt.

Definition der Sicherheitsklassen

Die IEC 62304 verlangt vom Hersteller, dass er die Software einer Sicherheitsklasse zuordnet. Die Norm unterscheidet dabei drei Software-Sicherheitsklassifizierungen: Es sind keine Verletzungen oder gesundheitlichen Schäden möglich (Klasse A), es sind keine ernsten Verletzungen möglich (Klasse B) und es sind ernste Verletzungen oder Tod möglich (Klasse C). Wie das Projekt eingestuft wird, wirkt sich auch auf den Codeentwicklungs-Prozess aus – von der Planung über die Entwicklung, das Testen und die Verifikation bis zur Freigabe und darüber hinaus. Somit liegt es im Interesse der Medizingeräte-Hersteller, gleich im ersten Anlauf alles richtig zu machen, um teure und zeitaufwändige Nacharbeiten zu vermeiden.

In der Praxis wird jedes Unternehmen die Verifikation, die Integration und das Testen bei jeder Software anwenden – unabhängig von ihrer Sicherheitseinstufung. Die Gründlichkeit, mit der diese Aktivitäten durchgeführt werden, variiert jedoch erheblich. Zum Beispiel besagt die Norm: »Der Hersteller hat für jedes Modul des Softwarebausteins ein detailliertes Design zu entwickeln und zu dokumentieren«. Das gilt jedoch nur für Codes der Klasse C, nicht aber für die Klassen A und B.

Bild 1. Softwareentwicklungs-Prozesse und -Aktivitäten im Überblick
Bild 1. Softwareentwicklungs-Prozesse und -Aktivitäten im Überblick
© LDRA

  1. Teil 1: Normkonformes Design
  2. Softwareentwicklung mit der LDRA Tool Suite
  3. Design der Softwarearchitektur

Lesen Sie mehr zum Thema


Das könnte Sie auch interessieren

Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu LDRA Inc.