mibe000137 10.3205/mibe000137 urn:nbn:de:0183-mibe0001378 Positionspapier Risk management for medical networks in intensive care and emergency medicine – a joint position paper on IEC 80001-1 Ahlbrandt Ahlbrandt Janko J

Deutsche Interdisziplinäre Vereinigung für Intensiv- und Notfallmedizin (DIVI), Berlin, Deutschland Justus-Liebig-Universität Gießen, Deutschland

author Röhrig Röhrig Rainer R Dr. med.

Deutsche Interdisziplinäre Vereinigung für Intensiv- und Notfallmedizin (DIVI), Berlin, Deutschland Justus-Liebig-Universität Gießen, Deutschland

author Dehm Dehm Johannes J

Verband der Elektrotechnik Elektronik Informationstechnik e.V. (VDE), Initiative MikroMedizin, Frankfurt am Main, Deutschland

author Wrede Wrede Christian C. Priv.-Doz. Dr. med.

Deutsche Interdisziplinäre Vereinigung für Intensiv- und Notfallmedizin (DIVI), Berlin, Deutschland Deutsche Gesellschaft für Biomedizinische Technik im VDE (DGBMT), Frankfurt am Main, Deutschland Helios-Klinikum Berlin-Buch, Berlin, Deutschland

author Imhoff Imhoff Michael M Prof. Dr. med.

Deutsche Gesellschaft für Biomedizinische Technik im VDE (DGBMT), Frankfurt am Main, Deutschland Ruhr Universität Bochum, Deutschland

mike@imhoff.de author Sektion IT & Medizintechnik der Deutschen Interdisziplinären Vereinigung für Intensiv- und Notfallmedizin e.V. Sektion IT & Medizintechnik der Deutschen Interdisziplinären Vereinigung für Intensiv- und Notfallmedizin e.V. author Deutsche Gesellschaft für Biomedizinische Technik (DGBMT) im VDE e.V., Fachausschuss Methodik der Patientenüberwachung Deutsche Gesellschaft für Biomedizinische Technik (DGBMT) im VDE e.V., Fachausschuss Methodik der Patientenüberwachung

c/o Prof. Dr. med. Michael Imhoff, Abteilung für Medizinische Informatik, Biometrie und Epidemiologie, Ruhr-Universität Bochum, Universitätsstraße 150, 44801 Bochum, Deutschland, Tel.: +49 231 9730220

mike@imhoff.de author German Medical Science GMS Publishing House

Düsseldorf

610 patient safety risk management equipment failure organization and administration 20130219 germ 1860-9171 9 3 GMS Medizinische Informatik, Biometrie und Epidemiologie GMS Med Inform Biom Epidemiol 09 Die IEC 80001-1 ist eine Norm, die Empfehlungen für einen Risikomanagementprozess für medizinische IT-Netzwerke (MIT) – also Netzwerke mit angeschlossenen Medizinprodukten – gibt. Das Ziel ist der Aufbau und Betrieb von stabilen und sicheren IT-Netzwerken in Kliniken. Die Empfehlungen richten sich vor allem an die Betreiber von Krankenhäusern, weisen Verantwortlichkeiten innerhalb einer verantwortlichen Organisation (meist einer Klinik) zu und geben deren Interaktion vor. Eine zentrale Rolle ist der MIT Risiko-Manager, der von der Geschäftsführung beauftragt wird und die Anstrengungen in Richtung Risikomanagement koordiniert. Dazu steht er in Kontakt mit Mitarbeitern von klinischen Abteilungen, der Medizintechnik, der IT-Abteilung und auch den Herstellern der beteiligten Medizinprodukte. Auf diese Art wird Wissen, das oft nur an diesen verschiedenen Stellen vorhanden ist, gesammelt und in der Risikomanagement-Akte dokumentiert. Jede gefundene Bedrohungs-Situation wird analysiert und nach ihrer Wahrscheinlichkeit und ihren (geschätzten) Folgen bewertet. Danach wird festgelegt, ob ein bestehendes Restrisiko tragbar ist und wie Gegenmaßnahmen umgesetzt werden. Der Dialog, der während des Informationsaustausches entsteht, nützt allen Parteien und trägt maßgeblich dazu bei, MITs stabiler und sicherer zu machen.Die Umsetzung der Norm erfordert einen Mehraufwand an Personal und Dokumentation. Nach Einschätzung der Autoren lohnt sich diese Investition am Anfang von Projekten, da sich dadurch Probleme im späteren Projektverlauf vermeiden oder zumindest reduzieren lassen. Spätestens bei Anschlussprojekten ist hier mit einer Aufwands- und damit Kostenersparnis zu rechnen. Ein stabiles und sicheres Netzwerk stellt die Basis für reibungslosen Routinebetrieb aber vor allem auch für Innovation im Bereich der vernetzten Medizingeräte dar. Eine sofortige unternehmensweite Einführung der IEC 80001-1 ist ein unrealistischer Ansatz. Vielmehr ist zu empfehlen, sich zunächst auf bestimmte Subnetze zu konzentrieren, die innerhalb eines Projektes oder eines bestimmten Prozesses wichtig sind. In einem solchen kleineren Rahmen bleibt der Aufwand für das Risikomanagement beherrschbar und lässt sich danach auf weitere Bereiche ausdehnen.Die IEC 80001-1 fordert alle Beteiligten zur Kommunikation auf und bietet so die Chance, aus einer Kooperation heraus die besten Entscheidungen im Sinne der verantwortlichen Organisation zu treffen. IEC 80001-1 is an international standard and offers recommendations for a risk management process for medical information technology networks (MITs). MITs are defined as IT networks incorporating at least one medical device. The goal is to build and maintain reliable and secure MITs for hospitals of all kids. To achieve it, the standard suggests applying risk management and defines the roles involved as well as their responsibilities. A central role is the medical IT-network risk manager, assigned by the top management of organizations. He communicates with and mediates between clinical, medical device and IT divisions and compiles risk relevant facts usually distributed among them. All identified risks are analyzed, evaluated and documented in the risk management file along with counter measures and a final assessment of acceptability.We acknowledge that implementing the suggested process will create an overhead cost in documentation and – partly by extension – in personnel. However we believe that the investment at the start of projects is worthwhile, because it helps to prevent or solve problems in later stages. Especially consecutive projects can profit from the investment, reducing required effort and costs. Furthermore, a reliable and secure MIT forms the basis for frictionless routine operations and innovations for connected medical devices. Hence the investment is justified. Applying risk management to the whole cooperation all at once is unrealistic. Focusing on parts of the network, which are crucial to a new project is more recommendable. With a smaller scope, risk management remains feasible and can later be expanded to other parts of the network.IEC 80001-1 demands communication among involved employees from different specialties and divisions. This offers a chance for cooperation to find better decisions and solutions regarding an organization’s medical IT network. 1 VorwortDie Informationstechnologie spielt in der Krankenversorgung und speziell der stationären Versorgung eine große und immer noch wachsende Rolle. Systeme, die benötigt werden, um Daten zu erfassen, zu verwalten und aufzubereiten, werden durch eine systemübergreifende Prozessunterstützung immer komplexer und verlangen zunehmend die Integration von verschiedenen Datenquellen. Diese Integration ist nur über Vernetzung von IT-Systemen und Medizinprodukten (MP) zu erreichen. In der Vernetzung liegen also große Möglichkeiten und Chancen für die Informationsverarbeitung in der Medizin, aber auch damit verbundene Risiken. Ein Ausfall von Informationstechnologie, selbst wenn er auf einen Teilbereich eines Krankenhauses beschränkt bleibt, ist oft gleichbedeutend mit Stillstand des betrieblichen Ablaufs in klinischen Abteilungen. Und auch Zwischenfälle in technischen Systemen, die nicht zum Ausfall führen sind potentiell gefährdend. Aus diesen Gründen braucht es ein klares Regelwerk, das die Vernetzung medizinischer Geräte zu einem sogenannten medizinischen IT-Netzwerk (MIT) für alle Beteiligten transparent macht. Die gegensätzlichen Zielsetzungen zwischen einerseits hohen Anforderungen an Verfügbarkeit und Sicherheit und andererseits dem Bedürfnis nach einem möglichst großen Funktionsumfang müssen bei der Einrichtung und dem Betrieb eines MIT abgewogen werden und bilden den Rahmen dieses Positionspapiers.Am 13. Dezember 2010 fand in Gießen ein Workshop zur IEC 80001-1 („Anwendung des Risikomanagements für IT-Netzwerke mit Medizinprodukten; Teil 1: Aufgaben, Verantwortlichkeiten und Aktivitäten“) statt. Anwesend waren Vertreter des Verbandes der Elektrotechnik Elektronik Informationstechnik e.V. (VDE), der Deutschen Gesellschaft für Biomedizinische Technik im VDE (DGBMT), der Sektion IT und Medizintechnik der Deutschen Interdisziplinären Vereinigung für Intensiv- und Notfallmedizin (DIVI), von Medizin-Technik-Herstellern, Unternehmensberatungen und Kliniken für den Bereich Medizintechnik und Informationstechnologie (IT). Dieses Positionspapier entstand durch Zusammenführen der Ergebnisse des Workshops, weiteren Beiträgen der Teilnehmer und anderer Organisationen, sowie Studien und Forschungsergebnissen zu den diskutierten Themen.Das vorliegende Positionspapier befasst sich mit dem Risikomanagement von vernetzten Medizinprodukten in der Intensiv- und Notfallmedizin. Er ist das Ergebnis einer Expertenrunde aus Sachverständigen des VDE, der DGBMT, der Sektion IT und Medizintechnik der DIVI, des Bundesverbandes Gesundheits-IT (BVITG) und der Deutschen Gesellschaft für Fachkrankenpflege (DGF). Dies geschieht in Bezug auf die 2010 in Kraft getretene Norm IEC 80001-1. 2 Einführung2.1 Entwicklung der IT-Netzwerkinfrastruktur in KrankenhäusernIn den letzten 15 Jahren hat in den deutschen Krankenhäusern eine rasante Entwicklung der IT-Infrastruktur stattgefunden. Dies ist zum einen in den durch die Einführung des fallpauschalen-basierten Entgeltsystems der Diagnosis Related Groups (DRG) zu begründen. Die Erfassung der DRGs erfordert eine detaillierte Dokumentation der Patientenbehandlung. Hinzu kommt der Kostendruck, der eine Prozessoptimierung, z.B. durch klinische Pfade, nach sich zieht. Beides ist ohne Informationstechnik auf den Stationen und am Krankenbett nicht wirtschaftlich durchführbar. Dementsprechend wird der Wertbeitrag der Informationstechnologie in deutschen Krankenhäusern hoch eingeschätzt .Zum anderen hat eine technische Entwicklung stattgefunden: Beispielhaft ist hier die Einführung des digitalen Röntgen anzuführen und der damit verbundenen Implementierung von Picture Archive and Communication Systemen (PACS) zu nennen. Den technischen Möglichkeiten in der Bildverarbeitung steht die Notwendigkeit einer flächendeckenden Installation von Arbeitsplätzen am Behandlungsplatz, also auf Station, im Operationssaal, in der Ambulanz oder am Krankenbett gegenüber.Dies hat zu einem Ausbau der IT-Infrastruktur geführt, der sich in einem sprunghaften Anstieg der Anzahl von PC-Arbeitsplätzen und damit der aktiven Netzwerkknoten im IT-Netzwerk darstellt. Hier ist in den nächsten Jahren, wenn alle Mitarbeiter und alle Patienten(-zimmer) über einen (Tablet-)PC verfügen, mit einer Verlangsamung der Zunahme an notwendigen Netzwerkknoten zu rechnen. In den letzten Jahren hat auch in der Medizintechnik ein Wandel stattgefunden: Während früher Medizingeräte, wie z.B. Spritzenpumpen, (Narkose-) Beatmungsgeräte, Geräte für die Nieren- oder Leberdialyse einzelnstehende Geräte waren, bei denen Daten maximal über eine proprietäre serielle Schnittstelle ausgelesen werden konnten, verfügen sie heute über Schnittstellen in ein IT-Netzwerk. Durch die Nutzung der vorhandenen IT-Netzwerkstruktur können über diese Schnittstellen ortsunabhängig Behandlungsdaten ausgelesen, Software- und Wartungsstände abgefragt und Updates durchgeführt, sowie Gerätestandorte lokalisiert werden. Aufgrund der Vielzahl von Medizingeräten ist davon auszugehen, dass sowohl die absolute Anzahl als auch der relative Anteil von Medizingeräten an den aktiven Netzwerkknoten steigen wird. Nach einer internen Erhebung von Peter Roß (Rhön-Klinikum AG) ist zu erwarten, dass 2015 Medizingeräte 50% der Netzwerkknoten in einem mittelgroßen Krankenhaus ausmachen werden (s. Abbildung 1 ).Im Gegensatz zur Medizintechnik gehört es zu den Grundzügen einer IT Infrastruktur auf technische und organisatorische Veränderungen zu reagieren und immer wieder neue Verfahren aufzunehmen. Deshalb gibt es für die IT Infrastruktur nie ein endgültiges Design aus dem alle Fragen entschieden werden können.2.2 Entstehende Risiken in der Intensiv- und NotfallmedizinAus der Tatsache, dass für den Wertbeitrag der Informationstechnologie und der Medizinprodukte eine funktionierende Netzwerkstruktur essentiell ist, geht deren unternehmenskritische Bedeutung im ökonomischen Sinne hervor. Bei der Vernetzung von Medizinprodukten gilt es jedoch auch, mögliche Folgen für die Gesundheit des Patienten zu beachten.Prinzipiell gibt es für die Anwendung von Medizingeräten am Menschen verschiedene Vorschriften und Normen, die den Schutz der Gesundheit und der Unversehrtheit des Patienten im Fokus haben:EU-Directive: Council Directive 2007/47/EC concerning medical devicesMPG: Gesetz über Medizinprodukte DIN EN 60601-1 (3. Ausgabe): Medizinische elektrische Geräte; Teil 1: Allgemeine Festlegungen für die Sicherheit einschließlich der wesentlichen LeistungsmerkmaleDIN EN 60601-1-6: Medizinische elektrische Geräte – Teil 1-6: Allgemeine Festlegungen für die Sicherheit einschließlich der wesentlichen Leistungsmerkmale – Ergänzungsnorm: Gebrauchstauglichkeit, europäische, harmonisierte Fassung der internationalen Norm IEC 60601-1-6.DIN EN 62304: Medizingeräte-Software – Software-Lebenszyklus-Prozesse, europäische, harmonisierte Fassung der internationalen Norm IEC 62304 DIN EN 62366: Anwendung der Gebrauchstauglichkeit auf Medizinprodukte, europäische, harmonisierte Fassung der internationalen Norm IEC 62366DIN EN 13485: Medizinprodukte – Qualitätsmanagementsysteme – Anforderungen für regulatorische Zwecke, europäische, harmonisierte Fassung der internationalen Norm ISO 13485DIN EN ISO 14971: Anwendung des Risikomanagements auf Medizinprodukte, europäische, harmonisierte Fassung der internationalen Norm ISO 14971In Gesetzen und Verordnungen wird vor allem die Verantwortung der Hersteller für die „Sicherheit und Leistung der Medizinprodukte, sowie die Gesundheit und den erforderlichen Schutz der Patienten, Anwender und Dritter“ geregelt. Voraussetzung für die Verantwortung und damit auch die Haftung des Herstellers ist die ordnungsgemäße Verwendung des Medizinproduktes.Das „Errichten, Betreiben, Anwenden und Instandhalten von Medizinprodukten“ fällt gemäß der Medizinprodukte-Betreiberverordnung (MPBetreibV) in die Verantwortung des Betreibers und damit der Kliniken. Der Betreiber hat sicherzustellen, dass Medizinprodukte nur entsprechend Ihrer Zweckbestimmung eingesetzt werden (§2(1) MPBetreibV)) .Durch die Anbindung eines Medizinproduktes an ein anderes Gerät oder an eine Gruppe unterschiedlicher Produkte über ein IT-Netzwerk übernimmt der Betreiber gewissermaßen wie ein Hersteller Verantwortung für den ordnungsgemäßen Betrieb des Gesamtsystems einschließlich der Medizinprodukte. Schwierigkeiten, die sich aus dieser Vernetzung ergeben können, sollten mit folgenden – real stattgefundenen – Beispielen aufgezeigt werden:Beispiel 1: Ein Beatmungsgerät wurde an ein Intensivinformationsmanagementsystem (IMS) für die Datenübernahme angeschlossen. Nach einer unbestimmten Zeit schaltete sich das Beatmungsgerät ohne Fehlermeldung oder Alarmgebung aus. Ursache war, dass der Gerätetreiber des PDMS regelmäßig seine Datenanfrage wiederholte. Dabei wurde jedes Mal in dem Beatmungsgerät ein neuer Prozess generiert ohne den Speicherbereich des vorherigen freizugeben. Mit der Zeit kam es zu einem Speicherüberlauf und es wurden für den Betrieb des Beatmungsgerätes essentielle Speicherbereiche überschrieben, es kam zum Totalabsturz der Betriebssoftware des Beatmungsgeräts.Beispiel 2: Auf einer Intensivstation wird ein Programm installiert, welches Informationen und Alarmmeldungen von Spritzenpumpen in den Patientenzimmern ortsfern anzeigen kann. Von den Alarmmeldungen gehen mehrere nachweislich verloren. Da sich das Pflegepersonal auf die Meldungen verlässt, kommt es zu verzögerten Reaktionen auf die Alarmmeldungen.Beispiel 3: Eine defekte Netzwerkkomponente (Router) ist in einem IT-Netzwerk und sendet ununterbrochen auf bestimmte Ports und IP-Adressen. Dadurch wird die Funktion von einigen, im IT-Netzwerk eingebundenen Medizinprodukten gestört.Beispiel 4: Die Software auf Medizinprodukten darf vom Anwender nur in den vom Hersteller vorgegebenen Rahmen verändert werden. Dies lässt meist keine Updates des Betriebssystems, einer Firewall oder einer Malware Detection Software (Virenscanner) zu. Dies führt zu Konflikten, wenn z.B. auf einer Intensivstation die Zentrale des Patientenmonitorings mit dem IT-Netzwerk des Klinikums verbunden wird, um auch im Arztzimmer einen Einblick auf die Monitoringdaten zu erhalten. Auf der einen Seite kann die Funktionalität nicht ausreichend geschützt werden, auf der anderen Seite benötigt die Funktionalität die Integration in das IT-Netzwerk der Klinik. So kam es, dass bei einem Schädlingsbefall (Wurm) bei Wartungsarbeiten an einem PACS-System die Zentralen des Patientenmonitorings befallen wurden. In diesem Fall ist kein regelrechter Betrieb mehr zu gewährleisten.Die Fallberichte der Autoren werden durch die Statistik des Bundesinstitut für Arzneimittel und Medizinprodukten (BfArM) gestützt: Im Zeitraum von 2005 bis 2010 wurden von 3.788 Risikomeldungen mit der Fehlerursache „Design-/Konstruktionsfehler“ 813 als Softwarefehler</PlainText></TextGroup> eingestuft (Abbildung 2 <ImgLink imgNo="2" imgType="figure"/>, <TextLink reference="4"></TextLink>), davon jedoch nur 310 als Softwareprobleme eigener Art (falsche Therapievorgaben, falsche Patientenzuordnung, Auswertungs- und Dokumentationsfehler) eingestuft werden <TextLink reference="5"></TextLink>. Auch wenn die Probleme, die aufgrund einer Vernetzung aufgetreten sind, nicht gesondert ausgewiesen werden, so ist doch von einem relevanten Anteil auszugehen. Hinzu kommt, dass Fehler, die durch die Integration eines Medizinproduktes in ein IT-Netzwerk auftreten, wahrscheinlich kaum gemeldet werden und somit eine sehr hohe Dunkelziffer existiert.</Pgraph><Pgraph>Mit dem zunehmenden Ausbau der Netzwerkinfrastruktur, der angeschlossenen Systeme und Medizinprodukte w&#228;chst auch die Komplexit&#228;t des Gesamtsystems und damit die Fehleranf&#228;lligkeit einzelner angeschlossener Komponenten. Um ein solches Netzwerk sicher betreiben zu k&#246;nnen, muss dieses auch einem Risikomanagement unterworfen werden.</Pgraph><Pgraph>Daher wurde nach langj&#228;hriger Abstimmungsarbeit im Oktober 2010 von der International Electrotechnical Commission (IEC) die Norm IEC 80001-1:2010 (Anwendung des Risikomanangements f&#252;r IT-Netzwerke, die Medizinprodukte beinhalten &#8211; Teil 1: Aufgaben, Verantwortlichkeiten und Aktivit&#228;ten) f&#252;r das Risikomanagement in der medizinischen Informationstechnologie ver&#246;ffentlicht. Sie ist Teil einer Normenreihe und enth&#228;lt neben Regelungen zur Zust&#228;ndigkeit auch Handlungsempfehlungen f&#252;r Betreiber von Medizinischen IT-Netzwerken (MITs). Dabei ist ein MIT ein Netzwerk, in dem mindestens ein Medizinprodukt angeschlossen ist. Im November 2011 ist die deutsche Fassung der Norm als DIN EN 80001-1 ver&#246;ffentlicht worden <TextLink reference="6"></TextLink>. Die Normenreihe wurde im September 2012 um die Technical Reports IEC&#47;TR 80001-2-1 bis IEC&#47;TR 80001-2-4 erg&#228;nzt. </Pgraph><Pgraph>Die IEC 80001-1 hat in vielen Kliniken f&#252;r eine Verunsicherung bez&#252;glich Verantwortlichkeiten und Haftungsrisiken gesorgt. Das Ziel des vorliegenden Positionspapiers ist, die IEC 80001-1 zu erl&#228;utern und deren Konsequenzen f&#252;r Betreiber, Anwender und Hersteller darzustellen und Empfehlungen f&#252;r die praktikable Umsetzung der Norm aufzuzeigen.</Pgraph></TextBlock> <TextBlock linked="yes" name="3 Die IEC 80001-1"> <MainHeadline>3 Die IEC 80001-1</MainHeadline><SubHeadline>3.1 Ziele der IEC 80001-1</SubHeadline><Pgraph>Die IEC 80001-1 ist eine Norm zur Anwendung des Risikomanagements bei Planung, Umsetzung und Betrieb eines medizinischen IT-Netzes (MIT). Sie definiert Rollen und Verantwortlichkeiten und legt Aufgaben und Aktivit&#228;ten f&#252;r den Prozess des Risiko-Managements fest. Sie ist kein rechtsverbindliches Dokument, stellt aber eine Empfehlung f&#252;r die Betreiber von MIT dar.</Pgraph><SubHeadline>3.2 Geltungsbereich</SubHeadline><Pgraph>Der Fokus des Geltungsbereiches ist das medizinische IT-Netzwerk (MIT). Dieses ist definiert als ein IT-Netzwerk, das wenigstens ein MP enth&#228;lt. </Pgraph><Pgraph>Nicht unter die Norm fallen</Pgraph><Pgraph><UnorderedList><ListItem level="1">Netzwerke, die ausschlie&#223;lich Medizinprodukte enthalten und von einem Hersteller als Gesamtsystem betreut werden. (Abgeschlossenes Netzwerk Klasse C gem&#228;&#223; Anlage H, DIN EN 60601-1). Hierunter f&#228;llt in der Regel das Patientenmonitoring mit Zentrale auf der Intensivstation.</ListItem><ListItem level="1">Netzwerke, in die keine MP Integriert sind.</ListItem></UnorderedList></Pgraph><SubHeadline>3.3 Definitionen</SubHeadline><Pgraph>In der IEC 80001-1 werden einige Begriffe definiert, die zum Teil aus dem Bereich des klassischen Risikomanagements kommen. In Tabelle 1 <ImgLink imgNo="1" imgType="table"/> finden Sie einige wichtige Definitionen.</Pgraph><SubHeadline>3.4 Organisationsstruktur und Rollen</SubHeadline><Pgraph>In Tabelle 2 <ImgLink imgNo="2" imgType="table"/> sind die in der IEC80001-1 definierten Rollen, in Abbildung 3 <ImgLink imgNo="3" imgType="figure"/> ist die Organisationsstruktur dargestellt. Innerhalb der verantwortlichen Organisation findet das gesamte Risikomanagement statt. Dies umfasst alles von Planung und Design von MITs &#252;ber deren Installation, Wartung und Anschluss von Medizinger&#228;ten bis hin zum Betrieb und der geregelten Au&#223;erbetriebnahme. Das verantwortliche Management gibt f&#252;r die Durchf&#252;hrung des Risikomanagements Richtlinien vor, unter anderem f&#252;r eine Bestimmung eines akzeptablen Restrisikos. <TextGroup><PlainText>Au&#223;e</PlainText></TextGroup>rd<TextGroup><PlainText>em</PlainText></TextGroup> muss es sicherstellen, dass die ben&#246;tigten Ressourcen und qualifiziertes Personal aus verschiedenen Fachabteilungen vorhanden sind (Abbildung 4 <ImgLink imgNo="4" imgType="figure"/>).</Pgraph><Pgraph>Als Beauftragter der Obersten Leitung nimmt der MIT-Risiko-Manager dabei eine zentrale Rolle ein. Seine Aufgabe ist, nach Vorgaben der verantwortlichen Organisation die verschiedenen Perspektiven von Anwendern, Medizintechnik, IT-Abteilung und Herstellern zusammenzuf&#252;hren und zu koordinieren (Abbildung 5 <ImgLink imgNo="5" imgType="figure"/>). Er kooperiert dabei mit Mitarbeitern aus verschiedenen Fachabteilungen, die Experten f&#252;r den Risikomanagement-Prozess entsenden. Au&#223;erdem steht er in Kontakt mit den Herstellern der beteiligten Medizinprodukte, die die Verantwortung haben, wichtige technische Informationen zu ihren Produkten zu liefern, die f&#252;r eine Vernetzung der Ger&#228;te n&#246;tig sind. Ihm obliegt die Entscheidung, ob die Vernetzung eines Medizinger&#228;tes durchgef&#252;hrt werden kann und unter welchen Bedingungen dies passiert.</Pgraph><Pgraph>Weiterhin sollte der MIT-Manager die Kommunikation mit dem von der verantwortlichen Organisation benannten Datenschutzbeauftragten suchen. Dieser ist zwar in der Norm nicht erw&#228;hnt und damit nicht direkt in den Risikomanagement-Prozess eingebunden, ist aber f&#252;r das Schutzziel der Vertraulichkeit von Patientendaten im Unternehmen zust&#228;ndig.</Pgraph><Pgraph>Sowohl die Vorgaben der Obersten Leitung als auch die Ergebnisse des Risikomanagements werden dokumentiert und in der Risikomanagement-Akte zusammengef&#252;hrt. Der gesamte Vorgang wird ebenfalls vom Risiko-Manager &#252;berwacht, der der Obersten Leitung dar&#252;ber Bericht erstattet.</Pgraph><SubHeadline>3.5 Risikomanagementprozess</SubHeadline><Pgraph>Der Risikomanagementprozess beginnt in der Gesch&#228;ftsf&#252;hrung einer verantwortlichen Organisation. Ihr kommt die Aufgabe zu, Richtlinien f&#252;r den Risikomanagement-Prozess, die Vertretbarkeit von Risiken und die Vereinbarkeit mit den Gesch&#228;ftszielen des Unternehmens zu erarbeiten (Abbildung 4 <ImgLink imgNo="4" imgType="figure"/>). Diese dienen dem MIT Risiko-Manager als Grundlage f&#252;r die Entscheidungen im Detail. <TextGroup><PlainText>Au&#223;e</PlainText></TextGroup>rd<TextGroup><PlainText>em</PlainText></TextGroup> vermittelt er, wie in Abbildung 5 <ImgLink imgNo="5" imgType="figure"/> dargestellt, zwischen den beteiligten Interessensvertretern und koordiniert den Prozess des Risikomanagements. &#220;ber den Fortschritt, die Einhaltung der Richtlinien und grundlegenden Anforderungen berichtet er kontinuierlich der Gesch&#228;ftsf&#252;hrung.</Pgraph><Pgraph>Am Anfang eines neuen Projekts, dass nach den Vorgaben der IEC 80001-1 durchgef&#252;hrt werden soll, wird in einer Projektbeschreibung festgehalten, wie die zu unterst&#252;tzenden Prozesse aussehen, warum eine Vernetzung angestrebt wird und in welcher Form diese realisiert werden soll (siehe Abbildung 6 <ImgLink imgNo="6" imgType="figure"/>). </Pgraph><Pgraph>Mit den beteiligten Fachleuten wird f&#252;r einen definierten Prozess (eine Ma&#223;nahme, ein Eingriff, etc.) analysiert, welche Gefahrenpotenziale bestehen und f&#252;r diese eine Risiko-Analyse durchgef&#252;hrt. Dabei wird f&#252;r jede Gef&#228;hrdung festgelegt, wie wahrscheinlich ihr Eintreten und wie schwerwiegend der resultierende Schaden ist. Hierzu sind Herstellerangaben erforderlich, die die relevanten Eigenschaften und Mechanismen des Medizinproduktes beschreiben.</Pgraph><Pgraph>Nachdem diese Einsch&#228;tzungen dokumentiert sind, werden Ma&#223;nahmen definiert, die das Risiko auf ein akzeptables Ma&#223; reduzieren oder ganz eliminieren. Sie k&#246;nnen entweder pr&#228;ventiv durchzuf&#252;hren sein oder beim Eintreten des Fehlerfalls im Sinne einer Fallback-Strategie. Der resultierende Katalog an Risiken mit Risiko-Kontroll-Ma&#223;nahmen wird in einer Risiko-Management-Akte (wie in 3.6 beschrieben) dokumentiert. </Pgraph><Pgraph>In der Risikomanagement-Akte wird dokumentiert, welche Gefahr identifiziert wurde und in welcher Situation diese auftreten kann. Dazu werden die Ma&#223;nahmen definiert, die geeignet sind, das Risiko zu senken oder zu eliminieren. Sie k&#246;nnen entweder pr&#228;ventiv durchzuf&#252;hren sein oder beim Eintreten des Fehlerfalls im Sinne einer Fallback-Strategie. Zuletzt muss entschieden werden, ob das nach den implementierten (Gegen-)Ma&#223;nahmen verbleibende Risiko akzeptabel ist. Diese Entscheidung ist nach den Richtlinien und dem Grad der Gef&#228;hrdung f&#252;r Mitarbeiter und Patienten bzw. der Wichtigkeit f&#252;r das Gesch&#228;ft des Betreibers zu f&#228;llen.</Pgraph><Pgraph>Der Prozess des Risikomanagements ist keine einmalige Sache, er muss mehrfach und vor allem bei Ver&#228;nder<TextGroup><PlainText>ungen</PlainText></TextGroup> der Umgebung durchgef&#252;hrt werden, wie in Abbildung 6 <ImgLink imgNo="6" imgType="figure"/> schematisch dargestellt. Au&#223;erdem muss &#252;berwacht werden, ob die definierten Ma&#223;nahmen wirklich geeignet sind, Schaden abzuwenden oder zu begrenzen, und gegebenenfalls angepasst werden.</Pgraph><SubHeadline>3.6 Risikomanagementakte</SubHeadline><Pgraph>Die Risikomanagement-Akte ist der zentrale Ort der Dokumentation beim Risikomanagement. Hier werden die identifizierten Bedrohungen aufgef&#252;hrt, ihre H&#228;ufigkeit und damit ihre Wahrscheinlichkeit abgesch&#228;tzt und ihre Folge bewertet. Dabei muss ber&#252;cksichtigt werden, dass es Folgen sowohl f&#252;r Patienten und Personal als auch f&#252;r die Organisation als Ganzes, wie beispielsweise finanzielle Einbu&#223;en, geben kann. Diese beiden Schutzziele widersprechen sich mitunter und m&#252;ssen gegeneinander abgewogen werden.</Pgraph><Pgraph>Im n&#228;chsten Abschnitt geht es darum, wie man Risiken reduzieren oder Gefahren abwenden kann. F&#252;r die meisten Bedrohungen gibt es offensichtliche Gegenma&#223;nahmen bzw. Sicherheitsvorkehrungen. Hier gibt es zum Beispiel Netzwerk-Adapter f&#252;r die galvanische also elektrische Entkoppelung, die gegen einen &#220;bertritt einer Spannung auf den Patienten absichern. Bei anderen Bedrohungen, wie Software-Fehlern in Ger&#228;ten, ist es schwieriger, wirksame Gegenma&#223;nahmen zu finden. Das Ziel ist es, f&#252;r jede Bedrohung einen Katalog an Ma&#223;nahmen definiert zu haben, die geeignet sind, Schaden zu verhindern bzw. abzuwenden, oder das Schadensausma&#223; zu minimieren. Zuletzt muss zu jeder Bedrohung dokumentiert werden, ob das verbleibende (Rest-)Risiko &#8211; unter den gegebenen Umst&#228;nden und nach Anwendung der Gegenma&#223;nahmen &#8211; vertretbar ist.</Pgraph><Pgraph>Anhand der gef&#252;hrten Risikomanagement-Akte kann &#252;berpr&#252;ft (und auch zertifiziert) werden, ob sich eine Organisation nach den Vorgaben der IEC 80001-1 richtet. </Pgraph><SubHeadline>3.7 Verantwortlichkeitsvereinbarung</SubHeadline><Pgraph>Um festzulegen, wer welche Verantwortung in einem Projekt &#252;bernimmt, kann eine verantwortliche Organisation mit externen Partnern, wie Herstellern und Dienstleitern, Vereinbarungen treffen. Diese k&#246;nnen als Vertr&#228;ge ausformuliert und geschlossen werden und beziehen alle Beteiligten mit ein. Es wird dabei eine Person benannt, die f&#252;r das Risiko-Management zust&#228;ndig ist, der Rahmen des Projekts skizziert und die beteiligten Medizinger&#228;te aufgef&#252;hrt. Zus&#228;tzlich wird eine Liste (vor allem technischer) Dokumente erstellt, die der Hersteller der Ger&#228;te bereitstellen muss. F&#252;r den Fall von Zwischenf&#228;llen wird geregelt, wer diese zu bearbeiten hat. </Pgraph><Pgraph>Die vereinbarte Zusammenarbeit wird detailliert beschrieben, wozu vor allem auch geh&#246;rt, wer diese initiiert, wer die Ansprechpartner sind und nach welchen Kriterien gepr&#252;ft werden kann, ob die Partner ihrer Verantwortung nachgekommen sind. </Pgraph><Pgraph>Die Zuordnung der Mitarbeiter der verantwortlichen Organisation zu den hier besprochenen Rollen und Aufgaben, muss nicht zwingend aus deren genereller Rolle im Unternehmen abzuleiten sein. So kann es beispielsweise sinnvoll sein, Aufgaben an Mitarbeiter zu delegieren, die nicht st&#228;ndig im Alltagsbetrieb eingebunden sind.</Pgraph></TextBlock> <TextBlock linked="yes" name="4 Stellungnahme der Experten zur IEC 80001-1"> <MainHeadline>4 Stellungnahme der Experten zur IEC 80001-1</MainHeadline><SubHeadline>4.1 Ziele der IEC 80001-1</SubHeadline><Pgraph>MITs sind eine zwingende Voraussetzung f&#252;r eine effiziente Patientenversorgung. Die Zielsetzung der <TextGroup><PlainText>IEC 80001-1</PlainText></TextGroup> ist die Anwendung des Risikomanagements f&#252;r folgende Schutzziele: </Pgraph><Pgraph><UnorderedList><ListItem level="1">die Sicherheit von Patienten, Anwendern und Dritten</ListItem><ListItem level="1">die Sicherstellung der Wirksamkeit der Vernetzung von Medizinprodukten</ListItem><ListItem level="1">die System- und Datensicherheit.</ListItem></UnorderedList></Pgraph><Pgraph>Das hat zur Folge, dass bei der Anwendung der Norm auch 3 Risikoanalysen erforderlich sind, weil die Gef&#228;hrdungen pro Schutzziel unterschiedliche &#8222;G&#252;ter&#8220; sch&#252;tzen (Menschen, Prozesse einer Klinik, Daten). Die Akzeptanzkriterien sind f&#252;r jedes Schutzziel eigenst&#228;ndig festzulegen.</Pgraph><Pgraph>Das Ziel der Anwendung der Norm ist die Schaffung von Transparenz bei Errichtung und Betrieb eines MIT und die Herstellung eines robusten MIT, dass sich durch die folgenden drei Eigenschaften auszeichnet (Abbildung 7 <ImgLink imgNo="7" imgType="figure"/>):</Pgraph><Pgraph><Mark1>R&#252;ckwirkungsfreiheit:</Mark1> Beim Betreiben eines MIT ist darauf zu achten, dass St&#246;rungen im IT-Netzwerk keine Fehlfunktion von angeschlossenen Medizinprodukten ausl&#246;sen. Dabei ist sowohl auf die elektrische, wie auch auf die logische R&#252;ckwirkungsfreiheit zu achten. W&#228;hrend f&#252;r die elektrische R&#252;ckwirkungsfreiheit entsprechende Normen (z.B. DIN EN 60601-1) zur Verf&#252;gung stehen und in den meisten F&#228;llen durch Standardprodukte abgedeckt wird, stellt die logische R&#252;ckwirkungsfreiheit, z.B. durch ein Dauersenden einer defekten Komponente auf ein Medizinprodukt oder dem Einbringen einer Schadsoftware (Viren, Trojaner, etc.), eine neue Herausforderung dar. Da bei aktiven Komponenten alle Zust&#228;nde und deren Kombinationen zu betrachten sind entsteht schnell eine nicht oder kaum beherrschbare Komplexit&#228;t, f&#252;r die es in Zukunft L&#246;sungen zu finden gilt.</Pgraph><Pgraph><Mark1>Korrekte &#220;bertragung:</Mark1> Es gilt der Merksatz, dass die richtigen Daten die richtige Netzwerkkomponente (Empf&#228;nger) zur richtigen Zeit erreichen m&#252;ssen. Es muss also sichergestellt sein, dass die Daten unver&#228;ndert den Empf&#228;nger erreichen. Das bedeutet auch, dass in einem gerouteten Netzwerk sichergestellt sein muss, dass die einzelnen Datenpakete bei der &#220;bertragung in der richtigen Reihenfolge am Empf&#228;nger ankommen m&#252;ssen, bzw. der Empf&#228;nger diese wiederherstellen k&#246;nnen muss. </Pgraph><Pgraph>Es muss weiter sichergestellt werden, dass der richtige Empf&#228;nger erreicht wird. Dies setzt u.a. eine saubere Administration der Netzwerkadressen der Medizinprodukte und IT-Systeme voraus.</Pgraph><Pgraph>Die gr&#246;&#223;te Herausforderung stellt die zeitliche Komponente dar: Je komplexer ein Netzwerk wird und je mehr aktive Komponenten zwischen Sender und Empf&#228;nger geschaltet werden (Router, Firewall, etc.) desto l&#228;nger werden die Antwortzeiten. Zum anderen findet in Ethernet-Netzwerken keine Priorisierung von Nachrichten statt. Bei einer hohen Netzwerkauslastung kann es durch eine Verringerung der zur Verf&#252;gung stehenden Bandbreite nicht nur zu einer zeitlichen Verz&#246;gerung, sondern auch zu einem Abbruch der Daten&#252;bertragung durch Timeouts kommen. Hier gilt es z.B. zu betrachten, wie Systeme auf Verz&#246;gerungen oder Netzwerkabbr&#252;che reagieren.</Pgraph><Pgraph><Mark1>Interpretation: </Mark1>Es ist wichtig, dass die &#252;bertragenen Daten richtig interpretiert werden. Dies setzt eine syntaktische Korrektheit der Nachricht, sowie eine einheitliche Semantik zwischen Sendern und Empf&#228;ngern voraus. Hierzu stehen verschiedene Standards zur Verf&#252;gung, wie z.B. die IEEE 11073 f&#252;r die Datenkommunikation oder die Standards von HL7 (<Hyperlink href="http:&#47;&#47;www.hl7.de&#47;">http:&#47;&#47;www.hl7.de&#47;</Hyperlink>). Die gr&#246;&#223;te Herausforderung liegt in der semantisch eindeutigen Kodierung. Hier sind neben den Klassifikationen, wie die ICD oder der OPS, Terminologien wie LOINC oder SNOMED CT zu nennen <TextLink reference="7"></TextLink>. LOINC ist eine frei zur Verf&#252;gung stehende Terminologie, die jedoch nur die Bezeichnung (quantitativer) Parameter abbildet. F&#252;r die weiterf&#252;hrende Terminologie und Ontologie SNOMED CT, die aktuell die Basis nahezu aller internationalen Standards im Bereich der Interoperabilit&#228;t bildet, steht in Deutschland keine nationale Lizenz zur Verf&#252;gung. Aus diesem Grund arbeiten die meisten Medizinprodukte und IT-Systeme mit propriet&#228;ren Katalogen, die h&#228;ufig durch die Betreiber gepflegt und an den Schnittstellen angeglichen werden m&#252;ssen.</Pgraph><SubHeadline2>Fazit</SubHeadline2><Pgraph>Aus den Ausf&#252;hrungen geht hervor, dass ein Netzwerk respektive ein MIT nicht 100&#37; sicher zu gestalten ist. Dar&#252;ber hinaus k&#246;nnen MIT nicht wie einzelne MP einfach ausgeschaltet oder ausgetauscht werden. </Pgraph><Pgraph>Daraus lassen sich zwei wesentliche Konsequenzen f&#252;r die Erstellung eines robusten MITs ableiten:</Pgraph><Pgraph><UnorderedList><ListItem level="1">Ein MIT muss einem Management und damit auch einem Risikomanagement unterzogen werden</ListItem><ListItem level="1">Neben dem MIT m&#252;ssen auch die MP f&#252;r die Integration in ein MIT entsprechend robust gestaltet werden. Die von den Herstellern bei der Konzeption von Medizinprodukten getroffenen Ma&#223;nahmen stellen einen wesentlichen Baustein in der Risikobewertung eines MIT dar und sind im Risikomanagement eines MIT zwingend zu ber&#252;cksichtigen.</ListItem></UnorderedList></Pgraph><SubHeadline>4.2 Geltungsbereich</SubHeadline><Pgraph>Laut Definition ist ein MIT ein IT-Netzwerk, an dem mindestens ein Medizinprodukt angeschlossen ist. Reine IT-Netzwerke oder Netzwerke ausschlie&#223;lich mit Medizinprodukten eines daf&#252;r verantwortlichen Herstellers fallen nicht unter diese Definition (s. Abbildung 8 <ImgLink imgNo="8" imgType="figure"/>). </Pgraph><Pgraph>Mit der zunehmenden klinik&#252;bergreifenden Verbindung von IT-Netzwerken, sowie dem Anschluss von Klinik-IT-Netzwerken an das Internet ist eine Abgrenzung eines MIT entsprechend der Definition kaum m&#246;glich. Auch die Trennung von reinen MP-Netzwerken, wie die eigentlich abgeschlossenen Netzwerke f&#252;r das Patientenmonitoring auf der Intensivstation wird durch Verbindungen &#252;ber einen dezidierten Gatewayrechner an das Klinik-IT-Netz aufgeweicht.</Pgraph><Pgraph>Die Anwendung der IEC 80001-1 auf das gesamte Netzwerk einer Klinik ist wenig realistisch, wenn nicht g&#228;nzlich unm&#246;glich. Deshalb ist es am Betreiber eines gro&#223;en Netzwerkes, es in Subnetze zu unterteilen und Verantwortlichkeiten (und damit verantwortliche Personen) f&#252;r physikalische, logische oder gesch&#228;ftliche Bereiche zu bestimmen. Innerhalb dieser Teile sollte dann eine Bestandsaufnahme erfolgen und abgewogen werden, welche Teilbereiche sich f&#252;r ein Risikomanagement eignen bzw. f&#252;r welche es sinnvoll oder n&#246;tig erscheint. Hierbei ist abzuw&#228;gen, von welchen Teilen eine Gef&#228;hrdung der Patienten- oder Anwendersicherheit ausgeht, und welche Teile missionskritisch oder unternehmenskritisch sind. Als missionskritisch wird ein Ausfall der Anwendung verstanden (z.B. ist keine Untersuchung bei Ausfall der Verbindung zwischen Steuerungs-PC und Computertomograph m&#246;glich), als unternehmenskritisch ein gesch&#228;ftlicher Vorgang, ohne den eine Klinik nicht existieren kann (z.B. &#220;bermittlung der f&#252;r eine Abrechnung erforderlichen Daten).</Pgraph><Pgraph>Ein Netzwerk mit Medizinprodukten, wenn es als Ganzes wiederum ein Medizinprodukt ist, kann nicht als MIT gesehen werden. Als Beispiel kann hier ein Patientenmonitoring-System dienen, das als abgeschlossenes System Alarme am Patienten generiert und sie &#252;ber ein Netzwerk an zentrale &#220;berwachungsstationen &#252;bertr&#228;gt. Das Gesamtsystem f&#228;llt nicht zuletzt wegen der Alarmierungszeiten und -garantien unter das Medizinprodukte-Gesetz <TextLink reference="2"></TextLink> und die Medizinprodukte Betreiberverordnung <TextLink reference="3"></TextLink>. Ein solches Netzwerk ist nicht Gegenstand der IEC 80001-1, die Anwendung ihrer Prinzipien ist aber m&#246;glich und empfehlenswert. Verbindet man dieses Netz allerdings &#252;ber ein Gateway mit einem anderen Netzwerk, muss wieder nach IEC 80001-1 eine Risikoabsch&#228;tzung und<TextGroup><PlainText> -bewertung</PlainText></TextGroup> stattfinden.</Pgraph><Pgraph>Ein solches MP-Netzwerk sollte ausschlie&#223;lich mit Komponenten betrieben werden, die den Vorgaben des Herstellers entsprechen und von ihm abgenommen sind. In diesem Fall liegen die Verantwortung und das Haftungsrisiko beim Hersteller. Wird z.B. ein Netzwerk von bettseitigen Patientenmonitoren und einer Zentrale auf einer Intensivstation mit eigenen, nicht herstellerkonformen Netzwerkkomponenten und&#47;oder W-LAN eingerichtet, so ist dies kein abgeschlossenes Netzwerk Klasse C gem&#228;&#223; Anlage H der DIN EN 60601-1. Dieser Fall geh&#246;rt nicht in den Geltungsbereich der IEC 80001-1, jedoch kann deren Anwendung bei dem erforderlichen Risikomanagement weiterhelfen.</Pgraph><Pgraph>In solchen, wie auch mit der IEC 80001-1 zu behandelnden F&#228;llen ist es wichtig, dass die IT-Netze die herstellerseitigen Risiko-Strategien nicht unterlaufen. Das bedeutet, dass Hersteller ihre Risikoeinsch&#228;tzung bez&#252;glich Risiken, die sie nicht allein beherrschen k&#246;nnen oder die vermutlich bei einer Vernetzung auftreten k&#246;nnen, den Betreibern der Produkte mitteilen m&#252;ssen, damit die identifizierten Risiken mit in das Risikomanagement einflie&#223;en k&#246;nnen <TextLink reference="8"></TextLink>. </Pgraph><Pgraph>In der Definition des Geltungsbereiches ist die Definition des Medizinproduktes enthalten. Ein Medizinprodukt wird in der 4. Novelle des MPG in &#167;3 (1) wie folgt definiert:</Pgraph><Pgraph><Indentation>&#8222;<Mark2>Medizinprodukte sind alle einzeln oder miteinander verbunden verwendeten Instrumente, Apparate, Vorrichtungen, Software, Stoffe und Zubereitungen aus Stoffen oder andere Gegenst&#228;nde einschlie&#223;lich der vom Hersteller speziell zur Anwendung f&#252;r diagnostische oder therapeutische Zwecke bestimmten und f&#252;r ein einwandfreies Funktionieren des Medizinproduktes eingesetzten Software, die vom Hersteller zur Anwendung f&#252;r Menschen mittels ihrer Funktionen zum Zwecke </Mark2><LineBreak></LineBreak><Mark2>a) der Erkennung, Verh&#252;tung, &#220;berwachung, Behandlung oder Linderung von Krankheiten, </Mark2><LineBreak></LineBreak><Mark2>b) der Erkennung, &#220;berwachung, Behandlung, Linderung oder Kompensierung von Verletzungen oder Behinderungen, </Mark2><LineBreak></LineBreak><Mark2>c) der Untersuchung, der Ersetzung oder der Ver&#228;nderung des anatomischen Aufbaus oder eines physiologischen Vorgangs &#91;&#8230;&#93; </Mark2><LineBreak></LineBreak><Mark2>zu dienen bestimmt sind und deren bestimmungsgem&#228;&#223;e Hauptwirkung im oder am menschlichen K&#246;rper weder durch pharmakologisch oder immunologisch wirkende Mittel noch durch Metabolismus erreicht wird, deren Wirkungsweise aber durch solche Mittel unterst&#252;tzt werden kann.</Mark2>&#8220;</Indentation></Pgraph><Pgraph>Ein Produkt wird durch den Hersteller &#252;ber die subjektive medizinische Zweckbestimmung und der vorgesehenen medizinischen Verwendung zum Medizinprodukt. Eine zweckfremde Verwendung eines Nichtmedizinprodukts allein macht dies noch nicht zu einem Medizinprodukt. Ver&#228;ndert eine Person oder stellt etwas Neues her, um es in der Medizin zu verwenden, f&#228;llt dies in den Bereich der Eigenherstellung und das Resultat wird zum Medizinprodukt. Ein wesentliches Problem stellen zunehmend Produkte dar, deren Funktionsumfang oder Produkteigenschaft weit &#252;ber die beschriebene Zweckbestimmung hinausgeht. Dies betrifft meist Ger&#228;te, die auf &#8222;normalen&#8220; PCs basieren und die &#252;ber offene Schnittstellen verf&#252;gen.</Pgraph><Pgraph>Die teilweise kontrovers gef&#252;hrte Diskussion, in wie weit Software, wie Krankenhausinformationssysteme (KIS) oder Intensivinformationsmanagementsysteme (IMS), ein Medizinprodukt ist <TextLink reference="9"></TextLink>, <TextLink reference="10"></TextLink>, <TextLink reference="11"></TextLink>, wurde nun durch die Europ&#228;ische Kommission mit einer Guidance zur &#8222;Qualifikation und Klassifikation von Standalone-Software&#8220; (MEDDEV 2.1&#47;6 Jan 2012) weitestgehend gekl&#228;rt. KIS und IMS&#47;PDMS sind per se nicht als Medizinprodukt einzustufen (Module, die zus&#228;tzliche Information zur Diagnostik, Therapie oder Fortschreibungen&#47;Nachfolgeuntersuchungen anbieten, sind als Medizinprodukt einzustufen.) <TextLink reference="12"></TextLink>.</Pgraph><Pgraph>IMS fallen unabh&#228;ngig von der Einstufung als MP in den Geltungsbereich der IEC 80001-1, da IMS mit MP wie Patientenmonitoren, Beatmungsger&#228;ten oder Blutgasanalyseger&#228;ten verbunden sind. </Pgraph><Pgraph>Reine IT-Netzwerke fallen nicht unter die Bestimmung der IEC 80001-1. Die Erfahrungen und Prinzipien der Norm k&#246;nnen jedoch auch auf unternehmenskritische IT-Netzwerke angewendet und so Schaden von den Betreiberorganisationen abgewendet werden.</Pgraph><Pgraph>Bei Projekten empfiehlt es sich, gezielt nach dem vorgesehenen klinischen Prozess mit den dazu geh&#246;renden Anwendungsf&#228;llen zu schauen, und die dabei auftretenden Risiken zu betrachten. Dieser Ansatz verspricht eine begrenzte Zahl an Szenarien, f&#252;r die Risiken abgesch&#228;tzt werden m&#252;ssen, w&#228;hrend bei einer generellen Betrachtung praktisch kaum ein Ende absehbar ist. Hierbei gilt es zu beachten, dass gerade teure und komplexe Ger&#228;te oder -kombinationen in verschiedenen Prozessen genutzt werden oder die Form der Nutzung kontinuierlich erweitert wird. Reduziert man die Anwendungsf&#228;lle auf die im Prozess wichtigen Anwendungsf&#228;lle, kann man die Risiken eventuell viel niedriger ansehen, als sie wirklich sind. Mit steigender Anzahl an Projekten mit Risikomanagement, werden auch mehr Anwendungsf&#228;lle betrachtet und die Einsch&#228;tzung des Risikos wird realistischer.</Pgraph><SubHeadline2>Fazit</SubHeadline2><Pgraph><UnorderedList><ListItem level="1">In einer Klinik (Betreiberorganisation) sollte das IT-Netzwerk in die Subnetze anhand von logischen, organisatorischen und gesch&#228;ftlichen Bereichen getrennt werden.</ListItem><ListItem level="1">Es sollten f&#252;r die Subnetzbereiche verantwortliche Personen benannt werden.</ListItem><ListItem level="1">Durch die Verantwortlichen ist eine Pr&#252;fung durchzuf&#252;hren, ob die IEC 80001-1 auf das Subnetz anzuwenden ist.</ListItem></UnorderedList></Pgraph><Pgraph> </Pgraph><SubHeadline>4.3 Durchf&#252;hrung von Risikoidentifikation, Risikobewertung, Risikomanagement</SubHeadline><Pgraph><Indentation>&#8222;<Mark2>Entscheidend f&#252;r die Sicherheit ist nicht allein die Funktionalit&#228;t im Regelfall, sondern auch die R&#252;ckwirkung im St&#246;rfall auf das Medizinprodukt und die resultierenden Risiken f&#252;r Patient, Anwender und Betreiber&#33;</Mark2>&#8220; (Peter Ro&#223;)</Indentation></Pgraph><Pgraph><LineBreak></LineBreak><LineBreak></LineBreak>Das Ziel der Risikoidentifikation ist, m&#246;gliche St&#246;rf&#228;lle und Sch&#228;den zu identifizieren. Das Ziel der Risikobewertung ist, die Schadensh&#228;ufigkeit und das Schadensausma&#223; abzusch&#228;tzen, um im Risikomanagement die Ursachen identifizieren und geeignete Gegenma&#223;nahmen ergreifen zu k&#246;nnen. </Pgraph><Pgraph>Die Risikoidentifikation und -bewertung erfolgt in Verantwortung des MIT-Risiko-Managers. Dieser sollte eine Arbeitsgruppe aus Anwendern, Medizintechnik, Medizininformatik (Applikationen), IT-Netzwerkadministration als betroffene Beteiligte zusammenstellen und, wo notwendig, auch die Hersteller einbeziehen.</Pgraph><Pgraph>Die Anwender nehmen bei der Risikoidentifikation und <TextGroup><PlainText>-bewertung</PlainText></TextGroup> eine zentrale Stellung ein. Sie beschreiben die klinischen Prozesse und damit die Verwendung der eingesetzten MP und IT-Systeme des MIT. Danach gilt es systematisch f&#252;r alle Funktionalit&#228;ten und Kommunikationsszenarien St&#246;rf&#228;lle anzunehmen und deren hypothetische Auswirkungen durchzugehen. </Pgraph><Pgraph>Dazu sind detaillierte Kenntnisse &#252;ber die Funktionsweise und Implementierung der MP und IT-Systeme erforderlich, die nur der Hersteller besitzt. Daher sind die Hersteller von MP verpflichtetet, die folgenden Informationen an die Betreiber herauszugeben: </Pgraph><Pgraph><UnorderedList><ListItem level="1">Zweckbestimmung, Leistungsmerkmale des MP</ListItem><ListItem level="1">Anforderungen an das MIT</ListItem><ListItem level="1">Technische (elektrische und logische) Spezifikation der Netzwerk-Schnittstellen</ListItem><ListItem level="1">Funktionsweise der Kommunikation mit anderen MP, MIT und IT-Systemen</ListItem><ListItem level="1">Informationen &#252;ber die Bewertung von Restrisiken (Risikoanalyse des Herstellers)</ListItem><ListItem level="1">Liste der Gef&#228;hrdungssituationen, wenn das MIT die Anforderungen nicht erf&#252;llt.</ListItem></UnorderedList></Pgraph><Pgraph>Die Herausgabe dieser Informationen ist durch die IEC 60601-1:2005 geregelt und auch in der IEC 80001-1 Kapitel 3.5 beschrieben. Sollten f&#252;r die Risikobewertung der Betreiberorganisation Informationen erforderlich sein, die der Hersteller als Firmengeheimnis einstuft, so k&#246;nnen diese vertraulichen Informationen durch eine Vertraulichkeitsvereinbarung zwischen Betreiberorganisation und Hersteller gesch&#252;tzt werden.</Pgraph><Pgraph>Schwieriger stellt sich die Situation bei den Informationen &#252;ber die in das MIT integrierten IT-Systeme dar. Zum einen fehlt hier eine Verpflichtung f&#252;r die Hersteller zur Offenlegung der Risikoanalyse, zum anderen werden Restrisiken h&#228;ufig von den Herstellern nicht regelhaft identifiziert, bewertet und dokumentiert. Aufgrund deutlich k&#252;rzerer Releasezyklen und einer Vielzahl von Abh&#228;ngigkeiten (Betriebssystem, Virenscanner, Schnittstellen zu Subsystemen) und Freiheitsgraden (Parametrierungen des Betreibers bis zur Programmierung) stellt sich hier f&#252;r die Hersteller auch die Frage der Machbarkeit. Hersteller von IT-Systemen sollten aber folgende Informationen zur Verf&#252;gung stellen:</Pgraph><Pgraph><UnorderedList><ListItem level="1">Technische Beschreibungen und technische Handb&#252;cher&#47;Betriebsanleitungen</ListItem><ListItem level="1">Beschreibung der Parametrierungsoptionen und deren Auswirkungen</ListItem><ListItem level="1">System- und Betriebsanforderungen, inkl. Anforderungen an das IT-Netzwerk&#47;MIT</ListItem><ListItem level="1">bekannte Inkompatibilit&#228;ten mit anderen Produkten </ListItem><ListItem level="1">Informationen &#252;ber erforderliche Updates und Patches</ListItem><ListItem level="1">Sicherheitshinweise</ListItem></UnorderedList></Pgraph><Pgraph>Insbesondere die Auflistung der Kompatibilit&#228;ten&#47;Inkompatibilit&#228;ten stellt eine Schwierigkeit dar, da diese f&#252;r jeden Firmware Version und jeden Patch von jedem Ger&#228;t in unterschiedlichen Kombinationen getestet und ver&#246;ffentlicht werden m&#252;sste.</Pgraph><Pgraph>Die Herausforderung f&#252;r Betreiber besteht vor allem darin, mit mehreren Herstellern oder Lieferanten mit unterschiedlicher Risikomanagementkultur zu sprechen und die gesammelten Informationen abzugleichen. Dies kann nur durch einen kooperativen Dialog zwischen allen Beteiligten geschehen. </Pgraph><Pgraph>Der Austausch der Informationen sollte nach Meinung der Workshopteilnehmer eher eine kontinuierliche Kommunikation darstellen als eine einmalige &#220;bermittlung. Sowohl der Hersteller sollte bei &#196;nderungen den Kontakt zu den Betreibern suchen, als auch umgekehrt der Betreiber bei kritischen Situationen, die Produkte des Herstellers betreffen. Die Festlegung eines definierten Formats f&#252;r den Datenaustausch (beispielsweise XML-Dateien nach einem Schema) und eines maximalen Zeitraums seit der letzten Aktualisierung ist hier sehr zu empfehlen.</Pgraph><Pgraph>Auch die Einsch&#228;tzung der Eintrittswahrscheinlichkeit eines Schadens stellt sich schwierig dar: W&#228;hrend in der Medizin f&#252;r Behandlungsverfahren und Arzneimittel eine Risikobewertung durch die Gegen&#252;berstellung des Nutzens und m&#246;glicher Sch&#228;den auf einer empirischen Basis erfolgt, ist dies durch die gro&#223;e Anzahl verschiedenster Ger&#228;te (Heterogenit&#228;t) und Dynamik in der Ver&#228;nderung von MIT kaum m&#246;glich.</Pgraph><Pgraph>Bei MIT sollte die Absch&#228;tzung der Eintrittswahrscheinlichkeit eines Schadens anhand einer Gef&#228;hrdung (mit der Auswirkung auf das Schutzziel) erfolgen und nicht anhand jedes einzelnen m&#246;glichen Fehlers. Dabei sind alle m&#246;glichen St&#246;r- und Fehlerquellen zu ber&#252;cksichtigen und sowohl die Auswirkungen auf das System (Ausfall, Fehlverhalten), wie auch auf den Anwender (Fehlentscheidungen, Fehlverhalten) und den Patienten zu betrachten. F&#252;hrt ein Fehler zu einer Patientengef&#228;hrdung, ist er missions- oder unternehmenskritisch, gilt dieser als nicht akzeptabel und es sind entsprechende Ma&#223;nahmen zu ergreifen.</Pgraph><Pgraph>Bei der Beurteilung der Eintrittswahrscheinlichkeit eines Schadens und des Schadensausma&#223;es ist zwingend die Betrachtung des Nutzungskontextes und damit der klinischen Prozesse und die Konformit&#228;t mit den Erwartungen und dem Verhalten des Anwenders&#47;Bedieners erforderlich. W&#228;hrend in dem Beispiel einer zentralen Darstellung &#252;ber den F&#252;llstand von Spritzenpumpen auf der Intensivstation ein erhebliches Risiko ausgeht (s. Beispiel 3, Kapitel 2.2) kann die gleiche Technologie im Bereich der &#220;berwachung von Spritzenpumpen in der Patientenkontrollierten An&#228;sthesie (PCA) in der Akutschmerztherapie einen Mehrwert ohne zus&#228;tzliches Risiko entwickeln. Hier w&#228;re sogar der Einsatz einer unsichereren Technologie, wie WLAN, denkbar.</Pgraph><Pgraph>Zur Risikominimierung sollten vor allem technische, bzw. konstruktive und erg&#228;nzend organisatorische Ma&#223;nahmen ergriffen werden.</Pgraph><Pgraph>Besteht nach der Durchf&#252;hrung geeigneter technischer und organisatorischer Ma&#223;nahmen ein Restrisiko, so ist dies ebenfalls zu bewerten. Es ist die Aufgabe des obersten Managements der Betreiberorganisation die Kriterien f&#252;r die Ermittlung eines akzeptablen Restrisikos festzulegen. Diese Verantwortung kann nicht delegiert werden.</Pgraph><SubHeadline2>Fazit</SubHeadline2><Pgraph><UnorderedList><ListItem level="1">Basis f&#252;r die Risikoanalyse ist der klinische Prozess (Nutzungskontext).</ListItem><ListItem level="1">F&#252;r die Risikoidentifizierung sind Informationen der MP und IT-Systemhersteller erforderlich.</ListItem><ListItem level="1">Die Bereitstellung der notwendigen Informationen sollte in einem strukturierten Dialog erfolgen und auch strukturiert abgelegt (z.B. in einem XML-Dokument) werden.</ListItem><ListItem level="1">Die Risikobewertung sollte anhand des Schadens im 1. Fehlerfall erfolgen.</ListItem><ListItem level="1">Zur Risikominimierung sollten vor allem technische, bzw. konstruktive und erg&#228;nzend organisatorische Ma&#223;nahmen ergriffen werden.</ListItem><ListItem level="1">Vorgaben f&#252;r die Akzeptanz des Restrisikos m&#252;ssen vom obersten Management erfolgen. </ListItem></UnorderedList></Pgraph><SubHeadline>4.4 Empfehlung zur Einf&#252;hrung und Aufrechterhaltung des Risikomanagementprozesses</SubHeadline><SubHeadline2>4.4.1 Allgemeine Empfehlungen</SubHeadline2><Pgraph>Die IEC 80001-1 ist keine harmonisierte Norm und dient nicht zur Ausf&#252;llung der grundlegenden Anforderungen der MDD-Richtlinie einschlie&#223;lich der erg&#228;nzenden Verordnungen. Sie stellt den Stand der Technik dar und dient zu belegen, dass bestimmte Prozesse in der verantwortlichen Betreiberorganisation erf&#252;llt wurden. Sie kann als solche ggf. in Gutachten oder Gerichtsverfahren zitiert werden. Somit dient die Einhaltung der Prozesse entsprechend der Norm der Reduktion von Haftungsrisiken.</Pgraph><Pgraph>In den seltensten F&#228;llen gibt es in verantwortlichen Organisationen einen definierten Prozess f&#252;r die Errichtung oder Erweiterung eines MIT. Auch fehlt meist eine zentrale benannte Stelle, die f&#252;r diese Aufgabe zust&#228;ndig ist. Eher wird man den Zustand einer historisch gewachsenen IT- und MP-Infrastruktur mit wenig beschriebenen MITs vorfinden. Die IEC 80001-1 bezieht sich auf den gesamten Lebenszyklus eines MIT: Das Risikomanagement ist von der Planung &#252;ber die Inbetriebnahme und den Betrieb bis zum Abschalten durchzuf&#252;hren. Daher m&#252;ssen fr&#252;her oder sp&#228;ter alle Systeme einem Risikomanagement unterzogen werden. Um die Einf&#252;hrung handhabbar zu gestalten, empfiehlt sich folgendes Vorgehen:</Pgraph><Pgraph><UnorderedList><ListItem level="1">Benennung eines Verantwortlichen f&#252;r das Risikomanagement des gesamten IT-Netzwerks</ListItem><ListItem level="1">Aufteilung des Netzwerkes in Subnetze anhand von logischen, organisatorischen und gesch&#228;ftlichen Bereichen (wie auch in Kapitel 4.2 beschrieben)</ListItem><ListItem level="1">Bewertung der Subnetze bzgl. der Geltungsbereiche der IEC 80001-1</ListItem><ListItem level="1">Bewertung der Risiken in den einzelnen Subnetzen und Priorisierung eines Netzes, mit dem die Umsetzung begonnen und Erfahrungen mit der IEC 80001-1 gewonnen werden kann</ListItem><ListItem level="1">Ebenfalls bietet es sich an, alle neuen Projekte einem Risikomanagement gem&#228;&#223; IEC 80001-1 zu unterziehen.</ListItem></UnorderedList></Pgraph><SubHeadline3>Fazit</SubHeadline3><Pgraph>Die Einf&#252;hrung sollte zun&#228;chst an einem neuen Projekt pilotiert und danach ausgeweitet werden. Da sich der Nutzen der Aktivit&#228;ten nicht einfach und automatisch erschlie&#223;t, ist ein internes Marketing f&#252;r die IEC <TextGroup><PlainText>80001-1</PlainText></TextGroup> empfehlenswert. Nur so kann mit der Umsetzung der Norm der Dialog zwischen den verschiedenen Fachdisziplinen gef&#246;rdert werden. Aus Erfahrung der Workshopteilnehmer ist davon auszugehen, dass die Umsetzung der IEC 80001-1 in den meisten verantwortlichen Organisationen mehrere Jahre dauert. Daher ist es wichtig, bereits fr&#252;hzeitig damit zu beginnen. Beim ersten Projekt kann man sich meist auf besonders auf kritische Komponenten des bestehenden Netzwerkes und solche mit denen man direkt interagiert beschr&#228;nken.</Pgraph><SubHeadline2>4.4.2 MIT-Risiko-Manager</SubHeadline2><Pgraph>Die Oberste Leitung der verantwortlichen Organisation hat nach Vorgaben der Norm IEC 80001-1 einen MIT-Risiko-Manager zu benennen. Aufgrund der Komplexit&#228;t von MIT sollten Risikoidentifizierung und Risikobewertung jedoch nicht von einer einzelnen Person, sondern durch eine Gruppe durchgef&#252;hrt werden, in der folgende Kompetenzen vertreten sind:</Pgraph><Pgraph><UnorderedList><ListItem level="1">Risiko-&#47;Qualit&#228;tsmanagement</ListItem><ListItem level="1">Medizintechnik</ListItem><ListItem level="1">Medizinische Informatik</ListItem><ListItem level="1">Netzwerk- und Systemtechnik</ListItem><ListItem level="1">Klinische Anwender (&#196;rzte, Pflege, etc.)</ListItem></UnorderedList></Pgraph><Pgraph>In einem Klinikverbund oder einem gr&#246;&#223;eren Gesundheitsdienstleister mit mehreren Kliniken kann es sich anbieten, eine solche Arbeitsgruppe klinik&#252;bergreifend in der Konzernzentrale anzusiedeln. So k&#246;nnen Erfahrungen aus den verschiedenen Projekten synergetisch anderen Kliniken zur Verf&#252;gung gestellt werden.</Pgraph><Pgraph>K&#246;nnen in einer Betreiberorganisation nicht alle Kompetenzbereiche abgedeckt werden, ist ein Outsourcing an einen Hersteller oder eine unabh&#228;ngige Beratungsfirma m&#246;glich. Es ist jedoch zu &#252;berlegen, in wie weit das Betreiben eines MIT aufgrund unternehmenskritischer Eigenschaften zu den Kernprozessen einer Klinik geh&#246;rt und ein eigener Kompetenzaufbau angestrebt werden sollte.</Pgraph><SubHeadline2>4.4.3 Einrichtung einer Anlaufstelle f&#252;r neue Projekte</SubHeadline2><Pgraph>F&#252;r die Anwender und andere Stakeholder sollte eine Anlaufstelle und ein Prozess geschaffen werden, an der alle Projekte und Beschaffungen anzumelden sind, bei denen Ger&#228;te an ein Netzwerk angeschlossen werden. Dies sollte eine Pr&#252;fung nach sich ziehen, ob das Projekt oder die Beschaffung in den Geltungsbereich der IEC 80001-1 fallen. Da potentiell alle Ger&#228;te mit einem Netzwerkanschluss an ein MIT angeschlossen werden und f&#252;r die Anwender die Einteilung in die Subnetze <TextGroup><PlainText>(s. Kapitel 4.2</PlainText></TextGroup> und 4.4.1) nicht immer transparent und nachvollziehbar sind, sollte dies &#252;ber den Verantwortlichen f&#252;r das Gesamtnetzwerk oder den MIT-Risiko-Manager erfolgen. </Pgraph><SubHeadline2>4.4.4 Durchf&#252;hrung des Risikomanagementprozesses</SubHeadline2><Pgraph>Hinweise zu Risikoidentifikation, Risikobewertung und Risikomanagement wurden in Kapitel 4.3 beschrieben. </Pgraph><Pgraph>Bei der Etablierung des Prozesses ist an verschiedenen Stellen mit Widerst&#228;nden zu rechnen:</Pgraph><Pgraph>Ein wesentlicher Punkt ist eine &#8222;Bastelbudenmentalit&#228;t&#8220;: So findet die Integration von IT-Systemen im Gegensatz zur Strategie bei MP h&#228;ufig mit einer &#8222;Trial-and-Error&#8220; Strategie statt. In manchen F&#228;llen werden (Softw<TextGroup><PlainText>are-)</PlainText></TextGroup>Produkte auch in Gebieten eingesetzt, f&#252;r die sie nicht explizit entwickelt wurden, Funktionalit&#228;ten also &#8222;zweckentfremdet&#8220; oder nicht dokumentierte Systemeigenschaften als &#8222;Feature&#8220; genutzt werden. Da in diesen &#8222;Projekten&#8220; zudem h&#228;ufig zu wenig Zeit f&#252;r Dokumentation und Tests aufgewendet wird, k&#246;nnen schnell Funktionalit&#228;ten und damit nach au&#223;en sichtbare Erfolge hergestellt werden. Mit der Umsetzung einer schnellen L&#246;sung entspricht man kurz- bis mittelfristig den W&#252;nschen und Vorstellungen der Anwender bzgl. einer Leistungs- und Dienstleistungsorientierten IT-Abteilung, bzw. Herstellers. </Pgraph><Pgraph>Bei diesem Vorgehen fehlen jedoch die Schritte einer sauberen Prozess- und Umfeldanalyse, eine Festschreibung von Verantwortlichkeiten und Entscheidungsbefugnissen, sowie die erforderliche Dokumentation&#47;Kommunikation und damit letztendlich die notwendige Transparenz. Somit ist keine verl&#228;ssliche Risikoanalyse m&#246;glich. Umgekehrt ist mit einem Risikomanagement eine Integration neuer Ger&#228;te oder Systeme &#8222;nur mal eben schnell&#8220; nicht mehr m&#246;glich.</Pgraph><Pgraph>Dies unterstreicht sowohl die Notwendigkeit eines professionell verwalteten Netzwerkes, als auch den erforderlichen politischen Willen und den R&#252;ckhalt durch das Management (inklusive der Obersten Leitung) des Krankenhauses f&#252;r die Umsetzung.</Pgraph><Pgraph>Ein weiterer wichtiger Punkt ist die Rolle des MIT-Risiko-Managers: Er begleitet die f&#252;r den Betrieb und das Projekt verantwortlichen Mitarbeiter durch das Risikomanagement. Dabei ist zu definieren, in wie weit er eine rein begutachtende oder beratende und unterst&#252;tzende Rolle einnimmt. Um die Vorteile der IEC 80001-1 nutzen zu k&#246;nnen, empfehlen die Autoren, unbedingt Beratung und Unterst&#252;tzung des MIT-Risikomanagers in Anspruch zu nehmen. Au&#223;erdem obliegt ihm die Entscheidung, &#196;nderungen am MIT freizugeben. Eine aktive Einbindung in fr&#252;he Projektphasen ist also empfehlenswert.</Pgraph><SubHeadline2>4.4.5 Die Achillesferse: Risikomonitoring und Change Management</SubHeadline2><Pgraph>W&#228;hrend bei der Einf&#252;hrung eines neuen Systems oder eines Medizinprodukts klare, transparente Projektschritte (Projektantrag, Projektfreigabe, Abnahme) vorhanden sind, ist der flie&#223;ende Prozess des Routinebetriebes mit der Risiko&#252;berwachung schwieriger zu handhaben. </Pgraph><Pgraph>Betrachtet man ein IT-Netzwerk in einer Klinik, so vergeht kaum ein Tag an dem nicht an einem IT-System, einem Datenbanksystem, einer Firewall, einem Virenscanner oder einer anderen Applikation ein Update oder Patch installiert wird. Es ist nahezu unm&#246;glich, all diese Ver&#228;nderungen an einem MIT, die zu einem Gro&#223;teil aufgrund einer hohen Sicherheitsrelevanz zeitnah auszuf&#252;hren sind (z.B. Betriebssystem Patch, Update Virenscanner, aber auch Fehlerbehebung in IT-Systemen) einer umfangreichen Risikoanalyse oder gar einem vollst&#228;ndigen Test auf Seiteneffekte in einem MIT zu unterziehen. Dies dr&#252;ckt sich auch darin aus, dass mehr Softwarefehler durch Seiteneffekte und Inkompatibilit&#228;ten bei Updates als durch Konstruktionsfehler bei Entwurf und Implementierung auftreten. </Pgraph><Pgraph>Umso wichtiger ist es, klare Regeln f&#252;r die Risiko&#252;berwachung und das Changemanagement in MIT zu erarbeiten und zu etablieren. Um Funktionalit&#228;ten und IT-Systeme&#47;MP hinsichtlich von Seiteneffekten&#47;unerlaubten R&#252;ckwirkungen bei der Risikoanalyse im Changemanagement priorisieren zu k&#246;nnen, ist die bereits angesprochene Aufteilung des Gesamtnetzwerkes in Subnetze mit organisatorisch abh&#228;ngigen IT-Verfahren zwingend erforderlich. Der MIT-Risikomanager des betroffenen Subsystems ben&#246;tigt insbesondere folgende Informationen:</Pgraph><Pgraph><UnorderedList><ListItem level="1">Informationen des MP Herstellers zu dem Update</ListItem><ListItem level="1">Informationen des IT-Herstellers zu dem Update</ListItem><ListItem level="1">Information &#252;ber notwendige oder durchgef&#252;hrte Konfigurations&#228;nderungen an IT-Systemen, MP oder Netzwerk.</ListItem></UnorderedList></Pgraph><Pgraph>Neben robusten MP und IT-Systemen, die auf logische Fehler in der Kommunikation erwartungskonform reagieren, stellt die Protokollierung von Kommunikationsfehlern eine wesentliche Voraussetzung f&#252;r eine Fehler&#252;berwachung dar, die eine schnelle Reaktion der Verantwortlichen des MIT auf entsprechende Fehler erlaubt.</Pgraph><Pgraph>W&#228;hrend im Bereich der Medizintechnik durch das Medizinproduktegesetz und die Medizinprodukte-Betreiberverordnung klare gesetzliche Regelungen f&#252;r das Fehlermanagement existieren, ist dies im Bereich der IT-Administration weniger geregelt. So ist der defacto Standard f&#252;r das IT-Servicemanagement ITIL<Superscript>&#174;</Superscript> (IT Infrastructure Library<Superscript>&#174;</Superscript>, <Hyperlink href="http:&#47;&#47;www.itil-officialsite.com&#47;">http:&#47;&#47;www.itil-officialsite.com&#47;</Hyperlink>), in der Medizin kaum verbreitet <TextLink reference="13"></TextLink>. ITIL bietet verschiedene Prozesse zur Strukturierung von internen und externen IT-Dienstleistern an. Die Prozesse zum Incident-, Problem-, Change- und Releasemanagement k&#246;nnen einen wertvollen Baustein darstellen, ein MIT sicher zu &#252;berwachen und zu managen. Auf diese Weise kann die Kluft zwischen der Kultur der Medizintechnik und der IT-Administration geschlossen werden.</Pgraph><SubHeadline2>4.4.6 Dokumentation in der Risikomanagementakte</SubHeadline2><Pgraph>Die Dokumentation in der Risikomanagementakte dient vor allem der Transparenz der Risiken und der Rechtssicherheit im Schadensfall. </Pgraph><Pgraph>In der Akte soll das bestehende MIT inklusive der eingesetzten Medizinprodukte und Software und dem Verantwortlichen dokumentiert werden. Fehlen Informationen zu Ger&#228;ten, die vernetzt werden sollen, so sollte sowohl die Anfrage beim Hersteller als auch dessen Antwort in der Akte festgehalten werden, jeweils mit einem Verweis auf den verantwortlichen (betriebseigenen) Mitarbeiter. Des Weiteren wird hier der Risikobewertungs- und Risikokontroll-Prozess dokumentiert (siehe Kapitel 3.6). </Pgraph><Pgraph>Dar&#252;ber hinaus sollte festgeschrieben werden, wie die &#220;berwachung des Risikos stattfindet und wer daf&#252;r verantwortlich ist. Au&#223;erdem sind Abl&#228;ufe f&#252;r &#196;nderungen an der Risikomanagementakte sowie Ver&#228;nderungen am MIT hier dokumentiert.</Pgraph><Pgraph>Es gibt kein vorgegebenes Format, in dem die Daten erfasst und gespeichert werden sollten. Allerdings ist strikt auf Versionierung, Zugriffsrechte und Signierung der Dokumente zu achten, um die Verwendbarkeit in einem Rechtsstreit oder Zertifizierungsverfahren zu erhalten. Eine Vorgehensweise analog einem audit trail <TextLink reference="14"></TextLink> kann hier eingesetzt werden.</Pgraph><SubHeadline>4.5 Pro und Contra IEC 80001-1</SubHeadline><Pgraph>Eines zeigt die Diskussion &#252;ber die IEC 80001-1: Sie hat den verantwortlichen Organisationen aufgezeigt, welche Betreiberrisiken existieren. Dabei ist entscheidend, dass die Haftungsrisiken nicht durch die IEC 80001-1 auftreten, sondern durch sie aufgezeigt und damit beherrschbar werden. </Pgraph><Pgraph>Ein weiterer Vorteil ist eine klare Definition der Verantwortlichkeiten, einschlie&#223;lich des Zusammenspiels und der Kommunikation mit den Herstellern.</Pgraph><Pgraph>Dem Zugewinn an Sicherheit f&#252;r Patienten und Anwender steht ein erh&#246;hter administrativer Aufwand gegen&#252;ber: Die Position des MIT-Risiko-Managers muss ausgef&#252;llt und Verantwortlichkeiten m&#252;ssen gekl&#228;rt werden. Die Risikoanalyse vor dem eigentlichen Projektbeginn erh&#246;ht den administrativen Aufwand f&#252;r den Projektverantwortlichen und verlangsamt die Einf&#252;hrung neuer Technologien. So kann die IT-Abteilung nicht mehr so flexibel auf Anwenderw&#252;nsche eingehen. </Pgraph><Pgraph>Die Vorteile zeigen sich nach Meinung der Autoren bereits im Projektverlauf. Durch die Dokumentation und Transparenz, die im Projektvorlauf geschaffen wurde, k&#246;nnen vor allem folgende Projekte schneller und zuverl&#228;ssiger mit einem hohen Ma&#223; an Sicherheit durchgef&#252;hrt werden. Dies ergibt sich haupts&#228;chlich durch die Vermeidung von Problemen in sp&#228;teren Projektphasen, wie in <TextGroup><PlainText>Abbildung 9 </PlainText></TextGroup><ImgLink imgNo="9" imgType="figure"/> schematisch dargestellt.</Pgraph><SubHeadline2>Fazit</SubHeadline2><Pgraph>In Abw&#228;gung aller Argumente f&#252;r und gegen eine Anwendung der IEC 80001-1 (Abbildung 10 <ImgLink imgNo="10" imgType="figure"/>) &#252;berwiegen deutlich die Vorteile. Aufgrund der zunehmenden Komplexit&#228;t der Netzwerke und der Schnittstellen, letztendlich basierend auf der Komplexit&#228;t der abzubildenden klinischen Prozesse, werden die Kliniken in den n&#228;chsten Jahren keine Alternative zur Einf&#252;hrung eines strukturierten Managements von MIT haben. Die Herausforderung liegt nicht (allein) in der Technik, die eingesetzt wird, sondern vielmehr in der Organisation und Struktur der Betreiberfirmen. Sie erfordert Ver&#228;nderungen und vor allem Kooperation im Unternehmen, um interne Analysen durchf&#252;hren zu k&#246;nnen. Auch wenn externe Beratung und Unterst&#252;tzung sehr empfehlenswert ist, kann sie hierbei nur einen zus&#228;tzlichen Baustein zum betriebseigenen Know-How darstellen.</Pgraph><Pgraph>F&#252;r die Zukunft w&#228;re es w&#252;nschenswert, die Synergien zwischen Medizinproduktegesetz und IEC80001-1 zu verbessern, in dem die erforderlichen Ger&#228;te und Systembeschreibungen vereinheitlicht werden. </Pgraph></TextBlock> <TextBlock linked="yes" name="5 Abk&#252;rzungsverzeichnis"> <MainHeadline>5 Abk&#252;rzungsverzeichnis</MainHeadline><Pgraph><Mark1>DGBMT</Mark1> &#8211; Deutsche Gesellschaft f&#252;r Biomedizinische Technik</Pgraph><Pgraph><Mark1>DIVI</Mark1> &#8211; Deutsche Interdisziplin&#228;re Vereinigung f&#252;r Intensiv- und Notfallmedizin e.V. (Interdisziplin&#228;re und interprofessionelle Fachgesellschaft und Dachverband von Fachgesellschaften und Berufsverb&#228;nden)</Pgraph><Pgraph><Mark1>HL7</Mark1> &#8211; Health Level Seven: Gruppe von Standards&#47;Organisation, die diese Standards herausgibt</Pgraph><Pgraph><Mark1>IEC</Mark1> &#8211; International Electrotechnical Commission</Pgraph><Pgraph><Mark1>IHE</Mark1> &#8211; Integrating the Healthcare Enterprise</Pgraph><Pgraph><Mark1>IMS</Mark1> &#8211; Intensivinformationsmanagementsystem Synonym PDMS</Pgraph><Pgraph><Mark1>IT</Mark1> &#8211; Informationstechnologie</Pgraph><Pgraph><Mark1>LOINC</Mark1> &#8211; Logical Observation Identifiers Names and <TextGroup><PlainText>Codes:</PlainText></TextGroup> Nomenklatur f&#252;r die Bezeichnung von (Labor-)Parametern (Observation Identifier)</Pgraph><Pgraph><Mark1>MIT</Mark1> &#8211; Medizinisches-IT-Netzwerk: IT-Netzwerk mit mindestens einem Medizinprodukt</Pgraph><Pgraph><Mark1>MP</Mark1> &#8211; Medizinprodukt</Pgraph><Pgraph><Mark1>PACS</Mark1> &#8211; Picture Archiving and Communication System</Pgraph><Pgraph><Mark1>PDMS</Mark1> &#8211; Patientendatenmanagementsystem, Synonym f&#252;r ein Intensivinformationsmanagementsystem</Pgraph><Pgraph><Mark1>SNOMED CT</Mark1> &#8211; Systematized Nomenclature of Human and Veterinary Medicine &#8211; Clinical Terms; umfassende medizinische Nomenklatur</Pgraph><Pgraph><Mark1>TOC</Mark1> &#8211; Total Cost of Ownership (Gesamtkosten f&#252;r den Betreiber &#252;ber die Gesamtnutzungsdauer eines Systems)</Pgraph><Pgraph><Mark1>VDE</Mark1> &#8211; Verband der Elektrotechnik, Elektronik und Informationstechnik</Pgraph></TextBlock> <TextBlock linked="yes" name="Anmerkung"> <MainHeadline>Anmerkung</MainHeadline><Pgraph>Positionspaper Risikomanagement f&#252;r medizinische Netzwerke (MIT) DIVI &#8211; Sektion IT und Medizintechnik</Pgraph><Pgraph>unter Beteiligung</Pgraph><Pgraph><UnorderedList><ListItem level="1">des Verbandes der Elektrotechnik Elektronik Informationstechnik e.V. (VDE), </ListItem><ListItem level="1">der Deutschen Gesellschaft f&#252;r Biomedizinische Technik im VDE (DGBMT), </ListItem><ListItem level="1">der Deutschen Interdisziplin&#228;ren Vereinigung f&#252;r Intensiv- und Notfallmedizin (DIVI), </ListItem><ListItem level="1">des Bundesverbandes Gesundheits-IT (BVITG) </ListItem><ListItem level="1">und der Deutschen Gesellschaft f&#252;r Fachkrankenpflege (DGF).</ListItem></UnorderedList></Pgraph><Pgraph>Ergebnisse eines Workshops am 13. Dezember 2010 in Gie&#223;en. <LineBreak></LineBreak><LineBreak></LineBreak>Unter Mitarbeit von:</Pgraph><Pgraph><UnorderedList><ListItem level="1">Rawan Al-Alawi, Rh&#246;n-Klinikum AG</ListItem><ListItem level="1">Prof. Dr. Bj&#246;rn Bergh, Uniklinikum Heidelberg&#47;IHE Deutschland</ListItem><ListItem level="1">Dipl.-Ing. Oliver Christ, Prosystem AG</ListItem><ListItem level="1">Christoph Isele, Siemens AG Healthcare</ListItem><ListItem level="1">Andreas Kassner, BVITG</ListItem><ListItem level="1">Matthias Meierhofer, Meierhofer AG&#47;BVITG</ListItem><ListItem level="1">Dr. Klaus Neuder, VDE&#47;DKE</ListItem><ListItem level="1">Dr. Norbert Pauli, Dr&#228;ger Medical GmbH</ListItem><ListItem level="1">Peter Ro&#223;, Rh&#246;n-Klinikum AG</ListItem><ListItem level="1">Andreas Sch&#228;fer, DGF</ListItem><ListItem level="1">Christian Sch&#252;bel, T&#220;V S&#252;d</ListItem><ListItem level="1">Dr.-Ing. Dipl.-Wirt. Ing. Olaf Such, Philips&#47;DGBMT</ListItem></UnorderedList></Pgraph></TextBlock> <TextBlock linked="yes" name="Interessenkonflikte"> <MainHeadline>Interessenkonflikte</MainHeadline><Pgraph>Die Autoren erkl&#228;ren, dass sie keine Interessenkonflikte in Zusammenhang mit diesem Artikel haben.</Pgraph></TextBlock> <References linked="yes"> <Reference refNo="1"> <RefAuthor>F&#228;hling J</RefAuthor> <RefAuthor>K&#246;bler F</RefAuthor> <RefAuthor>Leimeister J</RefAuthor> <RefAuthor>Krcmar H</RefAuthor> <RefTitle>Wahrgenommener Wert von IT in Krankenh&#228;usern &#8211; eine empirische Studie</RefTitle> <RefYear>2009</RefYear> <RefBookTitle>Business Services: Konzepte, Technologien, Anwendungen</RefBookTitle> <RefPage>709-18</RefPage> <RefTotal>F&#228;hling J, K&#246;bler F, Leimeister J, Krcmar H. Wahrgenommener Wert von IT in Krankenh&#228;usern &#8211; eine empirische Studie. In: Hansen HR, Karagiannis D, Fill HG, eds. Business Services: Konzepte, Technologien, Anwendungen. Wien: ocg; 2009. p. 709-18.</RefTotal> </Reference> <Reference refNo="2"> <RefAuthor>Anonym</RefAuthor> <RefTitle></RefTitle> <RefYear></RefYear> <RefBookTitle>Medizinproduktegesetz in der Fassung der Bekanntmachung vom 7. August 2002 (BGBl. I S. 3146), das zuletzt durch Artikel 11 des Gesetzes vom 19. Oktober 2012 (BGBl. I S. 2192) ge&#228;ndert worden ist</RefBookTitle> <RefPage></RefPage> <RefTotal>Medizinproduktegesetz in der Fassung der Bekanntmachung vom 7. August 2002 (BGBl. I S. 3146), das zuletzt durch Artikel 11 des Gesetzes vom 19. Oktober 2012 (BGBl. I S. 2192) ge&#228;ndert worden ist.</RefTotal> </Reference> <Reference refNo="3"> <RefAuthor>Anonym</RefAuthor> <RefTitle></RefTitle> <RefYear></RefYear> <RefBookTitle>Medizinprodukte-Betreiberverordnung in der Fassung der Bekanntmachung vom 21. August 2002 (BGBl. I S. 3396), die zuletzt durch Artikel 4 des Gesetzes vom 29. Juli 2009 (BGBl. I S. 2326) ge&#228;ndert worden ist</RefBookTitle> <RefPage></RefPage> <RefTotal>Medizinprodukte-Betreiberverordnung in der Fassung der Bekanntmachung vom 21. August 2002 (BGBl. I S. 3396), die zuletzt durch Artikel 4 des Gesetzes vom 29. Juli 2009 (BGBl. I S. 2326) ge&#228;ndert worden ist.</RefTotal> </Reference> <Reference refNo="5"> <RefAuthor>Bundesinstitut f&#252;r Arzneimittel und Medizinprodukte (BfArM)</RefAuthor> <RefTitle></RefTitle> <RefYear></RefYear> <RefBookTitle>Aktuelle statistische Auswertungen der Abteilung Medizinprodukte</RefBookTitle> <RefPage></RefPage> <RefTotal>Bundesinstitut f&#252;r Arzneimittel und Medizinprodukte (BfArM). Aktuelle statistische Auswertungen der Abteilung Medizinprodukte. &#91;last accessed May 4th 2011&#93;. Available from: http:&#47;&#47;www.bfarm.de&#47;DE&#47;Medizinprodukte&#47;riskinfo&#47;wissauf&#47;statist-auswertung.html&#63;nn&#61;1012476</RefTotal> <RefLink>http:&#47;&#47;www.bfarm.de&#47;DE&#47;Medizinprodukte&#47;riskinfo&#47;wissauf&#47;statist-auswertung.html&#63;nn&#61;1012476</RefLink> </Reference> <Reference refNo="4"> <RefAuthor>Bundesinstitut f&#252;r Arzneimittel und Medizinprodukte (BfArM)</RefAuthor> <RefTitle></RefTitle> <RefYear></RefYear> <RefBookTitle>Design- &#47; Konstruktionsfehler</RefBookTitle> <RefPage></RefPage> <RefTotal>Bundesinstitut f&#252;r Arzneimittel und Medizinprodukte (BfArM). Design-&#47;Konstruktionsfehler. &#91;last accessed May 4th 2011&#93;. Available from: http:&#47;&#47;www.bfarm.de&#47;DE&#47;Medizinprodukte&#47;riskinfo&#47;wissauf&#47;statist&#47;statist-Auswert&#95;Fehlerursache&#95;Design-Konstrukfehler.html</RefTotal> <RefLink>http:&#47;&#47;www.bfarm.de&#47;DE&#47;Medizinprodukte&#47;riskinfo&#47;wissauf&#47;statist&#47;statist-Auswert&#95;Fehlerursache&#95;Design-Konstrukfehler.html</RefLink> </Reference> <Reference refNo="6"> <RefAuthor>Deutsches Institut f&#252;r Normung</RefAuthor> <RefTitle></RefTitle> <RefYear>2011</RefYear> <RefBookTitle>Anwendung des Risikomanagements f&#252;r IT-Netzwerke, die Medizinprodukte beinhalten: Teil 1: Aufgaben, Verantwortlichkeiten und Aktivit&#228;ten (IEC 80001-1:2010); Deutsche Fassung EN 80001-1:2011</RefBookTitle> <RefPage></RefPage> <RefTotal>Deutsches Institut f&#252;r Normung. Anwendung des Risikomanagements f&#252;r IT-Netzwerke, die Medizinprodukte beinhalten: Teil 1: Aufgaben, Verantwortlichkeiten und Aktivit&#228;ten (IEC 80001-1:2010); Deutsche Fassung EN 80001-1:2011. 2011.</RefTotal> </Reference> <Reference refNo="7"> <RefAuthor>R&#246;hrig R</RefAuthor> <RefAuthor>R&#252;th R</RefAuthor> <RefTitle>Intelligente Telemedizin in der Intensivmedizin &#8211; Patientennaher Einsatz von Medizintechnik und IT in der Intensivmedizin</RefTitle> <RefYear>2009</RefYear> <RefJournal>Bundesgesundheitsblatt Gesundheitsforschung Gesundheitsschutz</RefJournal> <RefPage>279-86</RefPage> <RefTotal>R&#246;hrig R, R&#252;th R. Intelligente Telemedizin in der Intensivmedizin &#8211; Patientennaher Einsatz von Medizintechnik und IT in der Intensivmedizin. Bundesgesundheitsblatt Gesundheitsforschung Gesundheitsschutz. 2009 Mar;52(3):279-86. DOI: 10.1007&#47;s00103-009-0792-x</RefTotal> <RefLink>http:&#47;&#47;dx.doi.org&#47;10.1007&#47;s00103-009-0792-x</RefLink> </Reference> <Reference refNo="8"> <RefAuthor>Deutsche Industrie Norm (DIN)</RefAuthor> <RefTitle></RefTitle> <RefYear></RefYear> <RefBookTitle>DIN EN 60601-1: Medizinische elektrische Ger&#228;te &#8211; Teil 1: Allgemeine Festlegungen f&#252;r die Sicherheit einschlie&#223;lich der wesentlichen Leistungsmerkmale</RefBookTitle> <RefPage></RefPage> <RefTotal>Deutsche Industrie Norm (DIN). DIN EN 60601-1: Medizinische elektrische Ger&#228;te &#8211; Teil 1: Allgemeine Festlegungen f&#252;r die Sicherheit einschlie&#223;lich der wesentlichen Leistungsmerkmale.</RefTotal> </Reference> <Reference refNo="9"> <RefAuthor>G&#228;rtner A</RefAuthor> <RefTitle>MDD 2007&#47;47&#47;EG: Software als Medizinprodukt</RefTitle> <RefYear>2012</RefYear> <RefJournal>E-Health-Com</RefJournal> <RefPage></RefPage> <RefTotal>G&#228;rtner A. MDD 2007&#47;47&#47;EG: Software als Medizinprodukt. E-Health-Com. 2012. Available from: http:&#47;&#47;www.e-health-com.eu&#47;fileadmin&#47;user&#95;upload&#47;dateien&#47;Downloads&#47;Gaertner-Medizinprodukte-Gesetz.pdf</RefTotal> <RefLink>http:&#47;&#47;www.e-health-com.eu&#47;fileadmin&#47;user&#95;upload&#47;dateien&#47;Downloads&#47;Gaertner-Medizinprodukte-Gesetz.pdf</RefLink> </Reference> <Reference refNo="10"> <RefAuthor>Johner C</RefAuthor> <RefAuthor>Geis T</RefAuthor> <RefTitle>Medizinproduktegesetz MPG und Klassifikation von Software</RefTitle> <RefYear>2009</RefYear> <RefBookTitle>Praxishandbuch IT im Gesundheitswesen</RefBookTitle> <RefPage>13-15.</RefPage> <RefTotal>Johner C, Geis T. Medizinproduktegesetz MPG und Klassifikation von Software. In: Johner C, Haas P, eds. Praxishandbuch IT im Gesundheitswesen. M&#252;nchen: Carl Hanser Verlag M&#252;nchen; 2009. p. 13-15.</RefTotal> </Reference> <Reference refNo="11"> <RefAuthor>Johner C</RefAuthor> <RefAuthor>H&#246;lzel-Kl&#252;pfel S</RefAuthor> <RefAuthor>Wittorf S</RefAuthor> <RefTitle></RefTitle> <RefYear>2011</RefYear> <RefBookTitle>Basiswissen medizinische Software</RefBookTitle> <RefPage></RefPage> <RefTotal>Johner C, H&#246;lzel-Kl&#252;pfel S, Wittorf S, eds. Basiswissen medizinische Software. Heidelberg: dpunkt-Verlag; 2011.</RefTotal> </Reference> <Reference refNo="12"> <RefAuthor>European Commission DG Health and Consumer</RefAuthor> <RefAuthor>Directorate B</RefAuthor> <RefAuthor>Unit B2 &#8220;Health Technology and Cosmetics&#8221;</RefAuthor> <RefTitle></RefTitle> <RefYear></RefYear> <RefBookTitle>Guidelines on the qualification and classification of stand alone software used in healthcare within the regulatory framework of medical devices. 2012. MEDDEV 2.1&#47;6.</RefBookTitle> <RefPage></RefPage> <RefTotal>European Commission DG Health and Consumer, Directorate B, Unit B2 &#8220;Health Technology and Cosmetics&#8221;. Guidelines on the qualification and classification of stand alone software used in healthcare within the regulatory framework of medical devices. 2012. MEDDEV 2.1&#47;6. Available from. http:&#47;&#47;ec.europa.eu&#47;health&#47;medical-devices&#47;files&#47;meddev&#47;2&#95;1&#95;6&#95;ol&#95;en.pdf</RefTotal> <RefLink>http:&#47;&#47;ec.europa.eu&#47;health&#47;medical-devices&#47;files&#47;meddev&#47;2&#95;1&#95;6&#95;ol&#95;en.pdf</RefLink> </Reference> <Reference refNo="13"> <RefAuthor>Hoerbst A</RefAuthor> <RefAuthor>Hackl WO</RefAuthor> <RefAuthor>Blomer R</RefAuthor> <RefAuthor>Ammenwerth E</RefAuthor> <RefTitle>The status of IT service management in health care &#8211; ITIL&#174; in selected European countries</RefTitle> <RefYear>2011</RefYear> <RefJournal>BMC Medial Informatics and Decision Making</RefJournal> <RefPage>76</RefPage> <RefTotal>Hoerbst A, Hackl WO, Blomer R, Ammenwerth E. The status of IT service management in health care &#8211; ITIL&#174; in selected European countries. BMC Medial Informatics and Decision Making. 2011;11:76. DOI: 10.1186&#47;1472-6947-11-76</RefTotal> <RefLink>http:&#47;&#47;dx.doi.org&#47;10.1186&#47;1472-6947-11-76</RefLink> </Reference> <Reference refNo="14"> <RefAuthor>General Services Administration Information Technology Service</RefAuthor> <RefTitle></RefTitle> <RefYear>1996</RefYear> <RefBookTitle>Federal Standard 1037C: Glossary of Telecommunications Terms</RefBookTitle> <RefPage></RefPage> <RefTotal>General Services Administration Information Technology Service. Federal Standard 1037C: Glossary of Telecommunications Terms. 1996.</RefTotal> </Reference> </References> <Media> <Tables> <Table format="png"> <MediaNo>1</MediaNo> <MediaID>1</MediaID> <Caption><Pgraph><Mark1>Tabelle 1: Die wichtigsten Definitionen basierend auf der IEC 80001-1</Mark1></Pgraph></Caption> </Table> <Table format="png"> <MediaNo>2</MediaNo> <MediaID>2</MediaID> <Caption><Pgraph><Mark1>Tabelle 2: Rollen, wie sie in der IEC 80001-1 definiert sind</Mark1></Pgraph></Caption> </Table> <NoOfTables>2</NoOfTables> </Tables> <Figures> <Figure format="png" height="580" width="836"> <MediaNo>1</MediaNo> <MediaID>1</MediaID> <Caption><Pgraph><Mark1>Abbildung 1: Entwicklung der aktiven Netzwerkknoten am Beispiel eines mittelgro&#223;en Krankenhauses (Abbildung: Peter Ro&#223;)</Mark1></Pgraph></Caption> </Figure> <Figure format="png" height="612" width="940"> <MediaNo>2</MediaNo> <MediaID>2</MediaID> <Caption><Pgraph><Mark1>Abbildung 2: Fehlerursachen f&#252;r Design-&#47;Konstruktionsfehler bei Risikomeldungen an das BfArM (Quelle BfArM &#91;4&#93;)</Mark1></Pgraph></Caption> </Figure> <Figure format="png" height="730" width="644"> <MediaNo>3</MediaNo> <MediaID>3</MediaID> <Caption><Pgraph><Mark1>Abbildung 3: Organisationsstruktur gem&#228;&#223; IEC 80001-1, abgeglichen mit DIN EN 80001-1</Mark1></Pgraph></Caption> </Figure> <Figure format="png" height="608" width="472"> <MediaNo>4</MediaNo> <MediaID>4</MediaID> <Caption><Pgraph><Mark1>Abbildung 4: Verantwortlichkeiten der obersten Leitung&#47;Gesch&#228;ftsf&#252;hrung (basierend auf IEC 80001-1 und DIN EN 80001-1)</Mark1></Pgraph></Caption> </Figure> <Figure format="png" height="476" width="471"> <MediaNo>5</MediaNo> <MediaID>5</MediaID> <Caption><Pgraph><Mark1>Abbildung 5: Aufgabe des MIT-Risikomanagements ist die Koordination der verschiedenen Interessensvertreter</Mark1></Pgraph></Caption> </Figure> <Figure format="png" height="591" width="631"> <MediaNo>6</MediaNo> <MediaID>6</MediaID> <Caption><Pgraph><Mark1>Abbildung 6: Ablauf des Risikomanagementprozesses nach IEC 80001-1</Mark1></Pgraph></Caption> </Figure> <Figure format="png" height="360" width="468"> <MediaNo>7</MediaNo> <MediaID>7</MediaID> <Caption><Pgraph><Mark1>Abbildung 7: Ebenen eines robusten MIT</Mark1></Pgraph></Caption> </Figure> <Figure format="png" height="528" width="764"> <MediaNo>8</MediaNo> <MediaID>8</MediaID> <Caption><Pgraph><Mark1>Abbildung 8: Definition eines MIT: Es bildet den &#220;bergang zwischen einem reinen IT-Netzwerk und einem reinen Medizinprodukte Netzwerk (MP).</Mark1></Pgraph></Caption> </Figure> <Figure format="png" height="462" width="712"> <MediaNo>9</MediaNo> <MediaID>9</MediaID> <Caption><Pgraph><Mark1>Abbildung 9: Schematisch skizzierter Aufwandsvergleich</Mark1></Pgraph></Caption> </Figure> <Figure format="png" height="447" width="569"> <MediaNo>10</MediaNo> <MediaID>10</MediaID> <Caption><Pgraph><Mark1>Abbildung 10: Pro und Contra-Argumente zur IEC 80001-1</Mark1></Pgraph></Caption> </Figure> <NoOfPictures>10</NoOfPictures> </Figures> <InlineFigures> <NoOfPictures>0</NoOfPictures> </InlineFigures> <Attachments> <NoOfAttachments>0</NoOfAttachments> </Attachments> </Media> </OrigData> </GmsArticle>