1. Fortbildungsveranstaltung FKT Hamburg und Schleswig-Holstein am

Transkript

1 1. Fortbildungsveranstaltung FKT Hamburg und Schleswig-Holstein am :00 Uhr bis ca. 15:45 Uhr in der LungenClinic Grosshansdorf Vortragssaal 09:30 bis 11:00 Uhr Rechtliche Notwendigkeit und Sinnhaftigkeit der IEC 80001

2 Vorstellung GMDS Projektgruppe Medizintechnik und IT Dipl. Inf. Jochen Kaiser MEDSIAS IT-Sicherheitsbeauftragter Universitätsklinikum Erlangen Mitarbeiter der DIN/DKE im UK für die BayKG

3 Motivation: Projektkoordination Station Bauliche Anforderung Netzwerk- Verfügbarkeit/ Alarmweiterschaltung Patientenruf Stationsplanung Patientenmonitoring

4 das kommt dann dabei raus

5 Beispiel für die Notwendigkeit interdisziplinäres Risikomanagement Patientenmonitoring auf Kinderkardio Betrieb des Wlan 24/7! Was ist beim Ausfall des Wlan? Was ist, wenn

6 Motivation: Projektkoordination Station Patientennähe der IT / MT vs. Pflege Beschaffung Hersteller IT & Medizintechnik Ausleuchtung IT Betriebsphase Medizinisches Personal

7 Motivation Alarmierung Störung

8 Mobility(Alarmierung) Alarm Wunsch: quittierter Alarmzustand

9 Konsequenzen und erste Schritte Alarmierungsrichtlinie einführen Eindeutiges Wording ( was ist Alarmierung ) Verbot von Komfortalarmen Anwendungsbereich definieren Alarmierungskonzept aufstellen Allianz mit dem Betreiber Rufanlagen

10 Mobility(Alarmierung) Alarm Aus TR zur IEC Alarmierung-Draft

11 Aus TR zur IEC Alarmierung-Draft Mobility(Alarmierung)

12 Überblick über die IEC

13 Einführung in die IEC

14 Definitionen der Schutzziele des EDV- Netzwerks Safety: Freiheit von unvertretbaren Risiken der physischen Verletzung oder Schädigung der Gesundheit von Menschen oder der Schädigung von Eigentum oder der Umwelt. Daten- und Systemsicherheit Betriebszustand eines MEDIZINISCHEN IT NETZWERKS, in dem wichtige Informationen (Daten und Systeme) vor Beeinträchtigung der Vertraulichkeit, vor Beeinträchtigung der Integrität und vor Beeinträchtigung der Verfügbarkeit ausreichend geschützt sind. Effektivität (engl. Effectiveness(!) ) Fähigkeit, das beabsichtigte Ergebnis für den Patienten und die Verantwortliche Organisation zu erzeugen.

15 Definitionen DIN EN ; VDE : : IT-NETZWERK (INFORMATIONSTECHNOLOGIE-NETZWERK) System/Systeme, bestehend aus Kommunikationsknoten und Übertragungsverbindungen, um Übertragungen, über Leitungen oder drahtlos, zwischen zwei oder mehr festgelegten Übertragungsknoten zu ermöglichen 2.22 Verantwortliche Organisation Betreiber, der die Sachherrschaft über den Gebrauch und die Instandhaltung eines medizinischen IT-Netzwerks besitzt

16 Definitionen DIN EN ; VDE : : MEDIZINISCHES IT-NETZWERK IT-NETZWERK, das mindestens ein MEDIZINPRODUKT enthält. ANMERKUNG 2:Der Anwendungsbereich des MEDIZINISCHEN IT-NETZWERKS wird in dieser Norm durch die VERANTWORTLICHE ORGANISATION definiert, basierend auf der Frage, wo sich die MEDIZINPRODUKTE im MEDIZINISCHEN IT- NETZWERK befinden und basierend auf der definierten Anwendung des Netzwerks. Es kann eine IT-Infrastruktur enthalten, sowie Elemente der häuslichen Pflege und nichtklinische Elemente. Siehe auch

17 Vorgehensweise Risikomanagement Risiken Hersteller vs. Risiken Betreiber Risikomanagement Gebrauchstauglichkeit QMS Herstellungsprozess Sicherheitsanforderungen SW Lebens zyklus Betreiber-Pflichten Anwender-Pflichten Anwendung und Betrieb Risikomanagement beim Anschluss ans Netz

18 Konsequenzen und erste Schritte Definition der Schutzziele Safety Schutz des Patienten Security Schutz der Geräte und Daten Effectiveness Schutz der Prozesse Prioritäten der Schutzziele untereinander Definition der Klasse von medizinischen Netzwerken, die geschützt werden sollen Verstehen was Risikomanagement ist

19 Herleitung der rechtlichen Notwendigkeit (IANAL)

20 MPBetreibV 2: Allgemeine Vorschriften (1) Medizinprodukte dürfen nur ihrer Zweckbestimmung entsprechend und nach den Vorschriften dieser Verordnung, den allgemein anerkannten Regeln der Technik sowie den Arbeitsschutz-und Unfallverhütungsvorschriften errichtet, betrieben, angewendet und in Stand gehalten werden. (2) Medizinprodukte dürfen nur von Personen errichtet, betrieben, angewendet und in Stand gehalten werden, die dafür die erforderliche Ausbildung oder Kenntnis und Erfahrung besitzen. (3) Miteinander verbundene Medizinprodukte sowie mit Zubehör einschließlich Software oder mit anderen Gegenständen verbundene Medizinprodukte dürfen nur betrieben und angewendet werden, wenn sie dazu unter Berücksichtigung der Zweckbestimmung und der Sicherheit der Patienten, Anwender, Beschäftigten oder Dritten geeignet sind. (4) Der Betreiber darf nur Personen mit dem Errichten und Anwenden von Medizinprodukten beauftragen, die die in Absatz 2 genannten Voraussetzungen erfüllen. (5) Der Anwender hat sich vor der Anwendung eines Medizinproduktes von der Funktionsfähigkeit und dem ordnungsgemäßen Zustand des Medizinproduktes zu überzeugen und die Gebrauchsanweisung sowie die sonstigen beigefügten sicherheitsbezogenen Informationen und Instandhaltungshinweise zu beachten. Satz 1 gilt entsprechend für die mit dem Medizinprodukt zur Anwendung miteinander verbundenen Medizinprodukte sowie Zubehör einschließlich Software und anderen Gegenständen. Die passenden Regeln anwenden Ausbildungskonzept Kopplung von MP regeln Überwachungspflicht der Einrichtung Anwenderverantwortung unterstützen

21 Anwendung technologischer und wissenschaftlicher Erkenntnisse Stand der Wissenschaft neueste belegte Erkenntnisse der Wissenschaft Grenzrisiko / Restrisiko (Residual Risk) Stand der Technik Beste verfügbare Technik, State of the Art Regeln der Technik alle auf Erkenntnissen und Erfahrungen beruhenden geschriebenen und ungeschriebenen Regeln der Technik deren Befolgung beachtet werden muss und in zugehörigen Fachkreisen bekannt sind Berufsausbildung : in der Praxis bei dem nach neuestem Erkenntnisstand vorgebildeten Techniker durchweg bekannt allgemein anerkannte Regel der Technik anerkannte Regel der Technik, die von der Mehrheit der Fachleute angewendet wird

22 MPBetreibV 2: Allgemeine Vorschriften (1) Medizinprodukte dürfen nur ihrer Zweckbestimmung entsprechend und nach den Vorschriften dieser Verordnung, den allgemein anerkannten Regeln der Technik sowie den Arbeitsschutz-und Unfallverhütungsvorschriften errichtet, betrieben, angewendet und in Stand gehalten werden. (2) Medizinprodukte dürfen nur von Personen errichtet, betrieben, angewendet und in Stand gehalten werden, die dafür die erforderliche Ausbildung oder Kenntnis und Erfahrung besitzen. (3) Miteinander verbundene Medizinprodukte sowie mit Zubehör einschließlich Software oder mit anderen Gegenständen verbundene Medizinprodukte dürfen nur betrieben und angewendet werden, wenn sie dazu unter Berücksichtigung der Zweckbestimmung und der Sicherheit der Patienten, Anwender, Beschäftigten oder Dritten geeignet sind. (4) Der Betreiber darf nur Personen mit dem Errichten und Anwenden von Medizinprodukten beauftragen, die die in Absatz 2 genannten Voraussetzungen erfüllen. (5) Der Anwender hat sich vor der Anwendung eines Medizinproduktes von der Funktionsfähigkeit und dem ordnungsgemäßen Zustand des Medizinproduktes zu überzeugen und die Gebrauchsanweisung sowie die sonstigen beigefügten sicherheitsbezogenen Informationen und Instandhaltungshinweise zu beachten. Satz 1 gilt entsprechend für die mit dem Medizinprodukt zur Anwendung miteinander verbundenen Medizinprodukte sowie Zubehör einschließlich Software und anderen Gegenständen. Die passenden Regeln anwenden Ausbildungskonzept Kopplung von MP regeln Überwachungspflicht der Einrichtung Anwenderverantwortung unterstützen

23 4 Verbote zum Schutz von Patienten, Anwendern und Dritten (1) Es ist verboten, Medizinprodukte in den Verkehr zu bringen, zu errichten, in Betrieb zu nehmen, zu betreiben oder anzuwenden, wenn 1. der begründete Verdacht besteht, dass sie die Sicherheit und die Gesundheit der Patienten, der Anwender oder Dritter bei sachgemäßer Anwendung, Instandhaltung und ihrer Zweckbestimmung entsprechender Verwendung über ein nach den Erkenntnissen der medizinischen Wissenschaften vertretbares Maßhinausgehend unmittelbar oder mittelbar gefährden oder Konsequenz: Risikoanalyse und -Bewertung notwendig

24 Zitat der grundlegenden Anforderungen aus EWG 93/42 Die Produkte müssen so ausgelegt und hergestellt sein, dass ihre Anwendung unter den vorgesehenen Bedingungen und zu den vorgesehenen Zwecken weder den klinischen Zustand und die Sicherheit der Patienten noch die Sicherheit und die Gesundheit der Anwender oder gegebenenfalls Dritter gefährdet, wobei etwaige Risiken im Zusammenhang mit der vorgesehenen Anwendung gemessen am Nutzen für den Patienten vertretbar und mit einem hohen Maßan Gesundheitsschutz und Sicherheit vereinbar sein müssen. Konsequenz: Risikoanalyse und Bewertung notwendig

25 14 Errichten, Betreiben, Anwenden und Instandhalten von Medizinprodukten Gesetzestext 14: Medizinprodukte dürfen nur nach Maßgabe der Rechtsverordnung nach 37 Abs. 5 errichtet, betrieben, angewendet und in Stand gehalten werden. Sie dürfen nicht betrieben und angewendet werden, wenn sie Mängel aufweisen, durch die Patienten, Beschäftigte oder Dritte gefährdet werden können. Konsequenz: Risikoanalyse notwendig

26 Fazit rechtliche Notwendigkeit für die IEC Im Gesetzestext keine explizite Erwähnung für die IEC noch für die Durchführung eines Risikomanagements bei Netzwerken IEC keine allgemein anerkannte Regel der Technik keine direkte Anwendbarkeit aus der MPBetreibV ableitbar. Viele Hinweise auf die Notwendigkeit einer Risikoanalyse evtl. auch eines Risikomanagements. MPBetreibV 2(1) und 2(3) MPG 4 und 14 Grundlegende Anforderungen aus dem ConTraG und der Anforderung eines IKS Risikoaussagen zum Einsatz vernetzter Medizinprodukte werden vom Geschäftsführer erwartet: Leiter von MT bzw. IT müssen das im Rahmen ihrer Beauftragung leisten!

27 Fragestellung: eigene Netzwerke oder nicht?

28 Netzwerkprobleme in medizinischen Dienstgüte Netzwerkänderung Netzwerken Netzwerkfehler OS-Aktualisierung Medizinprodukt Security Probs Med-Produkte schadhafte Software Medizinische Kommunikation Laptop der Service- Techniker (infiziert) Fehler am Patchfeld Inbetriebnahme/ Außerdienststellung

29 Ist so ein vertrauensvoller Betrieb von Medizintechnik möglich?

30 Einteilung der Netze nach DIN EN Anhang H (informativ) A: gemeinsames Netz mit Verwaltungsapplikationen B: virtuell getrenntes Netzwerk C: physikalisch getrenntes Netzwerk

31 Fragestellung: VLANs oder physisch getrennte Netze? Wunschbild Realität Albtraum 31

32 Verknüpfung ISO und IEC IEC ISO/IEC :2005 oder ISO/IEC : KONFIGURATIONSMANAGEMENT In IEC ist das KONFIGURATIONSMANAGEMENT ein Prozess, der in der CMDB abgespeichert wird. 2.5 Datenbank des Konfigurationsmanagement Die CMBD ist die Datenbank, die für das Konfigurationsmanagement benutzt wird. [ISO/IEC :2005] 2.7 MANAGEMENT VON VORKOMMNISSEN 2.7 Vorfall Die Art von Vorkommnissen wird in nicht definiert. Sie beziehen sich sowohl auf das IT-NETZWERK als auch auf das MEDIZINPRODUKT. Vorfall und Problem beziehen sich beide auf Vorkommnisse, die in IEC durch das Management von Vorkommnissen behandelt werden. [ISO/IEC :2005] 2.21 ZUSTÄNDIGKEITSVEREINBARUNG Eine Vereinbarung zwischen z. B. Lieferanten, Service- Anbietern, Systemintegratoren und der VERANTWORTLICHEN ORGANISATION Vereinbarung über Service-Stufen 2.14 Service-Management Definiert das Verhältnis zwischen Eigentümer eines IT-NETZWERKS und dem Service-Anbieter. [ISO/IEC :2005] 2.22 VERANTWORTLICHE ORGANISATION 2.15 Service-Anbieter Die VERANTWORTLICHE ORGANISATION muss den Service-Anbieter für das IT-NETZWERK als Teil ihrer Richtlinie zertifizieren. [ISO/IEC :2005] 2.29 RISIKOMANAGEMENTAKTE 2.9 Aufzeichnung; 2.3 Änderungsprotokoll 2.11 Änderungsanforderung Elemente der RISIKOMANAGEMENTAKTE 2.5 Datenbank des Konfigurationsmanagement Element der RISIKOMANAGEMENTAKTE (Element Beschreibung) ANMERKUNG Die RISIKOMANAGEMENTAKTE kann in einer Datenbank gespeichert werden, die die Datenbank für das Konfigurationsmanagement enthält. [ISO/IEC :2005] 3.3 OBERSTE LEITUNG 3.1 Verantwortung des Managements Beide Normen behandeln Verantwortlichkeiten des oberen Managements. ISO/IEC :2005 lässt mehr organisatorische Freiheit. Servicemanagementprozesse ISO Spielen auch in der IEC eine zentrale Rolle 3.4 RISIKOMANAGER FÜR DAS MEDIZINISCHE IT-NETZWERK Der RISIKOMANAGER ist für den RISIKOMANAGEMENT-PROZESS verantwortlich. 3.5 Hersteller von MEDIZINPRODUKTEN; 3.6 Andere Anbieter von Informationstechnologie Diese Abschnitte legen Informationen fest, die über die Lieferanten an die VERANTWORTLICHE ORGANISATION geliefert werden müssen Richtlinie für das RISIKOMANAGEMENT für die Einbindung von MEDIZINPRODUKTEN RISIKOMANAGEMENT PROZESS Behandelt SICHERHEIT, WIRKSAMKEIT und DATEN- UND SYSTEMSICHERHEIT. 4.3 RISIKOMANAGEMENT des IT-NETZWERKS, Planung und Dokumentation 3.1 Verantwortung des Managements RISIKOMANAGEMENT wird nicht besonders als Aufgabe des Managements bezeichnet Dokumente und Aufzeichnungen Aufzeichnungen sollten analysiert werden. In IEC ist dies die Verantwortung des RISIKOMANAGERS FÜR DAS MEDIZINISCHE IT-NETZWERK. [ISO/IEC :2005] 7.1 Beziehungsprozess Allgemeines, Sicherheit und Verfügbarkeit von Informationen [ISO/IEC :2005]; 7.3 Lieferantenmanagement Beide Normen fordern, dass die Geschäftsbeziehungen durch Vertrag geregelt werden und 7.3 beziehen sich auf Lieferanten von Komponenten des MEDIZINISCHEN IT-NETZWERKS. 3.1 Verantwortung des Managements Praktiken der Risikobewertung hinsichtlich Sicherheit [ISO/IEC :2005] Sicherheit ist ein Element der WESENTLICHEN EIGENSCHAFTEN eines MEDIZINISCHEN IT-NETZWERKS. IEC liefert den allgemeinen RISIKOMANAGEMENT-PROZESS für das IT-NETZWERK. 4.1 Servicemanagement-Plan, Management von Verbesserungen, 5.1 Elemente zur Überlegung ISO/IEC kann RISIKOMANAGEMENT einschließen. Tabelle Umsetzung des Wordings ISO IEC 80001

33 Anwendbarkeit der IEC nach System-Konfigu-r ation eigenem Anhang (informativ) Beschreibung des Szenarios Netzwerk Komponenten Netzwerk Netzwerk Verantwortung Norm 1 a MEDIZINPRODUKTE eines einzigen MEDIZINPRODUKTE- Hersteller und Nicht-MEDIZINPRODUKTE werden vom gleichen MEDIZINPRODUKTE-Hersteller eingebunden und nach den Anforderungen dieses MEDI-ZINPRODUKTE- Herstellers in ein isoliertes IT-NETZWERK installiert. b MEDIZINPRODUKTE mehrerer MEDI-ZINPRODUKTE-Hersteller und Nicht-MEDIZINPRODUKTE werden von einem MEDIZINPRODUKTE-Her-steller eingebunden und nach den Anforderungen dieses MEDIZIN-PRODUKTE-Herstellers in ein isoliertes IT-NETZWERK installiert. 2 a MEDIZINPRODUKTE und Nicht-MEDIZINPRODUKTE werden von einem MEDIZINPRODUKTE-Her-steller eingebunden; andere MEDIZINPRODUKTE und Nicht-MEDIZINPRODUKTE werden von anderen MEDIZINPRODUKTE-Her-stellern eingebunden. Alle Pro-dukte werden von einer dritten Partei (z.b. einem Krankenhaus) im gleichen IT-NETZWERK miteinander verbunden. b MEDIZINPRODUKTE und Nicht-MEDIZINPRODUKTE werden von einem MEDIZINPRODUKTE-Hersteller eingebunden. Andere MEDIZINPRODUKTE und Nicht-MEDIZINPRODUKTE werden von anderen MEDIZINPRODUKTE-Herstellern eingebunden. Nicht-MEDIZINPRODUKTE und Anwendungen werden von einer dritten Partei in einem gemein-samen IT-NETZWERK miteinander verbunden. 3 Installationen mit Nicht-MEDIZIN-PRODUKTEN vieler Hersteller, die das IT-NETZWERK für die Über-tragung elektronisch geschützter Gesundheitsinformationen nutzen. MEDIZINPRODUKTE und Nicht MEDIZINPRODUKTE eines einzigen MEDIZINPRODUKTE-Hersteller MEDIZINPRODUKTE und Nicht- MEDIZIN-PRODUKTE mehrerer MEDIZINPRODUKTE-Hersteller MEDIZINPRODUKTE und Nicht MEDIZIN-PRODUKTE mehrerer MEDIZINPRODUKTE-Hersteller MEDIZINPRODUKTE und Nicht- MEDIZINPRODUKTE mehrerer MEDIZINPRODUKTE-Hersteller und vielen Nicht-MEDIZINPRODUKTE- Herstellern Viele Nicht-MEDIZINPRODUKTE- Hersteller Physikalisch getrennt Physikalisch getrennt gemeinsam gemeinsam gemeinsam MEDIZIN-PRODUKTE- Hersteller MEDIZIN-PRODUKTE- Hersteller VERANTWORT-LICHE ORGANISATION VERANTWORT-LICHE ORGANISATION VERANTWORT-LICHE ORGANISATION Außer-halb des Anwen-dungs-berei chs der *) *) Es gelten die lokalen nationalen Vorschriften über die Sicherheit medizinischer Daten, die VERANT-WORTLICHE ORGANISATION kann sich jedoch auch entschließen, IEC anzuwenden.

34 Konsequenzen und erste Schritte Anhang H.1 ist informativ nicht normativ Hersteller von Monitoringapplikationen haben eigene Konzepte (Philips CSN, Dräger OneNet) Bewertung durch den MT-Leiter notwendig: Ist die IT in der Lage einen vernünftigen Dienst anzubieten Arbeitet die IT in diesen Bereichen mit einem Service- Management? Hat die IT die Vorgaben der Medizintechnik verstanden?

35 Was sind die genauen Anforderungen aus der IEC ?

36 Aufbau der Norm IEC Begrifflichkeiten und Definitionen Aufgaben und Verantwortlichkeiten Geschäftsführung Netzwerkbetreiber Med IT Risk-Manager MP-Hersteller Hersteller anderer IT IEC Anwendung des RM auf IT-Netzwerke mit Medizinprodukten 4 Risikomanagement für medizinische IT- Netzwerke allg. Anforderungen Planung / Doku Durchführung Change-Management Live Network Mgmt Verantwortungsverein b 5 Dokumentenkontrolle Vorgehensweise Netz-RM-Akte

37 IEC Aufgaben für die Geschäftsführung

38 Wie fange ich nun an? Mit einem Risikoerfassungsbogen!

39 Risikoentscheidungen abklären mittels Hersteller-Befragung Der Hersteller wird zu den Risiken beim Netzwerkanschluss befragt Ein allgemeiner Fragenkatalog ist zu erarbeiten und muss im Vorfeld von Käufen übermittelt werden Fragen sollten unterschrieben werden 2.21 VERANTWORTLICHKEITSVEREINBARUNG Ein oder mehrere Dokumente, die zusammen die Verantwortlichkeiten aller Beteiligten vollständig definieren. Anmerkung: Diese Vereinbarung kann Ein rechtskräftiges Dokument sein, z.b. ein Vertrag.

40 Risikoentscheidungen abklären mittels Grundsatzfrage: Kann mindestens eines der von Ihnen angebotenen Medizinprodukte mittels eines dafür gemäß der Zweckbestimmung vorgesehenen Netzwerkanschlusses an das IT-Netzwerk des Universitätsklinikums Erlangen angebunden werden? ja nein Falls Sie die obige Frage mit Nein beantwortet haben, müssen keine weiteren Fragen mehr beantwortet werden. Hersteller-Befragung Kommentar: Medizinische Zweckbestimmung unter Umständen ungleich der Netzwerkzweckbestimmung. Evtl. gibt es gar keinen medizinischen Zweck und das System soll nur ans Netz um Wartungskosten einzusparen. Nennung der Netzwerkzweckbestimmung für das System laut IEC (Hinweis: Warum müssen die Komponenten im Rahmen der medizinischen Zweckbestimmung im Netzwerk betrieben werden?) Nur der exakte medizinische Zweck der Netzwerknutzung kann als Startpunkt für das Risikomanagement dienen.

41 Risikoentscheidungen abklären mittels Hersteller-Befragung Ansprechpartner Nennung und Kontaktdaten (Telefon, ) des Vertriebskontakts. Nennung und Kontaktdaten (Telefon, ) des Vertriebsleiters bei Notwendigkeit einer Eskalation. Ist dieser zeichnungsberechtigt im Sinne des MPG, um Änderungen am Medizinprodukt freizugeben? Nennung und Kontaktdaten (Telefon, ) eines zeichnungsberechtigten Ansprechpartners der Qualitätssicherung / QM. Kommentar Im Notfall (z.b. bei Infektion mit einem Schädling) wird ein Kontakt zur Qualitätssicherung benötigt, um über dieses dringliche Problem zu informieren.

42 Risikoentscheidungen abklären mittels Hersteller-Befragung Anwendung der Norm DIN EN Sieht der medizinische Verwendungszweck die Nutzung eines Alarmsystems vor? Ja Nein Wurde die Norm DIN EN beim Herstellungsprozess angewendet? Ja Nein Wird von den Systemkomponenten eine Alarmmeldung über das EDV-Netzwerk abgesetzt? Ja Nein Kommentar Sobald ein Alarmsystem genutzt wird, muss auf das Netzwerk vertraut werden und Abläufe/Pläne müssen existieren, die bei einem Netzausfall / Netzwartung aktiv werden. Z.B. gegenseitige Information von geplantem / spontanem Ausfall.

43 Risikoentscheidungen abklären mittels Hersteller-Befragung Welche Risiken entstehen im Rahmen der zweckbestimmungskonformen Nutzung des MP bei Ausfall des EDV-Netzwerks? Welche Risiken entstehen im Rahmen der zweckbestimmungskonformen Nutzung durch den Anschluss des MP / Systems an das EDV-Netzwerk, wenn das Netzwerk nicht die erwartete Dienstgüte liefert? Bitte nennen Sie hierzu einzeln die Risiken, je nach Schutzziel der Norm a) Sicherheitsziel Schutz (Safety) b) Sicherheitsziel Effectiveness (Wirksamkeit) c) Sicherheitsziel Daten- und Systemsicherheit (Data- and Systemsecurity) Kommentar Aussagen für den Netzwerkadministrator, wie genau das Netzwerk mit dem Produkt in Einklang zu bringen ist.

44 Risikoentscheidungen abklären mittels Hersteller-Befragung Nennung der erforderlichen Kommunikationsbeziehungen damit das MP / System im Netzwerk betrieben werden kann. Hierzu zählen auch die Kommunikationsbeziehungen, die für eine Fernwartung notwendig sind. HL7 PACS Hinweis: Eine Kommunikationsbeziehung besteht dabei aus den folgenden Angaben: 1. Absende-System 2. Zielsystem 3. Protokoll und Zielport 4. Kommentar Absicherung Produkt 1 vor Produkt 2 Produkt 1 Firewall Produkt 2

45 Risikoentscheidungen abklären mittels Hersteller-Befragung Nennung der besonderen Charakteristika für das Netzwerk konform IEC Welche Spezifika muss das Netzwerk erfüllen? (Hinweis: Bitte beschreiben Sie auch, ob durch Sie als Hersteller an das Netzwerk bestimmte Anforderungen in der Dienstgüte gestellt werden.) Multimedia / Voice over IP Alarmierung Ist gewährleistet, dass Alarmzustände mit hoher Priorität transportiert werden?

46 Risikoentscheidungen abklären mittels Hersteller-Befragung 119 kritische Sicherheitslücken in den letzten 4 Jahren: Bei vielen MP geben die entsprechenden Hersteller die Aktualisierungen gar nicht oder nur sehr zögerlich frei. ==> Konsequenzen für den Betrieb?

47 Risikoentscheidungen abklären mittels Hersteller-Befragung Wird die Software, die als MP Bestandteil des Vertrags ist, auf Systemen mit Windowsbetriebssystem eingesetzt? Falls die Frage mit Ja beantwortet wurde: Die Betriebssystemsoftware kann sofort nach Erscheinen eines Microsoft Updates aktualisiert werden. Es ist keine separate Freigabe durch die Q-Abteilung notwendig. Die Updates werden durch den Hersteller eingespielt. Die Betriebssystemsoftware wird bei Microsoft Updates der Kategorie critical und important durch die Q-Abteilung mit einer Verzögerung von max. 3 Wochen freigegeben. Updates der Kategorie moderate fließen in Softwareaktualisierungen ein, die mind. 1x jährlich herausgegeben werden. Die Updates werden durch den Hersteller eingespielt. Die Betriebssystemsoftware kann nicht aktualisiert werden.

48 Risikoentscheidungen abklären mittels Hersteller-Befragung Sind die Betriebssysteme der eingesetzten Systemkomponenten anfällig gegen Infektionen mit Netzwerk- Schadsoftware? Falls Frage 21 mit Ja beantwortet wurde: Frage 22a) wie können diese Systemkomponenten dagegen abgesichert werden? Frage 22b) wie können diese Infektionen der Systemkomponenten erkannt werden? Frage 22c) wie können diese Infektionen entfernt werden? Frage 22d) ist die Entfernung dieser Schadsoftware und die Wiederherstellung des zertifizierten Zustands Bestandteil des Service-Vertrags? Kommentar Der Betrieb eines Virenschutzsystems kann sehr aufwendig sein. Bei Betrieb eines krankenhausweiten Virenschutzsystems hängt die allgemeine Freigabe von Agenten/ Software/Patterns von den einzelnen MP ab. Erst wenn alle Hersteller diese freigegeben haben, kann global nachgezogen werden.

49 Unterscheidungskriterien für schlanke und aufwendige Risikomanagement-Prozesse Schlanker RM Prozess Anwendung: papiergestützt, im Dialog mit dem Hersteller Beispiele für Produktklassen viele Softwareprodukte Serversysteme Analysesysteme Systeme mit passiver Netznutzung [ ] Aufwendiger RM Prozess Anwendung RM-Gremium, Integration aller Beteiligten, Workshop Beispiele für Produktklassen Alarmierungssysteme Chirurgieroboter Navigationssysteme Zeitkritische Systeme Entscheidungsunterstützende Systeme Systeme mit aktiver Netznutzung [ ]

50 Einkauf neues MP Change RM Revision Fragebogen Hersteller Schlanker Prozess Erstrisikobewertung pending Detaillierter Prozess tatsächliche mögliche Sicherheit des medizinischen Netzwerks an diesem Standort Aufwand 3-4h Beurteilung nach Aktenlage Kein aktives oder nur sehr geringes Risiko i.s. der IEC 80001, sondern nur passives Risiko also Absicherung als Netzteilnehmer garantieren Entscheidung, ob lean process oder detail process offen Weitere Nachfrage beim Hersteller Bewertung Aktives Risiko i.s. der IEC 80001! Es ist ein detaillierter Risikomanagem entprozess notwendig unter Beteiligung der Stakeholder Aufwand 2-3 Tage Anwenderbeteiligung

51 Beispiel Switch Röntgengerät PACS Befundungsarbeitsplatz

52 Alle an einen Tisch bringen Betroffener Anwender IT-Netzwerk Administrator Pfleger IT PACS-Betreuer Arzt Hersteller Risikomanager Gefährdung der Effektivität Automatisches Log-Out Ausfall des Netzwerks Drucker hat kein Papier mehr

53 Veranstaltungen des FFM e.v. Tübingen, Hamburg, Konsequenzen und erste Schritte:

54 Vielen Dank für Die Aufmerksamkeit! Unischranke.jpg 54