Medizinische Software · Normenarchitektur · Nachweise von Anfang an
ISO- und IEC-Normen für medizinische Software
Konformität wird nicht nach dem letzten Sprint ergänzt. Sie wird in jedes Release kompiliert.
Die Normen bilden ein vernetztes Build-System. Das Qualitätsmanagement steuert die Organisation, das Risikomanagement erklärt die Notwendigkeit von Maßnahmen, der Software-Lebenszyklus macht die Arbeit nachvollziehbar, Gebrauchstauglichkeit adressiert Anwendungsfehler, Cybersicherheit schützt das Produkt in einer feindlichen Umgebung und Produktanforderungen machen aus Code ein freigabefähiges Medizinprodukt.
Normen-Build starten ↓Zweckbestimmung · Architektur · Code · Daten · Schnittstelle
Nachweise über den Lebenszyklus verknüpft
Der zentrale Gedanke
Die Normen stehen nicht neben dem Code
Sie bestimmen, wie Entscheidungen rund um den Code getroffen, dokumentiert, geprüft und erneut bewertet werden.
Ein konformes Release ist daher nicht nur ein funktionierendes Binärprogramm. Es ist ein funktionierendes Produkt mit einer schlüssigen Vergangenheit und einer kontrollierten Zukunft.
01
Die Normen arbeiten als System und nicht als Einkaufsliste #
ISO- und IEC-Normen adressieren unterschiedliche Ebenen desselben Produkts. Ihre Anwendungsbereiche überschneiden sich bewusst, weil ein Softwarefehler selten nur einer Disziplin zuzuordnen ist. Eine missverständliche Warnmeldung kann gleichzeitig ein Problem der Gebrauchstauglichkeit, ein Fehler der Softwareanforderung, das Versagen einer Risikokontrollmaßnahme und ein Signal aus der Marktbeobachtung sein.
Die praktische Aufgabe besteht nicht darin, sechs Zertifikate oder sechs getrennte Ordner zu sammeln. Es gilt, die anwendbaren Normen zu bestimmen, den Beitrag jeder Norm zu verstehen und die Rückverfolgbarkeit über ihre Schnittstellen hinweg aufzubauen.
Qualitätsmanagementsystem, Entwicklungslenkung, Lieferanten, Änderungen und CAPA
Gefährdungen, Risikoeinschätzung, Kontrollen, Nutzen-Risiko-Abwägung und Produktionsdaten
Entwicklung, Wartung, Konfiguration, Problemlösung und Sicherheitsklassifizierung
Produktsicherheit, Validierung, Informationen und Verantwortlichkeiten im Lebenszyklus
Anwendungsbezogene Risiken und sicherheitsorientiertes Usability Engineering
Sichere Entwicklung und Wartung über den gesamten Lebenszyklus
Kann das Team bei Änderung einer Risikokontrollmaßnahme die betroffene Softwareanforderung, das Architekturelement, die Verifizierung, die Arbeiten zur Gebrauchstauglichkeit, die Cybersicherheitsanalyse, den Freigabenachweis und die Marktüberwachung identifizieren?
02
Vor der Auswahl von Normen muss die Produktgrenze feststehen #
Nicht jede Gesundheitsanwendung ist Medizinproduktesoftware. Zweckbestimmung, medizinische Aussagen, Nutzer, Patientenpopulation, Eingabedaten und Bedeutung der Ausgabe bestimmen, ob die Software unter die MDR, die IVDR oder einen anderen Rechtsrahmen fällt.
Dieselbe Grenze bestimmt auch, was zum Softwareprodukt gehört. Eine mobile Anwendung kann von einem Cloud-Dienst, einem trainierten Modell, einer Datenbank, einem Webportal, einer Drittanbieterbibliothek, einem Bereitstellungsskript und einer externen Schnittstelle abhängen. Wird eine Komponente aus einem Diagramm ausgeschlossen, verschwindet sie dadurch nicht aus der Sicherheitsargumentation.
Medizinischer Zweck, Aussagen, anwendbare Verordnung und Klassifizierungsbegründung
Anwendungen, Dienste, Modelle, Datenspeicher, Schnittstellen, Plattformen und Zubehör
Hersteller, Lieferanten, Cloud-Anbieter, Betreiber, Nutzer und Gesundheitseinrichtungen
Was verifiziert, validiert, überwacht und der Änderungskontrolle unterstellt werden muss
Die MDCG-Leitlinie zur Qualifizierung und Klassifizierung von Software ist hier wichtig, ersetzt jedoch keine produktspezifische Begründung. Die Normenarchitektur muss dem tatsächlichen Produkt folgen und nicht der ihm zugewiesenen Marketingbezeichnung.
03
ISO 13485 schafft die Organisation rund um den Code #
ISO 13485 schreibt weder eine Architektur noch eine Programmiersprache oder ein Testframework vor. Die Norm steuert die Organisation, die diese Entscheidungen trifft.
Pläne, Eingaben, Ergebnisse, Reviews, Verifizierung, Validierung und Übertragung
Cloud, Bibliotheken, Entwicklungswerkzeuge, externe Teams und kritische Dienste
Folgenabschätzung, Genehmigung, Umsetzung, Verifizierung und Freigabe
Reklamationen, Nichtkonformitäten, CAPA, Audits und Daten nach dem Inverkehrbringen
Für ein agiles Team verbietet die Norm weder kurze Iterationen noch automatisierte Auslieferung. Der Workflow muss jedoch Genehmigung, Rückverfolgbarkeit, objektive Nachweise und Kontrolle erhalten. Eine schnelle Pipeline kann konform sein, eine unsichtbare nicht.
04
ISO 14971 erklärt, warum die Softwarekontrollen existieren #
Software schädigt einen Patienten üblicherweise nicht, weil sie aus einem gefährlichen Material besteht. Sie kann durch falsche Informationen, verzögerte Maßnahmen, mangelnde Verfügbarkeit, unbeabsichtigte Befehle, verwirrende Interaktionen oder beeinträchtigte Daten und Funktionen zu einem Schaden beitragen.
ISO 14971 liefert die Logik, die vorhersehbare Ereignisabfolgen mit Gefährdungssituationen und Schäden verbindet. Anschließend werden Risiken bewertet, Kontrollen ausgewählt und deren Wirksamkeit verifiziert. IEC 62304 definiert die Softwareaktivitäten, mit denen viele dieser Kontrollen umgesetzt und aufrechterhalten werden.
Fehler, Fehlgebrauch, Datenproblem, Ausfall einer Abhängigkeit oder Angriff
Erkennung, Berechnung, Anzeige, Kommunikation oder Steuerung verhält sich unerwartet
Eine Person oder die Umgebung wird einer Schadensquelle ausgesetzt
Schweregrad und Wahrscheinlichkeit bestimmen die Risikoentscheidung
Inhärente Sicherheit, Schutzmaßnahme, Information, Überwachung oder betriebliche Kontrolle
Eine Schwachstelle ist nicht automatisch ein Risiko für die Patientensicherheit. Sobald ihre Ausnutzung eine medizinische Funktion, Verfügbarkeit, Integrität oder klinische Entscheidung beeinflussen kann, müssen Cybersicherheitsanalyse und Risikomanagementakte nach ISO 14971 miteinander verbunden sein.
05
IEC 62304 ist das Rückgrat des Software-Lebenszyklus #
IEC 62304 schafft einen gemeinsamen Rahmen für die Entwicklung und Wartung medizinischer Software unabhängig davon, ob die Software selbst ein Medizinprodukt ist oder in ein Medizinprodukt eingebettet beziehungsweise dessen integraler Bestandteil ist.
Ihre Stärke liegt in der disziplinierten Kontinuität. Anforderungen führen zu Architektur und detailliertem Entwurf, die Implementierung zur Verifizierung, Releases bleiben identifizierbar, Probleme werden untersucht und Änderungen durchlaufen erneut dasselbe kontrollierte System.
Lebenszyklusmodell, Aktivitäten, Verantwortlichkeiten, Ergebnisse und Schnittstellen
System- und Softwareanforderungen mit Verbindung zu Risikokontrollen
Softwareelemente, Segregation, Schnittstellen und SOUP-Abhängigkeiten
Einheiten, Integration und objektive Verifizierungsnachweise
Bekannte Anomalien, Versionsidentität, Aufzeichnungen und kontrollierte Bereitstellung
Rückmeldungen, Problemlösung, Folgenabschätzung und Änderung
IEC 62304 deckt die abschließende Validierung und Freigabe des vollständigen Medizinprodukts nicht ab, selbst wenn das Produkt ausschließlich aus Software besteht. Nachweise auf Produktebene müssen diese Lücke schließen.
06
Die Sicherheitsklassen nach IEC 62304 sind keine MDR-Risikoklassen #
Die beiden Klassifizierungssysteme beantworten unterschiedliche Fragen. Sie wie eine Umrechnungstabelle zu behandeln, ist einer der schnellsten Wege zu einem schwachen Softwareplan.
Klassifiziert das Medizinprodukt und bestimmt den Konformitätsbewertungsweg sowie die regulatorische Prüfungstiefe.
Skaliert die Strenge der Lebenszyklusprozesse entsprechend der möglichen Verletzung infolge eines Ausfalls des Softwaresystems.
Die Norm fordert den am wenigsten umfangreichen Satz an Lebenszyklusaktivitäten
Zusätzliche Kontrollen für Architektur, Entwurf und Verifizierung gelten
Die umfangreichsten Lebenszykluskontrollen und Nachweise gelten
Die Klassifizierungsbegründung muss das Softwaresystem, Gefährdungssituationen und externe Risikokontrollen gemäß der anwendbaren Ausgabe berücksichtigen. Sie sollte so früh vorliegen, dass sie Planung und Architektur prägt, und bei Änderungen von Risiken, Schnittstellen oder Kontrollen erneut bewertet werden.
07
IEC 82304-1 macht aus Software ein vollständiges Gesundheitssoftwareprodukt #
IEC 82304-1 gilt für Sicherheit und Cybersicherheit von Gesundheitssoftwareprodukten, die auf allgemeinen Rechnerplattformen betrieben und ohne dedizierte Hardware in Verkehr gebracht werden. Dieser Anwendungsbereich ist präziser als die pauschale Aussage, die Norm gelte für jede eigenständige Software.
Die Norm blickt über Entwicklungsaktivitäten hinaus auf das vollständige Produkt. Sie adressiert Produktanforderungen, Validierung, Identifizierung, Begleitinformationen, Installation, Wartung und Außerbetriebnahme über den Lebenszyklus.
Wie die Software entwickelt und gewartet wurde
Zweckbestimmung, Systemanforderungen und Betriebsumgebung
Das vollständige Gesundheitssoftwareprodukt erfüllt seinen vorgesehenen Verwendungszweck
Identifizierung, Anweisungen, Einschränkungen und Begleitdokumente
Installation, Wartung, Aktualisierungen und Außerbetriebnahme
Für reine Software-Medizinprodukte ergänzen sich IEC 62304 und IEC 82304-1 daher. Die eine steuert den Software-Lebenszyklus, die andere hilft, die Argumentation auf Produktebene zu schließen.
08
IEC 62366-1 behandelt die Schnittstelle als Teil des Sicherheitssystems #
Ein Bildschirm kann jeden Funktionstest bestehen und den Nutzer dennoch zu einer falschen Handlung führen. IEC 62366-1 etabliert einen Prozess des Usability Engineerings, der sich auf die sicherheitsbezogenen Merkmale der Benutzungsschnittstelle konzentriert.
Fähigkeiten, Einschränkungen, Schulung, Sprache und Nutzungsumgebung
Anwendungsszenarien, Aufgaben, Fehler und sicherheitsbezogene Schnittstellenmerkmale
Formative Evaluation verbessert die Schnittstelle, solange sie noch geändert werden kann
Summative Evaluation prüft die endgültige Schnittstelle unter repräsentativen Nutzungsbedingungen
Das Ziel ist nicht die allgemeine Kundenzufriedenheit. Bewertet und reduziert werden Risiken durch korrekte Anwendung und Anwendungsfehler bei normaler Anwendung. Der Prozess kann abnormale Anwendung erkennen, bewertet oder mindert die damit verbundenen Risiken jedoch nicht.
09
IEC 81001-5-1 ergänzt einen sicheren Produktlebenszyklus #
IEC 81001-5-1 definiert Lebenszyklusaktivitäten für die sichere Entwicklung und Wartung von Gesundheitssoftware. Sie überträgt Konzepte sicherer Entwicklung auf das besondere Gleichgewicht von Sicherheit, Effektivität und Cybersicherheit, das Gesundheitssoftware erfordert.
Rollen, Kompetenzen, Planung, Richtlinien und Entwicklungsumgebung
Assets, Vertrauensgrenzen, Angriffspfade, Auswirkungen und Risikobehandlung
Kontrollen, Architektur, Implementierung und Verifizierung
Restrisiko, sichere Auslieferung, Konfiguration und Dokumentation
Neue Erkenntnisse, koordinierte Offenlegung und Produktauswirkungen
Bewertung, Behebung, Kommunikation und kontrollierte Bereitstellung
Ein Penetrationstest kann diesen Lebenszyklus nicht ersetzen. Er ist eine Nachweisquelle innerhalb eines deutlich größeren Systems. Ebenso weist ein Zertifikat für Informationssicherheit auf Organisationsebene allein keine Cybersicherheit des Produkts nach.
10
Der Produktkontext entscheidet, was den Normenstapel ergänzt #
Die sechs zentralen Normen bilden keine universelle, abgeschlossene Liste. Hardware, Netzwerke, künstliche Intelligenz, Datenschutz, elektrische Sicherheit und die Bereitstellungsumgebung können weitere Normen und Leitlinien relevant machen.
Kann grundlegende Sicherheit, wesentliche Leistungsmerkmale und ergänzende Anforderungen bestimmen, wenn Software Teil eines medizinischen elektrischen Geräts ist.
Kann das Risikomanagement unterstützen, wenn Medizinprodukte in medizinischen IT-Netzwerken mit geteilter Verantwortung betrieben werden.
Kann ein Informationssicherheitsmanagementsystem unterstützen, ersetzt jedoch kein produktspezifisches Security Engineering.
Liefert Konzepte zum Ausgleich von Sicherheit, Effektivität und Cybersicherheit in Gesundheitssoftware und Gesundheits-IT-Systemen.
Eine Norm gehört in den Konformitätsplan, weil ihr Anwendungsbereich und der Produktkontext sie relevant machen, nicht weil sie auf der Checkliste eines anderen Herstellers stand.
11
Eine Normnummer ist noch keine rechtliche Konformitätsaussage #
Normen und Verordnungen erfüllen unterschiedliche Aufgaben. MDR und IVDR begründen rechtliche Pflichten. Normen stellen technische Prozesse und Lösungen bereit, die den Konformitätsnachweis unterstützen können.
Definiert die verbindlichen rechtlichen Anforderungen an Produkt und Hersteller
Eine gelistete Norm kann für die von ihrer Fundstelle erfassten Anforderungen eine Konformitätsvermutung begründen
Kann hohen Wert behalten, auch wenn sie nicht harmonisiert oder ihre neueste Ausgabe noch nicht gelistet ist
Anwendungsbereich, Ausgabe, Abweichungen, Nachweise und Verbindungen zu rechtlichen Anforderungen müssen dokumentiert sein
Die Anwendung harmonisierter Normen bleibt freiwillig. Der Nutzen hängt von der konkreten europäischen Ausgabe, Änderung, dem Datum und den durch die Fundstelle erfassten Anforderungen ab. Die neueste internationale Ausgabe und die aktuell harmonisierte europäische Ausgabe können unterschiedliche Dokumente sein.
Vor einem wesentlichen Release oder einer Einreichung sind aktuelle Ausgaben, Änderungen, Berichtigungen, Interpretationsblätter, Harmonisierungsstatus und Übergangsregelungen zu prüfen. Eine vor zwei Jahren kopierte Normenliste ist keine Konfigurationslenkung.
12
Eine gemeinsame Nachweisarchitektur kompilieren #
Die effizienteste Umsetzung nutzt Nachweise wieder, ohne Verantwortlichkeiten zu vermischen. Eine genehmigte Softwareanforderung kann zugleich eine Designeingabe erfüllen, eine Risikokontrolle umsetzen, eine Cybersicherheitsanforderung stützen und in eine gebrauchstauglichkeitskritische Aufgabe einfließen. Sie sollte nicht in vier unkontrollierte Dokumente kopiert werden.
Regulatorik · Produkt · Klinik · Risiko
Entwickeln und validieren wir dasselbe Produkt?Entwicklungslenkung · Risiko · Cybersicherheit · Gebrauchstauglichkeit
Ist jede kritische Anforderung zu ihrer Quelle und Verifizierung rückverfolgbar?IEC 62304 · Cybersicherheit · SOUP · Segregation
Sind Annahmen zu Sicherheit und Cybersicherheit an den Systemgrenzen sichtbar?Software · Produkt · Gebrauchstauglichkeit · Klinik
Decken die Nachweise Code, Systemverhalten und vorgesehenen Verwendungszweck ab?Konfiguration · Risiko · Produkt · Kommunikation
Ist der freigegebene Zustand identifizierbar und sind ungelöste Probleme akzeptabel?PMS · Wartung · CAPA · Cybersicherheit
Können Signale aus der Praxis die richtigen kontrollierten Aufzeichnungen ändern?Build-Fehler, die Begutachter erkennen
Der Hersteller kann nicht erklären, warum eine Norm angewandt, ausgeschlossen oder nur teilweise umgesetzt wird.
Zwei unterschiedliche Klassifizierungsfragen werden als austauschbar behandelt.
Umgesetzte Kontrollen, Anforderungen und Verifizierung beschreiben nicht mehr dasselbe Release.
Cybersicherheitsszenarien mit möglichen klinischen Folgen erreichen ISO 14971 nicht.
Kritische Aufgaben und gefährdungsbezogene Anwendungsszenarien gehen hinter allgemeinen Meinungen zur Schnittstelle verloren.
SOUP, übernommene Module und frühere Releases besitzen keine angemessene kontrollierte Begründung.
- Zweckbestimmung, regulatorischen Status und vollständige Produktgrenze definieren
- Ein Normenregister mit Anwendungsbereichen, Ausgaben und Anwendbarkeitsbegründungen erstellen
- Rechtliche Anforderungen den Normen, Prozessen und geplanten Nachweisen zuordnen
- QMS-, Risiko-, Software-, Gebrauchstauglichkeits- und Cybersicherheitspläne vor der Implementierung abstimmen
- Gemeinsame Kennungen und Rückverfolgbarkeit in den Entwicklungsworkflow integrieren
- Das vollständige Produkt validieren und nicht bei der Softwareverifizierung aufhören
- Eine kontrollierte Konfiguration mit bewerteten Anomalien und Restrisiken freigeben
- Wartung, PMS, Schwachstellen und Änderungen in dasselbe System zurückführen
Offizielle Quellen
- ISO-Überblick zu ISO 13485 für Qualitätsmanagementsysteme von Medizinprodukten
- ISO 14971 — Ausgabe 2019 zum Risikomanagement für Medizinprodukte
- IEC 62304 — Ausgabe 2006 mit Änderung 1 aus dem Jahr 2015 zu Software-Lebenszyklusprozessen
- IEC 82304-1 — Ausgabe 2016 zur Sicherheit von Gesundheitssoftwareprodukten
- IEC 62366-1 — Ausgabe 2015 mit Änderung 1 aus dem Jahr 2020 zum Usability Engineering
- IEC 81001-5-1 — Ausgabe 2021 zu sicheren Lebenszyklusaktivitäten für Gesundheitssoftware
- Überblick der Europäischen Kommission über harmonisierte Normen für Medizinprodukte
- Sammlung der Europäischen Kommission mit MDCG-Leitlinien zu Software und Cybersicherheit
Die Freigabeentscheidung
Die Normen müssen in einer gemeinsamen Produktwahrheit zusammenlaufen
ISO 13485 steuert die Organisation. ISO 14971 steuert die Risikologik. IEC 62304 steuert den Software-Lebenszyklus. IEC 62366-1 steuert die sicherheitsbezogene Interaktion. IEC 81001-5-1 steuert den sicheren Lebenszyklus. IEC 82304-1 hilft, die Argumentation auf Produktebene zu schließen.
Keine dieser Normen kann ein Produkt retten, dessen Zweck, Architektur, Nachweise und freigegebene Konfiguration einander widersprechen.
Das eigentliche Ergebnis ist kein Regal voller normenspezifischer Dateien. Es ist ein Release, dessen Sicherheit, Leistung, Cybersicherheit und Historie sich ohne Vermutungen rekonstruieren lassen.
Konformitätsarchitektur für medizinische Software
Müssen Sie überlappende Normen in ein praktikables Entwicklungs- und Nachweissystem überführen?
Softwareweg besprechen ↗Aus dem Wissenszentrum