Ideen aus Brüssel<br />Ein Kommentar zur aktuellen Diskussion von Prof. Dr. Christian Johner<br />
Eine Idee aus Brüssel<br />„Wäre es nicht gut, bei Standalone-Software nur den Teil gesetzeskonform entwickeln zu lassen, ...
Ein Beispiel<br />Keine regulatorischen<br />Vorgaben<br />Krankenhaus-Informationssystem (KSI)<br />„Expertensystem“<br /...
Eine gute Idee?<br />Photo: iStockphoto.com<br />
NEIN!!!<br />Photo: iStockphoto.com<br />
1. Grund: Das widerspricht dem Gesetz<br />Es gibt zwei Möglichkeiten:<br />Die Software wird als ein Medizinprodukt (MP) ...
2. Grund: Man spart damit nichts<br />Die IEC 62304 erlaubt doch bereits explizit, dass man für unkritisch Komponenten [1]...
3. Grund: Stand der Technik<br />Die IEC 62304 versteht sich als die Definition einer Untergrenze, nicht als eine Beschrei...
4. Grund: Verzahnung von Plugins und Framework<br />Der Gedanke, die Plugins als streng gekapselte Komponenten zu verstehe...
5. Grund: Risikomanagement<br />Man kann die Risiken, die von einer Komponente ausgehen, nur dann bewerten, wenn man deren...
6. Grund: Falscher Fokus<br />Die Software-Fehler, die dem BfArM gemeldet werden, sind nicht nur Probleme mit der Funktion...
7. Grund: Praxisnähe<br />Für viele Hersteller ist es eine erste Herausforderung, die Entwickler zur normenkonformen Entwi...
Fazit<br />Unsere Abhängigkeit von funktionierender (medizinischer) Software steigt. Die Hersteller melden dem BfArM berei...
Nächste SlideShare
Wird geladen in …5
×

SW-Entwicklung nach IEC 62304

3.155 Aufrufe

Veröffentlicht am

In Brüssel denken einige Experten darüber nach, dass nur die kritischen Komponenten von klinischen Informationssystemen konform mit den Normen (z.B. IEC 62304) entwickelt werden müssen.
Diese Präsentation ist ein Plädoyer dagegen.

Veröffentlicht in: Technologie, Unterhaltung & Humor
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
3.155
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
182
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

SW-Entwicklung nach IEC 62304

  1. 1. Ideen aus Brüssel<br />Ein Kommentar zur aktuellen Diskussion von Prof. Dr. Christian Johner<br />
  2. 2. Eine Idee aus Brüssel<br />„Wäre es nicht gut, bei Standalone-Software nur den Teil gesetzeskonform entwickeln zu lassen, der der Diagnostik, Therapie und Überwachung dient?“<br />Photo: iStockphoto.com<br />
  3. 3. Ein Beispiel<br />Keine regulatorischen<br />Vorgaben<br />Krankenhaus-Informationssystem (KSI)<br />„Expertensystem“<br />(Modul berechnet Therapievorschläge)<br />Entwicklung konform<br />IEC 62304, IEC 62366,<br />ISO 14971 usw.<br />Modul zur Ansteuerung von Spritzenpumpen<br />
  4. 4. Eine gute Idee?<br />Photo: iStockphoto.com<br />
  5. 5. NEIN!!!<br />Photo: iStockphoto.com<br />
  6. 6. 1. Grund: Das widerspricht dem Gesetz<br />Es gibt zwei Möglichkeiten:<br />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.<br />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.<br />
  7. 7. 2. Grund: Man spart damit nichts<br />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?<br />[1] Dieser Nachweis ist über eine Risikoanalyse zu führen<br />
  8. 8. 3. Grund: Stand der Technik<br />Die IEC 62304 versteht sich als die Definition einer Untergrenze, nicht als eine Beschreibung von Best-Practices. <br />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.<br />Auf die bisherigen Forderungen zu verzichten wäre wie ein Arzt, dem man erlaubt zu operieren, ohne die Hände vorher zu desinfizieren.<br />Photo: iStockphoto.com<br />
  9. 9. 4. Grund: Verzahnung von Plugins und Framework<br />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:<br />Gemeinsame Benutzerschnittstelle<br />Logik SW<br />Logik Plugin<br />Gemeinsame Datenbank<br />
  10. 10. 5. Grund: Risikomanagement<br />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. <br />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.<br />Photo: iStockphoto.com<br />
  11. 11. 6. Grund: Falscher Fokus<br />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.<br />
  12. 12. 7. Grund: Praxisnähe<br />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.<br />Photo: iStockphoto.com<br />
  13. 13. Fazit<br />Unsere Abhängigkeit von funktionierender (medizinischer) Software steigt. Die Hersteller melden dem BfArM bereits jetzt mehr als zwei Software-Fehler pro Woche. <br />Ein Zurückrudern bei den regulatorischen Anforderungen an die Softwareentwicklung wäre fatal.<br />Wehret den Anfängen!<br />Prof. Dr. Christian Johner<br />

×