Medizinproduktesoftware · Nachweisarchitektur · Lebenszykluskontrolle
Technische Dokumentation für Medizinproduktesoftware
Die Nachweise hinter dem Code
Eine technische Dokumentation sollte den Weg von der medizinischen Zweckbestimmung der Software zu jeder sicherheitsrelevanten Anforderung, Risikokontrollmaßnahme, jedem Prüfergebnis und jeder Entscheidung nach dem Inverkehrbringen lückenlos nachvollziehbar machen.
Der Nachweiskette folgen ↓Regulatorische Vorgaben
01Zweckbestimmung 02Anforderungen 03RisikokontrollenGelenkte Nachweise
04V&V-Aufzeichnungen 05Klinische Nachweise 06PMS-RückmeldungenTechnische Dokumentation als System
Vollständigkeit lässt sich nicht an der Zahl der Dokumente messen
Zusammenhängend
Claims, Risiken, Anforderungen und Prüfungen müssen dieselbe medizinische Funktion beschreiben.
Versionsbezogen
Die Nachweise müssen genau der Softwarekonfiguration entsprechen, die in Verkehr gebracht wird.
Lebenszyklusübergreifend
Informationen nach dem Inverkehrbringen müssen in Risikomanagement, Bewertung und Änderungskontrolle zurückfließen.
Zweckbestimmung → Anforderungen → Risiken und Kontrollen → Verifizierung → klinische Nachweise oder Leistungsnachweise → Freigabe → Überwachung
01
Technische Dokumentation ist für jede MDSW erforderlich #
Jeder Hersteller eines Medizinprodukts muss technische Dokumentation erstellen und auf dem aktuellen Stand halten. Das gilt unabhängig davon, ob eine Benannte Stelle am Konformitätsbewertungsverfahren beteiligt ist.
Artikel 10 Absatz 4 sowie die Anhänge II und III der MDR und IVDR legen die grundlegenden Anforderungen fest. Die Dokumentation muss klar, geordnet, leicht durchsuchbar und so detailliert sein, dass sich die Konformität mit der anwendbaren Verordnung bewerten lässt.
Bei Software bedeutet das weit mehr, als einige Prüfberichte neben eine Produktbeschreibung zu legen. Die technische Dokumentation muss die regulatorische Identität der Software mit den Nachweisen aus Entwicklung und Marktbeobachtung verbinden.
Die technische Dokumentation wird nicht nur für die Zertifizierung erstellt. Auch Software der Klasse I nach MDR und der Klasse A nach IVDR benötigt eine vollständige technische Dokumentation, obwohl vor dem Inverkehrbringen keine Prüfung durch eine Benannte Stelle erfolgt.
02
Was die technische Dokumentation enthalten muss #
Die regulatorische Grundstruktur ist bei unterschiedlichen Produkttypen ähnlich. Jeder Abschnitt muss jedoch auf die konkrete Software, ihre Zweckbestimmung und die freigegebene Konfiguration zugeschnitten sein.
Produktidentität
Produktname, medizinische Zweckbestimmung, Anwender, Patientengruppe, Anwendungsumgebung, Funktionsprinzip, Varianten, Plattformen und Versionen.
Qualifizierung und Klassifizierung
Warum die Software MDSW ist, ob MDR oder IVDR gilt, welche Regel angewendet wird und welche Risikoklasse daraus folgt.
Bereitgestellte Informationen
Kennzeichnung, Gebrauchsanweisung, Installationsinformationen, Warnhinweise und sicherheitsrelevante Elemente der Benutzeroberfläche.
Design und Entwicklung
Anforderungen, Architektur, Module, Schnittstellen, Datenflüsse, Abhängigkeiten, Build-Umgebung, Freigaben und Änderungen.
GSPR-Nachweise
Anwendbare Anforderungen aus Anhang I, Methoden zum Konformitätsnachweis und genaue Verweise auf die gelenkten Belege.
Risikomanagement
Gefährdungen, Gefährdungssituationen, Risikokontrollmaßnahmen, Nutzen-Risiko-Schlussfolgerungen und Rückverfolgbarkeit bis zu Umsetzung und Prüfung.
Verifizierung und Validierung
Anforderungsbasierte Prüfungen, Integration, Systemleistung, Gebrauchstauglichkeit, Sicherheit, Interoperabilität und Freigabeentscheidung.
Nachweise nach dem Inverkehrbringen
PMS-Planung, Beschwerden, Vigilanz, Trends, Cybersicherheitssignale, PMCF oder PMPF und der jeweils erforderliche periodische Bericht.
Eine praktische Checkliste für die technische Dokumentation von MDSW kann bestätigen, dass die erwarteten Abschnitte vorhanden sind. Sie kann jedoch nicht beurteilen, ob die darin enthaltenen wissenschaftlichen und technischen Nachweise ausreichend sind.
03
Was die Dokumentation von MDSW besonders macht #
Die in den Anhängen II und III vorgegebene Struktur gilt für alle Produkte. Die Nachweise innerhalb dieser Struktur müssen jedoch die Eigenschaften des jeweiligen Produkts abbilden.
Bei einem physischen Produkt betreffen viele Nachweise Materialien, Abmessungen, Sterilisation, Verpackung oder mechanische Leistung. Bei MDSW stehen andere Fragen im Mittelpunkt.
Lässt sich jede sicherheitsrelevante Funktion auf eine Anforderung zurückführen?
Kann die freigegebene Konfiguration eindeutig identifiziert und reproduziert werden?
Werden vorhersehbare Fehler und Anwendungsfehler beherrscht?
Ist die Softwareausgabe für die beanspruchte medizinische Zweckbestimmung valide?
Können Probleme im Feld und Schwachstellen erkannt und sicher behoben werden?
Diese Fragen verleihen der Softwaredokumentation ihren besonderen Charakter. Sie erklären auch, warum ein Ordner mit Prüfberichten zum Quellcode allein noch keine technische Dokumentation für ein Medizinprodukt darstellt.
04
Nachweise zum Software-Lebenszyklus #
Die Lebenszyklusdokumentation sollte zeigen, wie Anforderungen in Architektur, Implementierung und verifizierte Funktionalität überführt werden. Sie muss außerdem belegen, wie Anomalien, Änderungen und Freigaben gelenkt werden.
Planung
Prozesse · Verantwortlichkeiten · SicherheitsklasseAnforderungen
Funktionen · Schnittstellen · RisikokontrollenArchitektur
Module · Abhängigkeiten · TrennungV&V
Protokolle · Ergebnisse · RückverfolgbarkeitFreigabe
Konfiguration · Anomalien · GenehmigungWartung
Probleme · Änderungen · RegressionstestsIEC 62304 wird häufig verwendet, um diese Nachweise zu strukturieren. Die Norm ist sehr relevant, doch die Konformität mit IEC 62304 allein belegt noch keine Konformität mit MDR oder IVDR. Sie ersetzt weder die klinische Bewertung oder Leistungsbewertung noch Gebrauchstauglichkeit, Cybersicherheit, regulatorisches Risikomanagement oder Überwachung nach dem Inverkehrbringen.
Normen stellen anerkannte Methoden bereit. Der Hersteller muss dennoch zeigen, wie die gesamte Nachweisführung die anwendbaren Grundlegenden Sicherheits- und Leistungsanforderungen erfüllt. Mehr dazu finden Sie im MDRC-Beitrag über die Lebenszykluskonformität nach IEC 62304.
05
Klinische Nachweise oder Leistungsnachweise #
Medizinproduktesoftware muss mehr leisten, als nur störungsfrei zu funktionieren. Ihre Ausgabe muss für die beanspruchte medizinische Zweckbestimmung valide sein.
Klinische Bewertung
Der Hersteller verbindet eine valide klinische Assoziation, die technische Leistung und die klinische Leistung mit der medizinischen Zweckbestimmung.
Leistungsbewertung
Der Hersteller behandelt wissenschaftliche Validität, analytische Leistung und klinische Leistung der aus Proben gewonnenen Informationen.
Ein technisch genauer Algorithmus ist nicht automatisch klinisch valide. Die Dokumentation muss zeigen, dass die ausgegebene Information für den klinischen oder diagnostischen Claim des Herstellers aussagekräftig ist.
Das Leitliniendokument MDCG 2020-1 der Europäischen Kommission erläutert, wie diese Nachweiskomponenten speziell auf Medizinproduktesoftware anzuwenden sind.
06
Gebrauchstauglichkeit #
Ein richtiges Ergebnis ist wenig wert, wenn Anwender es missverstehen, einen Warnhinweis übersehen oder den falschen Patienten oder Parameter auswählen können.
Die Dokumentation zur Gebrauchstauglichkeit sollte die Software in ihrer tatsächlichen Anwendungsumgebung untersuchen. Dazu gehören Bildschirmgestaltung, Arbeitsabläufe, Warnmeldungen, Dateneingabe, Interpretation der Ergebnisse und vernünftigerweise vorhersehbare Anwendungsfehler.
IEC 62366-1 wird häufig verwendet, um den Prozess der Gebrauchstauglichkeit zu strukturieren. Die Nachweise sollten erkannte anwendungsbezogene Gefährdungen mit Anforderungen an die Benutzeroberfläche, Risikokontrollmaßnahmen und einer Validierung mit repräsentativen Anwendern verbinden.
07
Cybersicherheit gehört zur Produktsicherheit #
Cybersicherheit ist keine getrennte IT-Aufgabe. Ein kompromittiertes Konto, ein veränderter Datenstrom, ein nicht verfügbarer Dienst oder eine verwundbare Abhängigkeit kann ein Medizinprodukterisiko verursachen.
Die technische Dokumentation sollte Sicherheitsarchitektur, Zugriffskontrollen, Datenschutz, sichere Kommunikation, Update-Mechanismen, Protokollierung, Abhängigkeitsmanagement und den Umgang mit Schwachstellen abdecken.
Die Prüfungen können Schwachstellenscans, Penetrationstests, Fuzz-Tests und die Analyse von Drittanbieterkomponenten umfassen. Der Hersteller sollte außerdem festlegen, wie neu entdeckte Schwachstellen nach der Freigabe bewertet und behandelt werden.
Eine ausführlichere Betrachtung dieses Lebenszyklus finden Sie im Beitrag zur Cybersicherheit von Medizinproduktesoftware.
08
Versions- und Konfigurationskontrolle #
Bei Software kann sich die Identität des Produkts ändern, ohne dass eine sichtbare physische Änderung erkennbar ist.
Die technische Dokumentation muss die regulierte Version eindeutig identifizieren und sie von früheren Freigaben, Entwicklungs-Builds und nicht medizinischen Konfigurationen unterscheiden. Sie sollte festlegen, welche Änderungen Regressionstests, eine aktualisierte Risikobewertung, überarbeitete klinische Nachweise oder Leistungsnachweise, eine neue UDI-DI oder die Abstimmung mit einer Benannten Stelle erfordern.
Bei cloudbasierten Produkten muss die Versionskontrolle auch serverseitige Änderungen, Infrastrukturabhängigkeiten, APIs und Drittanbieterdienste erfassen, die unabhängig von der nutzerseitigen Anwendung aktualisiert werden können.
09
Reine Software ist nicht immer systemunabhängig #
Es wäre irreführend anzunehmen, dass elektrische Sicherheit, Biokompatibilität und andere Nachweise zu physischen Produkten aus der Softwaredokumentation grundsätzlich ausgeschlossen werden können.
Bei echten reinen Softwareprodukten können solche Anforderungen nicht anwendbar sein. Diese Nichtanwendbarkeit muss jedoch begründet werden. Arbeitet die MDSW mit Sensoren, Wearables, diagnostischen Instrumenten, Servern oder anderer Hardware, kann der Hersteller Nachweise zur Kompatibilität, Interoperabilität und Sicherheit der gesamten vorgesehenen Konfiguration benötigen.
Die technische Dokumentation sollte das tatsächliche Produktsystem abbilden und nicht eine künstliche Grenze um den Quellcode ziehen.
10
Nachweise nach dem Inverkehrbringen halten die Dokumentation aktuell #
Die technische Dokumentation ist mit der Softwarefreigabe nicht abgeschlossen. Erkenntnisse nach dem Inverkehrbringen müssen in Risikomanagement, klinische Bewertung oder Leistungsbewertung, Cybersicherheit, Gebrauchstauglichkeit und Änderungskontrolle zurückfließen.
Artikel 84 verlangt den PMS-Plan. Für Produkte der Klasse I ist der PMS-Bericht nach Artikel 85 erforderlich. Für die Klassen IIa, IIb und III gilt der PSUR nach Artikel 86.
Artikel 79 verlangt den PMS-Plan. Für die Klassen A und B ist der PMS-Bericht nach Artikel 80 erforderlich. Für die Klassen C und D gilt der PSUR nach Artikel 81.
Wenn anwendbar, erzeugt die klinische Nachbeobachtung nach dem Inverkehrbringen gemäß MDR oder die Leistungsnachbeobachtung nach dem Inverkehrbringen gemäß IVDR zusätzliche Nachweise. Die daraus resultierende Bewertung fließt in die klinische Bewertung oder Leistungsbewertung und in die technische Dokumentation ein. Relevante Schlussfolgerungen werden außerdem im jeweils anwendbaren PMS-Bericht oder PSUR berücksichtigt.
Der PMCF- oder PMPF-Bewertungsbericht ersetzt die technische Dokumentation nicht und ist auch nicht lediglich eine Anlage zum PSUR. Er ist einer der Nachweisströme, die die Bewertung des Produkts aktuell halten.
Ein schlüssiges System zur Überwachung nach dem Inverkehrbringen verwandelt Informationen aus dem Markt in gelenkte regulatorische Entscheidungen.
11
Technische Dokumentation sollte eine schlüssige Geschichte erzählen #
Die stärkste technische Dokumentation für MDSW liest sich nicht wie eine Sammlung voneinander unabhängiger Vorlagen. Sie stellt eine gelenkte und überprüfbare Argumentation dar.
- Dies ist die medizinische Zweckbestimmung der Software.
- Diese Entscheidungen oder Handlungen unterstützt sie.
- In diesen Situationen könnte ein Fehler Schaden verursachen.
- Diese Kontrollen wurden entwickelt, um die Risiken zu reduzieren.
- Diese Prüfungen belegen, dass die Kontrollen funktionieren.
- Diese Nachweise stützen die klinischen oder diagnostischen Claims.
- Diese freigegebene Version entspricht dem dokumentierten und validierten Produkt.
- Dieses System zur Marktbeobachtung erkennt, wann Nachweise, Risiken oder Kontrollen angepasst werden müssen.
Werden diese Aussagen durch klare Rückverfolgbarkeit miteinander verbunden, ist die technische Dokumentation mehr als nur eine regulatorische Anforderung. Sie wird zu einem praktischen Modell dafür, wie der Hersteller seine Software versteht, kontrolliert und Verantwortung für sie übernimmt.
Fazit
Medizinproduktesoftware ist immateriell. Ihre Nachweise dürfen es nicht sein.
Die technische Dokumentation nach MDR oder IVDR muss Zweckbestimmung, Klassifizierung, Designarchitektur, Software-Lebenszyklus, Risikomanagement, Gebrauchstauglichkeit, Cybersicherheit, Verifizierung und Validierung, klinische Nachweise oder Leistungsnachweise sowie die Überwachung nach dem Inverkehrbringen zusammenführen.
Das Ziel besteht nicht darin, eine möglichst große Dokumentensammlung zu produzieren. Erforderlich ist eine präzise und belastbare Nachweisführung, die zeigt, dass die Software sicher ist, wie vorgesehen funktioniert und während ihres gesamten Lebenszyklus unter Kontrolle bleibt.
Für Hersteller auf dem Weg zur CE-Kennzeichnung von Medizinproduktesoftware unterscheidet genau diese Kohärenz häufig eine Dokumentation, die nur vollständig aussieht, von einer Dokumentation, die einer gründlichen regulatorischen Prüfung standhält.
Technische Dokumentation
Sollen aus Ihren Softwareentwicklungsunterlagen eine schlüssige und belastbare technische Dokumentation werden?
Softwaredokumentation besprechen ↗Aus dem Wissenszentrum