gms | German Medical Science

51. Jahrestagung der Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie

Deutsche Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie e. V. (gmds)

10. - 14.09.2006, Leipzig

DICOM Proxy zur Kommunikation von DICOM Objekten über Einrichtungsgrenzen

Meeting Abstract

Suche in Medline nach

  • Andreas Heldt - Fachhochschule Stralsund, Stralsund
  • M. Staemmler - Fachhochschule Stralsund, Stralsund

Deutsche Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie e.V. (gmds). 51. Jahrestagung der Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie. Leipzig, 10.-14.09.2006. Düsseldorf, Köln: German Medical Science; 2006. Doc06gmds382

Die elektronische Version dieses Artikels ist vollständig und ist verfügbar unter: http://www.egms.de/de/meetings/gmds2006/06gmds210.shtml

Veröffentlicht: 1. September 2006

© 2006 Heldt et al.
Dieser Artikel ist ein Open Access-Artikel und steht unter den Creative Commons Lizenzbedingungen (http://creativecommons.org/licenses/by-nc-nd/3.0/deed.de). Er darf vervielf&aauml;ltigt, verbreitet und &oauml;ffentlich zug&aauml;nglich gemacht werden, vorausgesetzt dass Autor und Quelle genannt werden.


Gliederung

Text

Einleitung

Proxy Dienste werden heutzutage für die am meisten genutzten Protokolle (http, ftp, POP3, etc.) in Verbindung mit einer Firewall angeboten. Aufgrund der Stellvertreterfunktion eines Proxy können einrichtungsinterne Informationen zu Systemen und Netzwerk gegenüber externen Kommunikationspartnern versteckt werden. Allerdings steht für domänenspezifische Protokolle wie DICOM kein verfügbarer Proxy zur Verfügung. Dieser Beitrag stellt den entwickelten DICOM Proxy vor und diskutiert seine Funktionalität im Vergleich zu anderen Ansätzen für die Kommunikation von DICOM Objekten.

Material und Methoden

Ein Proxy kapselt die Eigenschaften einer Einrichtung gegenüber der externen Umgebung. Als solcher nimmt ein Proxy gegenüber einrichtungsinternen DICOM Systemen die Rolle von externen Systemen an und baut stellvertretend für die einrichtungsinternen Systeme eine Verbindung mit externen DICOM Systemen auf. Dabei bietet er zunächst gegenüber der Einrichtung eine SCP-Rolle (Service Class Provider) an und agiert als SCU (Service Class User) nach extern. Aufgrund des typischen Vorgehens in der DICOM Kommunikation, dass die Anforderung eines DICOM Objekts mittels C-MOVE auf C-MOVE und ein vom angefragten Kommunikationspartner initiiertes C-STORE abgebildet wird, ist dieser „Rollentausch“ SCP nach SCU bzw. SCU nach SCP in der Umsetzung des DICOM Proxy entsprechend implementiert (Abbildung 1 [Abb. 1]). Die Umsetzung selbst wurde in JAVA plattformunabhängig realisiert und bedient sich dabei der PixelMed Bibliothek von David Clunie [1] mit entsprechenden Erweiterungen.

Der aktuelle Implementation des DICOM-Proxy unterstützt die DICOM-Dienste C-FIND, C-MOVE, C-STORE und C-ECHO. Zusätzlich wurde die Möglichkeit integriert, über den Proxy DICOM Datenobjekte zu anonymisieren bzw. zu pseudonymisieren, um auch die Forderung nach Datensparsamkeit gemäß BDSG §3a erfüllen zu können. Zur Rechteverwaltung hält der Proxy-Dienst eine Liste ihm bekannter DICOM-Systeme und ihrer Rechte zum Aufruf von Funktionen des Proxy. Für jedes DICOM-System ist neben der zur Kommunikation benötigten Parameter (Application Entity Titles, Ports und IPs) auch eine Liste zugelassener Kommunikationspartner hinterlegt. Dabei kann durch eine weitere Option gesteuert werden, ob C-Find Anfragen nur einen bestimmten Kommunikationspartner betreffen dürfen oder alle in der Liste enthaltenen. Die Nutzung des Proxy kann sowohl einseitig, d.h. bei einem Kommunikationspartner als auch zweiseitig bei beiden Kommunikationspartnern erfolgen (Abbildung 1 [Abb. 1]).

Diskussion

Gegenüber einer direkten Kommunikation von DICOM-Objekten zwischen Systemen über Einrichtungsgrenzen hinweg fasst der DICOM Proxy alle Kommunikationskanäle an der Einrichtungsgrenze zusammen und reduziert die Anzahl der benötigten Freigaben in der Firewall. Zudem erlaubt der Proxy das Verstecken der einrichtungsinternen Gegebenheiten in Verbindung mit einer dezidierten Rechtevergabe bis auf DICOM-Funktionsebene. Im Vergleich mit dem Versand von DICOM Bilddaten per DICOM-email benötigt der DICOM Proxy die Freigabe eines zusätzlichen Ports für die Kommunikation, da i.d.R. der email Port für eine Einrichtung bereits offen ist. Allerdings bedingt die effektive Nutzung von DICOM-email den Betrieb eines email-Servers, um eine zeitnahe DICOM Kommunikation ohne Verzögerungen durch zwischengeschaltete Provider zu gewährleisten. Der DICOM Proxy setzt unmittelbar auf den DICOM-Funktionen auf und kann damit eine nahe „online“ Bereitstellung von Bilddaten gewährleisten. Analog zu einer optimal umgesetzten DICOM email ist die Verzögerung durch den Zeitraum zwischen Übernahme eines DICOM Objekts und Beginn des aktiven Versands gegeben. Vorteilhaft ist zudem, dass der Proxy auch über den reinen Bildversand hinausgehende DICOM Funktionen (C-FIND) unterstützt. Dies unterscheidet ihn auch von der im DICOM Standard WADO (Web Access to DICOM Persistent Objects) [2] definierten Funktionalität, die den Aufruf eines bestimmten Bildobjekts vorsieht und explizit eine Suche nicht unterstützt.

Ergebnis

Der DICOM Proxy bündelt alle DICOM Kommunikationswege an der Grenze einer Einrichtung und erlaubt eine dezidierte Rechtevergabe und –management. In Verbindung mit „site-to-site“ oder „site-to-end“ VPN-Tunneln können DICOM Objekte gesichert an Kommunikationspartner übertragen bzw. von diesen abgerufen werden. Die Bereitstellung von DICOM-Diensten über den Proxy unterstützt eine nahezu „online“ Kommunikation verbunden mit Zusatzdiensten wie Pseudonymisierung/Anonymisierung und Suche nach DICOM Objekten in einer Einrichtung.


Literatur

1.
David Clunie, PixelMed Java DICOM Toolkit, www.pixelmed.com/index.html#PixelMedJavaDICOMToolkit, letzter Zugriff am 9.4.2006
2.
DICOM Standard, http:://medical.nema.org/dicom/2004.html, DICOM Part 18, letzter Zugriff am 9.4.2006