Roundtable-Gespräch zur Software in Medizingeräten

Werner Kexel ist Geschäftsführer und Managing Director der benannten Stelle Eurocat / BSI in Darmstadt.Achim Leitner

Die Medizingeräte-Gesetzgebung ist im Umbruch: Hersteller müssen sich seit seit 23. März 2010 an die EU-Verordnung 2007/47 halten. „In dem Wechsel sind wir gerade mitten drin“, erklärt Werner Kexel von Eurocat / BSI und ergänzt: „Für nächstes Jahr ist ein gravierender Wechsel geplant. Alle drei Medizinprodukterichtlinien werden komplett überarbeitet.“ Dabei hat die 2007/47 vor allem eine „Klarstellung gebracht, dass Software auch ein Medizinprodukt sein kann“, meint Prof. Johner vom Institut für IT im Gesundheitswesen.

Normen und Gesetze

Prof. Dr. Christian Johner gründete das Institut für IT im Gesundheitswesen und lehrt dort sowie an der Hochschule Konstanz.Achim Leitner

Werner Kexel fasst den Zusammenhang zwischen Gesetzen und Normen zusammen: „Das Gute ist, dass die Gesetzgebung nur grundlegende Dinge regelt, und getrennt davon die technisch-pragmatische Umsetzung auf der normativen Ebene geregelt wird.“ Normen sind starke Empfehlungen, wie man das Gesetz erfüllen kann. Im Medizinproduktebereich gibt es nach seiner Schätzung etwa 400 harmonisierte Normen. „Wer diese anwendet, kann eine Vermutungswirkung erzielen, dass er das Gesetz erfüllt.“

Man kann aber auch eigene Wege beschreiten: „Dann muss man beweisen, dass die eigene Methodik das gleiche Sicherheitsniveau, den Stand der Technik einhält. Das findet dann in regen Diskussionen mit der benannten Stelle statt“, ergänzt Kexel. Prof. Christian Johner findet gut, „dass man nicht so strikt an die Kandarre genommen wird. In der Praxis haben gerade kleine und mittlere Firmen aber kaum die Möglichkeit, so eine Argumentationskette aufzubauen.“ Für die Forschung öffnen sich damit eher neue Wege, erklärt Sören Kemmann vom Fraunhofer IESE, schränkt aber ein: „Wir haben auch die Herausforderung, benannte Stellen davon zu überzeugen, dass das was wir machen der Stand der Technik ist oder sicherer als das, was die Normen fordern.“

Sören Kemmann forscht am Fraunhofer-Institut für Experimentelles Software Engineering in Kaiserslautern.Achim Leitner

Spielräume nutzen

Letztlich prüfen die benannten Stellen wie ein Produkt entsteht, nicht das Endprodukt selber. Kemmann dazu: „Eine recht große Diskussion ist Prozesssicherheit und Prozesskonformität gegenüber Produktsicherheit. In der Forschung kennen wir viele Ansätze, um die Sicherheit des Produkts zu prüfen. Es gibt aber keine Studie, die detailliert darlegen würde, dass eine höhere Prozessqualität auch zu einer höheren Produktqualität führt. Man hat nur bewiesen, dass eine höhere Prozessqualität zu einer konstanteren Qualität im Produkt führt.“ Wenn ein Produkt schlecht war, dann wird es durch einen besseren Prozess auch nicht besser.

Matthias Hölzer-Klüpfel ist Principal Consultant Medical beim Erlanger Unternehmen Method Park Software.Achim Leitner

Allerdings gilt, wie Matthias Hölzer-Klüpfel von Method Park aus seiner Beratungspraxis berichtet: „Die meisten Unternehmen argumentieren bei weitem nicht auf diesem Level. Die sind bestrebt, wenigstens 80% der Norm überhaupt umzusetzen.“ Auch Bernhard Mumm, dessen Firma Tomtec mittlerweile ausschließlich medizinische Software schreibt, sieht den Spielraum eher theoretisch: „Als Firma Freiraum leben und beim jährlichen Audit der benannten Stelle das verargumentieren? Unsere langjährige Erfahrung sagt: Audit-Fragebögen sind Normen-getrieben. Die Auditoren gehen die Anforderungen der Reihenfolge nach durch. Wenn man das nicht genau erfüllt, hat man viel Diskussion. In der Realität arbeitet man mit einem Mapping: Mit unserer Methode X erfüllen wir Norm-Anforderung Y.“

Bernhard Mumm ist President & COO des Software-Herstellers Tomtec Imaging Systems in Unter­schleißheim.Achim Leitner

Werner Kexel sieht Spielraum auch noch, wenn man sich an die Normen hält: „Die Grundnorm für Qualitätsmanagement ISO 13485 sagt, dass es sehr sinnvoll ist, sich am Anfang zu überlegen, was ich entwickeln will und das nicht dem Zufall überlasse. Die Norm erlaubt aber Modifikationen und fordert nur, dass es einen Änderungsprozess gibt, damit sie strukturiert ablaufen.“

Anforderungen verstehen

Bei den Anforderungen zu Beginn einer Produktentwicklung räumt Prof. Christian Johner mit einem Missverständnis auf: „90 bis 100 Prozent aller Firmen wirbeln Nutzungsanforderungen und die Anforderungen an das Gerät durcheinander. Die Systemanforderungen sind beliebig, die kann man nie vollständig erfassen. Wir befinden uns hier ja im Lösungsraum. Konstant sind dagegen die Nutzungsanforderungen. Die kann man ziemlich vollständig herausbekommen, wenn man methodisch herangeht.“ Prof. Johner ist sich sicher: „Wir könnten Quantensprünge erzielen und die meisten Iterationen obsolet machen. Mein Wunsch ist, dieses Wissen zu berücksichtigen. Es ist zwar in einigen Normen drin, aber noch nicht in den harmonisierten wie der IEC 62366, die das Gesamtsystem angeht.“ Mehr dazu steht im Infokasten „Nutzen und Anforderungen“.

Auch die Validierung bewegt sich nach seiner Überzeugung eine Ebene zu tief. „Wir machen organisatorisch zu viel aus den Entwicklungsabteilungen heraus. Techniker denken in Lösungen.“ Matthias Hölzer-Klüpfel präzisiert: „Die Norm sagt, ich muss die Anforderungen aufschreiben. Ein Entwickler schreibt dann mehrere tausend Systemanforderungen nieder, bis auf die Schraube und den Farbton der Oberfläche hinunter.“ Die eigentlichen Nutzungsanforderungen des Anwenders gehen dabei leicht unter.

Unsicherheit durch Flexibilität

Roland Bickel ist Head of Marketing and Sales beim Embedded-Spezialisten Hitex Development Tools in Karlsruhe.Achim Leitner

Hitex-Manager Roland Bickel sieht Unsicherheiten auch beim Testen. „Im Automotive-Bereich steht in der ISO 26262 genau drin, wie ich Software fürs Automobil zu entwickeln habe und welche Arten von Tests ich nachweisen muss. Auch im Fahrstuhl weiß ich genau, wie dessen Software zertifiziert wurde. Im Medizintechnikbereich gibt es keine exakte Vorgabe, wie eine Software zu testen ist oder wie Regressionstests aussehen müssen. Nur von der FDA gibt es eine recht alte Guideline. Die ist trotzdem heute noch das konkreteste, was es im Medizintechnikbereich fürs Testen gibt.“

Matthias Hölzer-Klüpfel bestätigt: „Die ISO 26262 ist quasi die Automobilvariante der IEC 61508. Sie ist nicht harmonisiert, aber es lohnt sich trotzdem sie zu lesen. Sie differenziert die Sicherheitslevel viel feiner als die IEC 62304 mit ihrer A-B-C-Klassifikation. Das erlaubt auch Folgerungen wie: Wenn ich mich in SIL-3 einordne, weiß ich, wann ich genug getan habe.“ Prof. Johner erwidert: „Die IEC 62304 versteht sich auch gar nicht als Best-Pracitice-Norm. Sie gibt nur das unterste Niveau vor, das man überspringen muss, und das ist nicht diskussionswürdig. Trotzdem haben viele Firmen das Problem, überhaupt auf dieses Niveau zu kommen.“

Diesen Zwiespalt kennt Werner Kexel zur Genüge: „Wenn etwas genau spezifiziert ist, dann führen wir die Diskussion: Warum gibt uns diese Zwangsjacke keinen Spielraum? Gibt es aber prinzipiellere Regelungen und trägt der Hersteller die Verantwortung, dann hören wir: Was sollen wir jetzt machen? Ich sage dann: Das müsst ihr selbst wissen.“ Letztlich hat der Hersteller das beste Know-how zum Produkt. Die benannte Stelle kann nie besser sein, weil der Auditor binnen Stunden oder Tagen prüft, was der Hersteller in Mannjahren geschaffen hat.

Prof. Johner holt weiter aus: „Die Unsicherheit ist, wie man mit verschieden kritischen Programmen oder Teilen von Software umgeht. Das Problem liegt aber eine Stufe davor: Wer macht das Risikomanagement? Das sind die Leute aus dem QM oder aus der Entwicklung. Das ist aber nicht deren Aufgabe! Wir brauchen Leute, die den medizinischen Kontext kennen. 75% aller Toten sind laut FDA nicht durch Fehler im Gerät gestorben, sondern weil die Anwender im Kontext falsch damit umgehen.“ Zudem fehlt laut Johner das medizinische Wissen: „Man muss mit dem Arzt sprechen: Was passiert, wenn sich das Gerät so oder so verhält? Wie oft würden sie das bemerken, wie oft könnten sie reagieren? Wie oft würde es zum Todesfall oder einer Verletzung führen? Da bin ich auch immer wieder überrascht.“ Man dürfe nicht nur die Schrauben und die Software betrachten. „Risiko-Management geht bis zum Patienten, das ist der wichtigere Teil. Solange man die Ursachenkette von der Gerätekante bis zum Patienten nicht betrachtet, ist es völlig absurd, über das Innenleben des Geräts zu sprechen.“

Die Umgebung und ihre Risiken

Sören Kemmann zieht nochmal den Vergleich zur ISO 26262: „Der Umgebungsaspekt ist beim Auto sehr simpel. Die Hersteller wissen genau, was mit ihrem Fahrzeug passieren wird. In der Medizintechnik ist das Anwendungsfeld viel breiter, vom Brachytherapiegerät über den Defibrillator bis zur Patientenverwaltungssoftware. Ich kann keine normalen Nutzungsszenarien festlegen und klassifizieren. Außerdem gibt es neben der IEC 62304 noch die ISO 14971 für Risikomanagement, also nichts Integriertes.“

Rahman Jamal ist Technical & Marketing Director Europe und Prokurist bei National Instruments in München.Achim Leitner

Wo die realen Risiken liegen, zeigt Prof. Johner anhand des Vigilanzsystems beim Bundesinstitut für Arzneimittel und Medizinprodukte, bei dem Hersteller sicherheitsrelevante Fehler melden: „Auf der Seite des BfArMs hatten wir in der letzten Woche fast jeden Tag einen Hinweis, der potenziell tödliche Folgen haben könnte. Da wurden Patientendaten verwechselt, da wurden in Bestrahlungsgeräten Algorithmen falsch implementiert. Wir sprechen also nicht von esotherischen Problemen, sondern von was, das täglich auftritt.“ Dabei wird nur ein Bruchteil der Probleme bekannt: „Wir sehen nur die Spitze des Eisbergs und nur Dinge, die mit Einzelgeräten zu tun haben. Die Kombination der Geräte, und zwar nicht nur die geplante Kombination, wird uns in eine ganz neue Dimension der Probleme hineinführen.“ Rahman Jamal von National Instruments führt weiter: „Zum Beispiel werden Geräte der Intensivmedizin heute automatisiert, also einzelne Maschinen miteinander verbunden und zentral gesteuert, und zwar über die IT-Anlage.“

Werner Kexel gibt sich gelassen und schmunzelt: „Gesetzlich sind wir darauf vorbereitet: Der Hersteller muss dafür sorgen, dass alle Kombinationen mit seinem Gerät sicher funktionieren.“ Wie realitätsfern diese Vorgabe ist, zeigt sich am schallenden Gelächter in der Runde. Kexel weiter: „Was fehlt, ist der normative Unterbau. Normen werden allerdings nur langsam entwickelt und es beteiligen sich nur die Industrie und vielleicht einige Prüfhäuser und benannte Stellen. Nie in diesen Gremien vertreten sind die, die es betrifft: Ärzte und Patienten.“

Modellgetriebene Entwicklung

Das Problem, dass Mediziner und Patienten erst sehr spät eingebunden werden, findet sich nicht nur in der Normung und in der Spezifikation eines Geräts: Auch die Entwicklung findet in aller Regel reichlich abgeschottet statt. Die Runde kritisiert auch diesen Aspekt und sucht nach Alternativen. Einen Weg sieht Rahman Jamal in den hauseigenen Werkzeugen: „Wir haben eine Methode namens ,Graphical System Design‘. Vom Design über das Prototyping bis zur Serienfertigung testet man alle Phasen iterativ mit der gleichen Labview-Toolkette, nicht erst am Schluss. Je früher das Testen passiert, um so besser. Bei uns geht das gleich mit den echten Signalen. Das versteht zwar jeder, in der Praxis gibt es aber getrennte Abteilungen in den Firmen, und an den Schnittstellen von einer Phase zur nächsten kollidieren verschiedene Welten mit eigenen Sprachen und eigenem Know-how.“

Matthias Hölzer-Klüpfel ergänzt: „Während man einen echten Prototypen wegwerfen muss, entsteht bei modellgetriebener Entwicklung eigentlich was anderes. Was ich mit Matlab aufgebaut habe, will und kann ich ins finale Produkt übernehmen.“ Und man kann es viel früher den Anwendern zeigen. Sören Kemmann sieht weitere Vorteile: „Modellgetriebene Entwicklung sorgt für effiziente Dokumentation und Verfolgbarkeit über verschiedene Ebenen und Modelle hinweg. Das ist einfacher als mit Word und Excel. Der Hauptvorteil ist die Doku. Hier haben wir eine eindeutige Semantik und sehen, was zum Beispiel eine Änderung bewirkt.“

Update als integraler Bestandteil

Änderungen gehören nicht nur zur Entwicklung, sondern auch zur Wartung eines Produkts. Folglich stellt sich die Frage nach der Update-Policy. Matthias Hölzer-Klüpfel betont: „Update-Möglichkeiten muss man in ein Medizinprodukt natürlich reindesignen, das ist Handwerk. Wann muss ich mit dem Update aber zur benannten Stelle? Wenn sich der bestimmungsgemäße Gebrauch ändert, auf jeden Fall.“ Das bestätigt Werner Kexel: „Die Normen verlangen als Software-Wartungsprozess Methoden, wie ich mit Updates umgehe. Wir empfehlen: Nur über wesentliche Produktänderungen muss man die benannte Stelle informieren. Release-Nummern sind jedenfalls kein Maßstab. Wenn man Funktionalitäten verändert, dann ist das eine wesentliche Änderung und wir brauchen eine Re-Validierung. Dazwischen gibt es aber eine große Bandbreite, die von Produkt zu Produkt unterschiedlich ist.“

Damit ein Update keine längst gelösten Probleme neu aufreißt, sind Regressionstests entscheidend. Roland Bickel sieht auch hier offene Punkte: „Was habe ich schon mal getestet, was muss ich alles nochmal testen? Muss man die gesamte Applikation mit einem Regressionstest noch einmal prüfen, oder genügen Modul- und Unit-Tests für den geänderten Teil? Es könnte ja Auswirkungen auf andere Bereiche geben.“ Das Problem geht laut Bernhard Mumm weiter: „Der modulare Ansatz ist auch an anderer Stelle schwer, wenn man nicht weiß, wo eine Komponente eingesetzt wird. Unsere OEM-Kunden erhalten oft Module als DLL. Zunächst kennen wir die Anforderungen und testen genau dafür. Auf einmal stellen wir fest, dass der Kunde es auch für andere Anwendungen einsetzt, etwa Biopsie. Ohne neue Risikobetrachtung und ohne uns zu fragen – es funktioniert für den Kunden, und er fragt gar nicht, ob sich das Modul dafür eignet.“

Komplexe Systeme

Werner Kexel zieht den Kreis weiter: „Unsere Herausforderung ist die Integration. Bisher kam jedes Gerät aus einer Hand, heute wachsen sie mit den Krankenhaus-Informationssystemen zusammen. Wie fassen wir das regulatorisch? Eine Gruppe arbeitet derzeit an einem Interpretationsdokument zur Einteilung Medizinprodukt ja/nein. Hier wird heftigst diskutiert: Wo endet das Medizinprodukt und wo beginnt die Verwaltungssoftware? Soll alles als Medizinprodukt gleich getestet werden, oder bauen wir das modular auf?“

Den modularen Ansatz hält Bernhard Mumm für unausweichlich. „Die ganzen Großinstallationen gibt es genau einmal auf der Welt, jedes Krankenhaus ist anders und muss vorhandene Systeme einbinden. Da gibt es an den Schnittstellen beliebig viele Unwägbarkeiten und Probleme, die erst im Betrieb auftreten.“ Das bestätigt auch Sören Kemmann: „In der Embedded-Roadmap 2020 der Bundesregierung lautet das große Schlagwort: Open Systems, oder sogar Cyber-Physical Systems. Da ändert sich das System laufend: Zum Beispiel kommt der Bruder des Patienten mit seinem iPad ins Krankenzimmer und darf damit die Daten ansehen. Systeme ändern sich relativ schnell: eine benannte Stelle kann gar nicht ein fertiges System zertifizieren.“

Dr. Andreas Purde ist ­leitender Auditor bei TÜV Süd Product Service in der Abteilung aktive Medizinprodukte, München.Achim Leitner

Für steigende Komplexität braucht man aber gar kein komplettes Krankenhaus, auch einzelne Produkt werden immer stärker skalierbar. Andreas Purde vom TÜV Süd sieht „eine Gratwanderung: Wo endet die Verantwortung des Herstellers, wo beginnt die des Krankenhauses? Die Parameter, die der Hersteller anbietet, kann er gar nicht alle überprüft haben. Das ist gerade bei Laborgeräten der Fall, bei denen der Anwender eigene Formeln einträgt. Das kann die benannte Stelle unmöglich alles prüfen.“

Und wenn Ärzte künftig per Telemedizin ihre Produkte online parametrieren, ergeben sich weitere Herausforderungen. Andreas Purde, der gerade aus den USA zurückgekehrt ist, bringt ein spannendes Thema mit: „Der ,Mord übers Internet durch das Medizinprodukt‘ nimmt langsam Gestalt an. Ich wurde zum Beispiel gefragt: Wenn der Arzt sein Passwort eingibt, ist das dann sicher genug? Da kann ich noch sagen: Ich glaube nicht. Bei größeren Geräten kann man aber bestenfalls an ein paar kritischen Stellen in die Tiefe gehen und hoffen, dass auch der Rest passt.“

Safety und Security

Zu IT-Sicherheitsfragen erklärt Purde: „Für uns ist das Neuland. Wir haben aber Experten in unseren anderen Bereichen, wo wir uns Unterstützung holen können. Gerade wenn sich Security und Safety schneiden, muss ich es machen.“ Werner Kexel ergänzt: „Normativ gibt es in diesem Umfeld die IEC 27000 sowie die IEC-80000er-Serie, die sich mit Systemen beschäftigt. In Deutschland kommen übrigens die Vorgaben des BSI hinzu und generell die Datenschutzgesetzgebung. Wir stellen immer wieder fest, dass Hersteller nur auf die Medizinprodukte-Regularien achten und horizontale Regelungen außer Acht lassen.“

Matthias Hölzer-Klüpfel berichtet von Diskussionen auf einer Konferenz zu Security in Medizinprodukten: „Hier sind sogar die Bedrohungsszenarien noch völlig unklar. Zum Beispiel ein Mord, bei dem jemand einen Remote-fähigen Herzschrittmacher ferngesteuert umprogrammiert. Denkbar sind auch Menschen, die sich selber dopen, indem sie ihren Herzschrittmacher umprogrammieren. Viele Patienten verfälschen ihre eigenen Werte, weil sie nicht zugeben wollen dass sie ihren Blutzucker nicht im Griff haben. Wenn sich der Arzt dann darauf verlässt, hat er ein Problem.“

Die wahren Risiken

Bei IT-Sicherheit und Vernetzung täuscht der Eindruck oft, wo die wirklich großen Gefahren liegen. Bernhard Mumm: „Aus meiner Erfahrung sind Risiken bei vernetzten Systemen eher die Interpretation der Werte. Wer einen Wert erfasst, weiß oft gar nicht, welche diagnostische Entscheidung dahinter steckt.“ Und Matthias Hölzer-Klüpfel ergänzt: „Als Hersteller vernachlässigt man gerne, dass die meisten Attacken von innen kommen. In einem Krankenhaus kann jeder sehen, was der andere macht. Daher gilt bei medizinischem Fachpersonal oft die Regel: Wenn Du krank bist, gehe auf jeden Fall in ein anderes Krankenhaus…“

Prof. Christian Johner schwenkt mit diesem Gedanken in die Risikoanalyse: „Wir rechnen damit, dass die Angriffe zwei bis drei Größenordnungen häufiger von innen kommen als von außen. Dann ist es nicht mehr so entscheidend, wie sicher der Router nach außen arbeitet und mit wie vielen Bits er verschlüsselt, sondern viel mehr, dass man wenigstens für innen mal eine Policy aufstellt, wer was darf und welche Rechte hat.“ Auch Werner Kexel ist überzeugt, dass nur „gutes Risikomanagement hilft, in komplexen Systemen das Augenmerk auf die Stellen zu richten, wo das größte Risiko vorherrscht. Ich brauche nur die Methodik, das zu finden. Und genau dafür gibt es immer mehr Normen, zum Beispiel die 80000er-Serie. Die Kernaussage lautet: Betreibe Risikomanagement und definiere Verantwortlichkeiten. Kliniken, die heute zukunftssicher arbeiten wollen, etablieren Risikomanagement-Prozeduren. Das wird künftig ein Erfolgsfaktor werden.“

Audio-Statements

Zum Ende des Roundtable-Gesprächs bat die Redaktion alle Teilnehmer um ein persönliches Fazit und einen Ratschlag an die Entwickler von Medizingeräten, wie sie ihre Software sicher gestalten und reibungslos durch die Zertifizierung bringen.

Prof. Dr. Christian Johner, Institut für IT im Gesundheitswesen:

Rahman Jamal, National Instruments:

Sören Kemmann, Fraunhofer-Institut für Experimentelles Software Engineering:

Dr. Andreas Purde, TÜV Süd Product Service:

Werner Kexel, Eurocat / BSI:

Matthias Hölzer-Klüpfel, Method Park:

Bernhard Mumm, Tomtec Imaging Systems:

Roland Bickel, Hitex Development Tools:

An dieser Stelle ein herzliches Dankeschön an alle Teinehmer!

(lei)