IEC 62304: Software-Lebenszyklus-Prozesse von Medizinprodukten

Die IEC 62304 gibt Prozesse und Aktivitäten vor, die Sie bei der Entwicklung einer Software als Medizinprodukt beachten müssen. Sie stellt spezifische Anforderungen daran, wie Sie Ihre Software entwickeln und warten müssen. Dies gilt sowohl für eigenständige Software (z.B. Medical Apps) als auch für Software, die Teil eines Medizinprodukts ist (z.B. embedded Software).

An der Norm IEC 62304 kommen Sie schwer vorbei, falls Sie eine Medical App bzw. Medical Software für den europäischen Markt entwickeln möchten. Und das ist auch gut so: die IEC 62304 ist ein nützliches Werkzeug, um die Konformität Ihres Software-gestützten Medizinprodukts mit der MDR (Medical Device Regulation) oder MDD (Medical Device Directive) nachzuweisen.

Falls Sie die Entwicklung einer Medical App oder Medical Software planen, finden Sie hier einen Leitfaden, der Sie durch alle Inhalte der IEC 62304 Schritt für Schritt hindurchführt. Im Internet gibt es viele Artikel zur IEC 62304, jedoch greift sich meist jeder Artikel nur einen Teilaspekt heraus. Als Hersteller ist es daher schwer einen Überblick zu bekommen, was denn nun alles zu beachten ist. Dieser Artikel soll ihnen dieses Gesamtbild einmal aufmalen. Wir gehen jeden Abschnitt der IEC 62304 durch, und fassen ihn in verständlicher Weise mit veranschaulichenden Beispielen zusammen.

Überblick über die IEC 62304

Eine Software/App, die eine medizinische Zweckbestimmung hat, ist nach MDR/MDD ein reguliertes Medizinprodukt (lesen Sie hier, ob das speziell für Ihre Software gilt). Im Rahmen des Digitale-Versorgung-Gesetz (DVG) muss ihre digitale Gesundheitsanwendung (DiGA) sogar ein Medizinprodukt sein.

Die IEC 62304 kann für regulierte Medizinprodukt-Software verwendet werden, um die Konformität mit Anforderungen z.B. der MDR oder MDD nachzuweisen. Die Anwendung der Norm im Rahmen der MDR/MDD ist theoretisch freiwillig. Sie sind dazu nicht gesetzlich verpflichtet. Die Anforderungen der MDR/MDD ohne eine derartige Norm nachzuweisen ist jedoch schwierig und bedarf am Ende vermutlich mehr Aufwand und Überzeugungsarbeit bei den Auditoren. Falls Sie eine Software/App als Medizinprodukt herstellen, empfiehlt es sich daher von der IEC 62304 Gebrauch zu machen.

Ziel der IEC 62304 ist, dass die entwickelte Medical App bzw. Medical Software innerhalb eines durchdachten Prozesses umgesetzt wird. Dabei sollen Dinge vermieden werden, die man z.B. häufig in anderen Software-Projekten findet:

Änderungen an der Software werden umgesetzt ohne diese ausreichend zu testen
Implikationen von bestimmten Software-Funktionen werden nicht auf Risiken untersucht. Die Implikationen werden erst bei Verwendung durch echte Nutzer klar.
Es existiert keine durchdachte Software-Architektur. Spätere Änderungen führen daher meist zu unerwarteten Problemen.
Aufgrund von mangelnder Dokumentation und unstrukturierter Arbeitsweise verstehen Entwickler den Code selbst nicht mehr. Sie machen daher mehr Fehler bei der Entwicklung.
Die Software-Stände werden nicht innerhalb eines Versionierung-Systems gepflegt. Es ist daher nachträglich nur sehr aufwändig möglich festzustellen, welche Änderung einen bestimmten Fehler verursacht hat. Das Zurücksetzen auf frühere Zustände der Software ist nicht möglich.
Anforderungen der Software werden nicht geplant. Die Entwickler implementieren die falschen Funktionen, und setzen diese nicht im Sinne des Nutzers um. Das Produkt erfüllt am Ende nicht den geplanten Zweck.

Dies sind nur einige Beispiel-Szenarien, welche die IEC 62304 zu verhindern versucht.

Wichtig zu erwähnen ist auch, dass Sie die Norm (wie auch andere ISO/IEC-Normen) kaufen müssen. Sie können die Normen z.B. bei Beuth, iso.org oder, deutlich günstiger, bei evs.ee (ca. 10% des Preises im Vergleich zu Beuth/iso.org) erwerben.

Um Ihnen vorab einen Überblick über alle Inhalte der IEC 62304 zu geben, sehen Sie hier das Inhaltsverzeichnis der Norm auf der obersten Ebene:

In den folgenden Kapiteln fassen wir jeden dieser Abschnitte und die zugehörigen Anforderungen prägnant für Sie zusammen.

Anwendungsbereich (1.), Normative Verweisungen (2.) und Begriffe (3.)

Dem eigentlichen Hauptteil aller Anforderungen der IEC 62304 gehen drei kurze Kapitel voran:

Im ersten Kapitel wird das Anwendungsgebiet der IEC 62304 spezifiziert. Zusammengefasst gilt die Norm für die Entwicklung und Wartung von Medizinprodukt-Software. Die Software kann entweder ein eigenständiges Medizinprodukt sein, oder ein eingebetteter Bestandteil eines anderen Medizinprodukts (z.B. embedded Software).

Im zweiten Kapitel finden Sie normative Verweisungen. Unter normativ versteht man hier, dass die referenzierten Dokumente für die Anwendung der IEC 62304 erforderlich sind. Hier wird nur die ISO 14971 (Risikomanagement von Medizinprodukten) genannt. Dazu später mehr.

Im dritten Kapitel werden die wichtigsten genutzten Begriffe innerhalb der IEC 62304 definiert. Diese sind für die korrekte Interpretation der Norm wichtig. Was z.B. eine “Aktivität” von einem “Prozess” unterscheidet, mag nicht jedem Leser klar sein (Prozess = Reihe von verbundenen Aktivitäten, die Eingaben in Ergebnisse umwandeln).

Allgemeine Anforderungen (4.)

Bevor wir uns den Kern-Aspekt der IEC 62304 ansehen, den Software-Entwicklungs-Prozess, sollten wir einen Blick auf die sog. allgemeinen Anforderungen werfen.

Der Hersteller muss …

… ein Qualitätsmanagement-System führen. Dies kann z.B. durch die Anwendung der ISO 13485 (Norm für Qualitätsmanagement-Systeme von Medizinprodukten) nachgewiesen werden. (4.1)
… einen Risikomanagement-Prozess nach ISO 14971 anwenden. (4.2)
… jedem Software-System eine Software-Sicherheitsklasse (A, B oder C) zuweisen (4.3)

Bezüglich des Qualitätsmanagement-Systems und dem geforderten Risikomanagement sollten Sie einen Blick in die jeweiligen referenzierten Normen (ISO 13485 und ISO 14971) werfen. Diese Normen behandeln wir nicht innerhalb dieses Artikels.

Auf den sehr einflussreichen Punkt der Software-Sicherheitsklassifizierung gehen wir hier ein:

Software-Sicherheits-Klassifizierung (4.3)

Sie müssen jedem Software-System eine Sicherheitsklasse (A, B oder C) zuordnen. Je nach Sicherheitsklasse fordert die IEC 62304 mehr (Sicherheitsklasse B oder C) oder weniger (Sicherheitsklasse A) von Ihnen und Ihren Prozessen.

Es steht Ihnen hierbei in gewisser Weise frei, in wie viele Systeme Sie Ihre Software unterteilen möchten. Der Einfachheit halber bestehen viele Medical Apps aus nur genau einem Software-System. Falls Sie aber z.B. einen nicht sicherheitskritischen Teil sowie einen sehr sicherheitskritischen Teil in Ihrer Anwendung haben, könnten Sie hierfür jeweils ein Software-System der Klasse A und ein Software-System der Klasse C aufbauen. Diese Systeme müssen natürlich entsprechend technisch getrennt und unabhängig voneinander sein.

Die Klassifizierungsregeln sind in der folgenden Abbildung prägnant zusammengefasst. Im Zweifel sollten Sie einen zusätzlichen Blick in das entsprechende Kapitel (4.3) der IEC 62304 werfen.

Entscheidungsbaum zur Software-Sicherheitsklasse nach IEC 62304: Zum Vergrößern klicken

Software-Entwicklungs-Prozess (5.)

Der zentrale Inhalt der IEC 62304 ist die Forderung nach einem definierten Software-Entwicklungs-Prozess. Dieser Prozess besteht aus einer Anzahl von Aktivitäten, die wir hier näher erläutern.

Die geforderten Aktivitäten sind in der folgenden Abbildung dargestellt:

Software-Entwicklungs-Prozess nach IEC 62304: Zum Vergrößern klicken

Der Software-Entwicklungs-Prozess besteht also aus den folgenden Kernaktivitäten:

Es fällt schnell auf, dass sich dieser Prozess stark am V-Modell der Software-Entwicklung orientiert. Es ist jedoch wichtig zu beachten, dass die IEC 62304 nicht explizit ein bestimmtes Vorgehensmodell während der Software-Entwicklung fordert. Dem Hersteller steht frei, ob er ein V-Modell, agile Entwicklung oder das Wasserfall-Modell anwendet.
Im V-Modell würden Sie die genannten Aktivitäten über den gesamten Entwicklungszeitraum der Medical App verteilen. Bei agiler Entwicklung würde z.B. jeweils jeder Sprint die genannten Aktivitäten beinhalten (zumindest einen Teil davon). Jeder Sprint wäre dann ein eigenes kleines V.

In den folgenden Abschnitten geben wir einen Überblick über jede der genannten Aktivitäten:

Planung der Software-Entwicklung (5.1)

Sie müssen einen Software-Entwicklungsplan erstellen. Dieser Plan beschreibt im Grunde wie genau bei der Software-Entwicklung zu arbeiten ist. Der Software-Entwicklungsplan beschreibt folgende Punkte (oder referenziert diese in anderen Dokumenten):

Prozesse der Software-Entwicklung
zu liefernde Ergebnisse und Dokumente
Beschreibung der Rückverfolgbarkeit zwischen Anforderungen, Prüfungen und Risikokontrollmaßnahmen (Stichwort: Traceability)
Konfigurations- und Änderungsmanagement
Problembehandlung- und Lösung
Software-Integration und Integrationsprüfung
Software-Verifizierung
Software-Risikomanagement
Dokumentation

Er ist also eine Art Handbuch für den gesamten Prozess der Software-Entwicklung.

Analyse der Software-Anforderungen (5.2)

Sie müssen alle Anforderungen an Ihre Software dokumentieren. Dazu gehören funktionale Anforderungen sowie nicht-funktionale Anforderungen. Genauer gesagt müssen Sie u.a. Folgendes dokumentieren:

Anforderungen an Funktionalität und Leistungsfähigkeit
Ein- und Ausgaben des Software-Systems
Schnittstellen zwischen dem Software-System und anderen Systemen
Software-gesteuerte Alarme, Warnungen und Anwender-Meldungen
Anforderungen für die Datensicherheit
Anforderungen für die Benutzerschnittstelle
Datendefinition und Datenbank-Anforderungen
Anforderungen für Installation und Abnahme
Anforderungen für Betrieb und Wartung
Anforderungen bezüglich IT-Netzwerkaspekten (z.B. Handhabung, wenn Netzwerk nicht verfügbar ist, Netzwerk-Protokolle, etc.)
regulatorische Anforderungen
Einbeziehung von Risikobeherrschungsmaßnahmen (zur Verminderung oder Eliminierung von identifizierten Risiken)

Diese Punkte können sich auch gegenseitig überlappen. Alle dokumentierten Software-Anforderungen müssen (nach der Implementierung) verifiziert werden. Die Verifizierung lässt sich zusammenfassen als Prüfung, ob alle Anforderungen erfüllt sind. Dafür müssen alle Anforderungen so formuliert werden, dass eine Prüfung anhand von definierten Prüfkriterien möglich ist.

Design der Software-Architektur (5.3)

Innerhalb von Software-Systemen der Sicherheitsklasse B oder C müssen Sie vor der Implementierung die geplante Software-Architektur dokumentieren. Diese inkludiert auch Schnittstellen zwischen einzelnen Software-Komponenten und z.B. externen Systemen. Sie können dies z.B. grafisch mit Hilfe von UML oder C4 umsetzen. Dabei können Sie z.B. die Software-Architektur selbst mit Hilfe von UML-Klassendiagrammen beschreiben, und einzelne Kern-Abläufe z.B. mit Hilfe eines Sequenzdiagramms.

Eine Medical App bzw. Medical Software kommt selten ohne Abhängigkeiten zu externen Software-Paketen (z.B. für die Anzeige oder Speicherung von Daten) aus. Diese Software-Pakete (bzw. Software-Komponenten) bezeichnet man als SOUP (Software Of Unknow Provenance). Derartige Komponenten wurden normalerweise nicht vom eigenen Team entwickelt und wurden nicht innerhalb eines geeigneten Qualitätsmanagement-Systems dokumentiert. Sie müssen daher u.a. selbst Funktions- und Leistungsanforderungen für die SOUP-Komponente festlegen. Konkret schreiben Sie dafür eine Liste aller Abhängigkeiten (Dependencies), und legen für jede Abhängigkeit fest, ob und wie Sie diese überprüft haben. Wie detailliert Sie dies tuen müssen hängt von der Sicherheitsklasse des Systems ab.

Zuletzt müssen Sie auch die Software-Architektur verifizieren, und z.B. nachweisen, dass diese Ihre Software-Anforderungen implementiert.

Detailliertes Software-Design (5.4)

Bei Software-Design handelt es sich nicht um Design im Sinne der Nutzeroberfläche (Nutzer-Input/Output), sondern um eine Dokumentation der Software-Einheiten auf technischer Ebene (ähnlich zur Software-Architektur). Im Gegensatz zur Software-Architektur, welche die Software-Komponenten abbildet, zeigt das detaillierte Software-Design jedoch alle Software-Einheiten und ihre Beziehungen zueinander auf. Software-Design existiert also auf einem niedrigeren Abstraktionsniveau und ist somit detaillierter.

Im Gegensatz zu einer Software-Komponente definiert sich eine Software-Einheit als “nicht weiter unterteilbare” Einheit. Eine Software-Komponente kann aus mehreren Software-Einheiten bestehen. Ein Software-System besteht aus Software-Komponenten. Als Faust- und Merk-Regel könnte man es so definieren:
Software-System ≥ Software-Komponente ≥ Software-Einheit

Dieses Design muss detailliert genug sein, um die korrekte Implementierung zu ermöglichen. Außerdem muss es natürlich in Harmonie mit der Software-Architektur stehen, frei von Widersprüchen.

Implementierung der Software-Einheiten (5.5)

Nach ausführlicher Dokumentation der genannten Punkte, kommt nun endlich der Teil, auf den wohl jeder Software-Entwickler gewartet hat: die eigentliche Implementierung der Software-Einheiten.

Für Software-Systeme der Sicherheitsklassen B oder C müssen außerdem alle Software-Einheiten einzeln verifiziert werden und Akzeptanzkriterien festgelegt werden. Für die Verifizierung können Sie z.B. auch auf Ihre Codierungs-Normen verweisen (Coding Guidelines). Diese definieren z.B. wie viele Zeilen Code Sie maximal pro Software-Methode und Software-Klasse zulassen (um Übersicht zu gewährleisten), die zu erreichende Unit-Test-Coverage und sonstige Programmiersprachen-abhängige Vorschriften. Um die Einhaltung Ihrer Codierungs-Normen zu überprüfen bietet sich ein Tool für statische Code-Analyse an (in Kombination mit einem Linter, der Verstöße sofort für den Entwickler im Code markiert).

Außerdem sind Code-Reviews ideal, um die Einhaltung der Anforderungen, Akzeptanz-Kriterien und Software-Metriken zu überprüfen. Ein Entwickler prüft den Code des anderen Entwicklers vor Freigabe (bzw. vor jedem “Git-merge”) und hinterlässt Kommentare mit Nachbesserungs-Vorschlägen. Diese Kommentare sind nachträglich ein idealer Nachweis, um schriftlich zu belegen, dass sie die Prozesse der IEC 62304 einhalten. Dies geschieht normalerweise mit Hilfe von Code-Review-Funktionalitäten auf z.B. GitHub, GitLab oder Bitbucket.

Software-Integration und -Integrationsprüfung (5.6)

Nach der Implementierung der einzelnen Software-Einheiten müssen diese natürlich im selben System landen. Für Software-Systeme der Sicherheitsklassen B oder C müssen Sie diese nach einem dokumentierten Integrationsplan in das Gesamtsystem integrieren. Anschließend muss geprüft werden, ob die Integration erfolgreich war, oder ob z.B. Probleme entstanden sind.

Konkret kann dies entweder durch manuelle Tests z.B. eines QA-Experten (der Titel ist nicht entscheidend) geschehen oder durch automatisierte Integration-Tests in der Software selbst.

Prüfung des Software-Systems (5.7)

Sie müssen eine Reihe von Prüfungen festlegen und durchführen, die alle Software-Anforderungen abdecken. Dafür geben Sie u.a. Eingabe-Werte und erwartete Ausgabewerte an, setzen Pass/Fail-Kriterien und beschreiben generell Ihre Verfahren zur Software-System-Prüfung.

Diese Prüfungen können natürlich sowohl (menschliche) manuelle Tests als auch automatisierte Tests (UI-Tests, Integration-Tests, Unit-Tests, etc.) jeglicher Art beinhalten.

Gleichzeitig müssen diese Tests so dokumentiert werden, dass Sie wiederholbar sind. Dafür müssen Sie bei der Prüfung z.B. Ihre Hardware- und Software-Konfiguration, Prüfwerkzeuge und die Version der geprüften Software dokumentieren. Außerdem empfiehlt sich eine Dokumentation der Test-Schritte, um Wiederholbarkeit zu gewährleisten.
Das kann z.B. so aussehen:

Öffne die App – Erwartetes Ergebnis: Startbildschirm mit “Messen”-Knopf ist sichtbar
Klicke auf den “Messen”-Knopf – Erwartetes Ergebnis: die Kamera öffnet sich. Der “Aufnahme” Button ist sichtbar.
Klicke auf den “Aufnahme”-Knopf – Erwartetes Ergebnis: Ein Ladebalken öffnet sich.
…

Derartige Testabläufe können Sie entweder in Word-Dokumenten dokumentieren, oder Tools wie Jira (jedes Ticket ist ein Test-Fall) oder TestRail benutzen.

Software-Freigabe (5.8)

Nach erfolgreicher Verifizierung der Software kann die Software freigegeben werden. Sie wird in ein ausführbares Format kompiliert. Restliche Anomalien werden dokumentiert. Die fertige Software wird mitsamt der zugehörigen Dokumentation archiviert und kann ausgeliefert werden. Pragmatisch betrachtet reicht hier z.B. ein Ordner für jede neue freigegebene Version: Quellcode, kompilierter, ausführbarer Code (z.B. als APK-Datei für Android-Systeme) und alle Build-Tools, die zur erneuten Erstellung dieser ausführbaren Software-Version nötig sind (z.B. die Installationsdatei der konkreten Version der Entwicklungsumgebung).

Bei der Auslieferung an Ihre Nutzer muss sichergestellt werden, dass auf dem Weg keine unerwünschten Änderungen/Verfälschungen der Software mehr passieren können. Bei Software impliziert dies vor allem Sicherheitsvorkehrungen, damit keine Hacker ihren fertigen Software-Release manipulieren können (und so z.B. Schadcode einschleusen).

Es kann natürlich sein, dass Ihre Software und Ihr Qualitätsmanagement-System z.B. im Rahmen der MDR vor der Freigabe an Nutzer erst von einer benannten Stelle geprüft werden muss. Das hängt von der Gesetzgebung Ihrer Zielmärkte ab. Die IEC 62304 ist unabhängig davon und schlägt nur einen Prozess vor, den Sie zum Nachweis der Konformität umsetzen können.

Falls Ihr Produkt z.B. schon auf dem europäischen Markt ist, müssen Sie für jede Änderung entscheiden, ob diese “signifikant” ist. Wenn es sich um eine “signifikante Änderung” handelt, muss Ihre benannte Stelle die Änderung vor der Freigabe absegnen. Diese Forderung ist jedoch Teil der MDR bzw. MDD, und nicht Teil der IEC 62304.

Weitere Prozesse der IEC 62304

Der Software-Entwicklungs-Prozess ist mit Abstand der umfangreichste Teil der IEC 62304. Darüber hinaus müssen Sie allerdings noch vier weitere Prozesse aufbauen: für Software-Wartung, Software-Risikomanagement, Software-Konfigurationsmanagement und Problemlösung. Auf jeden dieser Prozesse gehen wir in Folgendem kurz ein:

Software-Wartungs-Prozess (6.)

Für den Betrieb der Software muss ein Software-Wartungs-Prozess definiert werden. Dafür wird zuerst ein Software-Wartungs-Plan aufgesetzt. Dieser beschreibt wie nach Freigabe der Medical App bzw. Medical Software mit Rückmeldungen von Nutzern oder anderen Parteien umgegangen werden soll. Es werden z.B. Kriterien dafür definiert, ab wann eine Rückmeldung als Problem zu betrachten ist. Im Falle eines Problems kommt der Problemlösungs-Prozess zum Einsatz.

Außerdem muss jede Änderungsanforderung an der Software analysiert und genehmigt werden. Nach Genehmigung der Änderung werden diese mit Hilfe des Software-Entwicklungs-Prozesses wie gewohnt implementiert.

Während der Software-Wartung kommt weiterhin ein definierter Risikomanagment-Prozess zum Einsatz (siehe unten). Jede Änderung durchläuft das Risikomanagement und wird auf mögliche Gefährdungen untersucht.

Einen Überblick der Software-Wartungs-Prozesse und Aktivitäten sehen Sie hier:

Software-Wartungs-Prozess nach IEC 62304: Zum Vergrößern klicken

Wie man sieht ist der Software-Wartungs-Prozess lediglich eine leichte Abwandlung des Software-Entwicklungs-Prozesses.

Software-Risikomanagement-Prozess (7.)

Die einzige weitere Norm, welche von der IEC 62304 vorrausgesetzt wird, ist die ISO 14971. Diese beschreibt das Risikomanagement von Medizinprodukten. Zusammengefasst müssen Sie Ihre Medical Software daher auf mögliche Gefährdungen (= Schadensquellen) und Gefährdungssituationen untersuchen. Das mit diesen verbundene Risiko muss eingeschätzt werden. Auf dieser Basis wird nun evaluiert, ob ein Risiko akzeptabel ist oder es z.B. durch Risikokontrollmaßnahmen verringert werden muss. Die ISO 14971 gilt auch für Hardware-Medizinprodukte und nimmt daher nicht explizit Stellung zu Problematiken im Rahmen der Software. Die IEC 62304 verweist für diesen Prozess hauptsächlich auf die ISO 13485 und stellt keine nennenswerten Zusatzanforderungen.

Hier sehen Sie einen Überblick über alle Prozesse und Aktivitäten im Rahmen des Risikomanagements nach ISO 14971:

Software-Risikomanagement-Prozess nach ISO 14971: Zum Vergrößern klicken

Im Rahmen des Risikomanagements werden Sie dann z.B. eine Failure Mode and Effects Analysis-Tabelle (FMEA) erstellen oder ein Fault-Tree-Analyse (FTA) durchführen.

Software-Konfigurationsmanagement-Prozess (8.)

Dieser Prozess definiert, wie Änderungen und Freigaben in der Software kontrolliert bzw. protokolliert werden.

Dies kann zum Beispiel durch ein Software-Versionierung-Tool wie Git geschehen. Änderungen werden als einzelne “Commits” (Änderungspakete) festgehalten, und freigegebene Versionen werden als solche markiert (z.B. durch einen “Release”-Tag). Außerdem fordert dieser Abschnitt, dass die System-Konfiguration und mögliche SOUPs systematisch dokumentiert werden.

Der zweite Teil des Prozesses beschäftigt sich mit der sog. Änderungskontrolle. Jegliche Änderungen dürfen nur nach vorheriger Genehmigung einer entsprechenden Änderungsanforderung implementiert werden. In diesem Rahmen müssen Sie bei Änderungen alle Aktivitäten identifizieren, die wiederholt werden müssen. Dies können Schritte des Software-Entwicklungs-Prozesses sein, oder auch die Software-Sicherheitsklassifizierung der Software-Systeme.

Problemlösungsprozess für Software (9.)

Für jedes neue Problem, das Sie in Ihrer Medical Software identifizieren, müssen Sie einen Problembericht anlegen. Dieser Bericht enthält dann z.B. eine Einschätzung, wie kritisch das Problem ist, sowie jegliche Informationen, die bei der Problemlösung helfen könnten (z.B. betroffene Geräte oder Anweisungen für die Reproduktion des Problems).

Außerdem müssen Sie für jedes Problem wenn möglich Ursachen identifizieren. Das Risikomanagement wird für das Problem neu angestoßen. Und schlussendlich wird eine Änderungsanforderung für die Lösung des Problems gestellt. Nach der Implementierung dieser Änderungsanforderung muss diese natürlich wieder verifiziert werden:
Wurde das Problem gelöst oder besteht es weiterhin? Wurden dadurch zusätzliche Probleme verursacht?
Derartige Fragen müssen Sie sich nach jeder Änderungsanforderung stellen.

Weitere wichtige Normen

Dies war ein Überblick über alle Abschnitte der IEC 62304. Falls Sie eine medizinische Software bzw. App auf den europäischen Markt bringen möchten, sollten Sie sich auch noch folgende Normen ansehen:

IEC 62366 (Gebrauchstauglichkeit)
ISO 13485 (Qualitätsmanagement)
ISO 14971 (Risikomanagement)
IEC 82304 (Gesundheitssoftware Produktsicherheit – sinnvolle Erweiterung der IEC 62304)

Mehr zu diesen Normen finden Sie auch in unserem Leitfaden für die Entwicklung von Medical Apps.

Fazit

Die IEC 62304 fordert grundsätzlich viele sinnvolle Dinge, die ein gutes Software-Team sowieso schon befolgen sollte. Trotzdem wird sich ein Team darauf einstellen müssen deutlich mehr Dokumentation und Aufzeichnungen als bei herkömmlicher “Nicht-Medizinprodukt”-Software zur erstellen. Viele Software-Entwickler sind es außerdem nicht gewöhnt nach sehr strikt definierten Prozessen zu arbeiten. Das Entwickeln von medizinischer Software nach IEC 62304 bringt also durchaus weitreichende Änderungen mit sich. Falls Sie zusätzlich die Einbindung von künstlicher Intelligenz (KI) planen, sollten Sie dies in Ihrem Software-Lebenszyklus berücksichtigen (mehr dazu in unserem KI-Leitfaden).

Wir haben versucht Ihnen im Rahmen dieses Artikels einen vollständigen Überblick über alle Punkte der IEC 62304 zu geben. Eben dieser Überblick ist nötig, wenn man sich anfängt mit der Entwicklung medizinischer Software auseinander zu setzen. Weitere Anforderungen an die Entwicklung von Software als Medizinprodukt finden Sie in unserem Leitfaden zur Entwicklung von Medical Apps. Falls Sie eine digitale Gesundheitsanwendung (DiGA) im Rahmen des DVG planen, finden Sie alle Anforderungen in unserem Leitfaden zur DiGAV.