Hotfix: 6 Tipps für schnelle und normenkonforme Bugfixes

Unter einem Hotfix verstehen die meisten Medizinprodukte-Hersteller die kurzfristige Behebung eines dringenden Software-Bugs. Bei diesen Hotfixes unterlaufen den Herstellern gravierende Fehler. Auch regulatorische.

Lesen Sie hier, wie Sie die Software Ihrer Medizinprodukte durch einen Hotfix schnell und ohne Overhead aber dennoch gesetzeskonform updaten können.

Ein Hotfix aus regulatorischer Brille

Die Gesetze, Normen (z.B. IEC 62304) und Verordnungen kennen keine Hotfixe. Sie kennen hingegen Begriffe wie

• Korrektive Maßnahme z.B. Rückruf
• Software-Wartung oder
• Problemlösung

Hotfix aus Sicht der IEC 62304

Wenn Sie einen Hotfix „deployen“ wollen (um nun endgültig in Anglizismen abzugleiten), müssen Sie

• den Problemlösungsprozess gemäß IEC 62304 durchlaufen,
• den Wartungsprozess gemäß IEC 62304 durchlaufen,
• als Teil derer ggf. Behörden und Kunden informieren (beachten Sie in Deutschland explizit die Forderungen der Medizinprodukte-Sicherheitsplanverordnung) und
• Ihre Risikomanagementakte ggf. aktualisieren.

Der Wartungsprozess umfasst die gleichen Tätigkeiten wie der initiale Software-Entwicklungsprozess nämlich

• eine Analyse der Anforderungen einschließlich deren Verifizierung,
• eine (Aktualisierung) der Software-Architektur
• und des detaillierten Designs einschließlich der jeweiligen Verifizierung,
• die Verifizierung der Software-Einheiten (z.B. durch Unit-Tests, Code-Reviews),
• das Durchführen von Integrationstests und Systemtests (ggf. als Regressionstests) sowie
• die Software-Freigabe

Damit stellt sich die Frage, wie Sie als Hersteller einen Hotfix zeitnah und normenkonform gestalten können. Dazu gleich mehr.

Hotfix in Audits

Hotfixes sind wie jedes Software-Update ein Lieblingsthema der Auditoren. Das ist kein Wunder:

• Hotfixes sind ein Zeichen, dass Fehler gemacht wurden. Für deren Ursachen interessieren sich Auditoren.
• Die Wahrscheinlichkeit, dass einem Hersteller in einer „dringenden Situation“ Fehler unterlaufen, ist besonders hoch.
• Viele Hersteller haben für Hotfixes nur unzureichende Regelungen getroffen.
• Manche Hersteller umgehen den regulären Entwicklungsprozess, indem sie „Features“ im Rahmen von Hotfixes mit ausliefern.

Hotfix schnell und normenkonform durchführen

Zum ersten sollten Sie Ihren Problemlösungsprozess und Ihren Wartungsprozess schlank gestalten, in dem Sie Redundanzen vermeiden. Wie das geht, habe ich in einem weiteren Artikel beschrieben.

Zum zweiten wollen Sie die oben genannten Aktivitäten ohne Overhead durchführen. Achten Sie dabei auf Folgendes:

1. Ändern Sie nur, was geändert werden muss

Die Norm verlangt nicht, dass Sie alle Dokumente neu erstellen müssen. Sie ändern die Dokumente wie eine Software Requirements Specification oder eine Software-Architektur nur dann, wenn es auch Änderungsbedarf gibt. Halten Sie diese Dokumente aber immer aktuell!

Auch das Handbuch muss mit geänderten Software-Version übereinstimmen. Wenn allerdings das Handbuch geändert wird, stellst sich oft die Frage, ob das nur ein Hotfix war. Muss gar die Gebrauchstauglichkeit neu bewertet werden?

Die Risikomanagementakte sollten Sie immer — auch bei keinen nennenswerten Änderungen — aktualisieren und die Ursachen des Hotfixes und Auswirkungen der Änderungen diskutieren. Siehe auch Punkt 6.

2. Sorgen Sie für eine schlanke Verifizierung und Freigabe

Die Hauptarbeit liegt oft darin, die Freigaben bzw. Verifizierungen der Dokumente zu erreichen. Wie schnell das geht, hängt von Ihrem Prozess ab. Ich habe Ihnen bereits einen Artikel zu schlanken Dokumenten-Freigaben verfasst.

3. Geben Sie sich unterschiedliche Vorgaben für Software-Entwicklung und -Wartung

Zwar fordert die IEC 62304 für den Entwicklungs- und Wartungsprozess die gleichen Tätigkeiten. Sie dürfen aber unterschiedliche Regelungen für die jeweiligen Tätigkeiten treffen. Sie könnten beispielsweise unterscheiden:

1. Typ: Initiale Entwicklung
2. Typ: Weiterentwicklung (neue Feature)
3. Typ: Bug-Fixes (z.B. ohne Änderung an der Architektur)

Für diese drei Typen können Sie individuelle Regelungen treffen. Auch hierfür Beispiele:

• Bei Typ 1. und 2. muss das komplette Software-Anforderungsdokument einem Review unterzogen werden. Bei Typ 3 nur der geänderte Teil.
• Bei Typ 2. und 3. sind Regressionstests vorgeschrieben, bei Typ 1 (noch) nicht.
• Bei Typ 3. muss das Produktmanagement nicht an der Software-Freigabe beteiligt werden.

Durch solche Vorgaben können Sie den Prozess beschleunigen. Dieses Vorgehen hat aber auch Nachteile:

1. Ihre Entwickler müssen genau wissen, an welchem Typ von Entwicklung sie gerade arbeiten. Das verlangt ein sehr gutes Prozessverständnis und kann im Audit zum Risiko werden.
2. Die Entscheidung für einen Typ muss ggf. auch risikobasiert erfolgen.
3. Typ 3 darf nicht missbraucht werden, um Quality-Gates zu umgehen.

In Summe rate ich davon eher ab. Wenn Sie glauben, mit einem Typ 3 schneller sein zu können, liegen die Ursachen wahrscheinlich wo anders:

• Sie haben Ihren Entwicklungsprozess unnötig aufgebläht. Dann entschlacken Sie diesen.
• Sie unterlassen Tätigkeiten, die für eine professionelle Software-Entwicklung und eine state-of-the-art Software-Qualitätssicherung Selbstverständlichkeiten sein sollten. Aber Sie sind Profi. Deshalb entwickeln Sie auch so. 🙂

4. Analysieren Sie präzise den Grund des Prozessversagens

Dass dieser Hotfix notwendig wurde, ist nicht das Versagen eines Entwicklers. Vielmehr ist der Hotfix ein Zeichen eines Prozessversagens. Offensichtlich waren entweder

• Anforderungen nicht systematisch erhoben,
• eine ungeeignete Architektur gewählt,
• geeignete Programmierrichtlinien nicht bestimmt oder eingehalten,
• der oder die Entwickler nicht ausreichend geschult,
• Unit-, Integrations- oder Systemtests diesem Fehler gegenüber blind
• usw.

Es ist Ihre Pflicht, den wirklichen Grund des Problems zu erforschen. Fragen Sie fünf Mal mit „Warum“ nach. Die Antwort lautet nicht, „weil ein Fehler im Code war“.

5. Bewerten Sie vollständigedie Konsequenzen

Der Bug, den Sie durch den Hotfix beheben wollen, müssen Sie auch aus der Risikomanagement-Brille bewerten:

• Welche Konsequenzen könnte er außer den beobachteten für Ihr gesamtes Medizinprodukt und die Sicherheit von Patienten, Anwendern und Dritten noch haben?
• War dieses Problem mit dieser Wahrscheinlichkeit und dem möglichen Schweregrad eines Schadens bereits in Ihrer Risikoanalyse betrachtet worden? Das ist in den meisten Fällen nicht der Fall. Aktualisieren Sie also Ihre Risikomanagement-Akte entsprechend.
• Welche Auswirkungen haben die Änderungen an der Software (Spezifikation, Architektur, Implementierung) oder im Handbuch auf die Sicherheit der Patienten? Wie begründen Sie, dass die Risiken durch den Hotfix minimiert und keine neuen Risiken eingeführt wurden?

6. Sinnvolle Dokumentation

Um einen Hotfix schnell entwickeln zu können, muss man den Fehler schnell finden und beheben können. Dies klingt nach einer Trivial-Aussage. Aber deren Konsequenzen lauten:

• Schaffen Sie eine wartbare Software-Architektur. Andernfalls werden Sie den Fehler nur schwer lokalisieren können und ein Bug-Fix wird aufwendig sein und mit einer (zu) hohen Wahrscheinlichkeit neue Fehler nach sich ziehen.
• Dokumentieren Sie die Software-Architektur. Nur so wird es Ihrem Entwicklungsteam gelingen,
  • den Fehler schnell zu finden,
  • einen Entwickler mit dessen Behebung zu beauftragen,
  • geeignete Testfälle abzuleiten, die die Korrektur des Fehlers nachweisen sowie
  • Auswirkungen einer Fehlerkorrektur auf das restliche System abschätzen zu können.

Fazit & Empfehlung

Ein Hotfix kann durchaus in wenigen Stunden gesetzeskonform durchgeführt und die aktualisierte Software verteilt werden.

Wenn Ihnen das nicht gelingt, liegen die Ursachen nicht in überzogenen Forderungen einer IEC 62304, sondern wahrscheinlich darin, dass die oben genannten Hinweise nicht Berücksichtigung fanden. Das zu tun, wäre mein Tipp :-).

Speziell mit den Tipps 4. und 6. werden Sie es schaffen, Fehler und damit die Notwendigkeit für Hotfixes auf Dauer zu minimieren. Und ein Hotfix, der nicht gemacht werden muss, geht am schnellsten.