Software-Updates & Patches nach MDR dokumentieren
Was Hersteller bei Änderungen unbedingt beachten müssen
Kontakt aufnehmenWarum Updates in der Medizintechnik besonders kritisch sind
In regulierten Softwareprojekten gehören Updates, Bugfixes und Funktionsänderungen zum Alltag. Gleichzeitig stellen sie ein potenzielles Risiko für Sicherheit, Leistung und klinischen Nutzen dar – weshalb die MDR, die IEC 62304 und die ISO 14971 klare Anforderungen an die Dokumentation und Bewertung von Änderungen stellen.
Ohne nachvollziehbare Update-Dokumentation gilt eine Software nicht als regelkonform betreut. Besonders Benannte Stellen prüfen streng:
- Bewertung der Änderung (Impact Analysis)
- Nachweis der Risikokontrolle
- Änderungs- und Versionshistorie
- aktualisierte Testnachweise
- Auswirkungen auf IFU, UI-Texte & Warnhinweise
Eine Einführung zu Grundprinzipien finden Sie in unserer Softwaredokumentation – Was gehört hinein?.
Welche Anforderungen gelten für Software-Updates?
Die MDR behandelt Updates wie jede andere Änderung am Medizinprodukt: Sie dürfen Sicherheit und Leistung nicht beeinträchtigen und müssen nachvollziehbar dokumentiert werden. Die IEC 62304 ergänzt dies um klare Vorgaben für Software-Lebenszyklen.
1. Bewertung der Änderung (Impact Analysis)
Für jedes Update muss dokumentiert werden:
- Was wurde geändert?
- Warum wurde es geändert?
- Welche Module/Komponenten sind betroffen?
- Gibt es Auswirkungen auf Risiken, Anforderungen oder Tests?
- Gibt es Auswirkungen auf die Software-Sicherheitsklasse?
2. Risikoanalyse aktualisieren
Jede Änderung kann neue Risiken erzeugen oder bestehende beeinflussen. Daher fordert ISO 14971:
- Bewertung der Gefährdungssituationen
- Überprüfung der Risikokontrollmaßnahmen
- Verifikation der Wirksamkeit
Mehr dazu finden Sie in unserer Seite zum Software-Risikomanagement.
3. Testdokumentation aktualisieren
Typische Nachweise:
- Regressionstests
- modulspezifische Tests
- Systemtests
- Verifikation der Risikokontrollen
4. Versions- und Konfigurationsmanagement
IEC 62304 verlangt ein strukturiertes Konfigurationsmanagement, z. B.:
- Versionierung der Software
- Änderungsdokumentation
- Freigabe-Workflows
- Archivierung früherer Versionen
5. Release Notes & Änderungsübersicht
Release Notes müssen für regulierte Software überprüfbar und nachvollziehbar sein – nicht marketingorientiert.
- Beschreibung der Änderungen
- betroffene Komponenten
- Hinweise zu Risiken & sicherheitsrelevanten Anpassungen
- Informationen für Anwender/Support
6. Auswirkungen auf Technische Dokumentation & IFU
Jede Softwareänderung kann Einfluss auf Benutzerführung, Warnhinweise oder IFU haben.
- Anpassung der IFU (falls erforderlich)
- Aktualisierung von UI-Texten
- Überprüfung sicherheitsrelevanter Hinweise
- Änderungen in der technischen Dokumentation (z. B. SRS, Architektur, Tests)
Meldepflichtige Änderungen: Wann muss ich die Behörde informieren?
Nicht jede Änderung ist meldepflichtig. Die MDR unterscheidet zwischen:
- wesentlichen Änderungen (meldepflichtig)
- nicht-wesentlichen Änderungen (nicht meldepflichtig, aber dokumentationspflichtig)
Wesentliche Änderungen können sein:
- neue Funktionen, die das Verhalten des Produkts verändern
- Änderungen sicherheitskritischer Module
- neue Algorithmen oder Risikokontrollmaßnahmen
- UI-Änderungen, die Einfluss auf kritische Benutzeraufgaben haben
- Fehlerkorrekturen, die ein sicherheitsrelevantes Problem beheben
Der wichtigste Punkt: Jede Änderung muss dokumentiert werden – unabhängig von der Meldepflicht.
Typische Fehler bei der Dokumentation von Updates
- Keine Impact Analysis („nur ein kleiner Bugfix“)
- Fehlende Traceability zu Risiken und Tests
- Release Notes zu oberflächlich
- Risikokontrollen nicht erneut verifiziert
- Änderungen nicht in Architektur & SRS nachgeführt
- UI-Änderungen nicht im IEC-62366-Kontext bewertet
Weitere häufige Fehler erläutern wir im Artikel Typische Fehler in Softwaredokumentationen.
Best Practices für Updates & Patches
- Änderungsmanagementprozess definieren (IEC 62304 & MDR)
- Release Notes strukturieren – technisch, nicht marketingorientiert
- Risikoanalyse immer aktualisieren
- Teststrategie für Updates festlegen (Regression + gezielte Tests)
- UI-Änderungen mit Usability Engineering verknüpfen
- klare Versionierung im gesamten Software-Doku-System
- Dokumente synchron halten (SRS, Architektur, Tests, Risikoakte)
Eine passende Dokumentenstruktur finden Sie in unserer Vorlage für Softwaredokumentation.