Software-Lebenszyklus-Dokumentation nach IEC 62304

Das echte Ausmaß des Problems

IEC 62304, der Standard für den Software-Lebenszyklus in Medizinprodukten, verlangt, dass jede Softwarekomponente vollständig dokumentiert ist. Das bedeutet konkret:

• Software-Entwicklungsplan: Prozess, Rollen, Werkzeuge, Standards
• Anforderungsspezifikation: Was soll die Software tun?
• Architekturentwurf: Wie ist die Software strukturiert?
• Komponentenentwurf: Wie ist jede Komponente umgesetzt?
• Verifikationsprotokoll: Welche Tests wurden durchgeführt?
• Validierungsprotokoll: Wurden klinische und funktionale Anforderungen erfüllt?
• Nachverfolgbarkeitsmatrix: Jede Anforderung → Entwurf → Code → Test
• Versionshistorie: Alle Änderungen dokumentiert
• Risikoanalyse: Sicherheitsklasse und Risikobehandlung

Für ein mittleres Medizintechnik-Softwareteam, 5 bis 10 Entwickler, 100.000 bis 500.000 Zeilen Code, summiert sich das auf 600 bis 1.200 Stunden Dokumentationsaufwand pro Freigabezyklus. Wenn ein Zyklus 2 bis 3 Monate dauert, sitzt ein Entwickler in Teilzeit ständig an der Dokumentation, statt Fehler zu beheben oder Funktionen zu bauen.

Dazu kommt die Audit-Vorbereitung. Ist die Dokumentation zerstreut, brauchst du 2 bis 4 Wochen allein fürs Zusammentragen und Konsistenzprüfen. Ein fehlender Verweis in der Nachverfolgbarkeitsmatrix reicht für einen Auditbefund. Das kostet 10.000 bis 50.000 Euro an Nacharbeit oder Zertifizierungs-Verzögerungen.

Mit vs. ohne KI, ein ehrlicher Vergleich

¹ Schätzwerte aus Praxisberichten; keine repräsentative Erhebung. Ohne KI fehlen typischerweise 15 bis 20 Prozent der erwarteten Nachverfolgbarkeitsverweise oder sind mehrdeutig. Mit KI bleiben 2 bis 5 Prozent Lücken, meist bei Sonderfällen oder Richtlinien-Überschneidungen.

Einschätzung auf einen Blick

Zeitersparnis, hoch (4/5)
2 Stunden pro Sprint sind real und direkt spürbar. In 2-Wochen-Sprints sind das 5 bis 10 Stunden weniger Dokumentationsaufwand pro Monat. Aufs Jahr gerechnet sind es rund 120 Stunden für ein 6-köpfiges Team. Nicht die spektakulärste Zeiteinsparung unter den verglichenen Anwendungsfällen, aber konsistent und vorhersagbar.

Kosteneinsparung, mittel (3/5)
Die Einsparung entsteht doppelt: weniger Dokumentationszeit bringt rund 15.000 bis 20.000 Euro pro Jahr für ein 5- bis 6-köpfiges Team. Vermiedene Auditbefunde und Zertifizierungs-Verzögerungen schlagen mit 10.000 bis 100.000 Euro zu Buche, je nachdem, wie schwer ein Befund wiegt. Der zweite Block ist groß, aber schwer zu garantieren. Anders als bei der Rechnungsverarbeitung, wo die Einsparung sofort auf dem Konto sichtbar ist.

Schnelle Umsetzung, schwierig (2/5)
Ein Dokumentationssystem muss sich in Entwicklerwerkzeuge einklinken: Git, Jira, Confluence. Das KI-Modell muss die Codebasis, die Prozesse und die Architektur kennenlernen. 16 bis 24 Wochen sind realistisch. Das ist, zusammen mit der Risikoanalyse, die längste Einführungsphase in dieser Kategorie.

ROI-Sicherheit, hoch (4/5)
Der Nutzen ist messbar: Die Lückenquote in der Nachverfolgbarkeitsmatrix sinkt, Auditbefunde werden weniger, die Dokumentationszeit geht zurück. Keine 5, weil die Größe des Effekts stark vom Ausgangschaos abhängt. Ein Team mit bereits gut gepflegtem Prozess spart weniger als eines, das bei null anfängt.

Skalierbarkeit, hoch (4/5)
Das System wächst mit: mehr Commits, mehr Funktionen, mehr Freigaben. Mit mehr Daten wird die Dokumentation sogar besser, weil die KI die Muster im Team lernt. Keine 5, weil bei sehr großen Codebasen über 2 Millionen Zeilen die Antwortzeiten des Modells länger werden können, das ist aber ein technisches, kein strategisches Problem.

Richtwerte, stark abhängig von Codebase-Größe, Komplexität, Release-Frequenz und vorhandener Dokumentations-Disziplin.

Was ein Software-Dokumentations-System konkret macht

Das System arbeitet in vier Phasen:

Phase 1: Dokumentation direkt aus dem Code ziehen
Das System liest die Git-Historie aus: Welche Dateien wurden geändert? Welche Commits lagen dazwischen? Welche Zweige wurden zusammengeführt? Daraus entsteht automatisch ein Änderungsprotokoll und eine Entwicklungsgeschichte. Neu ist das nicht, aber KI macht es lesbar: Statt „Commit XY änderte Datei Z” schreibt sie „Funktion ABC wurde umgesetzt durch den Umbau des Parser-Moduls, eine neue Fehlerbehandlungs-Logik und drei neue Komponententests.” Das kommt dem nahe, was ein Mensch selbst formulieren würde.

Phase 2: Nachverfolgbarkeitsmatrix aufbauen
Das ist der kritischste Teil. IEC 62304 verlangt, dass sich jede Anforderung aus der Spezifikation zu einem Entwurfselement, einem Code-Modul und einem Testfall zurückverfolgen lässt. Manuell ist das Fleißarbeit, eine Anforderung kann in 3 bis 5 Dateien stecken. Die KI liest die Spezifikation, scannt den Code, verknüpft semantisch und erzeugt die Matrix: „Anforderung REQ-123 wird in Modul M-45 (Zeilen 234 bis 567) umgesetzt und durch Test TC-89 geprüft.” Das ist in der Regel zu 80 bis 90 Prozent richtig und erspart den Großteil manueller Konsistenzprüfungen.

Phase 3: Fehler erkennen und Konformität prüfen
Das System prüft: Hat jede Anforderung einen Test? Gibt es Code-Zeilen, die von keiner Anforderung gedeckt sind? Sind die Konsequenzen der Sicherheitsklasse beachtet, höhere Klasse, strengere Tests? Das ist Audit-Vorbereitung nebenbei.

Phase 4: Dokumentation ausliefern
Am Ende des Zyklus liefert das System ein Dossier in IEC-62304-Struktur: Entwicklungsplan, Anforderungsspezifikation, Architektur, Nachverfolgbarkeitsmatrix, Testergebnisse, Freigabenotizen. Das ist für Benannte Stellen oder interne Audits direkt verwendbar.

Ein konkretes Beispiel

Ein Medizintechnik-Startup pflegt eine App zur Glukose-Überwachung. Dreierteam, 50.000 Zeilen Kotlin. Der Lead-Entwickler schiebt einen Commit mit Schweregrad MAJOR (Sicherheitskorrektur fürs Bluetooth-Pairing). Das System:

1. erkennt: Das ist sicherheitsklassen-relevant.
2. prüft: Gibt es ein Anforderungsdokument für Bluetooth-Sicherheit? Ja.
3. verknüpft: Dieser Commit setzt Anforderung REQ-SEC-005 um.
4. prüft: Gibt es Komponententests für diesen Code? Ja, fünf Tests.
5. erzeugt: Nachverfolgbarkeits-Verweis REQ-SEC-005 → Code-Zeilen 234–456 → Tests TC-SEC-001 bis 005.
6. dokumentiert: automatisch einen Abschnitt in den Freigabenotizen.

Alles ohne manuelle Einträge.

Konkrete Werkzeuge, was wann passt

Es gibt verschiedene Ansätze zur Software-Dokumentation:

Eigenbau mit Git und Claude- oder ChatGPT-Schnittstelle
Ein kleines Skript liest Git-Commits aus und lässt Claude oder ChatGPT daraus strukturierte Dokumentation erzeugen. Die Nachverfolgbarkeitsmatrix bleibt manuell. Aufwand: 40 bis 60 Stunden, 5.000 bis 10.000 Euro. Vorteil: günstig. Nachteil: Nachverfolgbarkeit nicht automatisiert. Sinnvoll für: Teams mit unter 50.000 Codezeilen, maximal 2 Freigaben pro Jahr, noch ohne regulatorischen Druck.

Spezialisierte Software-QMS-Plattformen
SimplerQMS mit GitHub-Anbindung kann die Dokumentation teilweise automatisieren, muss aber konfiguriert werden. Einrichtung: 12 bis 16 Wochen. Kosten: 3.000 bis 5.000 Euro im Monat. Die Nachverfolgbarkeitsmatrix bleibt teilautomatisch, KI-Unterstützung ist begrenzt. Sinnvoll für: Teams mit etabliertem QM-System, die sich auf eine Benannte Stelle vorbereiten.

Entwickler-Plattformen mit Erweiterungen
Werkzeuge wie GitHub Advanced Security zusammen mit Azure DevOps und eigenen Erweiterungen liefern ein vollständiges Bild, brauchen aber viel Einrichtungsarbeit. 20.000 bis 50.000 Euro Einrichtung. Sinnvoll für: mehr als 100 Entwickler, komplexes Produktportfolio.

Eigenentwicklung mit Claude und semantischer Code-Analyse
Bei sehr speziellen Anforderungen, etwa mehrsprachigen Codebasen oder eigenen IEC-Auslegungen, kann Eigenbau schneller sein. Die Claude-Schnittstelle für semantische Code-Analyse (nicht nur Mustererkennung) ist stark. Aufwand: 60 bis 100 Stunden, 8.000 bis 15.000 Euro. Sinnvoll für: Nischen-Hersteller mit sehr speziellen Anforderungen.

Datenschutz und Datenhaltung

Code und Dokumentation sind nicht öffentlich und oft firmeneigen. Beim KI-Einsatz gilt:

• Der Code darf nicht in die Trainingsdaten von OpenAI wandern. Die Claude-Schnittstelle sichert vertraglich zu, dass Eingaben nicht zum Training verwendet werden.
• Am sichersten ist eine Eigenlösung mit lokaler Inferenz.
• SimplerQMS hostet in der EU und ist DSGVO-konform.
• Ein AVV ist formal nicht zwingend, weil Quellcode selbst keine personenbezogenen Daten enthält. Konformitätsprüfungen fragen aber trotzdem nach EU-Hosting.

Was es kostet, realistisch gerechnet

Annahmen für die Rechnung:

• Team mit 6 Entwicklern, 100.000 Codezeilen, 4 Freigaben pro Jahr
• Zeitersparnis: 10 bis 15 Stunden je Freigabe, also 40 bis 60 Stunden pro Jahr
• Stundensatz Entwicklung: 100 Euro → 4.000 bis 6.000 Euro Zeiteinsparung jährlich
• Vermiedene Auditbefunde: 10.000 bis 30.000 Euro pro Jahr (konservativ)

Mit dem schlanken Eigenbau bist du in 6 bis 10 Monaten im Plus. Mit einer Unternehmens-Plattform erst nach 14 bis 20 Monaten.

Drei typische Einstiegsfehler

1. Automatisierung auf Kosten der Genauigkeit.
Das System baut die Nachverfolgbarkeitsmatrix automatisch auf, aber mit 10 bis 15 Prozent Fehlern: falsche oder fehlende Verknüpfungen. Teams übernehmen die Matrix blind, statt zu prüfen. Im Audit kommt dann heraus: „Anforderung XY soll durch Test TC-89 abgesichert sein, aber der Test prüft etwas ganz anderes.” Was hilft: Eine feste Prüfphase einplanen, nicht als Nice-to-have behandeln.

2. Dokumentation spiegelt eins zu eins den Code.
Das System erzeugt eine Dokumentation, die exakt die Code-Struktur abbildet. Technisch korrekt, aber nur für Entwickler lesbar, nicht für Auditoren oder die Regulierungsabteilung. Was hilft: Eine Nachbearbeitungs-Vorlage bauen, die die Rohdokumente ins Standardformat nach IEC 62304 überträgt.

3. Alt-Code wird ignoriert.
Das System läuft, dokumentiert neue Freigaben sauber. Aber Code, der vor drei Jahren geschrieben wurde und immer noch produktiv läuft, ist nicht erfasst. Im Audit fällt das auf. Was hilft: Eine Anfangsphase von 2 bis 4 Wochen einplanen, in der die bestehende Codebasis rückwirkend dokumentiert wird.

Was mit der Einführung wirklich passiert, und was nicht

Was passiert:

• Woche 1–4: Werkzeuge einrichten, Git und Jira anbinden, den IEC-62304-Prozess beschreiben.
• Woche 5–8: Trainingsdaten sammeln, 3 bis 5 alte Freigaben durchgehen und manuell dokumentieren, um eine Referenz zu setzen.
• Woche 9–14: Erste echte Freigabe mit KI-Unterstützung, alle erzeugten Dokumente werden vollständig geprüft.
• Woche 15–20: Zweite Freigabe, die Prüfung sinkt auf 50 Prozent Stichprobe.
• Ab Woche 21: Regelbetrieb, volle Automatisierung mit quartalsweisen Plausibilitätsprüfungen.

Was nicht passiert:

• Ein Mensch prüft die Dokumentation weiterhin, KI ersetzt nicht die Freigabe.
• Code-Qualität und Testabdeckung müssen weiterhin manuell geprüft werden.
• Die Audit-Vorbereitung geht schneller. Das Audit selbst bleibt genauso streng.

Realistischer Zeitplan mit Risikohinweisen

Kritisches Risiko: Die Anbindung an Altsysteme deckt oft unerwartete Komplexität auf. Gegenmaßnahme: IT-Architektur-Review in Phase 2 durchführen, nicht später.

Häufige Einwände, und was dahintersteckt

„Unsere Codebasis ist zu komplex, die KI wird das nie verstehen.”
Wahrscheinlich stimmt das bei 1 bis 2 Millionen Codezeilen mit vielen eigenen Mustern. Aber die KI muss auch nicht alles verstehen. Sie muss 80 Prozent automatisieren und die restlichen 20 Prozent zur manuellen Prüfung markieren. Das ist schon ein Gewinn.

„Wir haben schon ein LIMS, ein ELN oder ein QMS, warum noch ein System?”
Berechtigter Einwand. Wenn ihr SimplerQMS oder Ähnliches habt, ist eine Anbindung besser als ein Parallelsystem. Die Frage ist: Kann euer QMS mit Git und eurer Entwicklungs-Pipeline reden? Wenn nein, lohnt eine Zwischenschicht.

„Das rentiert sich nur für große Teams, wir sind zu dritt.”
Auch Dreierteams mit kritischer Software (Klasse II oder III) müssen dokumentieren. Der schlanke Eigenbau mit Git und KI-Schnittstelle (5.000 bis 10.000 Euro Einrichtung) ist günstiger als Unternehmens-Software und halbiert die Dokumentationslast trotzdem.

Woran du merkst, dass das zu dir passt

✓ Ihr habt aktive Software-Entwicklung mit mindestens zwei Freigaben pro Jahr
✓ Eure Codebasis umfasst mehr als 50.000 Zeilen
✓ Mindestens eine Person im Team kennt IEC 62304
✓ Audits durch eine Benannte Stelle sind geplant oder laufen regelmäßig

✗ Ausschlusskriterium 1: Ihr entwickelt Klasse-I-Software ohne regulatorischen Druck. Dann ist die Dokumentation optional.

✗ Ausschlusskriterium 2: Eure Codebasis besteht aus vielen eigenen Frameworks, auf die sich keine KI sinnvoll trainieren lässt. Die Vorhersagen werden zu fehlerhaft.

✗ Ausschlusskriterium 3: Ihr habt weder Git noch eine Entwicklungs-Pipeline, oder euer Prozess ist sehr informell. Dann müsst ihr erst den Prozess ordnen.

Das kannst du heute noch tun

1. Prüf deine aktuelle Software-Dokumentation. Nimm eine alte Freigabe und geh sie durch: Ist die Nachverfolgbarkeitsmatrix vollständig? Gibt es Code ohne zugehörige Anforderungen? Notiere die Lücken. Das zeigt dir, wo Automatisierung wirklich etwas bringt.

2. Exportiere dein Git-Log der letzten zwei Freigaben. Ein kurzes Skript reicht, das alle Commits ausliest. Das wird die Eingabe für einen Machbarkeitstest mit ChatGPT oder Claude.

3. Schreib einen Dokumentations-Prompt (siehe unten) und teste ihn mit einem echten Commit aus eurem Repo.

Quellen & Methodik

• IEC 62304:2015, Medical device software lifecycle processes, Johner Institut Übersicht, April 2026
• Requirements Traceability Matrix, Ketryx Guide, Praktische Guidance zur RTM-Implementierung, abgerufen April 2026
• FDA Traceability for Medical Devices, ComplianceQuest Regulatory Perspective, abgerufen April 2026
• Software Development according to IEC 62304, Risk Manager Erläuterungen, 2021
• Kennzahlen in der Vergleichstabelle (Lückenquoten, Auditbefunde, Zeitaufwände): Schätzwerte aus Praxisberichten und internen Erfahrungswerten; keine repräsentative Studie