Die IEC 80001-1 ist eine Norm die das Risikomanagement beim Betrieb von IT-Systemen in Krankenhäusern und bei anderen Anbietern von Gesundheitsdienstleistungen beschreibt.

Geltungsbereich

Medizinische IT-Netzwerke

Die IEC 80001-1 beschreibt Anforderungen an ein Risikomanagement für medizinische IT-Netzwerke (MIT). Darunter versteht die Norm IT-Netzwerke, die mindestens ein Medizinprodukt enthalten . Nicht dazu gehören zum Beispiel

• geschlossene Netzwerke, die nur von einem Medizinproduktehersteller betrieben werden (auch wenn Produkte anderer Hersteller darin genutzt werden), und
• Netzwerke, die keine Medizinprodukte enthalten.

IEC 80001-1 und gesetzliche Forderungen an die Betreiber

Wenn Hersteller Medizinprodukte auf den Markt bringen wollen, müssen Sie unzählige Normen und Gesetze einhalten. So werden der Entwicklungs- und Produktionsprozess genauso wie das Produkt selbst streng überwacht. Und auch im Betrieb, z.B. im Krankenhaus, muss dieses Produkt regelmäßig von geschulten Personen überprüft werden.

Die IEC 80001-1 ist aber nicht gesetzlich gefordert. Sie ist auch keine harmonisierte Norm, mit deren Einhaltung der Nachweis einer gesetzlichen Anforderung erbracht ist. Vielmehr beschreibt sie den Stand der Technik mit Bezug zum Risikomanagement von IT-Netzwerken. Und so ein Risikomanagement wiederum ist gesetzlich vorgeschrieben, beispielsweise von der Medizinprodukte-Betreiberverordnung (MPBetreibV).

Problematik, dass IEC 80001-1 nicht gesetzlich gefordert ist

Wie gesagt, verpflichtend ist die Einhaltung der IEC 80001-1 nicht. Es mag erstaunlicher klingen, dass die Medizinprodukte ohne weitere Prüfungen in IT-Netzwerke eingebunden werden dürfen. Denn diese Netzwerke enthalten Netzwerkkomponenten wie Switches, Router und Kabel ebenso wie Server und weitere Medizinprodukte. Hier wird eifrig verkabelt und verschaltet – ohne darüber nachzudenken, welche Wechselwirkungen entstehen können.

Da überrascht es kaum, dass in einer Klinik wegen Überlastung des Netzwerks keine Röntgenbilder mehr übertragen werden, in einer anderen die Arztbriefe wegen falscher IP-Settings im Nirvana verschwinden und in einer dritten 4(!) Ampere auf den Netzwerkkabeln gemessen werden.

Inhalte der IEC 80001-1 Norm

Ich war sehr gespannt auf die neue Norm IEC 80001-1, die sich langsam der endgültigen Form nähert und die oben genannten Risiken adressieren soll. Sie nennt sich „Anwendung des Risikomanagements für IT-Netzwerke mit Medizinprodukten. Sie legt Anforderungen

• die Organisation und Rollen wie den Med-IT-Risk-Manager und die oberste Leitung
• sowie an Prozesse, insbesondere den Risikomanagement-Prozesse

Wie bei vielen Normen wie der ISO 9001 bzw. 13485 trägt die oberste Leitung die Verantwortung. Sie muss den Risikomanagementprozess einführen, darf aber einen Risikomanager benennen. Dieser soll als Vermittler zwischen den internen Abteilungen (klassische IT, „medizinische IT“ und Medizintechnik) und externen Partnern (Dienstleister, Hersteller) vermitteln. Es ist seine Aufgabe, Informationen zu sammeln und auszuwerten, um mögliche Risiken zu finden und zu beherrschen.

Auch an die Hersteller werden Forderungen gestellt: Sie müssen über ihr Produkt, dessen Zweckbestimmung und Anforderungen an das Netzwerk informieren.

Der weitaus größte Teil der IEC 80001-1 ist dem eigentlichen Risikomanagement gewidmet, vereinfacht gesagt dem:

• Risiken finden
• Risiken bewerten
• Risiken beherrschen
• Risiken neu bewerten und akzeptieren, d.h. genehmigen.

Das kennt man aus der ISO 14971 schon.

Dem vorgeschaltet ist eine Projektplanungs- und Dokumentationsphase. Ich gestehe, nicht zu verstehen, was hier unter Projekt und Projektplanung zu verstehen ist. Die Planung dessen, wie ein konkretes Medizinprodukt eingebunden werden muss? Oder die Planung, wie generell Medizinprodukte in ein Netzwerk einzubinden sind? Wie versteht man einen Satz wie „Die Verantwortliche Organisation muss einen Projektplan aufstellen und überwachen, der vorgesehen ist […] für eine systemübergreifende und/oder systemische Sicht auf die wesentlichen Merkmale der medizinischen Werte der Patienten unter Abwägung der technischen Möglichkeiten gegen die Risiken“? Was sind „wesentliche Merkmale von medizinischen Werten“?

Einige in der IEC 80001-1 genannten Maßnahmen sollten Krankenhäuser aber umsetzen:

1. Eine Person auswählen, die sich systematisch über Risiken von (neuen) Medizinprodukten in Netzwerken und den Auswirkungen von Änderungen an Netzwerken Gedanken macht.
2. Keine Änderungen durchführen, die nicht zuvor von der IT und der Medizintechnik gemeinsam besprochen wurden. Dies gilt es zu dokumentieren.

Schutzziele der IEC 80001-1

Die IEC 80001-1 nennt drei Schutzziele:

1. Die Sicherheit (Safety),
2. die Effektivität und
3. die Daten- und Systemsicherheit.

Allerdings sind diese Schutzziele nicht unabhängig von einander:

Weshalb ist die Datensicherheit per se ein Schutzziel? Die Datensicherheit ist eine Voraussetzung, beispielsweise um Safety zu erreichen. Datenschutz hätte man als eigenes Schutzziel als vernünftig eingeschätzt. Die Norm nennt Schutzziele, die voneinander abhängen und sogar in einer Ursachen-Wirkungsbeziehung zueinander stehen.

Die Safety bedeutet, dass man Schäden minimieren will. Dieser Schäden korrelieren aber definitionsgemäß mit einer Verringerung der Effektivität. D.h. die Effektivität ist sowohl ein direktes als auch ein indirektes Schutzziel? Das verwirrt. Schutzziele sollten disjunkte (überlappungsfreie) Mengen sein.

Dann stellt sich die Frage: Wie grenzt sich „Ergebnis für Patienten erreichen“ von einer „Vermeidung von physischen Verletzungen und Schädigungen der menschlichen Gesundheit“ ab? Auch diese beiden Aspekte sind zu nicht unwesentlichen Teilen deckungsgleich.

In anderen Worten: Die Neudefinitionen der Begriffe Schaden und Effektivität so wie die Festlegung der Schutzziele erscheinen in der IEC 80001-1 für überdenkenswert. Hätten die Schutzziele gelautet

• geplantes/gewünschtes Ergebnis für Patienten erreichen (im Sinn einer erfolgreichen und „nebenwirkungsfreien“ Behandlung und/oder Diagnose),
• Vertraulichkeit gewährleisten und
• sonstige Organisationsziele erreichen (z.B. finanzielle, Image),

hätte das mehr eingeleuchtet. Mit einer Trennung des ersten Schutzziels in eine Behandlung/Diagnose, die einerseits erfolgreich (wirkungsvoll) und andererseits „nebenwirkungsfrei“, d.h. ohne unnötige Schäden (hier durch IT-Probleme) ist, könnte man auch gut leben. Dann wären es vier Schutzziele.

Die Überlappung der Begriffe, wie sie die Norm definiert, macht das alles etwas unnötig kompliziert.

Weitere Hilfsmittel und Informationen

IEC 80001-1 Tools

Noch bin ich mit meinen IEC 80001-1 Projekten nicht soweit: Wir haben die Prozesse nicht so stabil , dass der Einsatz von  Werkzeugen Sinn ergibt. Dennoch möchte ich Sie auf zwei Werkzeuge aufmerksam machen, die mir Teilnehmer meiner Masterstudiengänge empfohlen haben:

• http://www.verinice.org/: Dieses Werkzeuge nennt sich selbst ein „ISMS-Tool für das Management von Informationssicherheit“. Neben einer kostenlosen Variante gibt es noch kommerzielle Versionen.
• http://www.intermapper.com/: Dieses Werkzeug hilft bei der (semi-)automatisierten Dokumentation des Netzwerks. Wer diese Dokumentation von Hand (in meinem Fall hätte der Begriff „zu Fuß“ die Sache auch getroffen) erstellt hat, weiß, wie viel Arbeit das bedeutet. Noch mehr Arbeit bedeutet es allerdings, die Dokumentation aktuell zu halten. Das ist eines der Nutzenversprechen dieses Tools.

Vielleicht ist was Geeignetes für Sie dabei. Wenn Sie weitere Werkzeuge kennen, die Sie im IEC 80001-1 Kontext als nützlich empfinden, dann schicken Sie mir doch eine kurze Mail (christian [at] johner-institut [dot] de).

IEC 80001-1 aus UML-Sicht

Wo wir gerade im UML-Rausch sind (nun der dritte Beitrag in Folge dazu):

Michael Ständer von GE hat begonnen, die IEC 80001-1 in UML zu modellieren, und mir das erste Ergebnis geschickt. Das verschafft einen wie ich finde sehr guten und schnellen ersten Überblick.

Personen und Rollen

Mein 80001-1-Projekt nimmt Fahrt auf. Ich habe mich getroffen mit dem

• Krankenhaus-IT-Leiter
• Leiter Medizintechnik
• externen Anbieter von IT-Dienstleistungen
• Verantwortlichen für die Kliniknetzwerke
• Geschäftsführer des Krankenhauses

Kommt Ihnen diese Auflistung bekannt vor? Es sind die Personen und Rollen, mit denen ein Med-IT-Risikomanager laut IEC 80001-1 kommunizieren muss. Doch einige fehlen noch:

• Medizintechnikhersteller
• Hersteller von (klinischen) IT-Systemen
• Lieferanten von IT
• Ärzte, Pflegepersonal und weitere Anwender

Da habe ich noch was vor mir – als unerwartet in die Rolle des ehrenamtlichen Med-IT-Risikomanager Geschlüpfter. Welche Erfahrungen ich in dieser Rolle mache, auf welche Schwierigkeiten ich dabei stoße, wie/ob ich diese meistern konnte, darüber werde ich in diesem und dem nächsten Quartal berichten.

Kritische Bewertung der IEC 80001-1

Ein erster Eindruck

Auch nach mehrmaligem Lesen bin ich nicht wirklich begeistert. Zwar ist der Text weitgehend nachvollziehbar und er formuliert Forderungen, denen ich zustimmen kann. Aber eine wirkliche Hilfestellung für die Krankenhäuser kann ich in der Norm nicht entdecken. Keine Checklisten, keine Anleitung wie man konkret zu verfahren hat. Den Kern der Norm stellt eine Beschreibung des Risikomanagementprozesses aus der ISO14971 dar. Und dieser ist wahrlich nicht sehr spezifisch für die IT-Netzwerke mit Medizinprodukte.

Die Schutzziele sind nicht Überlappungsfrei:

• Patientensicherheit
• IT-Sicherheit
• Unternehmensziele

Die Unternehmensziele beinhalten hoffentlich die Patientensicherheit und die IT-Sicherheit. Und die IT-Sicherheit dient hoffentlich der Patientensicherheit — zugegeben auch dem Datenschutz. Mehr zu diesem Thema finden Sie weiter unten.

So sehr ich an die Notwendigkeit glaube, Krankenhäusern Hilfestellungen bei dem Betrieb von Netzwerken mit Medizingeräten geben zu müssen, so sehr frage ich mich, ob diese Norm dabei wirklich hilft. Oder nur die Qualitätssicherungs-Bürokratie fördert. Bleibt zu hoffen, dass an diesem Entwurf doch noch etwas verbessert wird.

Braucht es diese Norm wirklich?

Mit meinem IT-Security Referenten am Institut, Jochen Kaiser, diskutiere ich zurzeit die IEC 80001-1. Ich habe ja kürzlich deren Begriffsdefinitionen kritisiert, weil beispielsweise die Sicherheitsziele überlappend und inkonsistent sind.

Aber auch der Sinn der Norm an sich steht immer wieder zur Diskussion. So wie das momentan angegangen wird, habe ich meine massiven Zweifel: Entweder die Betreiber tun gar nichts, oder sie bauen eine Bürokratie auf. Aber am Nutzen für den Patienten zweifle ich massiv bei diesem Ansatz.

Und dennoch gibt es ein paar gewichtige Gründe, die für die IEC 80001-1 sprechen:

1. Ohne die Norm wären die Krankenhäuser (hier als Metapher für alle Betreiber) nicht gezwungen, sich mit den Herstellern abzustimmen und diese zu zwingen, endlich den bestimmungsgemäßen Gebrauch sauber zu formulieren. Fast immer fehlen konkrete Forderungen, die gegeben sein müssen, um ein Medizinprodukt betreiben zu dürfen. Und damit meine ich explizit nicht nur die Forderungen an das Netzwerk.
2. Ohne die Norm würden die Krankenhäuser sich noch weniger Gedanken machen, was passiert, wenn man ein Gerät an ein Netzwerk anhängt, ein Gerät neu konfiguriert oder wieder entfernt.
3. Und ohne Norm wäre das Konzept des Risikomanagements bestenfalls bekannt aber niemals gelebt. Wie kann es sein, dass Krankenhäuser, deren Sinn darin besteht, Patienten zu heilen, nicht darüber nachdenken, wie sie ihre Patienten vor den selbst verursachten Risiken schützen?

Ich werde alles daran setzen, mit den nächsten webbased Trainings ein wirkliches Verständnis davon zu schaffen, was die Norm will und wie man das umsetzen kann, ohne einen QM-Overhead ohne Sinn und Verstand zu etablieren. Das ist es nämlich, was ich beobachte, weil die meisten selbsternannten Berater nicht einmal verstehen, dass ein Netzwerk eben keine Gefährdung darstellt.

Warum 80001-1 nur ein „guter Start“ ist

Die IEC 80001-1 beschreibt das Risikomanagement für medizinische IT-Netzwerke. Ich habe den Eindruck, dass viele Krankenhaus-IT-Abteilungen ihre Bemühungen mit Bezug zum Risikomanagement nur noch im Kontext dieser Norm sehen. Es gibt aber zahlreiche Risiken, die die IEC 80001-1 überhaupt nicht adressiert:

Wie gehen Sie beispielsweise mit Risiken um, dass Ihnen die guten Leute weglaufen? Oder die guten Leute die Sicherungsbänder mit vertraulichen Daten verlieren wie gerade in einem badischen Krankenhaus geschehen? Beides hat die IEC 80001-1 nicht im Fokus. Ein vollständiges IT-Security-Management beispielsweise nach ISO 27001 ist viel umfangreicher.

Die IEC 80001-1 deckt eben nur einen Teil des Risikomanagements ab. Sie ist aber für die Krankenhaus-IT ein guter Startpunkt.

Dilemma beim Risikomanagement nach IEC 80001-1

Die IEC 80001-1 verfolgt mehrere Schutzziele:

• die Sicherheit der Patienten
• den Datenschutz
• das Erreichen von Geschäftszielen, zu denen auch ökonomische Ziele zählen.

Die IEC 80001-1 fordert v.a. ein Risikomanagement im Gesundheitswesen. Das schließt eine Nutzen-Risikobewertung zwingend mit ein. Der Nutzen entspricht dabei den o.g. Schutzzielen, die Schäden entsprechen dem Nichterreichen dieser Ziele.

Soweit so gut. Doch wie drückt man seine Risikopolitik in einer Risikoakzeptanzmatrix aus? D.h. in einer Matrix, deren eine Achse die Schweregradachse ist? Das wird schwierig, denn nun müsste man die Schäden (Verletzung der Patientensicherheit, Verletzung des Datenschutzes und das Nichterreichen beispielsweise von ökonomischen Zielen) in einer Dimension quantifizieren. Und damit steht man auf einmal vor der unangenehmen Frage, was ein Menschenleben wert ist.

Vergessen Sie diesen Ansatz (auch wenn manche Krankenhäuser ihn unbewusst so gehen)! Sie benötigen für unterschiedliche Schutzziele unterschiedliche Matrizen mit jeweils unterschiedlichen Akzeptanzkriterien. Sie können dann abschließend eine Regel definieren, die beispielsweise besagt, dass jeweils das höchste Risiko zu betrachten ist, wenn man die Auswirkungen eines Problems (z.B. Ausfall eines Servers, Hacker-Angriff, fehlkonfigurierter Integrationsserver) bewerten will.

Sparen Sie sich die unnötige Diskussion darüber, was ein Menschenleben wert ist. Die führt Sie nur aufs ethische Glatteis.

Begriffe

Ein IT-Netzwerk mit einem oder mehreren Medizinprodukten ist ein Medizinisches Netzwerk (MIT).

• Ein IT-Netzwerk ist ein System welches die Kommunikation zwischen mehreren Datenknoten mit Kabel oder kabellos ermöglicht.
• Das Risiko ist die Verknüpfung aus der Wahrscheinlichkeit des Eintritts eines Schadens und der Höhe des Schadens.
• Das Rest-Risiko ist das übrige Risiko, welches verbleibt, wenn alle Maßnahmen zur Risikokontrolle getroffen wurden.
• Der Begriff Risikoanalyse fasst alle Methoden zusammen, die zur Abschätzung eines Risikos nötig sind.
• Risiko-Identifikation ist die Erfassung aller Risiken über verschiedene Methoden und Analysetechniken.
• Bei der Risikobewertung werden die potenziellen Risiken und deren Akzeptanz in ihrem Ausmaß bewertet. Ist ein inakzeptables Risiko nicht vorhanden, nennt man diesen Zustand sicher (Sicherheit).
• Der Schaden ist ein messbarer Nachteil, der entstehen kann. Dazu gehören Personenschäden, Produktionsausfall usw. Die Quelle eines solchen Schadens nennt man Gefährdung.
• Systemsicherheit und Datensicherheit ist der Zustand des MIT, bei welchem das System vor externen Eingriffen und Manipulation geschützt wird. Im Vordergrund liegt dabei die Integrität und Vertraulichkeit von Daten und auch die Verfügbarkeit des Systems.

Netzwerkmonitoring für IEC 80001-1

Selbst einfache Dinge erweisen sich manchmal als komplizierter als sie initial erscheinen. Zumindest mir geht das mal wieder so. Bei meinem IEC 80001-1 Projekt steht derzeit die Dokumentation des Krankenhaus-Netzwerks auf dem Programm. Dank des phantastischen Netzwerkadministrators gab es bereits eine gute Basisdokumentation. Doch wie will man diese auf dem Laufenden halten? Idealerweise automatisiert? Wie findet man heraus, welche Endpunkte es im Netzwerk überhaupt gibt?

Werkzeuge für das Netzwerk Monitoring

Werkzeuge für Netzwerk Monitoring gibt es viele. Dazu zählen sicher die Platzhirrsche wie NMAP und Nagios: NMAP zum Scannen und Nagios zum Überwachen. Gibt es Alternativen?

Die aufmerksamen Leser der iX sind in den letzten beiden Ausgaben möglicherweise auf folgende Open-Source-Tools gestoßen, bei denen es ebenfalls ums Netzwerk Monitoring geht:

• NeDI zum Sacnnen von Netzwerken (ix, 2012, Ausgabe 11, Seiten 127ff)
• Zabbix zum Überwachen von Netzwerken (ix, 2012, Ausgabe 10, Seiten 154ff).

Wir haben uns für NEDI entschieden und damit ein Netzwerk gescannt. Die Übersicht dazu begeistert einerseits, andererseits sind uns auch die Limitierungen klar geworden: Sobald man Switche mit proprietären und/oder eher unüblichen CLIs (Command Line Interfaces, musste ich auch erst lernen) nutzt, kommt die Detektion ins Stocken, und es ist wieder manuelle Arbeit notwendig.

Als ideal erscheint es natürlich, alle Netzwerkkomponenten von einem Hersteller zu beziehen, einem Hersteller der ein verbreitetes CLI fürs Verwalten und Monitoring des Netzwerks anbietet. Sie werden ahnen, wen ich meine und dass das nicht billig ist…

Durch meinen Blogbeitrag zu den Tools im IEC 80001-1-Kontext angeregt, hat mir Wolfgang Thoma folgenden Tipp geschickt:

Ich habe mich vor einiger Zeit mit Spiceworks  (http://www.spiceworks.com/app/) beschäftigt, ein leicht zu installierendes und absolut kostenloses Tool fürs Netzwerk Monitoring, das die üblichen Netzwerkaufgaben (u.a. Inventory, Alarmierung, Monitoring) und zudem noch eine Lizenzverwaltung sowie einen Helpdesk bietet.

Es läuft aus meiner Erfahrung raus recht gut, kommt ohne Agenten aus. Voraussetzung ist eine korrekte SNMP- bzw WMI Konfiguration der Netzwerkkomponenten, die vom Tool dann abgefragt werden können.

Ein Plugin für MS Virtual Server läßt eine Überwachung virtueller Umgebungen zu. Die App frägt auch Software ab und erzeugt Übersichten über Software, Version, Anzahl Installationen etc. Ad hoc sparen wir uns mindestens 3 serverbasierte Überwachungstools.

Die Geschwindigkeitsprobleme der webbasierten Applikation sind anscheinend behoben, das Antwortverhalten ist gut. Ich werde mal versuchen, medizintechnische Geräte einzubinden. Gerade bildgebende Geräte wären prädestiniert für Statusüberwachungen.

Danke für diese Informationen!

Zum Vergrößern klicken