Aus “Medical Device Software” wird “Health Software”
Die wohl auffälligste Änderung findet sich bereits im Titel. Aus „Medical Device Software – Software Life Cycle Processes“ wird „Health Software – Software Life Cycle Processes“. Was bedeutet das?
Tatsächlich ist dieser „Scope Change” eine der Haupt-Änderungen (deren Folgen in letzter Konsequenz auch zum Scheitern des ersten Anlaufs der Überarbeitung der IEC 62304 geführt hat). Mit dieser Änderung erschließt sich ein wesentlich breiteres Anwendungsgebiet. Denn während sich die aktuelle IEC 62304 ausschließlich auf Software bezieht, die selbst ein Medizinprodukt ist oder Bestandteil eines Medizinprodukts wird, soll die neue Edition grundsätzlich für Health Software gelten. Dazu gehören dann auch gesundheitsbezogene Softwarelösungen, die nicht zwangsläufig unter die Medizinprodukte-Regulierung fallen.
Diese Änderung hat weitreichende Folgen: nicht jede „Health Software” ist ein Medizinprodukt (oder wird in einem Medizinprodukt eingesetzt). Damit ergibt sich, dass die Software nicht zwangsläufig innerhalb eines nach ISO 13485 zertifizierten Qualitätsmanagementsystems entwickelt wird und darüber hinaus auch, dass ISO 14971 (Risikomanagement) nicht immer anwendbar ist. Deshalb verzichtet die kommende IEC 62304 Edition 2 auf die bisherige normative Verknüpfung mit diesen Normen. Stattdessen fordert sie lediglich allgemein ein Qualitäts- und Risikomanagement auf Produktebene.
Software-Sicherheitsklassen werden durch Process Rigour Levels ersetzt
Neben der „Scope-Erweiterung” betrifft eine der größten fachlichen Änderungen die Software-Sicherheitsklassen.
Bisher unterscheidet die IEC 62304 zwischen den Sicherheitsklassen A, B und C. Diese Einteilung kennt praktisch jeder Entwickler von Medizinproduktesoftware.
In der Edition 2 verschwindet dieses Modell vollständig. Stattdessen werden zwei Software Process Rigour Levels (PRL I und PRL II) eingeführt. Ziel ist es, unnötige Komplexität zu vermeiden, die insbesondere bei der Diskussion „in welche Klasse fällt meine Software?” immer wieder zu Diskussionen zwischen Hersteller und Auditoren geführt hat. Zu Bedenken ist aber: obwohl die Umstellung langfristig zu einem schlankeren und konsistenteren Modell führen soll, wird ihre Einführung kurzfristig erheblichen Anpassungsaufwand verursachen.
Da die Einstufung nicht nur auf Systemebene erfolgen kann, sondern auch auf einzelne Softwareelemente (Komponenten) angewendet werden kann, zeigt sich, wie wichtig eine saubere Softwarearchitektur ist (das war sie allerdings auch vorher schon). Nach wie vor ist sauber zu zeigen, dass diese Komponenten ausreichend voneinander getrennt sind.
Bekannte Prozesse bleiben – werden aber deutlich konkreter
Ein großer Vorteil: die bekannten Anforderungen zur Softwareentwicklung bleiben grundsätzlich erhalten. Was neu ist, das ist der Detaillierungsgrad.
So werden beispielsweise Anforderungen ergänzt bzw. präzisiert für:
- die Planung der Softwareentwicklung,
- Kommunikationsprozesse,
- Release- und Wartungsplanung,
- Softwarearchitektur,
- Verifikation der Architektur,
- statische Codeanalyse,
- Integrations- und Systemtests,
- Dokumentation der Testergebnisse,
- Nachverfolgbarkeit von Änderungen und Risikokontrollmaßnahmen.
Viele dieser Themen wurden bisher bereits im Rahmen von Audits erwartet oder über andere Normen und Leitfäden adressiert. Nun werden sie deutlicher Bestandteil der IEC 62304 Edition 2.
Wartung wird umfassender beschrieben
Auch Kapitel 6 wurde grundlegend überarbeitet. Die IEC 62304 Edition 2 trennt nun klarer zwischen
- Feedback aus dem Feld,
- tatsächlichen Softwareproblemen,
- Änderungsanforderungen (Change Requests) und
- Verbesserungen der Software.
Dadurch wird der Ablauf von der Rückmeldung eines Anwenders bis zur Umsetzung und Freigabe einer Softwareänderung klarer dargestellt. Zudem wird genauer beschrieben, wann zusätzlich der Problem-Resolution-Prozess anzuwenden ist. Das hat erfahrungsgemäß in der Vergangenheit immer wieder zu Fragen geführt. Insbesondere Hersteller mit etablierten Post-Market-Prozessen dürften diese Klarstellung begrüßen.
Cloud-Software wird erstmals berücksichtigt
Die aktuelle IEC 62304 entstand zu einer Zeit, in der cloudbasierte Software kaum eine Rolle spielte. Das hat sich bekanntermaßen grundlegend geändert und die 62304 Edition 2 trägt dieser Entwicklung Rechnung. Sie enthält erstmals Anforderungen für die kontrollierte Änderung und insbesondere die Außerbetriebnahme von Health Software, beispielsweise cloudbasierter Anwendungen oder Software-as-a-Service-Lösungen (SaaS).
Hersteller sollen künftig festlegen,
- wie Software außer Betrieb genommen wird,
- wie Anwender informiert werden,
- wie der Übergang organisiert wird und
- wie Risiken während dieser Phase beherrscht werden.
Damit deckt die Norm nun den gesamten Lebenszyklus bis zum Ende eines Softwareprodukts ab.
Cybersecurity-Anforderungen bleiben ausgelagert
Der Fokus der IEC 62304 Edition 2 liegt weiterhin auf der Beschreibung allgemeiner Software-Lebenszyklusprozesse. Die Definition von Cybersecurity-Anforderungen bleibt anderen Normen überlassen.
Da es mittlerweile in diesem Bereich etablierte Standards gibt (die IEC 81001-5-1 wurde beispielsweise eigens entwickelt, um diese Anforderungen im Einklang mit dem Entwicklungs-Lebenszyklus der IEC 62304 abzubilden) verweiset die IEC 62304 Edition 2 in diesem Zusammenhang auf
- IEC 81001-5-1 (Security-Anforderungen im Software-Lebenszyklus),
- IEC TR 60601-4-5 (Cybersecurity-Maßnahmen in medizinischen elektrischen Geräten; stellt den Bezug zur IEC 62443-Familie für IT-Sicherheit für industrielle Automatisierungs- und Steuerungssysteme (IACS/ICS) her),
- IEC TS 81001-2-2 (Kommunikation von Cybersecurity-Eigenschaften und -Anforderungen zwischen Hersteller und Betreiber).
Für Hersteller bedeutet das: Safety- und Security-Prozesse müssen weiterhin über mehrere Normen hinweg verzahnt werden. Das ist fachlich nachvollziehbar (da so die Inhalte der einzelnen Normen abgegrenzt dargestellt und weiterentwickelt werden können), erhöht jedoch den Aufwand für Planung, Dokumentation, Wartung und Auditierung für alle Beteiligten.
Künstliche Intelligenz und agile Entwicklung erhalten eigene Anhänge
Neu sind die informativen Anhänge zu KI und agiler Entwicklung.
Erstmals finden sich eigene Kapitel zu
- Artificial Intelligence-enabled Health Software und
- Agiler Softwareentwicklung
Diese Anhänge enthalten zwar keine neuen verpflichtenden Anforderungen, geben aber Hinweise darauf, welche Technologien und Entwicklungsmodelle künftig als Stand der Technik angesehen werden.
Der KI-Anhang könnte – neben dem bereits diskutierten Übergang zu den Process Rigour Leveln – der meistdiskutierte Abschnitt der Edition 2 sein.
Und: leider ist in diesem Kontext auch die Legacy Software in den informativen Anhang gewandert - siehe unsere Einschätzung weiter unten.
Unsere Einschätzung
Die zweite Edition der IEC 62304 verfolgt das Ziel, den Standard an moderne Softwareentwicklung anzupassen. Cloud-Anwendungen, agile Entwicklung und KI spielen heute eine wesentlich größere Rolle als bei der Veröffentlichung der ersten Edition im Jahr 2006. Umso überraschender ist jedoch, dass einige der spannendsten Themen letztlich nur in informativen Anhängen behandelt werden.
KI-Anforderungen unverbindlich
Besonders auffällig ist der Umgang mit Artificial Intelligence. Während KI inzwischen in immer mehr Medizinprodukten eingesetzt wird, enthält der Entwurf lediglich einen informativen Anhang zu AI-enabled Health Software. Gleiches gilt für agile Entwicklung.
Hersteller stehen heute vor ganz praktischen Fragestellungen: Wie wird ein trainiertes Modell versioniert? Wie wird Trainingsdatenmanagement dokumentiert? Welche Änderungen an einem Modell sind wartungsrelevant? Welche Verifikationsmaßnahmen sind angemessen? Gerade bei KI unterscheiden sich viele Fragestellungen deutlich von klassischer Softwareentwicklung.
Der informative Anhang liefert zwar hilfreiche Hinweise, schafft aber keine einheitlichen, auditierbaren Anforderungen. Damit bleiben wesentliche Erwartungen an die Umsetzung und Bewertung von KI-Systemen weiterhin außerhalb der IEC 62304 geregelt.
Leider ist auch die „Legacy-Software” in den informativen Anhang geraten. Nach unserer Ansicht werden insbesondere Europäische Hersteller das bedauern, da die Grundlage für eine fundierte und belastbare Diskussion bei Verwendung bereits existierender Software (-Komponenten) nunmehr fehlt. Gerade hier hätten weiterhin normative Anforderungen eines risikobasierten Umgangs mit Bestandssoftware zu mehr Planungssicherheit beigetragen.
Die neuen Process Rigour Levels werden nicht ohne Aufwand eingeführt werden können
Auch die Ablösung der bekannten Software-Sicherheitsklassen A, B und C durch Process Rigour Levels I und II dürfte in der Praxis nicht nur Vorteile bringen.
Zwar ist die Idee nachvollziehbar, den Umfang der Entwicklungsaktivitäten stärker an der erforderlichen Prozessstrenge auszurichten. Für Unternehmen, die seit vielen Jahren nach IEC 62304 arbeiten, bedeutet die Umstellung jedoch zunächst vor allem eines: zusätzlichen Aufwand.
Nahezu jede bestehende Dokumentation verweist heute auf die Software-Sicherheitsklassen. Entwicklungspläne, Verifikationskonzepte, Traceability-Matrizen, SOPs, Schulungsunterlagen und nicht zuletzt zahlreiche Softwarewerkzeuge basieren auf dem etablierten A/B/C-Modell. All diese Dokumente müssten überprüft und gegebenenfalls angepasst werden.
Hinzu kommt eine Übergangsphase, in der Hersteller gegenüber Benannten Stellen erklären müssen, wie die bisherigen Sicherheitsklassen auf die neuen Process Rigour Levels abgebildet werden. Gerade bei bestehenden Produkten mit langer Historie dürfte diese Migration erheblichen Dokumentationsaufwand verursachen – ohne dass sich die tatsächliche Produktsicherheit dadurch unmittelbar verbessert.
Unser Fazit
Die Edition 2 greift viele Themen auf, die sich seit 2006 in der Praxis etabliert haben. Das ist begrüßenswert, wenn man den Zeitraum von über 20 Jahren in einer Branche wie Softwareentwicklung bedenkt!
Die grundlegenden Lebenszyklusprozesse bleiben erhalten. Gleichzeitig reagiert die Norm auf Entwicklungen, die in den vergangenen Jahren die Softwareentwicklung geprägt haben: Cloud-Anwendungen, agile Entwicklung, Cybersecurity KI sowie eine (noch) stärkere risikobasierte Betrachtung der Entwicklungsprozesse.
Hersteller müssen bestehende Entwicklungsprozesse voraussichtlich nicht komplett neu aufbauen, aber der Teufel steckt im Detail. Deshalb lohnt es sich bereits heute, sich mit den geplanten Änderungen vertraut zu machen. Insbesondere die neuen Process Rigour Levels könnten erhebliche Auswirkungen auf Entwicklungs- und Qualitätsmanagementprozesse haben, da eine Software „plötzlich” in einen hohen Rigour-Level rutscht und wesentlich stringentere Prozesse sowie umfangreichere Dokumentation erforderlich macht.
Hinweis: Der zum Zeitpunkt der Erstellung vorliegende Text ist ein Arbeitsentwurf und noch keine veröffentlichte Norm. Bis zur finalen Veröffentlichung können sich Anforderungen, Begriffe und Inhalte noch erheblich ändern. Aussagen zur zukünftigen IEC 62304 Edition 2 sollten daher stets unter diesem Vorbehalt betrachtet werden.
