Software-Freigabe: ein „beliebtes“ Missverständnis

Die IEC 62304 fordert in Kapitel 5.8 eine Software-Freigabe, auf Englisch „Software Release“. Besonders bei Herstellern von Standalone-Software beobachte ich häufig ein Missverständnis des Begriffs Software-Freigabe. Das kann regulatorisch zum Problem werden.

Was die Software-Freigabe NICHT ist

Die Software-Freigabe im Sinn der IEC 62304 ist KEINE Freigabe der Software als Produkt. Sie darf als nicht mit einer Marktfreigabe verwechselt werden.

Beispielsweise müsste eine Marktfreigabe folgende Elemente enthalten, die NICHT Teil der Software-Freigabe wären:

• Konformitätserklärung
• Ausgefüllte MDD-Checkliste
• Bestätigung des Nutzen-Risikoverhältnisses
• Klassifizierung des Produkts (nach MDD)
• Klinische Bewertung
• Freigabe des Produkts durch das Qualitätsmanagement und Regulatory Affairs

Die Software-Freigabe ist vielmehr das „Okay“ der Software-Entwicklung. Also die Bestätigung das von ihrer Seite die Software fertig ist.

Diese Bestätigung ist in der Regel unabhängig vom Zielmarkt mit dessen spezifischen Regularien. Die Produktfreigabe hingegen ist sehr spezifisch für einen Zielmarkt.

Was die Software-Freigabe enthalten muss

Die IEC 62304 stellt in Kapitel 5.8 konkrete Anforderungen an die Software-Freigabe. Dazu zählen:

• Eine Auflistung und Bewertung der verbliebenen Bugs
• Eine Beschreibung wie die Software erstellt wurde (Build) und welche eindeutige Version sie hat
• Eine Bestätigung, dass alle Unterlagen vorliegen (z.B. Software-Anforderungen, Software-Architektur, Software-Tests)

Damit alles reproduzierbar ist, müssen die Hersteller

• all diese Unterlagen archivieren und
• sicherstellen, dass bei der weiteren Auslieferung nichts mehr schief gehen und wirklich nur die freigegebene Software im ausgelieferten Medizinprodukt sein kann.

Das Amendement I zur IEC 62304 aus dem Jahr 2015 belässt das Kapitel 5.8 von redaktionellen Änderungen abgesehen unverändert.

Freigabe bei der agilen Entwicklung

Ob Sie nach jedem Sprint eine formale Freigabe Ihrer Software verlangen oder nur vor der tatsächlichen Auslieferung, entscheiden Sie.

• Pro „Freigabe pro Sprint“: Ein Paradigma der agilen Entwicklung ist, dass nach jedem Sprint ein potenziell auslieferbares Produkt vorliegt. Und dazu zählen im regulatorischen Umfeld auch die zugehörigen Dokumente.
• Contra „Freigabe pro Sprint“: Bei vielen Firmen ist die Prozessgüte noch nicht so hoch, dass so eine Freigabe auch effizient erfolgen kann. Meist ist dies auch ein Hinweis auf eine suboptimale Güte des Software-Engineerings. Denn diese würde „automatisch“ zu den geforderten Dokumenten führen.