Was gehört in die technische Dokumentation einer Medizinsoftware?

Die Akte muss das Produkt rekonstruierbar machen

Anhang II der Verordnung (EU) 2017/745 gliedert die technische Dokumentation in sechs Hauptbereiche. Gefordert werden Produktbeschreibung und Spezifikation, Herstellerinformationen, Entwicklungs- und Herstellungsangaben, Nachweis der grundlegenden Sicherheits- und Leistungsanforderungen, Nutzen-Risiko-Analyse mit Risikomanagement sowie Verifikation und Validierung. Anhang III verlangt zusätzlich die technische Dokumentation zur Überwachung nach dem Inverkehrbringen.

Für Medizinsoftware reicht deshalb weder ein Pflichtenheft noch ein Ordner mit Testprotokollen. Die Unterlagen müssen einen konsistenten Weg von Zweckbestimmung und Klassifizierung über Risiken und Anforderungen bis zu Nachweisen bilden.

Typische Bausteine für Software

Eine belastbare Dokumentation enthält insbesondere:

• eindeutige Produkt- und Versionsbeschreibung, Varianten, Module, Zubehör und vorgesehene Systemumgebung,
• medizinische Zweckbestimmung, Nutzer, Patientengruppen, Indikationen, Kontraindikationen und vorhersehbare Fehlanwendungen,
• Klassifizierungsbegründung nach MDR-Anhang VIII,
• Softwareanforderungen, Architektur, Schnittstellen, Datenflüsse und eingesetzte Fremdsoftware,
• Entwicklungs- und Wartungsplan nach IEC 62304:2006+A1:2015,
• Risikoakte nach ISO 14971:2019 mit Verknüpfung zu Anforderungen und Tests,
• Gebrauchstauglichkeitsakte nach IEC 62366-1:2015+A1:2020,
• Cybersecurity-Konzept einschließlich Bedrohungsmodell, sicherer Konfiguration, Updateweg und relevanter Softwarekomponenten,
• Testpläne, Ergebnisse und Rückverfolgbarkeit für Unit-, Integrations-, System-, Regressions- und Freigabetests,
• klinischer Bewertungsplan und klinischer Bewertungsbericht,
• Kennzeichnung, Gebrauchsanweisung und Installations- beziehungsweise Betriebsanforderungen,
• PMS-Plan, gegebenenfalls PMCF-Unterlagen und Verfahren für Vigilanz sowie Sicherheitskorrekturen im Feld.

MDR-Anhang II Nummer 6.1(b) nennt für Software ausdrücklich die Beschreibung von Design und Entwicklung sowie Nachweise der Verifikation und Validierung in der fertigen Produktkonfiguration. Dazu gehören zusammengefasste Ergebnisse interner Tests und Prüfungen in simulierter oder tatsächlicher Nutzungsumgebung vor der finalen Freigabe.

Ein lebendes, versionsgebundenes System

Dokumente dürfen einander nicht widersprechen. Ändert sich beispielsweise ein Algorithmus, sind Zweckbestimmung, Risikobeurteilung, klinische Evidenz, Cybersecurity, Tests, UDI-Auswirkung und Gebrauchsinformation gemeinsam zu prüfen. Baselines und Konfigurationsmanagement müssen zeigen, welche Anforderungen, Komponenten und Nachweise genau zu einer freigegebenen Version gehören.

Anhang II und III definieren den regulatorischen Inhalt, nicht ein bestimmtes Dateiformat. Ein elektronisches Dokumentenmanagementsystem ist geeignet, wenn Freigaben, Versionen, Änderungen und Verknüpfungen revisionsfest nachvollziehbar bleiben. Umfang und Tiefe richten sich nach Produkt, Risikoklasse und Zweckbestimmung; eine universelle Mustermappe ersetzt diese Begründung nicht.