Prof. Dr. Christian Johner kritisiert die Idee, bei standalone-Software nur die entscheidenden Teile gesetzeskonform zu entwickeln, da dies den gesetzlichen Anforderungen widerspricht und keine Kosteneinsparungen bringt. Er argumentiert, dass eine ordnungsgemäße Risikobewertung und Softwareentwicklung unerlässlich sind, um die Qualität und Sicherheit medizinischer Software zu gewährleisten. Ein Rückgriff auf weniger strenge Vorschriften wäre fatal, da die Abhängigkeit von zuverlässiger medizinischer Software stetig zunimmt.

1. Institut für
Informationstechnologien
Im Gesundheitswesen
Prof. Dr. Christian Johner
Ideen aus Brüssel
Ein Kommentar zur aktuellen Diskussion
von Prof. Dr. Christian Johner

2. Eine Idee aus Brüssel
„Wäre es nicht gut, bei
Standalone-Software nur
den Teil gesetzeskonform
entwickeln zu lassen, der
der Diagnostik, Therapie
und Überwachung dient?“
Photo: iStockphoto.com

3. Ein Beispiel
Keine regulatorischen
Krankenhaus-Informationssystem (KSI)
Vorgaben
„Expertensystem“
(Modul berechnet
Therapievorschläge)
Entwicklung konform
Modul zur Ansteuerung
IEC 62304, IEC 62366,
von Spritzenpumpen
ISO 14971 usw.

4. Eine gute
Idee?
Photo: iStockphoto.com

5. NEIN!!!
Photo: iStockphoto.com

6. 1. Grund: Das widerspricht dem Gesetz
Es gibt zwei Möglichkeiten:
1. Die Software wird als ein Medizinprodukt (MP) in Verkehr gebracht: Dann muss
man die gesamte Software gesetzeskonform entwickeln. Man kann ja auch nicht
die Komponenten eines Röntgengeräts einzeln in Verkehr bringen.
2. Die Software wird als Nicht-MP in Verkehr gebracht, die „kritischen
Komponenten“ als eigenständige MPs: Eine Komponente, d.h. ein Plugin, kann aber
alleine gar nicht der Diagnose und Therapie dienen und kann damit kein MP sein.
Und selbst wenn das ginge, ist das nicht das, was hier zur Diskussion steht.
Unabhängig davon setzt ein gemeinsames Inverkehrbringen eines Nicht-MPs mit
einem MP ein erneutes Konformitätsbewertungsverfahren voraus.

7. 2. Grund: Man spart damit nichts
Die IEC 62304 erlaubt doch bereits explizit, dass man für unkritisch Komponenten [1],
also solche der Sicherheitsklasse A, auf eine Software-Architektur und Tests verzichtet.
Was erhofft man sich also?
[1] Dieser Nachweis ist über eine Risikoanalyse zu führen

8. 3. Grund: Stand der Technik
Die IEC 62304 versteht sich als die Definition einer Untergrenze, nicht als eine
Beschreibung von Best-Practices.
Wer ernsthaft vorschlägt, auf eine dokumentierte Software-Architektur und Tests zu
verzichten, hat offensichtlich von Software-Entwicklung nur bedingt eine Ahnung. Wir
sprechen hier über das, was ein Informatik-Student im Grundstudium lernt.
Auf die bisherigen Forderungen zu verzichten wäre wie ein Arzt,
dem man erlaubt zu operieren, ohne die Hände vorher zu desinfizieren.
Photo: iStockphoto.com

9. 4. Grund: Verzahnung von Plugins und Framework
Der Gedanke, die Plugins als streng gekapselte Komponenten zu verstehen, gefällt.
Viele Hersteller – besonders diejenigen, die über zu hohe regulatorische
Anforderungen klagen – haben jedoch Software-Architekturen, bei denen diese
Trennung nicht gegeben ist:
Gemeinsame Benutzerschnittstelle
Logik SW Logik Plugin
Gemeinsame Datenbank

10. 5. Grund: Risikomanagement
Man kann die Risiken, die von einer Komponente ausgehen, nur dann bewerten, wenn
man deren Umgebung (die Stand-alone Software) genau kennt und dort weiter
verfolgen kann. Damit dehnt man aber die Risikoanalyse auf diese Umgebung aus.
Nur mit Maßnahmen in dieser Umgebung lassen sich die Risiken, die von der
Komponente ausgehen, beherrschen. Um die Wirksamkeit der Maßnahmen zu
verifizieren, muss man nach IEC 62304 entwickeln. Man hat also nichts gespart.
Photo: iStockphoto.com

11. 6. Grund: Falscher Fokus
Die Software-Fehler, die dem BfArM gemeldet werden, sind nicht nur Probleme mit
der Funktionalität. Es gibt massive Probleme mit der Wartbarkeit und der
Gebrauchstauglichkeit. Und genau diese Qualitätsaspekte lassen sich für ein Plugin
nur schwer isoliert verifizieren und validieren.

12. 7. Grund: Praxisnähe
Für viele Hersteller ist es eine erste Herausforderung, die Entwickler zur
normenkonformen Entwicklung anzuhalten. Das Entwicklerteam so zu schulen, dass es
für die kritischen und unkritischen Komponenten einer Software verschiedene
Prozesse, Methoden und Werkzeuge anwendet, erscheint praxisfern.
Photo: iStockphoto.com

13. Fazit
Unsere Abhängigkeit von funktionierender (medizinischer)
Software steigt. Die Hersteller melden dem BfArM
bereits jetzt mehr als zwei Software-Fehler pro Woche.
Ein Zurückrudern bei den regulatorischen
Anforderungen an die Softwareentwicklung wäre fatal.
Wehret den Anfängen!
Prof. Dr. Christian Johner