Software & IEC 62304

Die IEC 62304 ist eine in Europa harmonisierte¹ Norm für „Medizingeräte-Software“. Sie trägt den Titel „Medizingeräte-Software – Software-Lebenszyklus-Prozesse“ und stellt Mindestanforderungen an Prozesse wie die Entwicklung und Wartung der Software.

¹ Die IEC 62304 war unter der MDD und IVDD harmonisiert und ist unter der MDR und IVDR zur Harmonisierung vorgesehen.

1. Artikel zu Aspekten der IEC 62304

a) Anwendungsbereich

Die IEC 62304 ist anwendbar bei

• eigenständiger (Standalone-) Software, die als Medizinprodukt zählt (Software as Medical Device), wie
  • Mobile Medical Apps oder
  • klinische Informationssysteme, sowie
• Software, die Teil eines Medizinprodukts ist (Software in a Medical Device).

Weil die IEC 82304-1 die Norm referenziert, ist die IEC 62304 sogar bei  Health Software relevant.

b) Regulatorischer Kontext

Qualifizierung und Klassifizierung

• Qualifizierung von Software gemäß MDR: Medizinprodukt ja/nein und Risikoklassen gemäß Anhang VIII
• Qualifizierung und Klassifizierung von Software gemäß IVDR
• Software der Klasse I (MDR)
• Klassifizierung gemäß MDR (insbesondere Regel 11)

Beachten Sie auch die Fachartikel zu den Lebenszyklus-Aktivitäten unter Punkt 2.

Besondere Anforderungen an Software

• Allgemeine Anforderungen der MDR
• Allgemeine Anforderungen der IVDR
• UDI–Anforderung der MDR (an standalone Software)
• Klinische Bewertung von Software
• Regulatorische Anforderungen an die IT-Sicherheit
• MDCG-Leitlinien z.B. die MDCG 2019-11 und die MDCG 2023-4

c) Konzepte der Norm

• Software-Sicherheitsklasse
• SOUP (Software of Unknown Provenance)
• Wahrscheinlichkeiten von Fehlern
• Validierung, insbesondere Validierung des Produkts und Validierung der Werkzeuge

2. Artikel zu den Lebenszyklus-Aktivitäten

Die folgenden Artikel sind nach den Kapiteln der IEC 62304 gruppiert.

Kapitel 5.1: Entwicklungsplan

Als Erstes verlangt die Norm, einen Entwicklungsplan zu erstellen. In diesem Zusammenhang sind diese Artikel lesenswert:

• Was sind Lebenszyklus-Prozesse?
• Agile Entwicklung (z. B. nach Scrum) und andere Entwicklungsprozesse wie das V-Modell
• Abgrenzung von Entwicklungsplan und Entwicklungsprozess
• Unterschied von Qualitätssicherung und Tests

Kapitel 5.2: Anforderungen

Aus den Anforderungen des Produkts oder den Stakeholder-Anforderungen muss der Hersteller die Software-Anforderungen ableiten.

• Ableiten der Software-Anforderungen aus den Kunden-Anforderungen
• Zusammenspiel mit Qualitätseigenschaften gemäß ISO 25010

Kapitel 5.3 und 5.4: Architektur

In der Architektur legt der Hersteller den „Bauplan“ fest.

• Normenkonforme Dokumentation der Architektur und der Schnittstellen
• Anforderungen an die Entwicklung von Komponenten
• Detailliertes Design bei Software

Kapitel 5.5 bis 5.7: Implementierung und Verifizierung

Gemäß diesem Bauplan ist dann die Software zu implementieren und zu verifizieren. Die Validierung ist nicht Gegenstand der IEC 62304, sondern der IEC 82304-1.

• Tipps zum Code Review (Kapitel 5.5)
• Anforderungen an das Testing, z. B. an
  • Unit-Tests (Kapitel 5.5),
  • Integrationstests (Kapitel 5.6),
  • Regressionstests und Systemtests (Kapitel 5.7)
• Hinweise zu Kodierrichtlinien und zur statischen Code-Analyse

Kapitel 5.8: Freigabe

Die Entwicklung und Wartung schließt mit der Freigabe, die aber nicht mit der Produktfreigabe verwechselt werden darf:

• Software-Freigabe, ein beliebtes Missverständnis

Weitere Forderungen und Prozesse der Norm

• Umgang mit Änderungen (Software-Wartung und Bugfixes)
• Software-Konfigurationsmanagement
• Design Changes

3. Regulatorische Bedeutung der IEC 62304

a) Nachweis der GSPR (MDR/IVDR)

Die Medizinprodukte-Verordnungen MDR und IVDR formulieren jeweils in Anhang I die sogenannten „Allgemeinen Sicherheits- und Leistungsanforderungen“ (engl.: General Safety and Performance Requirements, GSPR).

Eine dieser Forderungen lautet, dass „bei Produkten, zu deren Bestandteilen Software gehört, oder bei Produkten in Form einer Software“ die

„Software entsprechend dem Stand der Technik entwickelt und hergestellt [wird], wobei die Grundsätze des Software-Lebenszyklus, des Risikomanagements einschließlich der Informationssicherheit, der Verifizierung und der Validierung zu berücksichtigen sind.“

Das ist eine gesetzliche Anforderung. Ein Verstoß dagegen kann mit Geld- und Freiheitsstrafen belegt werden.

Hersteller von Medizingeräten bzw. Medizinprodukten sollten die Konformität mit diesen Anforderungen nachweisen, indem sie harmonisierte Normen einhalten.

Die Norm IEC 62304 ist die speziell für die Lebenszyklus-Prozesse harmonisierte¹ Norm. Eine weitere Norm ist die IEC 82304-1.

b) „Consensus Standard“ der FDA

Die FDA erkennt die IEC 62304 als „Consensus Standard“ an. Sie erwartet aber keine Konformität mit dieser Norm. Allerdings stellt die Behörde z. B. in ihren Leitlinien zur Software Validation vergleichbare Anforderungen.

c) IEC 62304 Zertifizierung

Einige Prüfstellen bieten eine „Zertifizierung nach IEC 62304“ an. Hersteller sollten sich der Grenzen dieser Zertifizierungen bewusst sein:

1. Eine Zertifizierung hat keinen so hohen Wert, v. a. nicht, wenn die Prüfinstitute für diese Zertifizierung nicht akkreditiert sind. Denn solch ein Zertifikat könnte jeder ausstellen.
2. Die IEC 62304 ist eine Prozessnorm, keine Produktnorm. Daher muss eine Prüfung die Prozesskonformität beurteilen und nicht das Produkt. Das Zertifikat sagt also nicht direkt etwas über die Produktgüte aus.
3. Die Behauptung einiger Prüfstellen, dass die Zertifizierung dabei helfe, beim Testen Zeit zu sparen, ist nicht nachvollziehbar. Hersteller können durch Testautomatisierung sowie durch den Einsatz von geeigneten Werkzeugen und Verfahren Zeit sparen. Die Zertifizierung senkt den Testaufwand aber nicht.
4. Im Rahmen einer Zertifizierung nach ISO 13485, die von akkreditierten Stellen vorgenommen wird, müssen Auditoren ohnehin indirekt die Konformität mit IEC 62304 prüfen, zumindest exemplarisch.

Das Johner Institut rät nicht generell von einer Zertifizierung nach IEC 62304 ab. Aber jeder sollte die „Beweiskraft“ dieser Zertifikate kennen.