Vortrag René Salamon
Hans Christian Wenner | Uwe Nölke
09.03.2018 Veranstaltungsrückblick 508 0

Safety, Security und Risikomanagement greifen bei der Herstellung sicherer Software in der Medizin wie Zahnräder ineinander

Medizinische Software umfasst zahlreiche Produkte, denn sie kann ein integraler Bestandteil eines Medizinprodukts (embedded software) oder ein eigenständiges Medizinprodukt (stand-alone software), z. B. eine App auf einem Smartphone, sein. Die Bedeutung von Software nimmt nicht zuletzt vor dem Hintergrund der Digitalisierung des Gesundheitswesens stark zu. Dem gegenüber stehen die wachsenden  regulatorischen Anforderungen aus verschiedenen Rechtbereichen, die sich gerade für kleinere und mittlere Herstellerunternehmen als echte Innovationshürde erweisen können und die zunehmenden Bedrohungen im Bereich der IT-Sicherheit. Am 28. Februar 2018 trafen sich in Frankfurt am Main rund 120 Expertinnen und Experten zu einem intensiven Austausch.

Kontakt

Geschäftsstelle

Wer schreibt, der bleibt

Im hochregulierten Umfeld der Medizintechnik gilt der Grundsatz „Was nicht dokumentiert wurde, gilt als nicht gemacht“. Für Matthias Wufka, Business Solution Manager bei der Zühlke Engineering GmbH, ist es deshalb von entscheidender Bedeutung, dass alle Aktivitäten der Softwareentwicklung von einer entsprechenden Dokumentation begleitet werden. Er erläuterte dies in seinem Vortrag anhand einer Darstellung im Stil des allseits bekannten V-Modells aus dem Buch „Entwicklung und Herstellung medizinischer Software“, bei dem er als Autor mitgewirkt hat.

Trotz der insgesamt gestiegenen Anforderungen an Medizinprodukte durch den neuen europäischen Rechtsrahmen, machte Michael Takla, Produktmanager und Prüfer für medizinische Software bei der VDE Prüf- und Zertifizierungsinstitut GmbH, den Herstellern „Mut“ mit dem Hinweis, dass nach wie vor die Möglichkeit existiere, die Konformität über die Anwendung harmonisierter Normen nachzuweisen. Formal gesehen würden gegenwärtig aber nur harmonisierte Normen existieren, die Bezug auf die alten EU-Richtlinien nehmen. 

Vortrag Keiter
Cordula Keiter | Uwe Nölke

Product Security im Fokus

Im englischsprachigen Raum fällt die Unterscheidung zwischen zwei wesentlichen Anforderungen für Medizinprodukte mit den Begriffen Safety (Betriebssicherheit) und Security (Informationssicherheit) leichter als im Deutschen mit dem übergreifenden Begriff „Sicherheit“. Safety Anforderungen haben eine lange Tradition bei der Entwicklung von Medizinprodukten, aber die Security nimmt einen immer größer werdenden Stellenwert ein, wie Frau Cordula Keiter, Senior Software Engineer bei der Siemens Healthcare Diagnostics Products GmbH, in ihrem Vortrag feststellte. Vermehrt wäre Medizintechnik das Ziel von „geplanten, zielgerichteten und absichtsvollen Angriffen“, der Gesetzgeber würde auch international immer höhere Anforderungen an die Product Security stellen und schließlich würden die Kunden sichere Produkte fordern, weil die Gesundheit der Patienten im Vordergrund steht. Weiterhin warnte Keiter vor den Folgen von Security Problemen bei Medizinprodukten für den Hersteller. Diese reichen unter anderem von rechtlichen Konsequenzen bis zum Verlust der Reputation des Unternehmens.  Dem könne nur dadurch begegnen, dass „Security Aktivitäten mit den Schutzzielen Confidentiality, Integrity und Availability (CIA)  von Anfang an in den Entwicklungsprozess eingebettet und ein definierter Prozess zum Incident Handling beim Hersteller existieren würde“.
Für die Security bei Medizingeräten existieren derzeit keine allgemein anerkannten Normen, aber verschiedene Normengremien arbeiten mit Hochdruck an der Lösung des Problems  wie Dr. Georg Heidenreich, Director des Bereichs Healthcare IT Standards der Siemens Healthcare GmbH, berichtete. Dies geschieht durch die Integration der Security Anforderungen in die bereits existierenden Medizinproduktenormen IEC 82304 und IEC 62304. Der oftmals falsche Umgang mit Security Problemen lasse sich gut mit einem Zitat von Bruce Schneier zusammenfassen „Security is not a product; it itself is a process. (...) If you think technology can solve your security problems, then you don't understand the problems and you don't understand the technology“, so Heidenreich abschließend.
„Auch bei der einschlägigen Norm ISO 14971 für das Risikomanagement von Medizinprodukten soll die Security zukünftig verankert werden, um den Risiko-Begriff zu erweitern“, betonte Hans Wenner, Inhaber vom Ingenieurbüro Wenner. Es bleibe dem Hersteller überlassen, ob er die Überlegungen zur Informationssicherheit in einem einzigen Risikomanagement-Prozess adressiert, beispielsweise, indem er seinen bestehenden Prozess erweitert, oder ob er unterschiedliche Prozesse dafür etabliert. Wenner empfahl an dieser Stelle, den Technical Report ISO TR 24971 als Hilfestellung zu Rate zu ziehen. Anhand einer in Verkehr gebrachten medizinischen App zur Behandlung von Hämophilie-Patienten demonstrierte Dr. Andreas Rösch, Geschäftsführer, Rösch & Associates Information Engineering GmbH, die praktische Umsetzung des Risikomanagements. Das Unternehmen hat diese Erkenntnisse auch öffentlich publiziert.

Spyra
Gerald Spyra | Uwe Nölke

Verantwortlichkeiten beim Datenschutz

"Respekt vor den Daten anderer“ fordert Rechtsanwalt Gerald Spyra, Partner der Kanzlei Ratajczak & Partner. Vor dem Hintergrund der neuen EU-Datenschutz-Grundverordnung (DSGVO) betonte Spyra, dass „in Abhängigkeit von konkreten technischen und organisatorischen Sachverhalten des Einsatzes einer medizinischen Software die Anforderungen des Datenschutzes sehr unterschiedlich sein können“. Ein Hersteller sollte darüber hinaus als Verantwortlicher dafür Sorge tragen, dass eine medizinische Software die Anforderungen an „data protection / security by design“ und „by default“ erfüllt. Zum Einsatz kommt das Medizinprodukt aber beim Betreiber und der Hersteller sollte deshalb „entsprechende (aussagekräftige) Informationen darüber zur Verfügung stellen, wie sein Produkt funktioniert, welche Datenverarbeitungen stattfinden und wie der Betreiber die ihm obliegenden gesetzlichen Anforderungen im konkreten Produkt abbilden kann“, so Spyra. Trotz der verbindlichen Anwendung der DSGVO ab dem 25. Mai 2018 erlauben nationale Öffnungsklauseln auch weiterhin nationale Vorschriften in einem bestimmten Umfang.

Handorn
Boris Handorn | Uwe Nölke

MDR, Haftungsrecht...

Obwohl die neue europäische Medizinprodukte-Verordnung (MDR) selbst keine Definition für Software enthält und auch keine explizite Unterscheidung zwischen stand-alone und embedded Software vornimmt, hat der Gesetzgeber die Anforderungen verschärft bzw. konkreter gefasst. „Strengere Klassifizierungsregeln  werden wohl nur wenige Software-Medizinprodukte in der Klasse I ohne Beteiligung einer Benannten Stelle belassen“, so Rechtsanwalt Dr. Boris Handorn, Partner der Kanzlei Simmons & Simmons. Eine viel diskutierte neue Anforderung an Medizinprodukte-Hersteller besteht in der Verpflichtung zur Deckungsvorsorge im Falle einer potentiellen Haftung gemäß der EU-Produkthaftungs-Richtlinie 85/374/EWG. Hier steckt der Teufel aber im Detail, wenn es um die Frage geht, ob „stand alone Software überhaupt ein „Produkt“ im Sinne der Produkthaftung ist“, stellte Handorn fest. Nach gängiger Auffassung gelte dies nicht für „Apps oder anderer Software, die nur zum Download angeboten werden oder Software, die ausschließlich auf dem Server des Anbieters genutzt wird“. Dieses Beispiel zeigt, wie kompliziert sich die rechtlichen Anforderungen für Software-Hersteller aus unterschiedlichen Rechtsgebieten darstellen.

800
René Salamon | Uwe Nölke

...und BSI-Gesetz - immer mehr Anforderungen an die Hersteller

Im Gesundheitssektor unterliegt ein Krankenhaus ab einer Fallzahl von 30.000 vollstationären Patienten im Jahr den Regelungen zu kritischen Infrastrukturen im nationalen BSI-Gesetz. Gemäß
§ 8a ergibt sich die Anforderung für Betreiber kritischer Infrastrukturen, „angemessene organisatorische und technische Vorkehrungen zur Vermeidung von Störungen der Verfügbarkeit, Integrität, Authentizität und Vertraulichkeit ihrer informationstechnischen Systeme, Komponenten oder Prozesse zu treffen, die für die Funktionsfähigkeit der von ihnen betriebenen kritischen Infrastrukturen maßgeblich sind“. Aber auch der Hersteller sei gefordert, stellte René Salamon, Verantwortlicher für den Sektor Gesundheit beim Bundesamt für Sicherheit in der Informationstechnik, fest, denn „eine unzureichende bzw. nicht dem Stand der Technik entsprechenden Security-Architektur der Produkte würde eine sichere Integration bzw. den sicheren Betrieb erschweren oder sogar unmöglich machen“. Die zu erwartenden Umgebungsbedingungen beim Betreiber müssten bei der Entwicklung dieser Produkte eine wesentliche Rolle spielen. Deshalb könnten die „konkreten Anforderungen nur im beiderseitigen Austausch zwischen Betreiber und Hersteller identifiziert werden“, so Salamon.

Impressionen