DOOP DOOP DOOP

Medizingerätevernetzung

Einleitung

Das vorliegende DOOP White Paper „Medizingerätevernetzung“ beschreibt Leistungsangebote eines zukünftigen DOOP Dienstleiters, der Kunden aus der medizintechnischen Industrie Unterstützung bei der Entwicklung medizinischer Software für die interoperable Vernetzung von Medizingeräten untereinander und deren Kopplung an klinische Informationssysteme unterstützt.

Um Daten aus Medizingeräten klinikweit nutzen zu können, sind Hersteller von Medizingeräten gefordert, eine möglichst auf Standards beruhende Geräteschnittstelle für die Einbindung in klinische IT-Netzwerke bereitzustellen. Improvisierte und nicht standardisierte Vorgehensweisen bei der Kopplung von Medizingeräten an klinische Informationssysteme bergen das Risiko von Systemausfällen durch nicht beherrschbare Datenflüsse über das Netzwerk. Systemausfälle können die Behandlung von Patienten stören und führen somit zu einem erhöhten Sicherheitsrisiko für den Patienten. Der im Jahr 2010 entstandene IEC 80001-1 Standard ´Application of risk management for IT-networks incorporating medical devices -- Part 1: Roles, responsibilities and activities´ soll mit seiner Anwendung die Sicherheit von Patienten fördern und den Schutz deren Privatsphäre gewähren. Hersteller von Medizingeräten sehen sich mit der Anforderung konfrontiert, den Betreibern von klinischen IT-Netzwerken Geräteschnittstellen anzubieten, die sich komfortabel in klinische IT-Netzwerke integrieren lassen und zugleich Patientensicherheit und Datenschutz beim Datenaustausch garantieren. Technische Vorgaben für die sichere Umsetzung der Geräteschnittstellen im Netzwerk und für die Systemarchitektur der vernetzten Systeme gibt es
nicht.

Ausgangsbasis für die zu entstehenden DOOP Dienstleistungsangebote sind Aktivitäten in dem laufenden DOOP Vorhaben (www.doop-projekt.de). Im DOOP-Projekt werden Lösungsstrategien für ein einheitliches Plug-and-Play-artiges Konzept zur Medizingerätevernetzung erarbeitet und in enger Zusammenarbeit mit verschiedenen innovativen Medizintechnikfirmen umgesetzt.

Das vorliegende White Paper „Medizingerätevernetzung“ beschreibt DOOP Leistungspakete, die Hersteller der Medizintechnikbranche bei der Entwicklung standardkonformer Software unterstützen, Medizingeräte entlang des medizinischen Workflows technisch und logisch miteinander zu verknüpfen.

DOOP Programm

Abbildung 1 illustriert die Vernetzung der DOOP Verbundpartner aus Universität und Industrie (Stand 2013). Aus der Zusammenarbeit der DOOP Partner sollen konkrete Dienste entstehen, die Industriepartner nutzen, um medizinische Softwareprodukte für vernetzte Medizinsysteme zu entwickeln.

Abbildung 1: Partner des DOOP Netzwerks (Stand 2013) und angebotene Leistungspakete

Abbildung 1: Partner des DOOP Netzwerks (Stand 2013) und angebotene Leistungspakete

Zu den in DOOP angebotenen Leistungspaketen gehören:

  • Modellierung und Softwareentwicklung von Webservice (WS) Schnittstellen für Medizingeräte
  • Aufbau einer WS Testumgebung für vernetzte Medizingeräte
  • Schnittstellenbeschreibung und -dokumentation vernetzter Medizingeräte mit Bezug zu Standards und gesetzlichen Regularien

DOOP Leistungspakete

(A) Webservice-Schnittstelle für Medizingeräte

Partner im DOOP Verbund verfolgen das Ziel, interoperable Webservice-Schnittstellen (WS-APIs) für Medizingeräte zu entwickeln, über die Patienten- und Gerätedaten im medizinischen ITNetzwerk ausgetauscht werden können. Konkretes Ziel ist es, medizinische Geräteprofile auf Basis von „Medical Device Profile Web Services (MDPWS)“ zu entwickeln und in simulierten Geräte-Netzwerken auf Interoperabilität und Konformität mit Standards und gesetzlichen Vorgaben zu überprüfen. Abb. 2 illustriert in sehr vereinfachter Weise die Vernetzung zweier Medizingeräte in
ihrer wechselnder Rolle als Client und Server, bzw. Provider und Consumer von Webdiensten.

Abbildung 2: Vernetzung zweier Medizingeräte unter Verwendung von standardisierten Medizingeräteprofile-Web-Schnittstellen (MDPWS)

Abbildung 2: Vernetzung zweier Medizingeräte unter Verwendung von standardisierten Medizingeräteprofile-Web-Schnittstellen (MDPWS)

Im Rahmen der laufenden DOOP Aktivitäten ist für die Vorgehensweise zur Konstruktion von Medizingeräteprofilen bereits ein White Paper entstanden1. In diesem Paper sind Schritte bis zur Erstellung von Web-Profilen beschrieben. Abb. 3 stellt die Arbeitsschritte dar, die für die Entwicklung bis hin zu lauffähigen Software für Webservice-Schnittstellen zu durchlaufen sind.

1 http://www.doop-projekt.de/vorgehensweise-zur-konstruktion-von-geraeteprofilen.html

Abbildung 3: Arbeitsschritte zur Softwareentwicklung einer lauffähigen Webservice-Schnittstelle für Medizingeräte

Abbildung 3: Arbeitsschritte zur Softwareentwicklung einer lauffähigen Webservice-Schnittstelle für Medizingeräte

Für die Entstehung medizinischer DOOP Softwaredienste in der Medizintechnik ist es notwendig, die Software entsprechend den Anforderungen aus der DIN EN Norm „Medizingeräte-Software - Software-Lebenszyklus-Prozesse (IEC 62304:2006) zu entwickeln. Die IEC 62304 unterscheidet folgende Entitäten zur Beschreibung der Bestandteile einer Software2:

Softwaresystem:
Ein Softwaresystem ist eine Sammlung von Softwarekomponenten, die so organisiert sind, dass spezifische Funktionen ausgeführt werden können.

Softwarekomponente:
Eine Softwarekomponente ist ein identifizierbarer Teil des Software Systems

Softwareeinheit:
Eine Softwareeinheit ist eine Softwarekomponente, die nicht weiter zerlegt wird.

Die gleiche Methodik empfiehlt sich bei der Entwicklung von Webservice-Schnittstellen für Medizingeräte. Zur Darstellung der Softwarearchitektur von Schnittstelle und Medizingerät werden üblicherweise UML („Unified Modeling Language“) -Diagramme verwendet. Unterschieden werden statische UML-Komponentendiagramme und dynamische UML-Sequenzdiagramme und UML-Aktivitätsdiagramme. Dazu werden für Medizingeräte therapeutische Funktionsgruppen (TFG) als Softwarekomponenten definiert. Die TFG unterteilen sich in therapeutische Funktionen
(TF1, TF2, …TFn), die als einzelne Softwareeinheiten betrachtet werden können. Das statische und dynamische Zusammenspiel der Softwarekomponenten (TFGs) und Softwareeinheiten (TFs) wird in UML-Diagrammen zur Beschreibung der Webservice (WS) Schnittstelle dargestellt und dokumentiert. Auf Basis des strukturierten Schnittstellendokuments wird gemäß Abb. 3, Schritt 2, Software für eine maschinell lesbare Form der WS-Schnittstelle erstellt. Die Softwareumsetzung in eine WS-Schnittstelle geschieht üblicherweise durch Verwendung des „Web-Service Description Language (WSDL)“. Auf Basis der dynamischen UML-Modellierungen entstehen anwendungsspezifische Kommunikationsprofile (Abb. 3, Schritt 3), die in maschinell lesbaren
Software Code in einer Laufzeitumgebung umgesetzt werden.

(B) Webservice Testumgebung vernetzter Medizingeräte

Um die Kommunikation der Gerätedaten zwischen zwei Medizingeräten zu testen, ist für die Konfiguration aus Abb. 2 eine Middleware-Testumgebung aufzubauen. Die Testumgebung ist so gestaltet, dass technische Spezifikationen von Use-Cases verifiziert und die Interoperabilität im Netzwerk überprüft werden kann. Der Einsatz von MDPWS Technologien im Medizingerätenetzwerk bedingt, dass die Testumgebung eine Middleware-Plattform darstellt, in
welche Eigenschaften und Funktionalitäten der Gerätedatenkommunikation integriert werden. Das „Institute of Standards and Technology (NIST)“ hat eine spezielle Testplattform entwickelt, in der die Konformität der Kommunikation von medizinischen Geräten und medizinischen Informationssystemen mit den HL7 und ISO-11073 Standards, sowie den IHE Profilen3 aus der IHE Domäne „Patient Care Devices“ getestet werden kann.4 Abbildung 4 illustriert die NIST Testumgebung und Systemkomponenten die eingesetzt werden, um den Datenaustausch von HL7
Nachrichten in einer IHE-PCD Domäne unter vorgegebenen semantischen Randbedingungen zu verifizieren.

2 Christian Johner: Basiswissen Medizinische Software, dpunkt.verlag, 2011, ISBN 978-3-89864-688-8

3 IHE - Integrating the Healthcare Enterprise, www.ihe.org

4 http://www.aami-bit.org/doi/abs/10.2345/0899-8205-45.3.249

Abbildung 4: Automatisierte NIST Testumgebung zur Validierung von HL7 Nachrichten unter vorgegebenen Randbedingungen

Abbildung 4: Automatisierte NIST Testumgebung zur Validierung von HL7 Nachrichten unter vorgegebenen Randbedingungen5

Realisiert wird eine Dienste-orientierte Middleware- und Entwicklungsumgebung, mit der die DOOP Partner ihre entwickelten MDPWS, bzw. ihre Medizingeräte-WS-Schnittstellen, testen und evaluieren können. Eingesetzt wird eine Middleware Architektur, die in anderen Forschungsverbünden, z.B. dem BMBF Verbundprojekt „OR.NET“ (www.ornet.org) entsteht. In einer höheren Ausbaustufe sind die Testsysteme in eine kommerzielle Softwareentwicklungsumgebung einzubinden, in der Entwicklungsprozesse gesteuert, Konformität nachgewiesen und
Dokumente für medizinische Software nach Vorgaben aus Standards und gesetzlichen Regularien
entstehen und gesteuert werden können6.

(C) Konforme Schnittstellen Dokumentation vernetzter Medizingeräte

Zur Entwicklung, Qualitätssicherung und Vermarktung medizinischer Software ist eine Vielzahl unterschiedlicher Konformitätsnachweise zu führen. Der Lebenszyklus medizinischer Software umfasst Konformitäten zu rechtlichen Rahmenbedingungen (z.B. zum Medizinproduktgesetz), zu Standards für das Qualitätsmanagement (ISO 13485), das Risikomanagement und die Risikoanalyse (ISO 14971, IEC 80001), das Management des Lebenszyklus medizinischer Software (IEC 62304), die Gebrauchstauglichkeit (IEC 60601-1-6, IEC 62366), die Kommunikation medizinischer Geräte
(ISO 11073) und zu Standards aus dem World Wide Web Consortium (W3C) für Web-basierte Software. Der aufzubauende DOOP Dienst „Konforme Dokumentation“ unterstützt Entwickler aus dem DOOP Verbund bei der Erstellung von technischen Dokumenten zur Erfüllung der regulatorischer Anforderungen medizinischer Software für die Vernetzung von Medizingeräten und die Ankopplung an ein „Middleware Gateway“. Der Schwerpunkt der Dokumentationsunterstützung liegt in Beiträgen zur Führung der Risikomanagementakte nach ISO 14971und IEC
80001 und in der technischen Dokumentation der Netzschnittstelle. medizinischer Geräte. Den Funktionalitäten, die sich durch den Austausch von Daten und Datenobjekten über die Schnittstelle ergeben, sind Zweckbestimmungen zuzuordnen, die einer Risikoanalyse zu unterziehen sind. Auf Basis der Risikoanalyse der Schnittstellen-Funktionalitäten von Medizingeräten im Netzwerk können Konsumer der Funktionalitäten im Netzwerk eigene Mehrwertdienste aus den vernetzten Medizingeräten erzeugen, deren Zweck zu bestimmen und dessen Risiko zu betrachten ist. Nur über die Festlegung der Zweckbestimmung des Mehrwertdienstes kann entschieden werden, ob der Mehrwertdienst ein medizinisches Softwareprodukt ist oder nicht. Bei der Vernetzung und Kombination von medizinischen Hardware und Software Systemen, z.B. im Operationsraum, können für die kombinierten Systeme aus vernetzten Medizingeräten und klinischen Informationssystemen folgenden Paragraphen aus dem MPG und Standards Orientierung bieten:

  1. Bei festgelegter Zweckbestimmung des Mehrwertdiensts im Netzwerk können sich die notwendigen Konformitätsbewertungsverfahren u.a. aus § 3, Abs. 10 und § 10, Abs. 1 und 2 des MPG ergeben.
  2. Die Klassifizierung des im medizinischen IT-Netzwerks angebotenen Dienstes geschieht u.a. nach § 13, Abs. 1 und Anhang 9 des MPG.
  3. Zur Erfüllung der Grundlegenden Anforderungen gemäß Anhang 1 MMD 93/42/EWG erweisen sich für kombinierte medizinische Softwaresysteme und Dienste u.a. der Einbezug der in Deutschland harmonisierten Standards DIN EN 62304:2007-03, DIN EN 62366/A1:2012-07 und DIN EN 80001:2011-11 als richtungsweisend.


Die DOOP Dienstleistungspakete (A) WS-Schnittstelle Medizingerät, (B) WS-Testumgebung und (C) Konforme Dokumentation sind in Abb. 5 als Leistungspakete dargestellt, mit denen Medizintechnikfirmen ihre Geräte vernetzen und an ein Gateway zum klinischen Informationssystem (nicht dargestellt) anbinden können.

5 John J. Garguilo, Sandra Martinez, and Maria Cherkaoui: A Standards-Based Testing Approach, AAMI BI&T Vol. 45
No 3, May/June 2011

6 http://www.parasoft.com/jsp/printables/IEC_62304_White_Paper.pdf?path=/jsp/products/article_reg.jsp

Abbildung 5: Schematische Darstellung der DOOP Leistungspakete für Medizingerätehersteller zur Vernetzung von Medizingeräten und deren Anbindung an ein Middleware Gateway (MG = Medizingerät; API = Programmierbare Geräteschnittstelle)

Abbildung 5: Schematische Darstellung der DOOP Leistungspakete für Medizingerätehersteller zur Vernetzung von Medizingeräten und deren Anbindung an ein Middleware Gateway
(MG = Medizingerät; API = Programmierbare Geräteschnittstelle)

DOOP Arbeitspakte „Medizingerätevernetzung“

Das zukünftige DOOP Leistungsangebot „Medizingerätevernetzung“ ist im Folgenden als Arbeitspakete und den dazugehörigen Tätigkeiten beschriebent. Die 3 Arbeitspakete, die der DOOP Dienstleister (Abb. 6, Symbol links) in enger Zusammenarbeit mit dem Medizintechnikhersteller (Abb.6, Symbol rechts) bearbeitet, entsprechen den bereits genannten Leistungspaketen:

  • AP100: Webservice Schnittstelle Medizingerät
  • AP200: Webservice Testumgebung vernetzter Medizingeräte
  • AP300: Konforme Schnittstellen Dokumentation

Die zunehmende Größe des Symbols für Medizingerätehersteller illustriert das zunehmende Engagement des Medizintechnikherstellers bei der Zusammenarbeit mit dem DOOP Dienstleister in der Produktentwicklungsphase.

Abbildung 6: Arbeitspakete für die DOOP Leistung „Medizingerätevernetzung“ AbAbbildung 5: Schematische Darstellung der DOOP Leistungspakete für Medizingerätehersteller zur Vernetzung von Medizingeräten und deren Anbindung an ein Middleware Gateway bildung

Abbildung 6: Arbeitspakete für die DOOP Leistung „Medizingerätevernetzung“

Abbildung 7: Tätigkeiten im Arbeitspaket „Webservice Schnittstelle Medizingerät“

Abbildung 7: Tätigkeiten im Arbeitspaket „Webservice Schnittstelle Medizingerät“

Anhand eines Fragebogens definiert der Hersteller die gewünschten Funktionalitäten und Anwendungen seines zu vernetzenden Medizingerätes. Dieser Fragebogen reflektiert die Art des Gerätes und kapselt die Funktionen, die vom Gerät ausgeführt werden können7. Aus den Anforderungen wird die Geräteschnittstelle modelliert. Bevorzugt soll die standardisierte und vereinheitlichte Modellierungssprache UML zum Einsatz kommen. Im Arbeitspaket AP110 entstehen Spezifikation, Konstruktion und Dokumentation von Software-Teilen und Systemen auf Basis der grafischen UML Beschreibung.

7 http://www.doop-projekt.de/vorgehensweise-zur-konstruktion-von-geraeteprofilen.html

Im Arbeitspaket AP120 werden die UML-Modelle in lauffähige Software umgesetzt. Aus den UML-Diagrammen des strukturierten Schnittstellendokuments entwickelt der DOOP Dienstleister Computer-lesbaren Softwarecode. Für die formale Schnittstellenbeschreibung wird die XMLbasierte WSDL (Web-Service-Description-Language) Sprache genutzt. Es entsteht ein maschinenlesbares WSDL Dokument (AP121) aus dem Schnittstellenmodell. Als mögliches Datenmodell kann das Domain Information Modell der IEC 11073 dienen, welches Medizingerät und physiologische Daten generisch beschreibt. In einem nächsten Arbeitsschritt wird das Dokument in einen MDPWS (Medical Device Profile Web Service) –Stack überführt (AP122). Der MDPWS Stack beruht auf eine Middleware-Spezifikation, wie sie gegenwärtig im BMBF Verbundvorhaben OR.NET entsteht8. Arbeitspaket AP130 widmet sich der Implementierung von Funktionseinheiten in Form von Softwarecode. Ergebnis ist eine WS-Schnittstelle mit Funktionalitäten, die den Anforderungen des Herstellers entsprechen (AP131). Herstellerneutral stellt sich die Aufgabe, aus dem spezifischen Funktionalitäten „Plug & Play“ fähige Funktionalitäten zu entwickeln, die sich an Standards und Profilen orientieren und den interoperablen Datenaustausch gewährleisten (AP132). Unter Nutzung einer integrierten Entwicklungsumgebung (IDE) wird der MDPWS-Stack in lauffähige Client/Server Software integriert (AP140)9.

Im Arbeitspaket AP200 „WS Testumgebung vernetzter Medizingeräte“ wird die gesamte Systemarchitektur betrachtet und Software bereitgestellt einzelne Komponenten des Systems gegen die technischen Spezifikationen zu testen. Die im AP210 entwickelte Middleware Testplattform dient der Überprüfung und Verifizierung von Daten, die als SOAP-Nachrichten vom Medizingeräte-Server zum konsumierenden Client verschickt werden. In AP220 werden Softwarekomponenten modelliert, mit denen der Datenaustausch zwischen Datenressourcen und Konsumenten der Daten getestet und nach Spezifikationen überprüft werden kann. Standardisierte Softwareentwicklungsprozesse, Datenmodelle und medizinische Datensprachen werden nach Eignung überprüft und eingesetzt. Nachweise sind zu führen, dass die entwickelte Software sich konform zu den üblichen Standards, wie HL7, DICOM, XML und IHE Profile, verhält.

WSDL ist eine Metasprache, mit deren Hilfe die angebotenen Funktionen, Daten, Datentypen und Austauschprotokolle eines Webservice beschrieben werden kann10. Im Arbeitspaket AP230 werden auf der Testplattform Routinen installiert, um die Konformität der verwendeten WSDL Spezifikationen zu überprüfen. Untersucht werden funktionelle Angaben zu den Schnittstellen, dem Zugangsprotokoll, Details zum „Deployment“, sowie alle notwendigen Informationen zum Zugriff auf den Service.

8 http://www.ornet.org

9 http://www.doop-projekt.de/vorgehensweise-zur-konstruktion-von-geraeteprofilen.html

10 http://de.wikipedia.org/wiki/Web_Services_Description_Language

Abbildung 8: Aufgaben im Arbeitspaket „Webservice Testumgebung vernetzter Medizingeräte“

Abbildung 8: Aufgaben im Arbeitspaket „Webservice Testumgebung vernetzter Medizingeräte“

Sowohl die Organisationen Continua Health Alliance11 als auch die IHE (Integrating the Healthcare Enterprise)12 orientieren sich bei der Verknüpfung von Medizingeräten und Vitaldatenmonitore mit medizinischen Informationssystemen an Semantiken, Standards und Modellen aus der Norm IEC 11073. In den Arbeitspaketen AP240 und AP250 wird die Konformität zu den 11073 Spezifikationen und Modellen, sowie zu den IHE-Domänen und Profilen überprüft. Das Arbeitspaket AP260 ist für den Konformitätsnachweis mit anderen Standards vorgesehen. Beispiele sind das Terminologie Mapping mittels dem IHE PCD Profile „Rosetta“ oder die Verwendung der in der Medizin systematisierten Nomenklaturen „SnowMed“.

Dem Arbeitspaket AP300 „Schnittstellendokumentation“ kommt im DOOP Dienstleistungsangebot besondere Bedeutung zu. Das Arbeitspaket unterteilt sich in die Risikobewertung der WS Schnittstelle (AP310) und in die Erstellung von Dokumenten für die Entwicklungsakte (AP320). Die Risikobewertung im AP310 umfasst Tätigkeiten zur Risikoanalyse der WS Schnittstelle (AP311), zur Bewertung des Risikos (AP312) und zur Risikovermeidung im Maßnahmenmanagement (AP313). Für medizinische IT-Netzwerke mit inkorporierten Medizingeräten gilt für das Risikomanagement die Prozessnorm IEC DIN-EN 80001-1, die im Arbeitspaket AP314 besonders behandelt wird. Entwicklungsprozesse unter Einbezug des 80001 Standards sollen der Minimierung von Komplexität und Risiko vernetzter Medizingeräte und deren Ankopplung an klinische Informationssysteme dienen. Der 80001 Standard beschreibt sowohl die Rolle der Medizintechnikhersteller als auch die Rolle des IT-Netzwerk-Betreibers im Krankenhaus. Prozessmanagement gemäß des 80001 Standards soll dem Betreiber im Krankenhäuser helfen, die Komplexität vernetzter Medizingeräte und Informationssysteme zu beherrschen, als auch die Hochverfügbarkeit der Systeme und Daten zuverlässig zu gewährleisten. Im AP314 geht es um den Nachweis, dass sowohl die Patientensicherheit gewährleistet ist als auch Richtlinien des Personenbezogenen Datenschutzes eingehalten werden. Die Prozessnormen 80001 für medizinische ITNetzwerke und 14971 für Medizingeräte lassen offen, welche Risikomanagement-Methoden zur Anwendung kommen. In der Praxis hat sich u.a. die „Failure Mode and Effects Analysis“ (FMEA) als praktisches Instrument herausgestellt, mit dem Schwachstellen, bzw. Risiken, frühzeitig identifiziert, Gegenmaßen dokumentiert, Fehler vermieden und technische Zuverlässigkeit maximiert werden kann13.

11 www.continuaalliance.org

12 www.ihe.net

13 http://www.medizin-edv.de/ARCHIV/Mit_ISO_IEC_80001_Komplexitaet_und_Risiko.pdf

Abbildung 9: Aufgaben und Tätigkeiten im Arbeitspaket „Schnittstellendokumentation“

Abbildung 9: Aufgaben und Tätigkeiten im Arbeitspaket „Schnittstellendokumentation“

Gantt-Chart zu DOOP Leistungspaketen und deren zeitliche Bearbeitung

Die untere Gantt-Chart Darstellung illustriert beispielhaft, wie eine DOOP Dienstleistung „Medizingerätevernetzung“ gemeinsam mit einem Hersteller von Medizingeräten aufgesetzt werden könnte. Die gesamte Projektdauer ist in diesem Beispiel für ca. 1.5 Jahr angesetzt. Abhängigkeiten der Arbeitspakete sind dargestellt.

Der DOOP Leistungsumfang im AP320 beinhaltet im Schwerpunkt Unterstützung bei der technischen Dokumentation zum Führen der Softwareentwicklungsakte (AP321) beim Hersteller sowie Beiträge beim Führen der Risikomanagementakte in Bezug auf die Einschätzung des technischen Risikos (AP322).

Abbildung 9: Aufgaben und Tätigkeiten im Arbeitspaket „Schnittstellendokumentation“

Das oben dargestellte DOOP Dienstleistungsangebot „Medizingerätevernetzung“ soll dem Medizintechnikhersteller zur Orientierung dienen, Anforderungen und Aufwand für die Entwicklung seiner vernetzten Medizingeräte abzuschätzen. Selbstverständlich werden die DOOP Leistungspakete an die individuellen Bedürfnisse des Medizintechnikherstellerkundens angepasst.

  • BioSkill
  • Braun
  • Carus
  • Dräger
  • Johneson
  • Localite
  • Möller Wedel
  • Olympus
  • Schmitz
  • Söring
  • IT UKSH

Netzwerkpartner