Sichere dynamische Vernetzung in Operationssaal und Klinik

Transkript

1 Sichere dynamische Vernetzung in Operationssaal und Klinik Update 2015 Gefördert vom

2 Redaktion, Gestaltung und Produktion Jasmin Dell Anna, Irit Beß-Schanze, Julia Benzko, Eva-Maria Zeißig, Laura Weingarten, Klaus Radermacher, Björn Bergh, Lehrstuhl für Medizintechnik, RWTH Aachen Zentrum für Informations und Medizintechnik, Universitätsklinikum Heidelberg Lehrstuhl für Medizintechnik, RWTH Aachen Lehrstuhl für Medizintechnik, RWTH Aachen Lehrstuhl für Medizintechnik, RWTH Aachen Lehrstuhl für Medizintechnik, RWTH Aachen Zentrum für Informations und Medizintechnik, Universitätsklinikum Heidelberg Texte Jasmin Dell Anna Irit Beß-Schanze, Julia Benzko, Andreas Besting, Martin Kasparik, Raluca Pahontu, Christian Kücherer, Markus Birkle, Armin Janß, Johannes Dehm, Sascha Ermeling, Tim Hoppe, Andreas Zimolong, Max Rockstroh, Klaus Radermacher, Björn Bergh, Lehrstuhl für Medizintechnik, RWTH Aachen Zentrum für Informations und Medizintechnik, Universitätsklinikum Heidelberg Lehrstuhl für Medizintechnik, RWTH Aachen SurgiTAIX AG Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock Zentrum für Informations und Medizintechnik, Universitätsklinikum Heidelberg Zentrum für Informations und Medizintechnik, Universitätsklinikum Heidelberg Zentrum für Informations und Medizintechnik, Universitätsklinikum Heidelberg Lehrstuhl für Medizintechnik, RWTH Aachen VDE MedTech Synagon GmbH Synagon GmbH Synagon GmbH ICCAS Innovation Center Computer Assisted Surgery, Universität Leipzig Lehrstuhl für Medizintechnik, RWTH Aachen Zentrum für Informations und Medizintechnik, Universitätsklinikum Heidelberg Herausgeber Zentrum für Informations und Medizintechnik, Universitätsklinikum Heidelberg Lehrstuhl für Medizintechnik, RWTH Aachen Stand April 2015

3 1 Das Projekt Einleitung Im Gesundheitswesen findet seit geraumer Zeit ein Paradigmenwechsel weg von Insellösungen hin zu standardisierten, vernetzten Lösungen statt. Im Bereich der Medizin gibt es heutzutage den Wunsch nach einer immer stärkeren Vernetzung, besseren Integration und Kommunikation der eingesetzten Geräte und Komponenten. Im Bereich der medizinischen IT und dem Operationssaal ist dies bereits seit Jahren ein großes Thema. Stand heute bieten die Medizinprodukte nur eine eingeschränkte Interoperabilität. Was heißt das? Die (Daten-) Schnittstellen von Medizinprodukten sind nicht offen sondern proprietär, die Vernetzung bzw. der Datenaustausch ist meist nur zwischen Produkten eines Herstellers oder vordefinierten Produkten bestimmter Hersteller untereinander möglich, und auch das oft nur sehr eingeschränkt. Gemeinsame Standards für den Datenaustausch und die Vernetzung einzelner Medizinprodukte untereinander, sowie mit angrenzenden IT-Systemen, fehlen. Gleichzeitig bergen aufeinander nicht abgestimmte Medizinprodukte erhebliche Fehlbedienungsrisiken. Wesentlich für die eingeschränkte Flexibilität der Vernetzung ist die Problematik des Risikomanagements, da die Betreiber in der Verantwortung sind, wenn diese Medizinprodukte in Eigenherstellung untereinander vernetzen und in Verbindung mit IT-Systemen einsetzen. Ein weiteres Problem stellt die Sicherheit dar. Die heutigen Medizinprodukte sind ein großes Risiko für die IT-Netze, da es oft keinen oder nur einen sehr eingeschränkten Malware-Schutz gibt. Um Betreibern sowie Anwendern eine flerxible Geräteauswahl zu ermöglichen, ist ein standardisierter Interoperabilitätsansatz für die Integration von Medizingeräten und medizinischen IT-Systemen notwendig. Die wesentlichen Mechanismen für eine sichere, dynamische und interoperable Integration von Medizingeräten untereinander, und mit angrenzenden medizinischen IT-Systemen, sollen im Rahmen des vom Bundesministerium für Bildung und Forschung (BMBF) geförderte Leuchtturmprojekt OR.NET erarbeitet und exemplarisch realisiert werden. Univ. Prof. Dr. med. Björn Bergh Sprecher ZIM Univ. Prof. Dr.-Ing. Klaus Radermacher Koordinator meditec

4 2 Das Projekt Kernziele von OR.NET Eine standardisierte Interoperabilität für alle Medizingeräte und IT-Systeme. Die Betreiber können unabhängig von der Kopplung der Medizingeräte ihre Kaufentscheidung treffen und somit zur freien Marktentwicklung beitragen. Sichere Medizinprodukte, bzw. Lösungen und Produkte, mit denen die Medizinprodukte ohne Zusatzaufwand in die Krankenhaus-Netze integriert werden können. Sichere Bedienung durch Optimierung der Mensch-Maschine- Interaktion (MMI). Zulassung von Kombinationen von Medizinprodukten und IT- Systemen über definierte Architektur- und Schnittstellenstandards, die den Betrieb flexibel vernetzbarer modularer Systeme mit einem in der klinischen Praxis umsetzbaren Risikomanagement ermöglichen. Die 46 Projekt- und 23 assoziierten Partner bilden ein interdisziplinäres Konsortium aus klinischen Anwendern und Betreibern, Wissenschaftlern, Herstellern, Standardisierungsorganisationen und regulierenden Stellen, dem in den drei Jahren Projektlaufzeit ein Gesamtbudget von ca. 18,5 Mio. Euro zur Verfügung steht, wovon rund 15 Mio. Euro aus Bundesmitteln gefördert werden. Sprecher des Projektkonsortiums ist Univ.-Prof. Dr. med. Björn Bergh, Direktor des Zentrums für Informations- und Medizintechnik (ZIM) am Universitätsklinikum Heidelberg. Koordinator und Stellvertretender Sprecher ist Univ.- Prof. Dr.-Ing. Klaus Radermacher, Leiter des Lehrstuhls für Medizintechnik im Helmholtz-Institut für Biomedizinische Technik der RWTH Aachen. Das Projekt gliedert sich in sechs fachliche Teilprojekte (TP), die wiederum in kausal zusammenhängende Arbeitspakete (AP) unterteilt sind. Die Teilprojekte gliedern sich grob in Management, Entwicklung und Anwendung. Deren Aufgaben bestehen darin, die Ziele und Aufgaben des Projektes zu erarbeiten und umzusetzen. Diese sind im Einzelnen: TP1: Projektmanagement Leitung: Irit Beß-Schanze, ZIM, Universitätsklinikum Heidelberg TP2: Entwicklung der Gesamtarchitektur Leitung: Dr. Frank Portheine, SurgiTAIX AG TP3: Prüfung und Umsetzung der Zulassungsfähigkeit Leitung: Armin Janss, RWTH Aachen TP4: Entwicklung von Betreibermodellen Leitung: Dr. Andreas Zimolong, Synagon GmbH TP5: Standardisierung Leitung: Johannes Dehm, VDE TP6: Aufbau von Demonstratoren Leitung: Max Rockstroh, ICCAS Leipzig Die Aufgaben des Projektmanagements sind dabei strategisches Management, Entscheidungsfindung und Konfliktlösung sowie operatives Management. Daneben wird auch das Finanzmanagement zentraler Geldmittel für teilprojektübergreifende Maßnahmen (u.a. Workshops, Projekttreffen, Beirat, ggf. Unteraufträge zur Erstellung von Informationsmaterialien, zur Organisation von

5 3 TP 1 Projektmanagement Aktuelle Mitglieder des OR.NET-Beirates sind: Dr.-Ing. Wolfgang Lauer, BfArM, technischer Direktor Abteilung Medizinprodukte Dr. Julian Goldman, CISE Advisory Committee at NSF Dr. Max Skorning, Fachgebietsleiter Patientensicherheit, Medizinischer Dienst des Spitzenverbandes Bund der Kranken kassen e.v. (MDS) Hans-Peter Bursig, ZVEI Zentralverband Elektrotechnik- und Elektronikindustrie e.v., Kompetenzzentrum Gesundheitswirt schaft Stefan Vollmer, Bundesamt f. Sicherheit in der Informationstechnik, Referat S 25 Dr. Maureen Baker CBE, Clinical Director for Patient Safety, NH, UK Workshops oder Messeinformationsständen zum Projekt) sowie die Koordination bei ggf. notwendigen Umschichtungen von Ressourcen in Absprache mit den Partnern und dem Projektträger von Teilprojekt 1 durchgeführt. Außerdem werden auch das Monitoring des Projektfortschritts und die Rückkoppelung in die Gesamtprojektkoordination sowie die Verbreitung der Ergebnisse übernommen. Um dies alles umzusetzen wurden verschiedene Strukturen zur Unterstützung geschaffen. Das Gesamtprojekt wird durch einen übergeordneten Lenkungskreis vertreten, in dem alle strategischen und organisatorischen Belange des Projekts behandelt und koordiniert werden. Im Lenkungskreis sind die gewählten Sprecher des Medical Board (PD Dr. Michael Czaplik, Klinik für Anästhesiologie, Universitätsklinikum, RWTH Aachen), des Operator Board (Dr. Armin Will, Stabsstelle Informationstechnologie, Universitätsklinikum Schleswig Holstein) und des Industrial Board (Dr. Cord Schlötelburg, VDE/ DGBMT) sowie die Teilprojektleiter vertreten. Ein Beirat, bestehend aus unabhängigen Experten unterschiedlicher Fachrichtungen und Interessenverbände, unterstützt den Lenkungskreis beratend. Interessierte Institutionen aus Forschung, Klinik, Industrie und sonstige Organisationen können als assoziierte Partner ohne Förderung in das Projekt eingebunden werden. Im Zuge dessen wurde ein standardisiertes Aufnahmeverfahren etabliert. Auf diesem Wege wurden bisher 23 assoziierte Partner in das Projektkonsortium aufgenommen. Interessenten für eine assoziierte Partnerschaft können über die -adresse info@ornet.org Informationsmaterial anfordern. Im Wechsel finden halbjährlich öffentliche und interne Statusmeetings des Projektes OR.NET statt. Daneben hat sich OR.NET auf internationalen Konferenzen und Messen präsentiert. Beispiele sind hierfür die Medica 2012, 2013 und 2014, die conhit 2013 und 2014, CARS 2013 sowie die GMDS Neben der Arbeit in nationalen und internationalen Standardisierungsgremien sollen die Präsenz auf internationalen Tagungen sowie Veröffentlichungen zu den Projektergebnissen eine internationale Standardisierung und Etablierung der in Deutschland entwickelten Technologien strategisch unterstützen. Nur wenn dies gelingt können die Risiken für die beteiligten industriellen Partner reduziert und ein (wirtschaftlicher) Erfolg mittel- und langfristig erzielt werden.

6 4 TP 2 IT-Integration/Vernetzung im OP Ziel und Herausforderung des Teilprojekts Das Teilprojekt zwei adressiert technische Fragen und Herausforderungen im Bereich Interoperabilität, Sicherheit, Dynamik und Vernetzung von Medizingeräten untereinander sowie mit angrenzenden IT-Systemen. Besondere Beachtung findet dabei, dass sich die Anforderungen an Kommunikationstechnologien seitens der IT-Systeme und seitens der Medizingeräte stark unterscheiden und daher neue Ansätze zur übergreifenden Integration entwickelt werden müssen. Grundlage zur effizienten Zusammenarbeit der beteiligten Partner sind eine gemeinsame Wissensbasis und der Kommunikationsaustausch zwischen allen Arbeitspaketen. Die wesentliche Herausforderung neben der konzeptionellen Lösung ist die hohe Komplexität im Bereich der medizintechnischen Geräte und Informationssysteme sowie die Koordination der vielen beteiligten Partner. Aktueller Stand und Ergebnisse TP2 gliedert sich in acht Arbeitspakete und weitere Fokusgruppen, in deren Rahmen Lösungen für die jeweiligen Fragestellungen erarbeitet werden. Grundlage für jegliche technischen Lösungen sind tragfähige Anforderungen. Diese wurden in Zusammenarbeit mit Klinikern und technischen Projektpartnern erhoben. Darüber hinaus wurden weitere Anforderungen aus dem Projektantrag, der Kommunikationsmatrix und den diesen zugrundeliegenden Schlüsselindikatoren dokumentiert. Ausgehend von diesen Anforderungen wurde eine Gesamtarchitektur erarbeitet, die relevante Vorarbeiten der Projekt-Partner berücksichtigt. Dazu wurden zunächst die existierenden Vorarbeiten im Rahmen abgeschlossener Forschungsprojekte durch die Projektpartner präsentiert und miteinander verglichen. Ausgehend vom Design-Prinzip einer Service-Orientierten Architektur (SOA) wurde eine Gesamtarchitektur mit den notwendigen Komponenten und den zu verwendenden Technologien in zahlreichen Workshops entworfen und abgestimmt. Die wesentlichen Merkmale dieser Architektur sind die Netzwerktrennung zwischen medizinischen Informationssystemen und dem OP-Netz mit den darin befindlichen Medizingeräten, die Berücksichtigung von Echtzeitkommunikation sowie die Modellierung aller Geräte und übermittelten Daten in einem einheitlichen Datenmodell. Medizinprodukte werden über eine Middleware untereinander und mit den medizinischen Informationssystemen verbunden. Die Middleware besteht aus mehreren verteilten Softwarekomponenten. Innerhalb dieser Middleware sind alle zur Vernetzung bzw. Integration notwendigen Funktionen angesiedelt. In ihrer Gesamtheit werden diese als Open Surgical Platform (OSP) bezeichnet. Ihre Komponenten kommunizieren über das Open Surgical Communication Protocol (OSCP). Die Kommunikation der Geräte untereinander sowie die Übermittlung der wesentlichen Datenklassen der Informationssysteme, wie Patienten- und Auftragsdaten, erfolgen über das Kommunikationsprotokoll OSCP. Bei der Protokolldefinition müssen Sicherheit und ein durchgängiges semantisches Datenmodell berücksichtigt werden. Dabei steht die Modellierung der Medizinprodukte hinsichtlich der zu übertragenden Daten und die Beschreibung der Funktionsmerkmale von Geräten im Vordergrund.

7 5 TP 2 IT-Integration/Vernetzung im OP Die Fokusgruppe Sicherheit erarbeitet notwendige Sicherheitskonzepte auf unterschiedlichen Ebenen, damit nicht nur die Patientensicherheit, sondern auch die Datenintegrität und das Vermeiden von Fehlbedienungen jederzeit sichergestellt ist. Ein wesentlicher Aspekt der Gesamtarchitektur ist die Vernetzung von echtzeitfähigen Medizinprodukten. Die Echtzeitfähigkeit von Medizinprodukten kann durch den Einsatz von zwei getrennten Kommunikationskomponenten hersteller- und gerätespezifisch realisiert werden. Aus den Anforderungen für echtzeitfähige Übertragung von Daten wurde ein Konzept zur Einbindung von nicht-echtzeit-diensten und Geräten über den sogenannten Konnektor-MP realisiert. Dadurch können bestehend Medizingeräte mit Echtzeitanforderungen über sogenannte Funktionsmodule in einen OR.NET Kommunikationsverbund aufgenommen werden, ohne dass eine Modifikation des Geräts notwendig ist. So können existierende Geräte auch weiterhin verwendet werden. Die Integration der Medizinprodukte mit den medizinischen IT- Systemen basiert auf einer eigenständigen Komponente, dem Konnektor IS. Bei der Festlegung der Funktionalität des Konnektor IS wurden die für das Projekt relevanten Systeme und Datenströme analysiert. Danach erfolgte die differenzierte Betrachtung der zur Anwendung kommenden Nachrichtentypen. Der Konnektor IS übersetzt und übermittelt Patienten- und Auftragsdaten aus der Klinik-IT an die Geräte im OP-Netz. Mittels einer weiteren Komponente, dem Device Observation Reporter, können Messwerte und andere Gerätedaten an klinische Informationssysteme übermittelt werden. Der sichere Betrieb von Verbünden von vernetzten Geräten im OP stellt die Benutzer vor die Herausforderung, diese Verbünde zu verwalten: Die Verfügbarkeit von benötigten Geräten und Diensten muss ermittelt werden, Geräte müssen bestimmten Behandlungssituationen und Patienten zugeordnet werden, Aus fälle und Probleme müssen erkannt und dem Benutzer mitgeteilt werden. Diese Aufgabe wird von einer eigenen Komponente in OR.NET übernommen, dem Kontext-Manager. OR.NET gestattet neben OSCP auch die Verwendung von anderen Kommunikationsprotokollen. Betrachtet werden dabei vor allem DICOM und HL7 Version 2. OSCP erhebt nicht den Anspruch, diese weit verbreiteten Protokolle zu ersetzen. Stattdessen werden dedizierte Gateways spezifiziert, die den Betrieb der DICOM- und HL7-Protokolle trotz der Netztrennung von OP-Netz und Klinik- Netz ermöglichen. Um Herstellern eine Interkonnektivität mit dem OSCP Protokoll zu erleichtern wird im Rahmen des Projekts eine Software-Bibliothek implementiert. Diese ermöglicht die Verwendung von OSCP auf den Medizinprodukten mittels einfach zu verwendenden Software- Schnittstellen. Im Projekt werden derzeit zwei unterschiedliche Implementierungen verwendet, die interoperabel gestaltet werden sollen und an die unterschiedlichen Softwareumgebungen auf den Geräten angepasst sind. Die dabei anfallenden Entwicklungsarbeiten und entstehenden Komponenten werden in Entwicklungs- und Testlaboren an den Standorten Heidelberg und München in definierten Integrationsszenarien auf ihre Konsistenz, Funktionalität und Interoperabilität hin geprüft. Die Bedienung des Gesamtsystems und der einzelnen Geräte findet über eine zentrale Bedienstation statt. Dazu werden neuartige Konzepte und Strategien im Bereich Mensch-Maschine-Interaktion entwickelt und umgesetzt. Ein wichtiger Aspekt hierbei ist die Bildschirmaufteilung, um dem Bediener Informationen darzustellen. Dabei wurden in einer ersten Untersuchung im Bereich der Neurochirurgie Daten zum Informationsfluss und ihrer Art gesammelt. Eine mögliche Anordnung wäre z.b. die Unterteilung in verschiedenen

8 6 TP 2 IT-Integration/Vernetzung im OP Bereiche, wie z. B. eine Statuszeile mit einer Geräteliste (aktiv/ inaktiv), eine Anzeige des Patientenzustandes in kondensierter Form sowie die Kombination von Anzeigen der verschiedenen Geräte dahinter. Des Weiteren werden hier Konzepte zu intelligenten Alarmen erarbeitet. Ausblick Im Teilprojekt zwei laufen neben der Fertigstellung der Konzepte zahlreiche Entwicklungsarbeiten. Bis zum Sommer 2015 werden die Kernkomponenten der OSP, die Konnektoren MP und IS, verfügbar sein sowie die OSCP Schnittstellen hinsichtlich deren Kompatibilität, Datenintegrität und Interoperabilität innerhalb OR.NET getestet. Gegen Ende des Projekts sollen im Rahmen eines projektinternen Connectathons die jeweiligen Mikro- und Makrointegrationsprofile getestet werden, um die Interoperabilität der beteiligten Geräte und Informationssysteme sicherzustellen. Interaktion von OR.NET Teilnehmern

9 TP 3 Zulassungsfähigkeit 7 Hintergrund Komplettlösungen integrierter Operationssysteme, die von einem Anbieter mit der CE-Kennzeichnung versehen werden, unterliegen einem von diesem Anbieter zu verantwortenden Risikomanagement und Usability-Engineering Prozess. Die dynamische Vernetzung von unterschiedlichen Geräten verschiedener Hersteller mit deren Hardware- und Softwarekomponenten stellt eine völlig neue Situation dar und wirft u.a. juristische Fragen der Zulassungsfähigkeit auf. Hierbei müssen schwerpunktmäßig der Usability-Engineering Prozess nach DIN EN ISO und das Risikomanagement nach DIN EN ISO (technisch sowie human-zentriert) sowie die Methodik der Validierung von Softwarekomponenten, welche über ein Netzwerk kommunizieren, überdacht und neu konzipiert werden. Ziel ist es, eine technisch realisierbare und juristische eindeutig abgeklärte modulare Gesamtzulassungsstrategie zu finden, welche einerseits eine Zulassung von dynamisch vernetzungsfähigen Medizinprodukten für die Hersteller ermöglicht. Ferner müssen Verfahren und Werkzeuge zur Unterstützung des Zulassungs- und auch des Betriebsprozesses für Hersteller und Betreiber bereitgestellt und standardisiert werden. Herausforderung Die Herausforderung in diesem Teilprojekt besteht darin, über die Definition von applikationsspezifischen Anwendungsszenarien und hierbei relevanten Gerätepaarungen und Systemkonfigurationen als Gesamtsystem die Problematik der Zulassung von modularen Teilsystemen mit offenen Schnittstellen als Komponenten integrierter Gesamt-OPs zu betrachten und zu lösen. Die Schnittstelle zwischen Gerätepaarungen hat je nach Zweckbestimmung im Nutzungskontext und Komplexität der Funktionalität große Auswirkungen auf die Risikobeherrschung als Teil des Risikomanagements und der dazugehörigen Dokumentation. Hierbei sind Risikomanagement- und Usability-Engineering-Prozess integral zu behandeln. Insbesondere das Zurverfügungstellen, Steuern und Anzeigen von Gerätefunktionen durch Ein- und Ausgabekomponenten anderer Hersteller ist zulassungstechnisch detailliert zu betrachten und zu bewerten. Das Anbieten neuer Funktionalitäten, die erst durch eine Vernetzung möglich werden, bedeutet im Rahmen des Zulassungsprozesses unter Umständen das Erfüllen neuer Anforderungen durch eine Einstufung in eine andere (höhere) Risikoklasse. Speziell das Steuern anderer Geräte wird mit Blick auf das Medizinproduktegesetz und die gültigen Klassifizierungsregeln für Software als Anwendungsbeeinflussung angesehen (Anhang 9, Regel 2.3, Richtlinie 93/42 EWG): Software, die ein Produkt steuert oder dessen Anwendung beeinflusst wird in die Risikoklasse des gesteuerten Gerätes eingeordnet. Im Rahmen des Risikomanagements müssen Hersteller und Betreiber in die Lage versetzt werden, die Risiko- und Usabilityanalysen der Einzelkomponenten bei der flexiblen Integration über offene Schnittstellen ebenfalls modular in eine Gesamtrisiko- und Usabilitybewertung einzubeziehen. Hierfür müssen Werkzeuge und Standards entwickelt werden, die den neu zu konzipierenden Zulassungsprozess modularer Systeme unterstützen. Insbesondere bei der Human-Risikobewertung entstehen durch die Kombination von Einzellösungen und den hiermit verbundenen Interaktionen zusätzliche Risiken. Aktueller Stand/Ergebnisse Vor diesem Hintergrund stehen in Teilprojekt 3 folgende Aspekte im Fokus der Entwicklung und Evaluierung: Zulassungsstrategien und rechtliche Aspekte für offene Systeme Service- und Geräteprofile zum modularen Risikomanagement User Interface Profiles und Human-Risikomanagement Werkzeuge und Methoden zum Nachweis sicherer Systeme Damit bei einer zukünftigen offenen Vernetzung nicht vollständig unbekannte Geräte miteinander verbunden werden ist es nötig, herstellerunabhängige Standards zu definieren, die sowohl formal beschrieben und dokumentiert sind, als auch auf ihre Sicherheit geprüft werden können. Die Entwicklung solcher Standards erfolgt derzeit auf Basis von Service- und Geräteprofilen (siehe Tabelle). Dies ermöglicht zum einen eine herstellerunabhängige

10 8 TP 3 Zulassungsfähigkeit Kommunikation einander unbekannter Geräte, zum anderen aber auch eine Risikoabschätzung für Hersteller und Betreiber hinsichtlich eines Einsatzes im Gesamtsystem. OR.NET Erweiterte Service- und Geräteprofil Zweckbestimnente oder dieser Service zur Verfügung? Soll gesteuert mung und Funktionalitäten Technische dungsszenario? Spezifikationen Welche Funktionalität stellt dieses Gerät, diese Kompo- oder nur angezeigt werden? Welche Dienste werden angeboten? Welche Dienste werden genutzt? Wie kommuniziert das Gerät/der Service mit Benutzern und Geräten? Wie ist der Nutzungskontext für ein definiertes Anwen- Protokoll, Datenmodellversion, Datentypen, Beschreibung der Funktionen über: MDS-Descriptor (Model-No, Model name, Serial No, Manufacturer, friendly name, UDI) Profile User Interface Eigenschaften der Ein- und Ausgabegeräte sowie Interaktionselemente (Größe, Position) und deren Abhängigkeiten, Kritikalitäten der einzelnen Funktionen, Gruppierungs- und Positionierungsinformationen zu den einzelnen Interaktionselementen, etc., Anwendungsszenario-spezifisch definierte Umgebungsbedingungen bzw. zu berücksichtigende externe leistungsbegrenzende Faktoren Um alle Aspekte eines sicheren und gebrauchstauglichen Verbundes im Vorfeld der eigentlichen Zulassung berücksichtigen zu können ist es darüber hinaus zweckmäßig zu definieren, welche Profilklasse von Geräten mit bestimmten anderen Profilklassen in einem definierten applikationsspezifischen klinischen Anwendungsszenario verknüpft werden darf (Profilklassen und Anwendungsszenarien). Hierzu müssen diese Anwendungsszenarien einschließlich ihrer notwendigen und hinreichenden klinischen Variabilitäten aus Sicht von klinischen Experten und Betreibern validiert und standardisiert werden. Im Rahmen des Projektes findet dies prototypisch in enger Zusammenarbeit mit den klinischen Partnern bzw. dem Medical Board und Operator Board statt. Auf dieser Basis wird den Herstellern die Zulassung vernetzungsfähiger Medizinprodukte für definierte Anwendungsszenarien durch den Nachweis der Kompatibilität über eine Verifikation und Validierung in entsprechenden standardisierten Testszenarien ermöglicht. Gegenmaßnahmen für Vernetzungsrisiken Netzwerkanforderungen Welche Risiken eines Gerätes beeinflussen ein anderes Gerät / anderen Service in einem speziellen Nutzungskontext des Anwendungsszenarios? Welche Risiken entstehen aus der Vernetzung (Anforderungen an den Vernetzungspartner)? Welche Gegenmaßnahmen wurden vom Hersteller gegen die Vernetzungsrisiken ausgewählt? Wie können die Gegenmaßnahmen (z.b. Zeitstempel, Zweikanaligkeit) dem Vernetzungspartner mitgeteilt werden? Welche Risiken entstehen am/durch das Netzwerk (Anforderungen an Betreiber)? Quality of Service-Anforderungen (Latenzzeit, Jitter, Paketverlustrate, Datenübertragungsrate) Die Evaluation des entwickelten Konzeptes einer Zulassungsstrategie auf Basis von Geräte- und Serviceprofilklassen in Zusammenarbeit mit unabhängigen benannten Stellen bestätigt bisher, dass der derzeit verfolgte Lösungsansatz nach aktuell gültigem Recht und aktueller Zulassungspraxis erfolgsversprechend ist. Die Entwicklung und Evaluation für weitere Gerätepaarungen und Anwendungssysteme ist Gegenstand laufender Arbeiten in enger Zusammenarbeit mit den Teilprojekten 2, 4 und 5. Neben den Medizinprodukten selber werden derzeit die aktiven

11 9 TP 3 Zulassungsfähigkeit Komponenten der Vernetzungs-Infrastruktur, die sog. Middleware, zulassungstechnisch betrachtet. Die Middleware enthält nach heutigem Stand u.a. OR.NET Specifications sowie OR.NET Geräte-/Service-/Komponenten- und User-Interface-Profile. Sie muss qualitätsgesichert entwickelt, aber nicht als Medizinprodukt zugelassen werden, da sie selber keine medizinische Zweckbestimmung erfüllt und nicht unter den Begriff von Zubehör laut MPG fällt. Virtuelle Geräte (Virtuelles Standardgerät und gerätespezifische MDIB) jedes einzelnen Herstellers können z.b. in einer Testsuite getestet und validiert werden, damit entsprechend MPBetreibV 2 ihre Eignung mit Bezug auf die Zweckbestimmung und die Sicherheit von Patienten und Anwendern nachgewiesen wird. Derzeit sieht das Konzept für eine Testumgebung zur Validierung der Software und Komponenten der Hersteller wie folgt aus: 1. Der Hersteller entwickelt einen Test-Simulator, mit dem im Netzwerk Szenarien getestet werden können. Er wird z.b. durch eine benannte Stelle oder ein akkreditiertes Prüfinstitut zertifiziert 2. Etablierung zentraler Testlabore, die Hersteller-unabhängig generische Tests mit verschiedensten Geräten durchführen können. Diese Testlabore anthalten Simulatoren der verschiedenen teilnehmenden Hersteller. Testszenarien und -labore werden ebenfalls zertifiziert oder akkreditiert Zur Umsetzung einer modularen technischen Risikoanalyse müssen zwei wesentliche Aufgaben erfüllt werden: zum einen die Entwicklung von Methoden für die Risikoanalyse offener integrierter Systeme, und zum anderen die Identifikation neuer Risiken, die sich aus Aspekten der Vernetzung und Fernsteuerung von fremden Systemen ergeben, und deren Auswirkungen auf den Zulassungsstatus und die Zweckbestimmung nach dem Medizinproduktegesetz. Im Rahmen der Entwicklung einer Human-Risikoanalyse für offene vernetzte Systeme wird das Konzept der User Interface Profiles entwickelt. Neben einer potentiellen Verbesserung der therapeutischen Qualität durch erhöhte Flexibilität in der Wahl der Komponenten und Geräte bringt die Vernetzung anderseits neue Potentiale humaninduzierter Risiken für Patienten, Anwender und Dritte mit sich. Bereits in heutigen klinischen Arbeitssystemen sind Chirurgen und OP-Pflegepersonal häufig mit ergonomisch unzureichenden Arbeitsbedingungen konfrontiert. Geeignete Bedienschnittstellen für integrierte Arbeitsstationen müssen daher konsistent umgesetzt und in Bezug auf definierte Anwendungsszenarien bewertet werden können, so dass die Funktionen der vernetzten Medizingeräte dem Anwender kontextspezifisch angeboten werden können. Mit Hilfe von User Interface Profilen (UI-Profile) werden die prozessspezifischen Grundinteraktionen und deren Charakteristika (z.b. Kritikalitäten von Funktionen, Gruppierung- und Positionsinformationen für GUI Interaktionselemente, etc.) sowie die Umgebungsbedingungen im OP mit den verschiedenen Ein-/Ausgabegeräten und Bedienelementen in Verbindung gesetzt und deren Abhängigkeiten herausgearbeitet, um eine funktionsorientierte Human-Risikobewertung sowie Gestaltung einer zentralen Bedienschnittstelle mit Hilfe einer zugehörigen systematischen UI-Integrationsmethodik zu ermöglichen. Die User Interface Profile erweitern dabei den Standard der ISO (Universal Remote Console) im Hinblick auf die MMI-spezifische Geräte- bzw. Funktionsbeschreibung insbesondere um sicherheitsrelevante Aspekte, die gerade zur Entwicklung zuverlässiger und sicherer Medizinprodukte notwendig sind. Die Evaluierung des Konzeptes der UI Profile sowie der UI-Integrationsmethodik wurde bereits am Beispiel der Gerätepaarung eines OP-Mikroskops und eines Ultraschall-Schneidegerätes sowie der Integration zahlreicher generischer GUI Designs von Einzelgeräten (US-Dissektor, OP-Tisch Ansteuerung, US-Knochenmesser, Integrierter Fußschalter, HF-Gerät, Endoskopielicht und -kamera sowie Insufflator) in ein zentrales Chirurgie-Bediencockpit erfolgreich durchgeführt. Derzeit werden die User Interface Profiles in maschinenlesbare Sprache übersetzt und in das OR.NET Datenmodell integriert.

12 10 TP 3 Zulassungsfähigkeit Im Rahmen des Teilvorhabens wurden unterschiedliche Anwendungsbeispiele in Zusammenarbeit mit den klinischen Partnern erarbeitet und diskutiert, sowie klinische Szenarien abgeleitet. Die entwickleten Zulassungsstrategien werden zurzeit anhand der benannten Gerätepaarung evaluiert und kontinuierlich an neue Entwicklungen und Ergebnisse angepasst. Darüber hinaus werden Werkzeuge zur Unterstützung des Test- und Verifikationsprozesses unter Berücksichtigung etablierter Methoden der Softwaretechnik spezifiziert Parallel dazu werden Methoden entwickelt, mit denen die Software von Medizinprodukten oder zentralen Server-Einheiten zur Laufzeit der vernetzten Prozesse überprüfen kann, ob die angeschlossenen vernetzten Geräte sich konform zu den vorgegebenen Spezifikationen und Protokollen verhalten. Dies stellt eine wesentliche Entlastung und Absicherung der Betreiber dar, die die komplexen vernetzten Systeme sonst nicht technisch überprüfen könnten hinsichtlich ihrer Eignung gemäß MPBetreibV 2. abgestimmt werden. Auch das Einbringen der Ergebnisse des Teilprojektes 3 ( Zulassungsfähigkeit ) in die Notified Bodies Recommendation Group ist in diesem Kontext bereits ein wichtiger Schritt zur internationalen Umsetzung und Standardisierung. Ausblick Im Rahmen der Zulassungsrealisierung wird das Geräte- bzw. Serviceprofil mit den für eine Zulassung notwendigen Dokumenten verglichen und notwendige Erweiterungen im Rahmen einer Konformitätserklärung in Zusammenarbeit mit unabhängigen Prüfinstituten ermittelt. Zudem ist die Integration weiterer technischen Geräte- und UI-Profile in das OR.NET Datenmodell Gegenstand laufender Arbeiten. Ferner sollen die in OR.NET erarbeiteten Konzepte im Sinne einer Internationalisierung beispielsweise in Workshops zu Zulassungsstrategien in den USA u.a. mit der FDA

13 11 TP 4 Standardisierung Herausforderung des Teilprojekts Derzeit wird der Markt von Medizingeräten im Operationssaal von herstellerspezifischen Lösungen weniger Anbieter dominiert, das heißt, eine kleine Zahl von Herstellern verwendet firmeneigene Kommunikationsprotokolle und Vokabularien für den Datenaustausch. Diese sind für Interessierte nicht einzusehen. So haben Mitbewerber nicht direkt die Möglichkeit, sich mit bestehenden Geräten dieser Hersteller im Operationssaal (OP) und in der Klinik zu vernetzen. Eine derartige Einschränkung bei der Beschaffung neuer Geräte verhindert einen unabhängigen Markt. Dem lässt sich durch zwei Maßnahmen entgegentreten: zum einen, die Entwicklung von weltweit gültigen Standards, die den Leistungserbringern ermöglichen, innerhalb einer Klinik Produkte verschiedener Anwender interoperabel einzusetzen, und zum anderen eine vereinfachte Inbetriebnahme, die dem Leistungserbringer auch den Betrieb eines solchen heterogenen Operationssaal- oder Klinik Netzes erlaubt. Auf diese Weise kann ein echter Markt entstehen, bei dem die Qualität der Produkte in den Vordergrund gerückt werden kann. Die in der Entwicklung befindlichen ergänzenden Teile der Normenfamilie IEEE bzw. DIN EN ISO definieren die Bestandteile eines Systems, mit dem es möglich ist, Daten zwischen unterschiedlichen medizinischen Geräten auszutauschen. Zusätzlich hat der Hersteller einen Freiraum, um sich durch Zusatzfunktionalitäten, Qualität und Ausgestaltung des Produkts im Markt von anderen Mitbewerbern abzuheben. Insgesamt übernimmt diese Normenfamilie deshalb eine wichtige, wettbewerbsfördernde Stellung. Aktueller Stand und Ergebnisse Der heutige Stand zeigt, dass der in OR.NET entwickelte und eingereichte Standardisierungsentwurf zur Kommunikation der im Operationssaal und in der Klinik betriebenen Medizinprodukte von den zuständigen Normungsorganisationen angenommen wurde. Dieser Entwurf zur Standardisierung füllt die Lücken der wenigen geeigneten veröffentlichten Standards in diesem Bereich. Er ergänzt die Normenfamilie IEEE Medizinische Informatik Kommunikation patientennaher medizinischer Geräte, die eine Reihe von Standards für die medizinische Gerätekommunikation bereitstellt. Als Grundlage setzt der Entwurf auf den OR.NET Vorschlag Open Surgical Communication Protocol (OSCP) auf. Dieser verweist normativ auf eine serviceorientierte Architektur (SOA) unter Verwendung der IEEE Nomenklatur. Weiterhin bindet dieser Entwurf das amerikanische Projekt Medical Device Plug-and-Play (MDPnP) ein, das in eine ähnliche Richtung zielt. Unter der Projektbezeichnung IEEE wird das sogenannte Medical Devices Profile for Web Services (MDPWS) be- Die Ausschreibung von nach IEEE spezifizierten Produkten trägt dazu bei, bei der Geräteausstattung von beispielsweise Operationssälen Kosten zu sparen, ohne Abstriche bei der Qualität der medizinischen Versorgung hinnehmen zu müssen.

14 12 TP 4 Standardisierung arbeitet. Es stellt eine Erweiterung des Devices Profile for Web Services (DPWS) für die Anforderungen an die Datenübertragung im Zuge einer Medizingerätevernetzung dar. Das Domänen, Informations- und Service-Modell (IEEE ) ermöglicht einerseits die semantisch interoperable Beschreibung von Medizingeräten und des aktuellen Zustands, andererseits werden die Möglichkeiten zur Interaktion definiert, wie etwa lesender bzw. schreibender Zugriff oder Benachrichtigungen nach dem Abonnement-Prinzip. Die Unabhängigkeit zwischen der Datenübertragung und der Geräterepräsentation wird durch die IEEE sichergestellt, welche ein Binding zwischen den beiden oben genannten Teilstandards definiert. Neben diesen medizingerätespezifischen Standards gibt es andere, die im Umfeld des Operationssaals eine Rolle spielen: Im klinischen Umfeld hat sich der Digital Imaging and Communications in Medicine (DICOM) -Standard weltweit für den Austausch medizinischer Bilder etabliert, und HL7 für administrative Daten (z. B. Patientenstammdaten, Versicherungsdaten) und Befunde. Beide Standards stellen Informationen zur Verfügung, die auch im Die Standardisierungs-Plattform und ihre internationalen Partner OP eine Rolle spielen, und können über entsprechende Gateways genutzt werden. Die weltweite Initiative Integrating the Healthcare Enterprise (IHE) hat sich zum Ziel gesetzt, den Informationsaustausch von Computersystemen im Gesundheitswesen zu verbessern. Ausgehend von Anwendungsfällen (Use Cases) wird in sogenannten Integrationsprofilen beschrieben, wie verschiedene Informationssysteme und Geräte in definierten Transaktionen bestimmte Daten austauschen. Für die Spezifikation des Datenaustausches in den Transaktionen wird auf Standards wie beispielsweise DICOM und Health Level 7 (HL7) zurückgegriffen. Softwarehersteller können sich im Rahmen von sogenannten Connectathons bescheinigen lassen, dass ihr Softwareprodukt zu einem oder mehreren speziellen Akteuren bestimmter IHE - Integrationsprofile konform ist. Der Betreiber von Informationssystemen kann nun in Softwareausschreibungen fordern, dass das gewünschte Produkt bei einem IHE Connectathon erfolgreich in einer bestimmten Rolle (als ein bestimmter Akteur) eines Integrationsprofils getestet worden sein soll. Dies ermöglicht den Betreibern, in ihren Kliniken Softwareprodukte und Geräte unterschiedlicher Hersteller einzusetzen, die im Rahmen der spezifizierten Transaktionen problemlos miteinander kommunizieren. Für die Integration von Gerätemesswerten (Device Observations) in die klinische Dokumentation existieren von IHE in der Domäne Patient Care Devices bereits solche Integrationsprofile, die auf HL7 basieren. Derzeit werden Vorschläge für solche Integrationsprofile entwickelt, die die Kommunikation zwischen den Medizingeräten auf der Basis der neuen Standards aus der IEEE Familie definieren.

15 13 Ausblick Die Normenfamilie IEEE mit ihren Festlegungen in den Teilen Service-oriented Medical Device Exchange Architecture and Protocol Medical Device Profile for Web Services Domain Information & Service Model for Service- Oriented Point-of-Care Medical Device Communication stellt die wesentlichen Vorrausetzungen für eine interoperable Kommunikation bereit. Aber auch durch die entstehenden IHE- Profile wird die interoperable Kommunikation mit der Klinik gefördert. Die entstehende Standard-Architektur muss an allen kritischen Stellen Zugriffsrechte und Datenschutz sicherstellen, wie dies auch für andere Teile des Krankenhauses der Fall ist. Entsprechende Konzepte sind bei den Ergänzungsnormen zur IEEE Normenfamilie bereits berücksichtigt worden. Die Ergänzungen zur IEEE Familie nutzen den Leistungserbringern, in dem die Geräte nach der Erstinbetriebnahme via Plug&Play einsatzbereit und registriert sind. Damit werden Betriebszustände wie Normalzustand, Service, Fehler, Gesamtbetriebsdauer, Verfügbarkeit etc. des Gerätes erfasst und überwacht. So lassen sich künftig die medizinischen Prozesse in OP und Klinik transparenter und effektiver gestalten. Eine ausführliche Dokumentation der vergangenen, aktuellen und zukünftigen Standardisierungsaktivitäten findet sich in der Roadmap Sichere dynamische Vernetzung in Operationssaal und Klinik, Ausgabe 2015.

16 14 TP 5 Betreibermodelle Hintergrund Die Betreiber von Gesundheitseinrichtungen sind in der Pflicht, die geltenden Vorschriften und Normen bei der Anwendung von Medizinprodukten einzuhalten. Von diesem Grundsatz wird auch im Zusammenhang mit vernetzten Medizinprodukten nicht abgewichen. Zur Aufrechterhaltung der rechtlichen und technischen Integrität sowie der Funktionsfähigkeit des Gesamtsystems werden die Betreiber von Gesundheitseinrichtungen Maßnahmen ergreifen müssen, welche ggf. dezidierten technischen Informationen der Medizinproduktehersteller bedürfen. Da Medizinproduktehersteller jedoch die Bereitstellung solcher Informationen im Vorfeld nicht für notwendig erachten oder ggf. aus marktstrategischen oder anderen Gründen ablehnen könnten, birgt dies prinzipiell Konfliktpotenzial. Betreiber Anwender Gibt die Betriebsprozesse vor Gemeinsame Festlegung des Nutzungskontextes Änderungen Gibt die Anwendungsprozesse vor EDV & Medizintechnik Medizin- produkte- Hersteller Der Einsatz von Anti-Virensoftware ist bspw. eine klassische Maßnahme zum Schutz des Gesamt-IT-Systems vor Schadsoftware bzw. Malware. Damit die Wirksamkeit der Software gewährleistet werden kann, müssen die Viren-Pattern, d.h. der Datenbestand des Virusscanners, der die codespezifische oder musterhafte Struktur aller bekannten Viren enthält, stets aktuell gehalten werden. Hierzu publizieren die Hersteller von Anti-Virensoftware regelmäßig Updates, in der Regel mehrmals täglich. Dagegen könnte auf einem Medizinprodukt ein aktiver Virenscan zu unvorhergesehenen oder nicht abgestimmten Zeitpunkten die Stabilität des Systems beeinträchtigen, hohe Res- sourcen binden oder über ein falsches Klassifizieren von für die Funktionalität des Medizinproduktes notwendiger Software als Schadsoftware zu Systemfehlern führen. Diesem Risiko kann nur das Risiko eines Virus-Befalls entgegengesetzt werden, wobei dabei das Schadensausmaß nicht nur für das Medizinprodukt betrachtet werden darf, sondern die Auswirkungen eines Virus-Befalls für das gesamte Netzwerk sowie der eingebundenen Geräte betrachtet werden muss. Herausforderung im Teilprojekt Medizinprodukte-Hersteller und Betreiber legen gemeinsam den Nutzungskontext für ein vernetztes Medizin- und Informationstechnik-System fest. Die Hersteller von Medizinprodukten geben dabei die Betriebsprozesse vor, der Betreiber definiert die Anwendungsprozesse. Im Teilprojekt TP5 Betreibermodelle soll grundsätzlich untersucht werden, welche Voraussetzungen und Bedingungen für einen Interessensausgleich zwischen Medizinprodukteherstellern und Betreibern notwendig sind und wie dieser umgesetzt werden kann. Dies erfordert u.a. auch, dass die Medizinproduktehersteller nach erfolgter Inbetriebnahme in das Risikomanagement nach DIN EN eingebunden bleiben. Im Rahmen von TP5 sollen daher die für den Betrieb der vernetzten Medizinprodukte notwendigen Aktivitäten identifiziert und als Leistungsscheine dokumentiert werden. Darüber hinaus soll geklärt werden, welche Formen der Organisation sowohl für interne als auch für externe Betriebsleistungen geeignet sind, um den sicheren, zuverlässigen und gleichermaßen wirksamen Betrieb der Medizinproduktenetzwerke sicherzustellen. Dabei sollen sowohl entsprechende Geschäftsmodelle mit den erforderlichen technischen Randbedingungen als auch begleitende Maßnahmen zum Datenschutz identifiziert werden. Die Fa. Synagon hat die Teilprojektleitung im TP5 für die Entwicklung der Betreibermodelle übernommen. Aktueller Stand In Abstimmung mit den Teilprojekten IT-Integration und Vernetzung im OP und Zulassungsfähigkeit wurden zunächst die für die

17 15 TP 5 Betreibermodelle Betreibermodelle relevanten Referenzsysteme sowie die zu betrachtenden Anwendungsfälle identifiziert. Auf Basis der Anforderungen an die Mitwirkungspflichten des Medizinproduktelieferanten /-herstellers aus der DIN EN wurden in sogenannten Fokusgruppen Prozesse für den Betrieb vernetzter Medizinprodukte entwickelt. Diese wurden anhand der klinischen Anwendungsszenarien (Wirbelsäulen-OP, Laparoskopischer Eingriff und HNO Eingriff) zu Betreibermodellen zusammengefasst. Dabei wurde für die Anwendungsszenarien auf die Ergebnisse aus TP2 zurückgegriffen, wo Anwendungsszenarien aus über 120 definierten Use-cases entwickelt wurden. Die Beschreibung der Betriebsprozesse umfasst u.a. eine Beschreibung des IT-Netzwerks des Betreibers sowie eine Beschreibung des angestrebten vernetzten Systems. Ausgehend von der Zweckbestimmung und den Anforderungen an das IT-Netzwerk wurden im Rahmen der Risikobetrachtung aus der Vernetzung resultierende Gefährdungssituationen identifiziert. Die entsprechenden Prozesse zur Erstinbetriebnahme und zum Betrieb des Systems wurden aus den der Risikoanalyse entsprungenen Risikokontrollmaßnahmen abgeleitet. Anschließend erfolgt die Abbildung der Betriebsprozesse in Leistungsscheine. Die Leistungsscheine sind eine Vereinbarung zwischen einem MIT-Service Provider und einem Kunden über den Umfang der vom Provider angebotenen Leistung zum Betrieb des vernetzten Systems. Für die Leistungsscheine sind insbesondere solche Aktivitäten von Bedeutung, welche regelmäßig (ausgelöst durch Ereignisse oder Zeitpunkte) anfallen. Gegenwärtig werden zu den einzelnen Aktivitäten geeignete Prozessindikatoren bzw. Leistungskennzahlen definiert, um eine Quantifizierung der Ergebnisqualität sowie eine hierauf aufsetzende zielorientierte Steuerung zu ermöglichen. Die Erarbeitung der Themen erfolgt in kleinen Fokusgruppen, welche die Sachverhalte aus konkreten Blickwinkeln beleuchten. Eine Fokusgruppe setzt sich im Kern aus einem Betreiber und ein bis zwei Herstellern zusammen. Die Fokusgruppen werden bedarfsweise durch Berater der Fa. Synagon unterstützt. Zu den Leistungsscheinen werden entsprechend marktgängige Vertragsmuster in ihren Grundzügen entworfen, welche geeignet sind, die Leistungsscheine in Auftrag zu geben. Dabei werden insbesondere standardisierte Vertragsmuster auf Anwendbarkeit untersucht, beispielsweise die Ergänzenden Vertragsbedingungen für die Beschaffung von IT-Leistungen (EVB-IT), welche bei Beschaffungen durch öffentliche Auftraggeber anzuwenden sind. In den Vertragsmustern sollen neben dem Leistungsumfang auch Sanktionsmöglichkeiten bei Leistungsstörungen, Vertragslaufzeiten und Ausstiegsklauseln spezifiziert werden. Fokusgruppe 1 Betriebsprozesse Leistungsmerkmale Betriebsprozesse Leistungsmerkmale Leistungsschein Leistungsschein Leistungsschein Ausblick Fokusgruppe 2 Berater Betreiber Hersteller Betriebsprozesse Leistungsmerkmale Systembeschreibung Leistungsschein Leistungsschein Leistungsschein Katalog Leistungsscheine Der erstellte Leistungsschein-Katalog wird im weiteren Projektverlauf im Zuge eines kontinuierlichen Verbesserungsprozesses auf seine Verallgemeinerbarkeit überprüft und an den entsprechenden Stellen überarbeitet. Hierzu wird eine Marktübersicht zur Erbringbarkeit der Leistungsscheine erstellt. Die Leistungsscheine wie auch die Vertragsmuster sollen mit am freien Markt platzierten Dienstleistern diskutiert werden, um die Anwendbarkeit der Leistungsscheine und Vertragsmuster schärfer zu greifen. Fokusgruppe 3 Leistungsschein Leistungsschein Leistungsschein Fokusgruppe n Betriebsprozesse Leistungsmerkmale Leistungsschein Leistungsschein Leistungsschein

18 16 TP 6 Demonstrator Ziele und Herausforderung des Teilprojekts Im Verlauf des Projekts werden Demonstratoren mit unterschiedlichen Funktionsumfängen realisiert. Entsprechend der Anwendungsbereiche, Kernkompetenzen und Forschungsfelder der Projektpartner entstehen deutschlandweit insgesamt fünf Demonstratoren. Die Demonstratoren dienen sowohl den Projektpartnern als auch interessierten assoziierten Partnern als Entwicklungs- und Testumgebung. Gemeinsam mit den Ärzten der am Projekt beteiligten Fachkliniken und den Klinikbetreibern sollen die im Rahmen des Projekts entwickelten Konzepte und Technologien in einem möglichst realitätsnahen Umfeld auf Ihre Praxistauglichkeit für die klinische Routine geprüft werden. Weiterhin werden die Demonstratoren genutzt, um der interessierten Fachöffentlichkeit die Projektergebnisse anschaulich zu präsentieren. Grundsätzlich sind alle Demonstratoren hinsichtlich ihrer technischen Grundausstattung und Funktionalität möglichst offen und austauschbar angelegt. Die Demonstratoren unterscheiden sich sowohl durch die betrachteten wissenschaftlichen Fragestellungen als auch in den demonstrierten klinischen Anwendungsfällen. Teildemonstratoren entstehen an den Projektstandorten Aachen, Lübeck und München. Sie unterstützen vor allem die konkreten Entwicklungsarbeiten der beteiligten Hersteller. Jeder Teildemonstrator hat auf Grund der Kompetenzfelder der beteiligten Projektpartner eine entsprechende Spezialisierung. Die SOA-basierte Kommunikation steht am Standort Lübeck im Mittelpunkt. Es wird die Funktion der zugrundeliegenden Kommunikations-Architektur im Allgemeinen und in besonderen Situationen untersucht. Hierzu zählen zum Beispiel die Etablierung des Geräteverbundes oder die Initialisierung von Interaktionen, sowie geeignete Rückfallszenarien bei Ausfall einzelner Geräteoder Infrastruktur-Komponenten. Ein weiterer Schwerpunkt ist die Untersuchung von Komponenten mit integrierter Laufzeitverhaltens-Verifikation. Außerdem werden in Lübeck unterschiedliche Lösungen zur Anbindung bereits existierender vernetzter Systeme an das OR.NET System getestet. Der Standort München fokussiert sich auf Medizingeräte mit Echtzeitanforderungen. Hierbei handelt es sich um Medizingeräte, die Daten verlässlich in definierten Zeitschranken verarbeiten müssen, um den sicheren und intuitiven Betrieb zu gewährleisten. Es soll untersucht werden, wie durch Datenfusion von Medizingeräten neue Funktionen ohne Neuverkabelung geschaffen und wieder entfernt werden können, ohne dabei die Funktion der Geräte selbst zu beeinflussen. Am Innovationszentrum für computerassistierte Chirurgie (IC- CAS) der Universität Leipzig entsteht ein Integrationsdemonst- Der Forschungsschwerpunkt in Aachen liegt auf der Nutzer- und nutzungsgerechten Mensch-Maschine-Integration, sowie der Erarbeitung eines modularen Vernetzungs- und Risikomanagements. Als weiterer Schwerpunkt werden Fragestellungen im Bereich der Zulassung integrierter OP-Systeme untersucht. In Aachen entsteht in diesem Kontext ein Demonstrator für integrierte OP-Systeme für die neurochirurgische Wirbelsäulenchirurgie und die laparoskopische Chirurgie. Außerdem wird ein Teildemonstrator entwickelt, der zahlreiche Fragestellungen aus Anästhesie und Tele-Anästhesie addressiert.

19 17 TP 6 Demonstrator rator. Darin werden Systeme und Konzepte zahlreicher Partner in einem OR.Net-fähigen Demonstrator-OP eingebunden, um die Flexibilität und Kompatibilität der dynamischen Vernetzung von Medizingeräten und Software zu präsentieren. Ein besonderer Fokus des Integrationsdemonstrators in Leipzig liegt auf der Generierung eines Mehrwerts für Chirurgen, OP-Personal und klinikweites Management aus dynamischer Vernetzung in Operationssaal und Klinik. Die integrierten Konzepte und Systeme werden an klinischen Anwendungsfällen aus der Kopf-Hals-Chirurgie in Laborstudien evaluiert. Dabei werden sowohl technische Aspekte der Kommunikationsinfrastruktur untersucht als auch klinische Fragestellungen in Zusammenarbeit mit den klinischen Partnern betrachtet. Am Standort Heidelberg entsteht ein kompletter integrierter OP als Gesamtdemonstrator. Als Integrationstechnologie kommen die in OR.NET entwickelten Konzepte und Komponenten zum Einsatz. Somit kann im Gesamtdemonstrator der komplette OR.NET Technologie Stack in einem realitätsnahen klinischen Umfeld auf seine Praxistauglichkeit hin überprüft werden. Im Rahmen von Analysestudien werden in simulierten Operationen mit realen OP-Teams die entwickelten Bedienschnittstellen und -konzepte auf ihre Praxistauglichkeit überprüft. Weiterhin wird geprüft wie sich die OR.NET Systeme in eine bestehende IT-Infrastruktur eines Krankenhauses integrieren lassen. Aktueller Stand und Ergebnisse Aktuell werden an den Demonstratorstandorten die Kommunikationsszenarien unter Beteiligung der Medizingeräte- und Softwarehersteller aufgebaut. Entsprechend der Ausrichtungen der Standorte sind die beteiligten Industriepartner jeweils an einem oder mehreren Demonstratoren beteiligt. Dort werden die klinischen Szenarien zum Ende der Projektlaufzeit mit den neuartigen, dynamisch vernetzten Geräten und Softwareprodukten realisiert. Die klinischen Szenarien bilden Anwendungsfälle aus HNO- Chirurgie, Neurochirurgie sowie Viszeralchirurgie exemplarisch ab. Die relevanten Abläufe der Eingriffe, sowie die angelagerten Prozesse, wie zum Beispiel das Einschleusen des Patienten inklusive der Verteilung der Patientendaten auf die unterschiedlichen Geräte, sind in umfangreichen Storyboards formuliert. Durch Simulationen und Laborstudien unter realitätsnahen Bedingungen auf Basis solcher Storyboards können komplexe medizinische und technische Abläufe vergleichbar, anschaulich und praxisnah dargestellt und untersucht werden. Ausblick Die Demonstratoren werden in den kommenden Monaten vollständig aufgebaut und in Betrieb genommen. Dazu werden aktuell noch Anpassungen an der Infrastruktur der Standorte vorgenommen, die benötigten Geräte beschafft, erweitert und integriert. Abschließend wird eine Evaluation in den Demonstratoren in Leipzig, Aachen und Heidelberg mit den beteiligten Fachkliniken und den Klinikbetreibern stattfinden. Bereits jetzt werden an allen Standorten wissenschaftliche Fragestellungen bearbeitet. Die Integration der Komponenten und Realisierung der Demonstratoren findet in enger Zusammenarbeit mit den anderen Arbeitspaketen statt. Die Erfahrungen aus der Entwicklung der Demonstratoren fließen direkt in die Arbeitspakete, die sich mit der Standardisierung sowie der Weiterentwicklung der Schnittstellen und des Datenmodells beschäftigen, zurück.

20 18 Partner Anbieter integrierter OPs Karl Storz GmbH & Co. KG Richard Wolf GmbH Hersteller von Medizingeräten/Medizintechnik-Komponenten SurgiTAIX AG Inomed Medizintechnik GmbH Localite GmbH KLS Martin Group Möller-Wedel GmbH Ziehm Imaging GmbH Söring GmbH (IT-)Dienstleister UTK - UniTransferKlinik GmbH Synagon GmbH MedPlan Engineering GmbH MT2IT GmbH & Co. Anbieter von Medizinsoftware VISUS Technology Transfer GmbH/ R & D Anbieter von IT-Lösungen für Vernetzung MEDNOVO Medical Software Solutions GmbH how to organize Forschungsinstitute Fraunhofer-Institut MEVIS Fraunhofer-Institut FOKUS Technische Universität München - Lehrstuhl MIMED im Bereich Mechatronik RWTH Aachen - Lehrstuhl für Medizintechnik RWTH Aachen - Lehrstuhl für Medizinische Informationstechnik RWTH Aachen - Universitätsklinikum Abteilung Integrierte Teleanästhesiologie Universität zu Lübeck - Institut für Telematik Universität zu Lübeck - Institut für Softwaretechnik und Programmiersprachen Universität zu Lübeck - Institut für Medizinische Informatik Universität Leipzig - ICCAS OFFIS - Institut für Informatik e.v. Universität Rostock - Institut für Angew. Mikroelektronik u. Datentechnik TU München - Lehrstuhl für Automatisierung und Informationssysteme TU München - Institut für Informatik, Robotics and Embedded Systems TU München - Minimal-invasive Interdisziplinäre Therapeutische Intervention Universität Augsburg - Forschungsstelle für Medizinprodukterecht Fachkliniken Uniklinik Tübingen - Universitätsklinik für Urologie Uniklinik Tübingen - Universitätsklinik für Radiologie Uniklinik Tübingen - Universitäts-Frauenklinik Klinikum Rostock - Klinik für Anästhesiologie und Intensivmedizin Uniklinik Schleswig-Holstein - Klinik für Chirurgie Uniklinik Leipzig - Klinik für Herzchirurgie Uniklinik der RWTH Aachen - Klinik für Anästhesiologie Uniklinik der RWTH Aachen - Orthopädische Klinik Uniklinik der RWTH Aachen - Neurochirurgie Klinik-IT-Abteilungen und Betreiber Uniklinikum Heidelberg - Zentrum für Informations- und Medizintechnik Rhön-Kliniken AG Uniklinik Schleswig-Holstein - IT-Planung und -Strategie Standardisierung/Normung/Zulassung Verband der Elektrotechnik Elektronik Informationstechnik Deutsches Institut für Normung e. V./ Normenausschuss Medizin (NAMed) IHE Deutschland e. V. qcmed GmbH Assoziierte Partner steute Schaltgeräte Gmbh & Co.KG, GADV Gesellschaft für Automatisierung mit Datenverarbeitungsanlagen mbh, Fritz Stephan GmbH Medizintechnik, BOWA electronic GmbH Co. KG, HEBUmedical GmbH, Maquet GmbH & CO. KG, Infoteam Software AG, Synedra information technologies GmbH, Trumpf Medizin Systeme GmbH & CO. KG, Weber Instrumente GmbH & Co. KG, Healthcare IT Solutions GmbH, CeMPEG Sicherheit und Gebrauchstauglichkeit von Medizinprodukten e.v., TEKNO-Medical-optik-Chirurgie GmbH, Docs in Clouds GmbH, Tritec Elektronic AG, Drägerwerke AG & Co. KGaA, Healthcare Consulting GmbH, HL7 Deutschland e.v., AKTORmed. GmbH, ICT AG, ESCTAIC e.v., Beger Design, UL International Germany GmbH

21 19 Partner