Software-Lebenszyklus-Dokumentation nach IEC 62304

Das echte Ausmaß des Problems

IEC 62304, der Standard für den Software-Lebenszyklus in Medizinprodukten, ist der anerkannte Weg, die Anforderung aus Anhang I Abschnitt 17.2 MDR zu erfüllen: Software nach dem Stand der Technik entwickeln, unter Berücksichtigung von Lebenszyklus, Risikomanagement einschließlich Informationssicherheit, Verifizierung und Validierung. Wie tief dokumentiert wird, hängt von der Software-Sicherheitsklasse A, B oder C ab, Klasse A braucht deutlich weniger als Klasse C. Typische Bestandteile:

• Software-Entwicklungsplan: Prozess, Rollen, Werkzeuge, Standards
• Anforderungsspezifikation: Was soll die Software tun?
• Architekturentwurf: Wie ist die Software strukturiert?
• Detaillierter Entwurf: Wie sind die Einheiten umgesetzt? Je nach Sicherheitsklasse
• Verifikationsprotokoll: Welche Tests wurden durchgeführt?
• Nachverfolgbarkeitsmatrix: Jede Anforderung → Entwurf → Code → Test
• Versionshistorie und Konfigurationsmanagement: Alle Änderungen dokumentiert
• Software-Risikomanagement: Sicherheitsklasse und Risikobehandlung, eingebettet in ISO 14971

Die Validierung, ob das Produkt seine klinischen Anforderungen erfüllt, deckt IEC 62304 nicht ab. Sie gehört zur Design-Validierung des Produkts, bei eigenständiger Gesundheitssoftware ergänzt um IEC 82304-1.

Für ein mittleres Medizintechnik-Softwareteam, 5 bis 10 Entwickler, 100.000 bis 500.000 Zeilen Code, rechnet diese Seite mit 120 bis 200 Stunden Dokumentationsaufwand je Freigabe. Das ist eine Annahme, keine Messung. 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, und jeder Befund bedeutet Nacharbeit und eine Nachweisfrist.

Mit vs. ohne KI, ein ehrlicher Vergleich

¹ Annahmen dieser Seite, keine Messung. Zusammen ergibt das bei 4 Freigaben im Jahr 40 bis 60 Stunden bei den Freigaben und 40 bis 100 Stunden bei der Audit-Vorbereitung, also 80 bis 160 Stunden im Jahr. Eine Erhebung zu Lückenquoten in Nachverfolgbarkeitsmatrizen mit und ohne KI haben wir nicht gefunden.

Einschätzung auf einen Blick

Zeitersparnis, hoch (4/5)
80 bis 160 Stunden im Jahr bei 4 Freigaben, wenn die Annahmen der Tabelle halten, das sind rund 2 bis 4 Arbeitswochen. Nicht die spektakulärste Zeiteinsparung unter den verglichenen Anwendungsfällen, aber konsistent und vorhersagbar, und sie fällt genau in den Wochen vor dem Audit an, in denen das Team am knappsten ist.

Kosteneinsparung, mittel (3/5)
Die gesparten Stunden sind bei 100 Euro je Entwicklerstunde 8.000 bis 16.000 Euro im Jahr wert, aber nur, wenn die Entwickler die Zeit wirklich in Fehlerbehebung und Funktionen stecken. Vermiedene Auditbefunde sparen Nacharbeit, beziffern lässt sich das nicht seriös. Die laufenden Kosten fressen einen großen Teil davon, die Rechnung steht unten.

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 eine der längsten Einführungsphasen in dieser Kategorie.

ROI-Sicherheit, hoch (4/5)
Der Nutzen ist messbar: Die offenen Stellen in der Nachverfolgbarkeitsmatrix lassen sich je Freigabe zählen, bei hunderten Anforderungen ist das eine echte Stichprobe, und die Dokumentationszeit geht zurück. Auditbefunde dagegen gibt es ein-, zweimal im Jahr, daraus lässt sich kein Effekt ablesen. 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 jeder Freigabe werden Vorlagen und Prompt-Beispiele besser, das Modell selbst lernt dabei nichts dazu. 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.” Wie oft solche Verknüpfungen stimmen, musst du an einer alten, sauber dokumentierten Freigabe messen, eine belastbare Quote kennen wir nicht. Jede Verknüpfung bleibt ein Vorschlag, den ein Mensch bestätigt.

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 einen Entwurf in IEC-62304-Struktur: Entwicklungsplan, Anforderungsspezifikation, Architektur, Nachverfolgbarkeitsmatrix, Testergebnisse, Freigabenotizen. Nach Prüfung und Freigabe durch die Verantwortlichen ist er für Benannte Stellen oder interne Audits 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.

Ohne manuelle Einträge, bis auf die Bestätigung durch einen Menschen. Und weil es eine Sicherheitskorrektur an ausgelieferter Software ist, gehört die Frage dazu, ob Geräte im Feld betroffen sind und ob daraus eine Vigilanzmeldung oder eine Sicherheitskorrekturmaßnahme im Feld folgt.

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 über die API 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 und höchstens 2 Freigaben pro Jahr.

Spezialisierte Software-QMS-Plattformen
SimplerQMS ist ein eQMS auf Basis von Microsoft 365. Eine Anbindung an GitHub oder Jira belegt unsere Toolseite nicht, die Dokumentenlenkung läuft in Word und SharePoint. Für die Software-Dokumentation heißt das: Das QMS verwaltet und gibt frei, die Verknüpfung mit dem Code musst du selbst bauen. Lizenz laut Toolseite ab rund 17.500 US-Dollar im Jahr. Sinnvoll für: Teams mit etabliertem QM-System, die sich auf eine Benannte Stelle vorbereiten.

Für das Gesamtpaket aus eQMS-Lizenz und selbst gebauter Integration setzt diese Seite 2.000 bis 4.000 Euro im Monat an (Annahme).

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 Trainingsdaten wandern. Nutze API- oder Business-Angebote von Claude oder ChatGPT, deren Vertragsbedingungen Training auf deinen Eingaben ausschließen, und prüfe die Einstellung. Private Plus- oder Pro-Abos sind für Firmencode der falsche Ort.
• Am sichersten ist eine Eigenlösung mit lokaler Inferenz.
• SimplerQMS hostet in der EU.
• Quellcode selbst ist meist nicht personenbezogen, das Git-Log aber schon: Es enthält Namen und E-Mail-Adressen der Entwickler. Damit braucht der KI-Dienst einen Auftragsverarbeitungsvertrag, oder du entfernst die Autorenfelder vor dem Export. Kann das System Commits je Person auswerten, ist es eine technische Einrichtung, die zur Überwachung von Leistung oder Verhalten geeignet ist, und der Betriebsrat bestimmt nach § 87 Abs. 1 Nr. 6 BetrVG mit.

Was es kostet, realistisch gerechnet

Annahmen für die Rechnung:

• Team mit 6 Entwicklern, 100.000 Codezeilen, 4 Freigaben pro Jahr
• Zeitersparnis bei den Freigaben: 4 mal 10 bis 15 Stunden = 40 bis 60 Stunden pro Jahr
• Zeitersparnis bei der Audit-Vorbereitung: 1 bis 2,5 Wochen, also 40 bis 100 Stunden pro Jahr
• Stundensatz Entwicklung: 100 Euro, also 80 bis 160 Stunden mal 100 Euro = 8.000 bis 16.000 Euro im Jahr, sofern die Stunden in Entwicklung fließen
• Vermiedene Auditbefunde: nicht beziffert, weil nicht seriös schätzbar
• Laufende Kosten des schlanken Eigenbaus: 12 mal 500 bis 1.000 Euro = 6.000 bis 12.000 Euro im Jahr (Annahme, überwiegend Pflege des Skripts)

Im Saldo liegt der schlanke Eigenbau zwischen 4.000 Euro Minus und 10.000 Euro Plus im Jahr. Die 5.000 bis 10.000 Euro Einrichtung sind im besten Fall nach einem halben Jahr zurück, im ungünstigen nie. Das eQMS mit Integration kostet laufend 12 mal 2.000 bis 4.000 Euro = 24.000 bis 48.000 Euro im Jahr, die Unternehmens-Plattform 12 mal 4.000 bis 8.000 Euro = 48.000 bis 96.000 Euro. Über gesparte Dokumentationsstunden rechnen sich beide bei diesem Team nicht, sie lohnen sich, wenn ihr sie als QMS oder Entwicklungsplattform ohnehin braucht.

Drei typische Einstiegsfehler

1. Automatisierung auf Kosten der Genauigkeit.
Das System baut die Nachverfolgbarkeitsmatrix automatisch auf, aber mit Fehlern: falsche oder fehlende Verknüpfungen, wie viele, zeigt erst die Prüfung. 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 konzentriert sich auf die Verknüpfungen, die das System als unsicher markiert, bestätigt wird weiterhin jede.
• Ab Woche 21: Regelbetrieb, die Erzeugung ist automatisiert, die Freigabe der Dokumentation nicht. Dazu quartalsweise 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 die Routinefälle vorschlagen und alles, was sie nicht sicher zuordnen kann, 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 (MDR-Klasse IIa bis III, Software-Sicherheitsklasse B oder C) 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 nimmt dem Team die Routine-Schreibarbeit ab. Ob er sich rechnet, hängt an den Pflegekosten, siehe oben.

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 Software der Klasse I mit Sicherheitsklasse A und seltenen Freigaben. Die Dokumentation ist dann nicht optional, auch Klasse I braucht technische Dokumentation nach Anhang II und einen Lebenszyklusprozess nach Anhang I Abschnitt 17.2 MDR, aber sie ist schmal genug, dass sich ein System nicht lohnt. Prüft vorher die Klasse: Nach Regel 11 landet Software, die Informationen für diagnostische oder therapeutische Entscheidungen liefert, meist mindestens in IIa.

✗ 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, ohne Autorenfelder. Ein kurzes Skript reicht, das Commit-Nachrichten und geänderte Dateien ausliest, Namen und E-Mail-Adressen der Entwickler lässt du weg. Das wird die Eingabe für einen Machbarkeitstest mit ChatGPT oder Claude , im Business- oder Team-Tarif, nicht im privaten Abo.

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

Quellen & Methodik

• IEC 62304:2006 mit Änderung 1: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
• MDR Anhang I Abschnitt 17.2, Anhang II: Verordnung (EU) 2017/745, konsolidierte Fassung vom 19.07.2026 (eur-lex.europa.eu, abgerufen am 19.09.2026): Software nach dem Stand der Technik unter Berücksichtigung von Lebenszyklus, Risikomanagement einschließlich Informationssicherheit, Verifizierung und Validierung.
• Zeitaufwände und Zeitersparnis: Annahmen dieser Seite, keine Messung; Lückenquoten und Auditbefunde bewusst nicht beziffert