SlideShare uma empresa Scribd logo
1 de 13
Institut für
              Informationstechnologien
              Im Gesundheitswesen
              Prof. Dr. Christian Johner




     Ideen aus Brüssel


Ein Kommentar zur aktuellen Diskussion
     von Prof. Dr. Christian Johner
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
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.
Eine gute
                           Idee?




Photo: iStockphoto.com
NEIN!!!

     Photo: iStockphoto.com
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.
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
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
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
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
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.
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
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

Mais conteúdo relacionado

Destaque

Alertas epi 2010_02_julio_carbapenemasas
Alertas epi 2010_02_julio_carbapenemasasAlertas epi 2010_02_julio_carbapenemasas
Alertas epi 2010_02_julio_carbapenemasasusapuka
 
Módulo I. Bases de datos bibliográficas
Módulo I. Bases de datos bibliográficasMódulo I. Bases de datos bibliográficas
Módulo I. Bases de datos bibliográficasNicolas Robinson-Garcia
 
Como desarrollar una politica farmaceutica nacional !!!
Como desarrollar una politica farmaceutica nacional !!!Como desarrollar una politica farmaceutica nacional !!!
Como desarrollar una politica farmaceutica nacional !!!Juan Edgar Chávez Mejía
 
Aktuelle Medienkultur: Das Bild im Plural
Aktuelle Medienkultur: Das Bild im PluralAktuelle Medienkultur: Das Bild im Plural
Aktuelle Medienkultur: Das Bild im PluralTorsten Meyer
 
Starwars1
Starwars1Starwars1
Starwars1shiking
 
Estudio De Mortalidad Gripe
Estudio De Mortalidad GripeEstudio De Mortalidad Gripe
Estudio De Mortalidad Gripeusapuka
 
Interaktiv-Gadgets in der Automobil-Markenkommunikation
Interaktiv-Gadgets in der Automobil-MarkenkommunikationInteraktiv-Gadgets in der Automobil-Markenkommunikation
Interaktiv-Gadgets in der Automobil-MarkenkommunikationMOONDA
 
Risiken eingehen statt Pläne schmieden: Beispiele für Web 2.0 im Unternehmen
Risiken eingehen statt Pläne schmieden: Beispiele für Web 2.0 im UnternehmenRisiken eingehen statt Pläne schmieden: Beispiele für Web 2.0 im Unternehmen
Risiken eingehen statt Pläne schmieden: Beispiele für Web 2.0 im UnternehmenStefan Holtel
 
Euro 2008 Back Stage
Euro 2008 Back StageEuro 2008 Back Stage
Euro 2008 Back Stageguest50a54b
 
Hacia un bicentenario
Hacia un bicentenarioHacia un bicentenario
Hacia un bicentenariousapuka
 
4velas
4velas4velas
4velasespuki
 

Destaque (20)

Alertas epi 2010_02_julio_carbapenemasas
Alertas epi 2010_02_julio_carbapenemasasAlertas epi 2010_02_julio_carbapenemasas
Alertas epi 2010_02_julio_carbapenemasas
 
Módulo I. Bases de datos bibliográficas
Módulo I. Bases de datos bibliográficasMódulo I. Bases de datos bibliográficas
Módulo I. Bases de datos bibliográficas
 
Barroco 01
Barroco 01Barroco 01
Barroco 01
 
Atix17
Atix17Atix17
Atix17
 
Como desarrollar una politica farmaceutica nacional !!!
Como desarrollar una politica farmaceutica nacional !!!Como desarrollar una politica farmaceutica nacional !!!
Como desarrollar una politica farmaceutica nacional !!!
 
A1 Österreich
A1  ÖsterreichA1  Österreich
A1 Österreich
 
Aktuelle Medienkultur: Das Bild im Plural
Aktuelle Medienkultur: Das Bild im PluralAktuelle Medienkultur: Das Bild im Plural
Aktuelle Medienkultur: Das Bild im Plural
 
Ellos Y Ellas
Ellos Y EllasEllos Y Ellas
Ellos Y Ellas
 
Starwars1
Starwars1Starwars1
Starwars1
 
Estudio De Mortalidad Gripe
Estudio De Mortalidad GripeEstudio De Mortalidad Gripe
Estudio De Mortalidad Gripe
 
Interaktiv-Gadgets in der Automobil-Markenkommunikation
Interaktiv-Gadgets in der Automobil-MarkenkommunikationInteraktiv-Gadgets in der Automobil-Markenkommunikation
Interaktiv-Gadgets in der Automobil-Markenkommunikation
 
Risiken eingehen statt Pläne schmieden: Beispiele für Web 2.0 im Unternehmen
Risiken eingehen statt Pläne schmieden: Beispiele für Web 2.0 im UnternehmenRisiken eingehen statt Pläne schmieden: Beispiele für Web 2.0 im Unternehmen
Risiken eingehen statt Pläne schmieden: Beispiele für Web 2.0 im Unternehmen
 
La Unión Europea LOC
La Unión Europea LOCLa Unión Europea LOC
La Unión Europea LOC
 
Informationsbeschaffung 2012
Informationsbeschaffung 2012Informationsbeschaffung 2012
Informationsbeschaffung 2012
 
Euro 2008 Back Stage
Euro 2008 Back StageEuro 2008 Back Stage
Euro 2008 Back Stage
 
Hacia un bicentenario
Hacia un bicentenarioHacia un bicentenario
Hacia un bicentenario
 
Módulo I. Web of Science
Módulo I. Web of ScienceMódulo I. Web of Science
Módulo I. Web of Science
 
Captacion y retencion de socios/donantes en Pimec by Antoni Cañete
Captacion y retencion de socios/donantes en Pimec by Antoni CañeteCaptacion y retencion de socios/donantes en Pimec by Antoni Cañete
Captacion y retencion de socios/donantes en Pimec by Antoni Cañete
 
Curso de Introducción a la Mejora de Procesos de Software
Curso de Introducción a la Mejora de Procesos de SoftwareCurso de Introducción a la Mejora de Procesos de Software
Curso de Introducción a la Mejora de Procesos de Software
 
4velas
4velas4velas
4velas
 

Semelhante a SW-Entwicklung nach IEC 62304

CE-Zeichen für Medizinprodukte
CE-Zeichen für MedizinprodukteCE-Zeichen für Medizinprodukte
CE-Zeichen für MedizinprodukteChristian Johner
 
Konformitätsbewertung: In 7 Schritten zum CE-Zeichen für Ihr Medizinprodukt
Konformitätsbewertung: In 7 Schritten zum CE-Zeichen für Ihr MedizinproduktKonformitätsbewertung: In 7 Schritten zum CE-Zeichen für Ihr Medizinprodukt
Konformitätsbewertung: In 7 Schritten zum CE-Zeichen für Ihr MedizinproduktChristian Johner
 
Medizinprodukte-Software: Ist QM-System notwendig?
Medizinprodukte-Software: Ist QM-System notwendig?Medizinprodukte-Software: Ist QM-System notwendig?
Medizinprodukte-Software: Ist QM-System notwendig?Christian Johner
 
So klappt’s: Qualitätsziele erreichen durch kontrollierte Absicherung
So klappt’s: Qualitätsziele erreichen durch kontrollierte AbsicherungSo klappt’s: Qualitätsziele erreichen durch kontrollierte Absicherung
So klappt’s: Qualitätsziele erreichen durch kontrollierte AbsicherungRalf Bongard
 
Software-Tests in PHP-Anwendungen
Software-Tests in PHP-AnwendungenSoftware-Tests in PHP-Anwendungen
Software-Tests in PHP-AnwendungenGjero Krsteski
 
Verbesserung des Risikomanagements für Medizinprodukte
Verbesserung des Risikomanagements für MedizinprodukteVerbesserung des Risikomanagements für Medizinprodukte
Verbesserung des Risikomanagements für MedizinprodukteDenis Werner
 
Konformitätsbewertung: In 7 Schritten zum CE-Zeichen für Ihr Medizinprodukt
Konformitätsbewertung: In 7 Schritten zum CE-Zeichen für Ihr MedizinproduktKonformitätsbewertung: In 7 Schritten zum CE-Zeichen für Ihr Medizinprodukt
Konformitätsbewertung: In 7 Schritten zum CE-Zeichen für Ihr MedizinproduktChristian Johner
 
Automatisiertes webauftritt testen
Automatisiertes webauftritt testenAutomatisiertes webauftritt testen
Automatisiertes webauftritt testenmradamlacey
 
Literatur- und Prüfungshinweise nwsMOOC SoSe 2016
Literatur- und Prüfungshinweise nwsMOOC SoSe 2016Literatur- und Prüfungshinweise nwsMOOC SoSe 2016
Literatur- und Prüfungshinweise nwsMOOC SoSe 2016oncampus
 
Steht alles im Wiki? Das kleine 1x1 der Architekturdokumentation
Steht alles im Wiki? Das kleine 1x1 der ArchitekturdokumentationSteht alles im Wiki? Das kleine 1x1 der Architekturdokumentation
Steht alles im Wiki? Das kleine 1x1 der Architekturdokumentationoose
 
Agile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich
Agile Methoden als Diagnose-Tool für den sicherheitskritischen BereichAgile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich
Agile Methoden als Diagnose-Tool für den sicherheitskritischen BereichChristoph Schmiedinger
 
Codebeamer ALM für medizinische Softwareentwicklung
Codebeamer ALM für medizinische SoftwareentwicklungCodebeamer ALM für medizinische Softwareentwicklung
Codebeamer ALM für medizinische SoftwareentwicklungIntland Software GmbH
 
MedConf 2013 - Der Treffpunkt der Medizintechnik-Fachwelt
MedConf 2013 - Der Treffpunkt der Medizintechnik-FachweltMedConf 2013 - Der Treffpunkt der Medizintechnik-Fachwelt
MedConf 2013 - Der Treffpunkt der Medizintechnik-FachweltHLMC Events GmbH
 
Zertifizierung von Werkzeugen und Werkzeugketten
Zertifizierung von Werkzeugen und WerkzeugkettenZertifizierung von Werkzeugen und Werkzeugketten
Zertifizierung von Werkzeugen und WerkzeugkettenAndreasBaerwald
 
Software Entwicklung im Team
Software Entwicklung im TeamSoftware Entwicklung im Team
Software Entwicklung im Teambrandts
 
Mobile-App-Risiken minimieren: Sichere und zuverlässige Bereitstellung
Mobile-App-Risiken minimieren: Sichere und zuverlässige BereitstellungMobile-App-Risiken minimieren: Sichere und zuverlässige Bereitstellung
Mobile-App-Risiken minimieren: Sichere und zuverlässige BereitstellungFlexera
 

Semelhante a SW-Entwicklung nach IEC 62304 (20)

CE-Zeichen für Medizinprodukte
CE-Zeichen für MedizinprodukteCE-Zeichen für Medizinprodukte
CE-Zeichen für Medizinprodukte
 
Everything's connected
Everything's connectedEverything's connected
Everything's connected
 
Konformitätsbewertung: In 7 Schritten zum CE-Zeichen für Ihr Medizinprodukt
Konformitätsbewertung: In 7 Schritten zum CE-Zeichen für Ihr MedizinproduktKonformitätsbewertung: In 7 Schritten zum CE-Zeichen für Ihr Medizinprodukt
Konformitätsbewertung: In 7 Schritten zum CE-Zeichen für Ihr Medizinprodukt
 
Medizinprodukte-Software: Ist QM-System notwendig?
Medizinprodukte-Software: Ist QM-System notwendig?Medizinprodukte-Software: Ist QM-System notwendig?
Medizinprodukte-Software: Ist QM-System notwendig?
 
So klappt’s: Qualitätsziele erreichen durch kontrollierte Absicherung
So klappt’s: Qualitätsziele erreichen durch kontrollierte AbsicherungSo klappt’s: Qualitätsziele erreichen durch kontrollierte Absicherung
So klappt’s: Qualitätsziele erreichen durch kontrollierte Absicherung
 
Software-Tests in PHP-Anwendungen
Software-Tests in PHP-AnwendungenSoftware-Tests in PHP-Anwendungen
Software-Tests in PHP-Anwendungen
 
Verbesserung des Risikomanagements für Medizinprodukte
Verbesserung des Risikomanagements für MedizinprodukteVerbesserung des Risikomanagements für Medizinprodukte
Verbesserung des Risikomanagements für Medizinprodukte
 
It Projekte
It  ProjekteIt  Projekte
It Projekte
 
Konformitätsbewertung: In 7 Schritten zum CE-Zeichen für Ihr Medizinprodukt
Konformitätsbewertung: In 7 Schritten zum CE-Zeichen für Ihr MedizinproduktKonformitätsbewertung: In 7 Schritten zum CE-Zeichen für Ihr Medizinprodukt
Konformitätsbewertung: In 7 Schritten zum CE-Zeichen für Ihr Medizinprodukt
 
Automatisiertes webauftritt testen
Automatisiertes webauftritt testenAutomatisiertes webauftritt testen
Automatisiertes webauftritt testen
 
Literatur- und Prüfungshinweise nwsMOOC SoSe 2016
Literatur- und Prüfungshinweise nwsMOOC SoSe 2016Literatur- und Prüfungshinweise nwsMOOC SoSe 2016
Literatur- und Prüfungshinweise nwsMOOC SoSe 2016
 
Kirchner + Robrecht-White Paper "IT-Systeme erfolgreich auswählen"
Kirchner + Robrecht-White Paper "IT-Systeme erfolgreich auswählen"Kirchner + Robrecht-White Paper "IT-Systeme erfolgreich auswählen"
Kirchner + Robrecht-White Paper "IT-Systeme erfolgreich auswählen"
 
Steht alles im Wiki? Das kleine 1x1 der Architekturdokumentation
Steht alles im Wiki? Das kleine 1x1 der ArchitekturdokumentationSteht alles im Wiki? Das kleine 1x1 der Architekturdokumentation
Steht alles im Wiki? Das kleine 1x1 der Architekturdokumentation
 
Mehr Softwarequalität: Team-Cleancoding
Mehr Softwarequalität: Team-CleancodingMehr Softwarequalität: Team-Cleancoding
Mehr Softwarequalität: Team-Cleancoding
 
Agile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich
Agile Methoden als Diagnose-Tool für den sicherheitskritischen BereichAgile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich
Agile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich
 
Codebeamer ALM für medizinische Softwareentwicklung
Codebeamer ALM für medizinische SoftwareentwicklungCodebeamer ALM für medizinische Softwareentwicklung
Codebeamer ALM für medizinische Softwareentwicklung
 
MedConf 2013 - Der Treffpunkt der Medizintechnik-Fachwelt
MedConf 2013 - Der Treffpunkt der Medizintechnik-FachweltMedConf 2013 - Der Treffpunkt der Medizintechnik-Fachwelt
MedConf 2013 - Der Treffpunkt der Medizintechnik-Fachwelt
 
Zertifizierung von Werkzeugen und Werkzeugketten
Zertifizierung von Werkzeugen und WerkzeugkettenZertifizierung von Werkzeugen und Werkzeugketten
Zertifizierung von Werkzeugen und Werkzeugketten
 
Software Entwicklung im Team
Software Entwicklung im TeamSoftware Entwicklung im Team
Software Entwicklung im Team
 
Mobile-App-Risiken minimieren: Sichere und zuverlässige Bereitstellung
Mobile-App-Risiken minimieren: Sichere und zuverlässige BereitstellungMobile-App-Risiken minimieren: Sichere und zuverlässige Bereitstellung
Mobile-App-Risiken minimieren: Sichere und zuverlässige Bereitstellung
 

Mais de Christian Johner

Zweckbestimmung von Medizinprodukten richtig formulieren
Zweckbestimmung von Medizinprodukten richtig formulierenZweckbestimmung von Medizinprodukten richtig formulieren
Zweckbestimmung von Medizinprodukten richtig formulierenChristian Johner
 
Mobile Medical Apps - From Start to CE-Mark
Mobile Medical Apps - From Start to CE-MarkMobile Medical Apps - From Start to CE-Mark
Mobile Medical Apps - From Start to CE-MarkChristian Johner
 
Medical Apps: 5 Steps to CE-mark
Medical Apps: 5 Steps to CE-markMedical Apps: 5 Steps to CE-mark
Medical Apps: 5 Steps to CE-markChristian Johner
 
CE-Zeichen für Medizinprodukte
CE-Zeichen für MedizinprodukteCE-Zeichen für Medizinprodukte
CE-Zeichen für MedizinprodukteChristian Johner
 
Projektmanagement in der Medizintechnik
Projektmanagement in der MedizintechnikProjektmanagement in der Medizintechnik
Projektmanagement in der MedizintechnikChristian Johner
 
Mobile Medical Apps: In 5 Schritten zur "Medizinprodukte-Zertifizierung"
Mobile Medical Apps: In 5 Schritten zur "Medizinprodukte-Zertifizierung"Mobile Medical Apps: In 5 Schritten zur "Medizinprodukte-Zertifizierung"
Mobile Medical Apps: In 5 Schritten zur "Medizinprodukte-Zertifizierung"Christian Johner
 

Mais de Christian Johner (7)

Zweckbestimmung von Medizinprodukten richtig formulieren
Zweckbestimmung von Medizinprodukten richtig formulierenZweckbestimmung von Medizinprodukten richtig formulieren
Zweckbestimmung von Medizinprodukten richtig formulieren
 
Mobile Medical Apps - From Start to CE-Mark
Mobile Medical Apps - From Start to CE-MarkMobile Medical Apps - From Start to CE-Mark
Mobile Medical Apps - From Start to CE-Mark
 
Medical Apps: 5 Steps to CE-mark
Medical Apps: 5 Steps to CE-markMedical Apps: 5 Steps to CE-mark
Medical Apps: 5 Steps to CE-mark
 
CE-Zeichen für Medizinprodukte
CE-Zeichen für MedizinprodukteCE-Zeichen für Medizinprodukte
CE-Zeichen für Medizinprodukte
 
Projektmanagement in der Medizintechnik
Projektmanagement in der MedizintechnikProjektmanagement in der Medizintechnik
Projektmanagement in der Medizintechnik
 
Mobile Medical Apps: In 5 Schritten zur "Medizinprodukte-Zertifizierung"
Mobile Medical Apps: In 5 Schritten zur "Medizinprodukte-Zertifizierung"Mobile Medical Apps: In 5 Schritten zur "Medizinprodukte-Zertifizierung"
Mobile Medical Apps: In 5 Schritten zur "Medizinprodukte-Zertifizierung"
 
Institutstag 2012
Institutstag 2012Institutstag 2012
Institutstag 2012
 

SW-Entwicklung nach IEC 62304

  • 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