IEC 62304 in der Praxis: Software-Lebenszyklus für Medizinprodukte

Was ist die IEC 62304?

Die IEC 62304 ist die internationale Norm für den Software-Lebenszyklus von Medizinprodukten. Sie beschreibt, welche Prozesse ein Hersteller für Entwicklung und Wartung von medizinischer Software nachweisen muss und wie tief die Dokumentation je nach Risiko gehen soll. Die gültige Fassung ist die IEC 62304:2006 mit dem Amendment 1 von 2015, in Europa übernommen als EN 62304.

Die Norm ist kein Handbuch, wie man Code schreibt. Sie fragt nicht, ob Sie React, Kotlin oder C verwenden. Sie fragt, ob Sie nachweisen können, dass Ihre Software geplant, spezifiziert, entworfen, getestet, freigegeben und gewartet wird, und zwar so, dass Risiken für Patienten und Anwender beherrscht sind. Wer diese Nachweise sauber führt, hat bei der benannten Stelle eine gute Ausgangslage. Wer sie nachträglich zusammensucht, zahlt dafür mit Zeit und Nerven.

Für Hersteller in der EU und in der Schweiz ist die Norm faktisch gesetzt. Die Medizinprodukteverordnung (EU) 2017/745, kurz MDR, verlangt in Anhang I, Abschnitt 17.2, dass Software nach dem Stand der Technik entwickelt wird, unter Berücksichtigung von Lebenszyklus, Risikomanagement, Informationssicherheit, Verifizierung und Validierung. Die IEC 62304 ist der etablierte Weg, genau das zu zeigen. Eine kompakte Begriffserklärung finden Sie im Glossar unter IEC 62304.

Zur Einordnung: An einer überarbeiteten zweiten Ausgabe der Norm wird seit Jahren gearbeitet. Prüfen Sie vor Projektstart, welche Fassung Ihre benannte Stelle erwartet.

Für wen sie gilt

Die IEC 62304 gilt für jede Software, die selbst ein Medizinprodukt ist oder Teil eines Medizinprodukts. In der Praxis sind das drei Gruppen:

• Software als Medizinprodukt (SaMD): eigenständige Software mit medizinischer Zweckbestimmung, etwa eine App zur Therapiebegleitung, eine Web-Anwendung zur Auswertung von Messdaten oder ein Algorithmus zur Unterstützung einer Diagnose.
• Embedded Software: Firmware in einem Gerät, zum Beispiel in einer Infusionspumpe, einem Blutzuckermessgerät oder einem Beatmungsgerät.
• Software als Zubehör oder Bestandteil einer Plattform: Backend-Dienste, Web-Portale für Fachpersonen oder Mobile Apps, die zusammen ein Medizinprodukt bilden.

Ob Ihre Software überhaupt ein Medizinprodukt ist, entscheidet die Zweckbestimmung, nicht die Technologie. Wie Sie das prüfen und welche Klasse nach MDR Regel 11 in Frage kommt, beschreiben wir in der Checkliste Software als Medizinprodukt.

Wichtig ist auch, was die Norm nicht abdeckt. Die Validierung des Gesamtprodukts im klinischen Kontext, die Gebrauchstauglichkeit und das Qualitätsmanagementsystem regeln andere Normen, vor allem IEC 62366-1 und ISO 13485. Für eigenständige Gesundheitssoftware kommt häufig die IEC 82304-1 dazu, die Anforderungen an das Produkt als Ganzes stellt und für den Software-Teil auf die IEC 62304 verweist.

Die Software-Sicherheitsklassen A, B, C und wie man klassifiziert

Das zentrale Instrument der Norm ist die Software-Sicherheitsklasse. Sie bestimmt, welche Prozessschritte und Dokumente Sie liefern müssen. Die Klassen richten sich nach dem schlimmsten Schaden, zu dem ein Fehler der Software beitragen kann:

• Klasse A: Die Software kann zu keiner Gefährdungssituation beitragen, oder das resultierende Risiko ist durch Massnahmen ausserhalb der Software auf ein akzeptables Mass reduziert.
• Klasse B: Die Software kann zu einer Gefährdungssituation beitragen, die zu einem unvertretbaren Risiko führt, und der mögliche Schaden ist eine nicht schwerwiegende Verletzung.
• Klasse C: Wie Klasse B, aber der mögliche Schaden ist Tod oder eine schwere Verletzung.

So gehen Sie bei der Klassifizierung vor

1. Gefährdungsanalyse nach ISO 14971 durchführen. Welche Gefährdungssituationen kann die Software auslösen oder mitverursachen? Falsche Anzeige eines Messwerts, verspätete Alarmierung, verwechselte Patientendaten.
2. Softwareversagen als gegeben annehmen. Die Norm verlangt, dass Sie bei der Klassifizierung nicht mit einer niedrigen Fehlerwahrscheinlichkeit der Software argumentieren. Sie gehen davon aus, dass die Software versagen kann.
3. Externe Risikokontrollmassnahmen berücksichtigen. Seit dem Amendment 2015 dürfen Massnahmen ausserhalb des Software-Systems die Klasse senken, etwa eine unabhängige Hardware-Abschaltung oder ein klinischer Arbeitsablauf, der jeden Wert von einer Fachperson prüfen lässt. Diese Massnahmen müssen dokumentiert und wirksam sein.
4. Schwere des möglichen Schadens bewerten. Daraus ergibt sich Klasse B oder C.
5. Begründung festhalten. Die Klassifizierung und ihre Herleitung gehören in die Dokumentation und werden im Audit geprüft.

Segregation: nicht alles muss Klasse C sein

Ein Software-System kann in Software-Elemente zerlegt werden, die unterschiedlich klassifiziert sind. Das lohnt sich, wenn nur ein kleiner Teil sicherheitsrelevant ist, zum Beispiel ein Berechnungsmodul in einer sonst administrativen Anwendung. Voraussetzung ist, dass Sie in der Architektur eine wirksame Trennung nachweisen können. Ohne diesen Nachweis gilt die höchste Klasse für das ganze System.

Verwechseln Sie die Sicherheitsklasse nicht mit der Risikoklasse nach MDR (I, IIa, IIb, III). Eine Software der MDR-Klasse IIa kann Sicherheitsklasse A, B oder C haben. Die beiden Einstufungen folgen unterschiedlichen Logiken und werden getrennt begründet.

Die Prozesse im Überblick

Kapitel 5 der Norm beschreibt den Entwicklungsprozess in acht Aktivitäten. Welche davon Sie in welcher Tiefe dokumentieren, hängt von der Sicherheitsklasse ab. Grob gilt: Klasse A braucht vor allem Planung, Anforderungen, Systemtest und Freigabe. Klasse B ergänzt Architektur, Einheitenverifikation und Integrationstests. Klasse C verlangt zusätzlich einen Detailentwurf und strengere Akzeptanzkriterien für Software-Einheiten. Die genaue Zuordnung pro Abschnitt steht in der Norm und sollte in Ihrem Entwicklungsplan explizit aufgeführt sein.

1. Planung der Software-Entwicklung

Der Entwicklungsplan legt fest, welche Prozesse, Werkzeuge, Standards und Ergebnisse gelten. Er beschreibt auch, wie Sie verifizieren, wie Sie Konfigurationen verwalten und wie der Plan mit Risikomanagement und Systementwicklung verknüpft ist. Der Plan ist ein lebendes Dokument und wird fortgeschrieben.

2. Analyse der Software-Anforderungen

Funktionale Anforderungen, Leistung, Schnittstellen, Alarme, Sicherheitsanforderungen, Datenschutz, Anforderungen aus dem Risikomanagement und aus der Gebrauchstauglichkeit. Jede Anforderung muss prüfbar, eindeutig und rückverfolgbar sein.

3. Software-Architektur

Die Architektur zeigt, aus welchen Software-Elementen das System besteht, wie sie zusammenspielen und wo SOUP eingesetzt wird. Hier dokumentieren Sie auch die Trennung von Elementen unterschiedlicher Sicherheitsklassen.

4. Detailentwurf

Die Zerlegung in Software-Einheiten und, für Klasse C, ein Detailentwurf jeder Einheit mit ihren Schnittstellen. Das Ziel ist, dass die Implementierung aus dem Entwurf nachvollziehbar ist.

5. Implementierung und Verifikation der Einheiten

Code schreiben, Einheiten verifizieren und Akzeptanzkriterien festlegen. In der Praxis sind das Code-Reviews, statische Analyse und Unit-Tests, die gegen definierte Kriterien laufen.

6. Integration und Integrationstest

Die Einheiten werden nach Plan zusammengeführt und getestet. Dazu gehört ein Regressionstest, damit Änderungen keine bestehenden Funktionen beschädigen.

7. Software-Systemtest

Der Systemtest prüft, ob jede Software-Anforderung erfüllt ist. Testfälle, Ergebnisse, Abweichungen und die verwendete Version werden dokumentiert.

8. Freigabe

Vor der Freigabe prüfen Sie, dass die Verifikation vollständig ist, dass bekannte Restfehler bewertet sind und dass Sie die freigegebene Version reproduzierbar erstellen und archivieren können.

Wartung, Risikomanagement, Konfigurationsmanagement, Problemlösung

Neben der Entwicklung verlangt die IEC 62304 vier unterstützende Prozesse. In Audits werden sie oft gründlicher geprüft als die Entwicklung selbst, weil sie zeigen, ob ein Hersteller ein Produkt über Jahre sicher betreiben kann.

Wartung (Kapitel 6)

Ein Wartungsplan legt fest, wie Rückmeldungen aus dem Markt aufgenommen, bewertet und in Änderungen überführt werden. Jede Änderung durchläuft wieder die relevanten Entwicklungsschritte. Für Software, die monatlich Updates erhält, muss dieser Prozess schlank und wiederholbar sein.

Risikomanagement (Kapitel 7)

Die IEC 62304 setzt ein Risikomanagement nach ISO 14971:2019 voraus und ergänzt es um software-spezifische Aspekte: Wie kann die Software zu einer Gefährdungssituation beitragen, welche Risikokontrollmassnahmen sind in der Software umgesetzt, und wie wird deren Wirksamkeit verifiziert? Auch jede Änderung wird auf ihre Risikowirkung geprüft.

Konfigurationsmanagement (Kapitel 8)

Sie müssen jederzeit sagen können, welche Version welcher Komponente in welchem Release steckt, inklusive aller SOUP. Mit Git, Tags, reproduzierbaren Builds und Lockfiles ist das heute gut lösbar, sofern es konsequent gelebt wird.

Problemlösung (Kapitel 9)

Fehler werden erfasst, untersucht, auf ihre Sicherheitsrelevanz bewertet, behoben und verifiziert. Ein Issue-Tracker genügt als Werkzeug, wenn die Pflichtfelder und der Ablauf definiert sind und Trends ausgewertet werden.

SOUP/OTS-Software: Open Source und npm-Pakete

SOUP steht für «Software of Unknown Provenance», also Software, die nicht nach IEC 62304 entwickelt wurde oder deren Entwicklungsnachweise Ihnen fehlen. Dazu gehören Betriebssysteme, Datenbanken, Frameworks, Cloud-SDKs und jede Open-Source-Bibliothek. OTS («Off-the-Shelf») ist der verwandte Begriff aus dem FDA-Umfeld.

In einer modernen Web- oder Mobile-Anwendung kommen schnell mehrere hundert npm-Pakete zusammen, die meisten davon als transitive Abhängigkeiten. Das ist kein Ausschlusskriterium, aber es verlangt Disziplin. Dokumentiert werden müssen typischerweise:

• Identifikation: Name, Hersteller oder Projekt und eine eindeutige Version. Das gilt für alle Sicherheitsklassen.
• Funktions- und Leistungsanforderungen: Wofür setzen Sie die Komponente ein und was muss sie leisten? Ab Klasse B.
• Benötigte Umgebung: Welche Hardware und Software braucht die SOUP, um korrekt zu funktionieren? Ab Klasse B.
• Bekannte Fehler: Veröffentlichte Anomalien und Sicherheitslücken müssen bewertet werden, ob sie zu einer Gefährdungssituation beitragen können. Ab Klasse B.

Bewährt hat sich eine Unterscheidung in zwei Ebenen. Direkte Abhängigkeiten mit fachlicher Wirkung, etwa eine Charting-Bibliothek, die Messwerte darstellt, oder eine Krypto-Bibliothek, erhalten eine eigene Bewertung. Die vollständige Liste aller Pakete inklusive transitiver Abhängigkeiten wird automatisiert als Software-Stückliste (SBOM) pro Release erzeugt und gegen Schwachstellendatenbanken geprüft. Wie genau Sie diese Ebenen abgrenzen, legen Sie im Entwicklungsplan fest und begründen es.

Ein Nebeneffekt: Eine gepflegte SBOM hilft auch bei den Cybersecurity-Anforderungen der MDR und bei Normen wie IEC 81001-5-1.

Traceability von Anforderung bis Test

Rückverfolgbarkeit ist das Rückgrat der Dokumentation. Auditoren wählen eine Anforderung aus und wollen sehen, woher sie kommt und wie sie verifiziert wurde. Die Kette sieht typischerweise so aus:

1. Zweckbestimmung und Nutzeranforderungen
2. System- und Software-Anforderungen
3. Risikokontrollmassnahmen aus der ISO-14971-Analyse
4. Architektur- und Designelemente
5. Code-Änderungen, Pull Requests und Reviews
6. Unit-, Integrations- und Systemtests mit Ergebnissen

Die Kette muss in beide Richtungen funktionieren: von der Anforderung zum Test und vom Test zurück zur Anforderung. Tests ohne Anforderung sind kein Problem, Anforderungen ohne Test schon.

In der Praxis lohnt es sich, die Traceability nicht in Tabellen von Hand zu pflegen. Eindeutige Kennungen für Anforderungen, die in Tickets, Commit-Nachrichten und Testnamen referenziert werden, erlauben eine automatisch erzeugte Matrix pro Release. Das spart Arbeit und reduziert Lücken, die sonst erst im Audit auffallen.

Agil und IEC 62304: wie das zusammengeht

Ein verbreitetes Missverständnis ist, dass die IEC 62304 ein Wasserfallmodell verlangt. Das stimmt nicht. Die Norm definiert Aktivitäten und Ergebnisse, nicht deren Reihenfolge. Der technische Bericht AAMI TIR45 beschreibt ausführlich, wie agile Methoden mit den Anforderungen vereinbar sind. So sieht das konkret aus:

Sprints als Entwicklungszyklen

Jeder Sprint durchläuft die relevanten Aktivitäten im Kleinen: Anforderungen verfeinern, Design anpassen, implementieren, verifizieren. Die Dokumentation wächst inkrementell mit dem Produkt, statt am Ende nachgeschrieben zu werden.

Definition of Done als Qualitätstor

Eine Story ist erst fertig, wenn Anforderung und Risikobezug verlinkt sind, der Code reviewt ist, Tests grün sind, die Architekturdokumentation nachgeführt ist und die SOUP-Liste bei neuen Abhängigkeiten aktualisiert wurde. So entsteht die Evidenz als Teil der normalen Arbeit.

Pull-Request-Reviews als Verifikation

Ein Pull Request mit dokumentiertem Review durch eine zweite Person, verlinkt auf die Anforderung, ist ein belastbarer Nachweis der Einheitenverifikation. Voraussetzung ist, dass die Review-Kriterien schriftlich festgelegt sind und die Plattform die Historie unveränderbar speichert.

CI/CD als Evidenzfabrik

Die Pipeline führt bei jedem Build Tests, statische Analyse und Schwachstellen-Scans aus und archiviert die Ergebnisse zusammen mit dem Commit. Aus diesen Artefakten lassen sich Testberichte und Release-Nachweise automatisch erzeugen. Werkzeuge, die Sie dafür nutzen, sollten nach ISO 13485 validiert sein, soweit sie Qualitätsnachweise erzeugen. Wie das in einem QMS eingebettet wird, beschreiben wir im Artikel ISO 13485 für agile Software-Teams.

Freigabe bewusst vom Deployment trennen

Kontinuierliches Deployment in eine Testumgebung ist unproblematisch. Die Freigabe einer Version für den Markt bleibt ein formaler Schritt mit Checkliste, Unterschriften und Archivierung. Diese Trennung sollten Sie im Entwicklungsplan klar beschreiben.

Typische Audit-Findings

Aus Audits und Gesprächen mit Regulatory-Teams kennen wir wiederkehrende Schwachstellen. Keine davon ist exotisch, aber jede kostet Zeit, wenn sie spät auffällt:

• Klassifizierung ohne nachvollziehbare Begründung oder mit Argumenten zur geringen Fehlerwahrscheinlichkeit der Software.
• Lücken in der Traceability, etwa Risikokontrollmassnahmen ohne Verifikation oder Anforderungen ohne Test.
• Unvollständige SOUP-Liste oder fehlende Bewertung bekannter Anomalien.
• Entwicklungsplan und gelebte Praxis weichen voneinander ab. Der Plan beschreibt einen Prozess, den das Team längst anders macht.
• Änderungen ohne Auswirkungsanalyse, besonders bei schnellen Bugfixes nach dem Release.
• Keine reproduzierbaren Builds, sodass eine ältere Version nicht exakt wiederhergestellt werden kann.
• Nicht validierte Werkzeuge, die Qualitätsnachweise erzeugen, etwa eine selbst gebaute Testauswertung.
• Problemlösung ohne Trendanalyse: Fehler werden behoben, aber nicht systematisch ausgewertet.

Werkzeuge und Vorlagen

Die IEC 62304 schreibt keine Werkzeuge vor. Bewährt hat sich eine Kombination aus Werkzeugen, die das Team ohnehin nutzt, ergänzt um klare Regeln:

• Versionskontrolle mit Git und einer Plattform mit geschützten Branches, Pflicht-Reviews und unveränderbarer Historie.
• Issue-Tracker für Anforderungen, Änderungen und Probleme, mit definierten Feldern für Sicherheitsrelevanz und Risikobezug.
• CI/CD-Pipeline mit automatisierten Tests, statischer Analyse, SBOM-Erzeugung und archivierten Ergebnissen.
• Dokumente als Code: Architektur, Pläne und Anforderungen in Markdown im Repository, versioniert und reviewt wie Code.
• Spezialisierte eQMS- oder ALM-Werkzeuge, wenn das Unternehmen elektronische Signaturen und integrierte Traceability braucht.

Vorlagen für Entwicklungsplan, Anforderungsspezifikation, Architektur, SOUP-Liste und Testbericht gibt es von Beratern, Verbänden und als Open-Source-Projekte. Sie sind ein guter Start, müssen aber an Ihre Prozesse angepasst werden. Eine Vorlage, die nicht zur gelebten Praxis passt, erzeugt genau das Audit-Finding, das sie verhindern sollte.

Was das kostet und wie man es klein hält

Medizinische Software-Entwicklung nach IEC 62304 ist teurer als die Entwicklung einer vergleichbaren Anwendung ohne regulatorische Anforderungen. Der Mehraufwand entsteht nicht beim Programmieren, sondern bei Spezifikation, Verifikation, Dokumentation und Reviews. Wie gross er ausfällt, hängt vor allem von der Sicherheitsklasse, der Architektur und dem Reifegrad der Prozesse ab. Eine allgemeine Einordnung von Kostentreibern finden Sie im Artikel über die Kosten von Individualsoftware.

Diese Hebel halten den Aufwand erfahrungsgemäss am kleinsten:

• Zweckbestimmung eng fassen. Jede zusätzliche medizinische Funktion kann Klasse und Aufwand erhöhen. Starten Sie mit dem kleinsten sinnvollen Umfang.
• Sicherheitsrelevante Teile isolieren. Eine Architektur mit klar getrennten Elementen erlaubt es, nur einen kleinen Teil nach Klasse C zu entwickeln.
• Evidenz automatisieren. Traceability, Testberichte und SBOM aus der Pipeline statt aus Tabellen.
• Abhängigkeiten bewusst wählen. Weniger und gut gepflegte Bibliotheken bedeuten weniger SOUP-Aufwand über die ganze Lebensdauer.
• Früh mit der benannten Stelle sprechen. Offene Fragen zur Klassifizierung oder zur Dokumentationstiefe sind vor der Einreichung günstiger zu klären als danach.
• Prozesse klein anfangen. Ein schlanker, gelebter Prozess ist besser als ein umfangreiches Handbuch, das niemand befolgt.

So arbeiten wir

Softverse hat eine MDR-zertifizierte Medizinprodukte-Plattform mit Backend, Web-App und Mobile App entwickelt und dabei nach IEC 62304 und ISO 13485 im QMS des Herstellers gearbeitet. Wir entwickeln so, dass die Dokumentation für die Konformitätsbewertung vorliegt. Die Klassifizierung und die Bewertung erfolgen durch den Hersteller mit der benannten Stelle bzw. Swissmedic. Mehr zu unserer Arbeit im regulierten Umfeld lesen Sie auf der Seite MedTech, zu unseren Leistungen unter Individualsoftware.

Wenn Sie ein Projekt nach IEC 62304 planen oder eine bestehende Software auf die Norm ausrichten wollen, sprechen Sie mit uns im kostenlosen Erstgespräch.

Dieser Artikel ist eine allgemeine Einführung und ersetzt keine Rechts- oder Regulierungsberatung.