DE102010043718A1

DE102010043718A1 - Automatische Verbindungsanalyse für ein DICOM-Netzwerk

Info

Publication number: DE102010043718A1
Application number: DE102010043718A
Authority: DE
Inventors: Angelika Sticlaru; Björn Nolte; Thomas Sebille
Original assignee: Siemens AG
Current assignee: Siemens Healthineers Ag De
Priority date: 2010-11-10
Filing date: 2010-11-10
Publication date: 2012-05-10
Also published as: US8725850B2; US9608885B2; US20140201341A1; US20120117205A1

Abstract

Die Erfindung betrifft ein Verfahren, ein Computerprogrammprodukt, ein System und einen Verbindungsanalysator zum Bestimmen von verfügbaren Kommunikationsfunktionalitäten bei der Konfiguration eines DICOM-Knotens in einem DICOM-Netzwerk. Dabei erfolgt ein automatisches Erfassen der verfügbaren Kommunikationsfunktionalitäten durch Test-Verbindungsanfragen (1, 2, 5, ...) und Analyse der Test-Verbindungsantworten (2, 4, 6, ...). Nach der Analyse kann das Ergebnis mit den erfassten Kommunikationsfunktionalitäten automatisch bereitgestellt werden. Das Ergebnis wird vorzugsweise in der Konfigurationsphase und noch vor Inbetriebnahme des jeweiligen DICOM-Knotens bereitgestellt.

Description

Die vorliegende Erfindung liegt auf den Gebieten der Informationstechnologie und der Medizintechnik und betrifft einen Ansatz, um verfügbare Kommunikationsfunktionalitäten bei der Konfiguration von DICOM-Geräten in einem DICOM-Netzwerk zu bestimmen.
Durch die Digitalisierung der bildgebenden Medizin werden bei modernen radiologischen Bildverarbeitungssystemen heute eine Vielzahl von unterschiedlichen digitalen Endgeräten von unterschiedlichen Herstellern eingesetzt, die in Datenaustausch stehen müssen. Um eine einheitliche Interaktion dieser Geräte zu ermöglichen, wurde 1993 der DICOM-Standard entwickelt, der heute als wichtigste Norm in der Radiologie gilt. Der DICOM-Standard orientiert sich am ISO-OSI-Referenzmodell und unterstützt die Kommunikation in heterogenen Systemen. Dabei gewährleistet der DICOM-Standard auch den Austausch von Daten (dies wird als Connectivity bezeichnet). Der DICOM-Standard hat allerdings keinen Einfluss auf die Applikationen, die die zu übertragenden Daten anwenden. Ein Endgerät kann die Daten grundsätzlich nur dann verarbeiten und anwenden, wenn es möglich ist, die Daten auch an das Gerät zu übertragen. Dies wird als Interoperabilität bezeichnet. Die Interoperabilität setzt also voraus, dass alle dem Netzwerk angeschlossenen Geräte (bzw. DICOM-Knoten) Daten austauschen können.
Aufgrund der Vielzahl der einzusetzenden Geräte (zum Beispiel MR-Scanner, Post Processing Systeme, Monitoren, Antennen, um die Signale des MR-Gerätes zu übermitteln etc.) und aufgrund der Tatsache, dass die Endgeräte von unterschiedlichen Herstellern, die die jeweiligen Geräte entwickeln stammen und aufgrund der unterschiedlichen Kommunikationsfunktionalitäten der Geräte ist es vorgesehen, im Vorfeld eine sogenannte Konformitätserklärung (conformance statement) bereitzustellen. Die Konformitätserklärung wird üblicherweise vom Hersteller erstellt und dient dazu, anzugeben, welche DICOM-Funktionen (insbesondere welche DICOM-Dienste und Optionen) von dem jeweiligen Gerät unterstützt werden.
Als nachteilig hat es sich bisher im Stand der Technik erwiesen, dass die Konformitätserklärungen nur rudimentär ausgefüllt sind und teilweise so unzureichend bereitgestellt werden, dass eine Verbindungsanalyse nicht möglich ist. Soll ein DICOM-Netzwerk neu aufgebaut, modifiziert oder erweitert werden, so muss ein (neues) DICOM-Gerät in das DICOM Netzwerk integriert werden. Dieses DICOM-Gerät steht – je nach Funktion des Gerätes – mit anderen DICOM-Geräten in Datenaustausch. Damit dieser Datenaustausch fehlerfrei ausgeführt werden kann, ist es erforderlich, im Vorfeld zu überprüfen, ob die jeweiligen Geräte interoperabel sind. Vereinfacht kann dieser Sachverhalt in simplifizierter Form exemplarisch an folgendem Beispiel erläutert werden: soll ein MR-Scanner seine erfassten Daten an ein Nachbearbeitungsmodul weiterleiten, so muss im Vorfeld überprüft werden, ob das Nachverarbeitungsmodul die vom MR-Scanner bereitgestellten Daten in dem jeweiligen Format überhaupt empfangen kann und beispielsweise, ob die zwischen den beiden Geräten vorgesehene Datenübertragung ausreichende Kapazität aufweist. Um im konkreten Anwendungsfall einen Fehler aufgrund von fehlerhafter Konnektivität zwischen den beteiligten DICOM-Knoten verhindern zu können, muss im Vorfeld eine Analyse der Konnektivität ausgeführt werden. Nachteiligerweise ist dies bisher aufgrund der defizitär bereitgestellten Konformitätserklärungen nicht möglich.
Die vorliegende Erfindung hat sich deshalb zur Aufgabe gestellt, ein Analysewerkzeug bereitzustellen, mit dem automatisch alle essentiellen DICOM-Kommunikationsparameter analysiert und präsentiert werden. Insbesondere soll die Konnektivität zwischen unterschiedlichen DICOM-Endgeräten unterschiedlicher Hersteller im Vorfeld und vor einem konkreten Verbindungsaufbau analysiert werden können, um möglicherweise im Vorfeld durch Abgleich von Verbindungsparametern eine Konnektivität herstellen zu können.
Diese Aufgabe wird durch die beiliegenden nebengeordneten Patentansprüche gelöst, insbesondere durch ein Verfahren, ein Computerprogrammprodukt, ein System und einen Verbindungsanalysator.
Im Folgenden wird die Erfindung näher am Beispiel des Verfahrens beschrieben. Hierbei erwähnte alternative Ausführungsformen, Vorteile und weitere Merkmale sind ebenso auch auf die anderen Anspruchskategorien, insbesondere auf das Computerprogrammprodukt, auf das System und den Verbindungsanalysator zu übertragen. Die jeweiligen Funktionen werden dabei durch spezifische Hardwaremodule gelöst, die in einem Mikrocontroller oder in einem (digitalen oder analogen) Schaltkreis bereitgestellt werden können und die jeweilige Funktion ausführen.
Gemäß einem Aspekt ist ein Lösungsvorschlag der vorliegenden Erfindung auf ein computerimplementiertes Verfahren zur Bestimmung von verfügbaren Kommunikationsfunktionalitäten bei der Konfiguration von zumindest einem DICOM-Gerät (bzw. DICOM-Knoten) in einem DICOM-Netzwerk ausgebildet, wobei das Verfahren folgende Verfahrensschritte umfasst:

– Automatisches Erfassen der verfügbaren Kommunikationsfunktionalität des DICOM-Knotens;
– Bereitstellen der erfassten Kommunikationsfunktionalität zur Konfiguration des DICOM-Knotens vor dessen Inbetriebnahme einer Verbindungsanfrage.

Im Folgenden sollen die im Rahmen dieser Patentanmeldung verwendeten Begrifflichkeiten näher erläutert werden.
Bei dem Verfahren handelt es sich um ein computerimplementiertes Verfahren, das als automatisches Werkzeug zur Konfiguration von DICOM-Geräten zur Integration in ein DICOM-Netzwerk verwendet werden kann. Soll das zu konfigurierende (neue) DICOM-Gerät beispielsweise mit einem oder mehreren anderen (alten) DICOM-Geräten interagieren, so kann die Konnektivität zwischen dem neuen und dem ersten alten, sowie zwischen dem neuen und dem zweiten alten DICOM-Gerät im Vorfeld analysiert werden. Die Analyse kann auch für einen entfernten DICOM-Knoten ausgeführt werden, sodass auf einem bereits integrierten (alten) DICOM-Knoten festgestellt werden kann, welche Kommunikationsfunktionalitäten der neue (zu integrierende) DICOM-Knoten bereitstellt.
Mit dem erfindungsgemäßen Tool werden Kommunikations-funktionalitäten bestimmt. Dabei handelt es sich grundsätzlich um (alle oder ausgewählte) relevante Parameter für die Konfiguration eines DICOM-Gerätes. Mit dem DICOM-Standard (insbesondere Version 3.0) sind alle Hersteller verpflichtet, alle DICOM-relevanten Eigenschaften des Gerätes in sogenannten SOP-Klassen (Service Object Pairs – SOP's) zusammenzufassen und bereitzustellen. Zum Nachrichtenaustausch definiert der DICOM-Standard einen Dienst zur Nachrichtenübertragung, nämlich ein DICOM Message Service Element (DIMSE), der auf einer TCP/IP, ISO-OSI oder Point-to-Point-Schnittstelle aufsetzt. Die Kombination eines Informationsobjektes und eines Dienstes wird im DICOM-Standard – wie oben bereits erwähnt – Service Objekt Pair (SOP) bezeichnet. Beim konkreten Verbindungsaufbau werden zunächst SOP-Klassen bestimmt, die von beiden Kommunikationspartnern (oder Applikationen) unterstützt werden. Darüber hinaus werden Anbieter und Benutzer des jeweiligen Dienstes bestimmt. Die Kommunikationsfunktionalität umfasst jeweils Kommunikationsparameter, wie zum Beispiel die von dem jeweiligen DICOM-Knoten angebotenen Dienste, die SOP-klassenunterstützten Transfersyntaxe, sowie weitere Kommunikationsparameter, wie zum Beispiel die maximale PDU-Größe (PDU: Protocol Data Unit) extended negotiations als erweiterte Dienste zwischen zwei Applikationen, ein Präsentationskontext, Parameter für ein asynchrones Windowing, Parameter, die festlegen ob beispielsweise eine Value Representation explizit oder implizit angegeben wird, wie Integerzahlen codiert werden (little Endian oder big Endian Format), wie Bilder gepackt sind oder nicht, wie diese codiert sind etc. Je nach Anwendung des beteiligten DICOM-Gerätes können hier noch weitere Konfigurationsparameter hinzukommen, sodass die Liste je nach Anwendung dynamisch konfiguriert werden kann.
Je nachdem, wie viele DICOM-Geräte miteinander in Datenaustausch stehen, werden erfindungsgemäß alle Kommunikationsfunktionalitäten auf den beteiligten Geräten überprüft und erfasst. Falls jedoch nur ein neuer DICOM-Knoten in ein bestehendes Netzwerk integriert werden soll, so ist es möglich, auf einem bisherigen DICOM-Knoten die Kommunikationsfunktionalitäten des entfernten neu zu integrierenden DICOM-Knotens bereitzustellen.
Der Begriff ”DICOM-Knoten” bezieht sich auf alle DICOM-kompatiblen Module, Geräte, Produkte, die üblicherweise von unterschiedlichen Herstellern bereitgestellt werden. Ein DICOM-Knoten kann ein Gerät (zum Beispiel zur Anzeige von Bilddaten, zur Speicherung von Bilddaten zum Post Processing von digitalen Bilddaten zur Akquisition der Bilddaten etc.) sein. Auf dem DICOM-Knoten kann eine oder es können mehrere Applikationen (sogenannte Application Entities – AE's) laufen.
Gemäß dem DICOM-Standard kann ein DICOM-Knoten die Rolle eines Service Class Provider's (SCP – Service Class Provider) oder die Rolle eines Service Class User's (SCU – Service Class User) einnehmen. Der Service Class Provider stellt einen bestimmten Dienst zur Verfügung, während der Service Class User den Dienst nutzt. Grundsätzlich ist es möglich, dass ein Knoten beide Rollen (SCU und SCP) gleichzeitig einnimmt.
Der Begriff ”DICOM-Netzwerk” soll ein Netzwerk aus DICOM-Knoten und DICOM-kompatiblen Knoten bezeichnen. Gemäß einer Ausführungsform ist es auch möglich, dass DICOM-externe Geräte in das DICOM-Netzwerk eingebunden sind. Üblicherweise werden die Geräte, die nicht DICOM-konform sind, über eine separate Schnittstelle (Adaptermodul) in das Netzwerk eingebunden.
Der Begriff ”Konfiguration” des DICOM-Knotens bezieht sich auf eine Zeitphase, die vor Inbetriebnahme des jeweiligen DICOM-Knotens liegt. Bevor also der jeweilige DICOM-Knoten in das DICOM-Netzwerk integriert wird und somit bevor eine konkrete Verbindungsaushandlung erfolgen kann, muss der jeweilige Knoten zunächst konfiguriert werden. Gemäß einem Aspekt der Erfindung kennzeichnet sich diese dadurch, dass die Kommunikationsfunktionalitäten bereits zum Zeitpunkt der Konfiguration bereitgestellt werden können und somit bevor eine Verbindungsaushandlung zwischen den jeweiligen DICOM-Knoten ausgeführt werden kann. Die bereitgestellten Kommunikationsfunktionalitäten werden zur Konfiguration des DICOM-Knotens genutzt.
Im Unterschied zum Stand der Technik erfolgt das Erfassen der Kommunikationsfunktionalität der beteiligten DICOM-Knoten nicht mehr manuell durch Analyse der Konformitätserklärung, sondern vollautomatisch und insbesondere ohne Benutzerinteraktion.
Die erfassten Kommunikationsfunktionalitäten werden bereits in der Konfigurationsphase bereitgestellt und können somit verwendet werden, um die Kommunikation der beteiligten DICOM-Knoten aufeinander abzustimmen. Das Bereitstellen kann ein Anzeigen und Weiterverarbeiten umfassen. Das Anzeigen erfolgt üblicherweise auf einer graphischen Benutzeroberfläche eines Monitors.
Ein wesentlicher Aspekt und Vorteil der Erfindung ist darin zu sehen, das Verhalten eines entfernten DICOM-Knotens bereits im Vorfeld zu wissen, insbesondere in einer Konfigurationsphase für den DICOM-Knoten. Dies hat zur Folge, dass bereits zur Konfigurationszeit eine Nachricht ausgegeben werden kann, falls die jeweiligen Kommunikationsfunktionalitäten der beteiligten DICOM-Knoten nicht übereinstimmen und ein Konnektivitätsproblem zu erwarten ist. Darüber hinaus wird es möglich, dass ein Service Class User (SCU) nur diejenigen Applikationen bzw. Anwendungsfälle oder Dienste präsentiert, die von dem entfernten DICOM-Knoten auch unterstützt werden.
Gemäß einer vorteilhaften Weiterbildung der Erfindung ist es vorgesehen, die erfassten und bereitgestellten Kommunikationsfunktionalitäten weiter zu verarbeiten. Die Weiterverarbeitung sieht vor, dass bei einer fehlenden Übereinstimmung (zum Beispiel zwischen SCU und SCP) eine automatische Funktionalitätserweiterung, insbesondere auf dem SCP-Knoten angefordert wird. Falls möglich, kann diese erweiterte Funktionalität auch von dem SCU-Knoten bereitgestellt werden.
Ein wichtiger Aspekt der vorliegenden Erfindung ist darin zu sehen, dass die verfügbaren Kommunikationsfunktionalität(en) bereits in einer Konfigurationsphase bereitgestellt wird/werden. Der ”Konfigurationsphase” bezieht sich auf das Hardware-bezogene Anschließen bzw. Einbinden des zumindest einen DICOM-Knotens in das DICOM-Netzwerk. Die Konfigurationsphase bezieht sich somit auf einen Installationsvorgang des jeweiligen DICOM-Gerätes. Die Konfigurationsphase ist einer Betriebsphase zeitlich vorgelagert. Die ”Betriebsphase”/(Runtime) des DICOM-Knotens bezieht sich auf den Zeitraum, in dem der jeweilige DICOM-Knoten in dem DICOM-Netzwerk in Betrieb genommen ist, also auf die Laufzeit des DICOM-Knotens, während dessen die Dienste und Funktionen des DICOM-Knotens ausgeführt werden. Bisher waren diese beiden Phasen (Konfigurationsphase und Betriebsphase) vollständig voneinander getrennt. Erfindungsgemäß ist es nun vorgesehen, die beiden Phasen ineinander zu verschränken, sodass bereits in der Konfigurationsphase eine vorgelagerte Betriebsphase ausgeführt wird, die dahingehend ausgelegt ist, die verfügbaren Kommunikationsfunktionalitäten der beteiligten DICOM-Knoten zu analysieren. Die vorgelagerte Betriebsphase unterscheidet sich von der (eigentlichen) Betriebsphase dadurch, dass der Kommunikationsbetrieb der beteiligten DICOM-Knoten sozusagen nur testweise und ohne konkreten Kommunikationsauftrag einer Applikation (Verbindungsanfrage, Association Request, Association Response) ausgeführt wird. Die vorgelagerte Betriebsphase dient lediglich dazu, Test-Verbindungsanfragen an den jeweiligen DICOM-Knoten zu senden und seine entsprechenden Antworten darauf zu empfangen und zu analysieren. Falls die Test- oder Probeanfrage mit der jeweiligen Antwort signalisiert, dass der Probeauftrag erfolgreich ausgeführt werden kann, wird dies als verfügbare Kommunikationsfunktionalität des DICOM-Knotens gespeichert. Andernfalls (falls also die Probeanfrage nicht erfolgreich ausgeführt werden konnte) wird die Funktionalität als nicht-verfügbar gekennzeichnet.
Wie bereits erwähnt, ist es gemäß einem Aspekt der vorliegenden Erfindung vorgesehen, dass das Bereitstellen der erfassten Kommunikationsfunktionalität(en) bereits bei Installation des DICOM-Knotens ausgeführt wird. Dies hat den Vorteil, dass nur die Dienste und Funktionen der Knoten auf einer Benutzeroberfläche dargestellt werden, die ohne Konnektivitätsprobleme tatsächlich ausführbar sein werden. Darüber hinaus kann die konkrete Verbindungsaushandlung in der Betriebsphase des DICOM-Netzwerkes kürzer und effizienter ausgestaltet werden, da relevante Konnektivitätsparameter bereits erfasst und bereitgestellt sind.
Die Erfindung ist grundsätzlich nicht auf eine bestimmte Anzahl von einzubindenden DICOM-Knoten beschränkt. Es kann somit nur ein neuer oder neu zu konfigurierender DICOM-Knoten in ein Netzwerk einzubinden sein, für den die verfügbaren Kommunikationsfunktionalitäten erfasst und bereitgestellt werden sollen. Ebenso ist es möglich, dass gleichzeitig oder sequentiell mehrere DICOM-Knoten in das Netzwerk eingebunden werden sollen, für die die jeweiligen Kommunikationsfunktionalitäten bestimmt werden sollen.
Wie vorstehend bereits erwähnt, ist es möglich, dass ein DICOM-Knoten mehrere Applikationen umfasst. Üblicherweise hat eine Applikation (bzw. eine Anwendung) unterschiedliche Kommunikationserfordernisse. In einem solchen Szenario ist es vorgesehen, dass automatisch alle relevanten Kommunikationsfunktionalitäten für alle Anwendungen des DICOM-Knotens erfasst, getestet und bestimmt werden.
In einer bevorzugten Weiterbildung der Erfindung ist es vorgesehen, dass die vom SCU angeforderten Kommunikationsfunktionalitäten und die vom SCP bereitgestellten Kommunikationsfunktionalitäten verglichen werden. Falls der Vergleich eine Übereinstimmung kennzeichnet, kann (optional) eine Verfügbarkeitsmeldung ausgegeben werden. Des Weiteren kann auf dem SCU die Applikation, die die jeweilige Kommunikations-funktionalität benötigt als ausführbar gekennzeichnet werden.
Bei einer fehlerhaften Übereinstimmung, falls also die angeforderte Kommunikationsfunktionalität nicht auf dem SCP bereitgestellt werden kann, kann eine Fehlernachricht generiert werden. Kumulativ oder alternativ kann die jeweilige Applikation auf dem SCU, die die Kommunikationsfunktionalität angefordert hat, als nicht verfügbar (bzw. als nicht aktivierbar oder nicht unterstützt) auf der Bildschirmoberfläche gekennzeichnet werden.
In einer Weiterbildung kann es vorgesehen sein, dass im Fehlerfall, falls also die angeforderte Kommunikationsfunktionalität auf dem SCP nicht bereitgestellt werden kann, ein Erweiterungsmodul vorgesehen ist, das dazu ausgebildet ist, die angeforderte Kommunikationsfunktionalität als Zusatzkommunikationsfunktionalität bereitzustellen. Beispielsweise kann die Zusatzfunktionalität auf dem SCU für den entfernten SCP bereitgestellt werden. In dieser Ausführungsform ähnelt der Ansatz somit dem Ansatz, der aus dem Cloud Computing bekannt ist. Bei Letzerem werden Funktionen und Dienste nicht lokal sondern von entfernten Netzwerkknoten bereitgestellt.
Ein Ergebnis des erfindungsgemäßen Verfahrens betrifft das Bereitstellen der erfassten Kommunikationsfunktionalitäten. In einer alternativen Ausführungsform umfasst das Ergebnis alternativ oder kumulativ noch eine Klassifikation der SCU-Applikationen. Die Klassifikation erfolgt dabei nach den Kriterien ”Ist hinsichtlich der Kommunikationsfunktionalität unterstützt” und ”Wird hinsichtlich der Kommunikationsfunktionalitäten nicht unterstützt”. Das Ergebnis wird gespeichert. Insbesondere wird das Ergebnis lokal für einen entfernten DICOM-Knoten gespeichert. Zur Laufzeit, also während der Betriebsphase, greifen alle Applikationen auf den lokalen Speicher zu und können somit auf das Ergebnis der Konnektivitätsanalyse zur Laufzeit zugreifen und dabei das Verhalten der Applikation anpassen an die aktuellen Konnektivitätsergebnisse, was wiederum das Laufzeitverhalten verbessert und die Verbindungsaushandlung beschleunigt.
Als wesentlicher Vorteil des erfindungsgemäßen Verfahrens lässt sich festhalten, dass mit dem Werkzeug eine automatische Analyse von Kommunikationsfunktionalitäten möglich ist. Darüber hinaus ist diese Analyse auch für ein entferntes System möglich, unter Verwendung von üblichen Kommunikationsprotokollen und Kalibrierungsmöglichkeiten. Mit anderen Worten muss kein zusätzliches, spezielles Protokoll verwendet werden.
Des Weiteren kann die Datenübertragung vereinfacht und beschleunigt werden, indem beispielsweise Konvertierungsvorgänge (zum Beispiel Kompression/Dekompression), die während der Datenübertragung zum Einsatz kommen, bereits im Vorfeld an die jeweils unterstützte Transfersyntax angepasst werden, bevor der Verbindungkanal geöffnet wurde.
Des Weiteren kann beispielsweise die ”Image-Send”-Funktionalität dahingehend angepasst werden, dass die Liste von (entfernten) Empfängerknoten an die jeweilige SOP-Klasse des jeweiligen Bildes angepasst wird, sodass infolge nur die Empfängerknoten als auswählbar dargestellt werden, die die notwendige Kommunikationsfunktionalität zum Empfangen des Bildes haben.
Darüber hinaus können bestimmte DICOM-Netzwerkknoten für das Archivieren und Prefetching bestimmt werden, in Abhängigkeit von Speicheranforderungen (storage commitment, query/retrieve).
Ein weiterer Vorteil ist darin zu sehen, dass spezielle Konnektivitätsparameter erfasst werden können, die für die jeweilige Anwendung (für den jeweiligen Knoten) relevant sind. Damit kann die Bestimmung der verfügbaren Kommunikationsfunktionalitäten spezifisch an den jeweiligen Anwendungsfall angepasst werden. Dies war im Stand der Technik nicht möglich, da jeweils eine manuelle Umsetzung der Konformitätserklärungen ausgeführt wurde. War der jeweilige Konnektivitätsparameter nicht in der Konformitätserklärung enthalten, konnte keine Aussage über den Konektivitäts-Parameter abgeleitet werden. Erfindungsgemäß ist dies nun anders, da je nach Anforderungs-Profil alle Konnektivitätsparameter analysiert werden können.
Eine weitere Aufgabenlösung besteht in einem Verbindungsanalysator. Darunter ist eine Computer-basierte oder – implementierte Anordnung zu verstehen, um verfügbare Kommunikationsfunktionalitäten bei der Konfiguration bzw. Installation von zumindest einem DICOM-Knoten in ein DICOM-Netzwerk zu bestimmen. Der Verbindungsanalysator kann als separates Modul über eine entsprechende Schnittstelle an das DICOM-Netzwerk angeschlossen. werden. Alternativ kann der Verbindungsanalysator bereits Teil des DICOM-Netzwerkes sein und beispielsweise einem bestimmten DICOM-Knoten zugeordnet sein. In einer alternativen Ausführungsform der Erfindung ist der Verbindungsanalysator auf jedem DICOM-Knoten bereit-gestellt. Dies hat den Vorteil, dass Konnektivitäts-ergebnisse durch mehrfaches Bestimmen überprüfbar werden.
Der Verbindungsanalysator umfasst:

– zumindest ein Erfassungsmodul, das zum automatischen Erfassen der verfügbaren Kommunikationsfunktionalität des jeweiligen DICOM-Knotens bestimmt ist und
– zumindest ein Bereitstellungsmodul, das zum automatischen Bereitstellen der erfassten Kommunikationsfunktionalität(en) des jeweiligen DICOM-Knotens bestimmt ist.

Dabei ist es vorgesehen, dass das Bereitstellungsmodul die erfassten Kommunikationsfunktionalitäten in der Konfigurations- bzw. Installationsphase des jeweiligen DICOM-Knotens bereitstellt und somit noch vor Inbetriebnahme mit einer konkreten Verbindungsanfrage des jeweiligen DICOM-Knotens.
Vorteilhafterweise kann dann die konkrete Verbindungsanfrage der jeweiligen Applikation des DICOM-Knotens spezifisch auf die verfügbaren Konnektivitätsparameter angepasst werden.
Der Verbindungsanalysator kann mit den Merkmalen weitergebildet sein, die vorstehend im Zusammenhang mit dem Verfahren beschrieben worden sind.
Eine weitere erfindungsgemäße Lösung betrifft ein DICOM-Netzwerk-System zur Bestimmung von verfügbaren Kommunikations-funktionalitäten in einem DICOM-Netzwerk, umfassend:

– eine Vielzahl von DICOM-Knoten
– zumindest einen zu konfigurierenden DICOM-Knoten
– zumindest einen Verbindungsanalysator, wobei die DICOM-Knoten, der zu konfigurierende DICOM-Knoten und der Verbindungsanalysator über das DICOM-Netzwerk in Datenaustausch stehen.

Eine weitere Aufgabenlösung betrifft ein Computerprogrammprodukt. Bei dem Produkt handelt es sich entweder um ein solches, das direkt in einen Speicher eines digitalen Computers geladen werden kann und Mittel oder Softwarecodeabschnitte umfasst, mit denen die Schritte des vorstehend erwähnten Verfahrens ausgeführt werden, wenn das Computerprogrammprodukt auf dem Computer ausgeführt wird oder geladen ist. Ebenso fallen unter das Produkt Speichermedien (wie z. B. eine CD oder andere tragbare Datenträger), auf denen ein Computerprogramm gespeichert ist, das das oben beschriebene Verfahren ausführt. Darüber hinaus kann das Produkt in computerimplementierten Modulen bestehen, die auf einem Server zum Download bereitgestellt werden, wobei die Module zur Ausführung des oben beschriebenen Verfahrens bestimmt sind.
Eine alternative Aufgabenlösung sieht ein Computerprogramm vor, umfassend Programmbefehle zur Ausführung des oben näher beschriebenen Verfahrens. Das Computerprogramm kann als ausführbarer Code oder als Objektcode oder Quellcode oder in einer anderen Form auf einem digitalen Speichermedium gespeichert sein.
Im Folgenden werden Ausführungsbeispiele der vorliegenden Erfindung im Zusammenhang mit den Figuren beschrieben. Dabei zeigt:
1 eine schematische, übersichtsartige Darstellung eines DICOM-Netzwerkes mit einem Verbindungsanalysator und
2 ein Ablaufdiagramm eines erfindungsgemäßen Verfahrens gemäß einer bevorzugten Ausführungsform der Erfindung
Im Folgenden wird die Erfindung im Zusammenhang mit 1 näher erläutert.
In 1 ist schematisch und übersichtsartig ein DICOM-Netzwerk dargestellt.
Das DICOM-Netzwerk besteht aus einer Vielzahl von DICOM-Knoten, die entweder als Service Class Provider SCP oder Service Class User SCU agieren können. Im Folgenden wird ein Service Class User auch kurz als SCU und ein Service Class Provider auch kurz als SCP bezeichnet. Die DICOM-Knoten sind Computer oder computerbasierte Instanzen, die radiologische Funktionen ausführen und auf einer digitalen Datenverarbeitung beruhen, wie beispielsweise Bildakquisitionsgeräte oder dergleichen. Alle angeschlossenen DICOM-Knoten kommunizieren über eine DICOM-Schnittstelle bzw. das DICOM-Netzwerk. Für Details zu dem DICOM-Standard wird auf die öffentlich zugänglichen Dokumente verwiesen, insbesondere ACR-NEMA Komitee zum DICOM-Standard (Herausgeber ist der National Electrical Manufacturers Association; erschienen in: Rosslyn, Virginia, USA 2008), deren Offenbarungsgehalt in die Patentanmeldung aufgenommen sein sollte.
Erfindungsgemäß wird ein Verbindungsanalysator 20 bereitgestellt (der im Folgenden auch als DICOM Network Connectivity Analyzer, kurz: DNCA bezeichnet wird).
Der Verbindungsanalysator 20 kann als separates Produkt, insbesondere Computerprodukt (z. B. in Form eines Steckplatzmoduls, das an einem Steckplatz dem DICOM-Netzwerk über eine (z. B. USB-) Schnittstelle zugeschaltet ist), angeschlossen sein oder er kann einem einzelnen DICOM-Knoten zugeordnet sein. Alternativ kann er auch als zentrale Netzwerkinstanz bereitgestellt werden. Ebenso liegt es im Rahmen der Erfindung den Verbindungsanalysator 20 als embedded system dem DICOM-Netzwerk als elektronisches Modul (z. B. einer Box mit entsprechenden Schnittstellen) zuzuschalten.
Der Verbindungsanalysator 20 dient zur Überprüfung von Konnektivitätsparametern für einen zu konfigurierenden DICOM-Knoten. Insbesondere sollen verfügbare Kommunikationsfunktionalitäten zwischen dem zu konfigurierenden DICOM-Knoten und den beteiligten Kommunikationspartnern im DICOM-Netzwerk bestimmt werden. Vorteilhafterweise erfolgt dies vollautomatisch.
Gemäß dem DICOM-Standard ist für jeden neu zu integrierenden DICOM-Knoten (zum Beispiel ein medizinisches oder ein informationstechnologisches Gerät) eine Konfiguration des Gerätes vorgesehen.
Bevor das jeweilige Gerät in Betrieb genommen werden kann, muss es zunächst konfiguriert werden. Die Konfiguration sieht beispielsweise vor, dass die auf dem DICOM-Knoten implementierten Applikationen (application entities, kurz AS's) die auf dem DICOM-Gerät konfiguriert sind, eine bestimmte Netzwerkverbindung erfordern. Diese Netzwerk-verbindung muss konfiguriert werden. Darüber hinaus stellt jede Applikation eine Liste von Diensten oder Funktionen (transfer capabilities) zur Verfügung. Beispiele für DICOM-Dienste sind:

– storage
– storage commitment
– query/retrieve
– basic print
– modality work list
– modality performed procedure steps
– etc.

Die meisten Applikationen erfordern es, dass ein DICOM-Knoten (in der Rolle als SCU) mit einem anderen DICOM-Knoten (in der Rolle als SCP) kommuniziert. Selbstverständlich können auch Anwendungen vorgesehen sein, in denen eine u. U. parallele Kommunikation mit mehreren DICOM-Knoten notwendig ist.
Die Applikation kann nur dann erfolgreich ausgeführt werden, wenn eine erfolgreiche Verbindung zwischen SCU und SCP hergestellt werden kann.
Erfindungsgemäß ist es nun vorgesehen, dass bereits in der Konfigurationsphase, die der eigentlichen Betriebsphase vorgelagert ist, ein Testen von erforderlichen Kommunikationsfunktionalitäten zwischen den beteiligten DICOM-Knoten ausgeführt wird. Dies hat den Zweck, zu überprüfen, ob die erforderlichen DICOM-Kommunikationen zwischen den beteiligten Knoten auch ausführbar sind.
Dazu wird erfindungsgemäß das DICOM-Protokoll zur Kommunikation verwendet.
Der Aufbau von Kommunikationsverbindungen gemäß dem DICOM-Standard läuft immer auf gleiche Art ab. Der DICOM-Knoten in der Rolle des SCU's stellt eine Verbindungsanfrage (communication request) an den Partner-DICOM-Knoten (in der Rolle des SCP). In dieser Anfrage wird mitgeteilt, welche Art der Verbindung gewünscht wird. Mit anderen Worten werden hier die Kommunikationsparameter mitgesendet. Es werden dabei die Transfersyntaxe übertragen, die der SCU unterstützt. Das heißt, dass mit der Verbindungsanfrage 1, 3, 5, ... mitgeschickt wird, wie Zahlen codiert werden, ob eine sogenannte value representation explizit angegeben wird und, ob die Bilder gepackt sind. Darüber hinaus können noch weitere Verbindungsparameter mitgesendet werden. Außerdem werden die sogenannten SOP Klassen (Service Object Pair – SOP) übertragen, die der SCU unterstützt. Zu jeder SOP-Klasse wird übertragen, ob sie als SCU oder als SOP unterstützt wird.
Auf die Verbindungsanfrage 1, 3, 5, ... schickt der SOP eine Verbindungsantwort 2, 4, 6 zurück. Die Verbindungsantwort 2, 4, 6 umfasst die unterstützten Präsentationskontexte. Dabei werden auch die Application Entities (AE's) übertragen, sodass der SOP entscheiden kann, ob mit diesem Applikationsnamen eine Kommunikation möglich ist.
Nach dem Verbindungsaufbau kann die eigentliche DICOM-Kommunikation stattfinden. Dabei ist es vorgesehen, dass bei allen Kommunikationsverbindungen auf jede Anfrage geantwortet wird, ob die Anfrage erfolgreich beantwortet werden konnte oder nicht.
Erfindungsgemäß ist es nun vorgesehen, dass bereits zur Installations- bzw. Konfigurationszeit Probe- bzw. Test-Verbindungsanfragen von dem SCU an den SCP und entsprechende Probe- bzw. Test-Antworten kommuniziert werden. In 1 sind die Test-Anfragen mit den Bezugszeichen 1, 3 und 5 gekennzeichnet, und die Test-Antworten auf diese Anfragen mit den Bezugszeichen 2, 4 und 6 gekennzeichnet. Der Verbindungsanalysator 20 ist erfindungsgemäß ausgebildet, um diese Test-Anfragen 1, 3, 5 zu generieren und die jeweiligen Test-Antworten 2, 4, 6 des SCP zu empfangen. Vorteilhafterweise werden die empfangenen Antworten analysiert und daraufhin untersucht, ob die Anfrage erfolgreich beantwortet (bzw. auf dem SCP ausgeführt) werden konnte. Falls dies möglich ist, wird die jeweilige Kommunikations-funktionalität als ”verfügbar” im SCU gekennzeichnet. Andernfalls (falls also die Test-Verbindungsanfrage 1, 3, 5 nicht erfolgreich beantwortet werden konnte) wird eine Fehlernachricht generiert. Dann wird die jeweilige Kommunikationsfunktionalität als ”nicht-verfügbar” im SCU repräsentiert. Nachdem alle Test-Verbindungsantworten 2, 4, 6 beim SCU eingegangen sind, kann die entsprechende Kommunikationsfunktionalität als ”verfügbar” oder ”nicht-verfügbar” gekennzeichnet werden. In 1 soll der unterbrochene Pfeil der Verbindungsantwort 4 kennzeichnen, dass die Verbindungsanfrage 3 nicht erfolgreich ausgeführt werden konnte. In diesem Fall wird bei der SCU die jeweilige Kommunikationsfunktionalität der Applikation als nicht unterstützt gekennzeichnet. In 1 sind alle weiteren Verbindungsanfragen 1 und 5 verfügbar, da sie erfolgreich auf den SCP ausgeführt werden konnten.
Somit kann der Techniker bereits zur Konfigurationsphase Aufschluss darüber erhalten, ob die jeweiligen Kommunikationsfunktionalitäten, die von den Applikationen erfordert werden, auch verfügbar sind. Insbesondere wird untersucht, ob die Kommunikationsfunktionalitäten auf den entfernten Kommunikationspartnern (es können auch mehrere sein), die die Rolle des SCP einnehmen, verfügbar sind.
In einer bevorzugten Weiterbildung der Erfindung ist es vorgesehen, dass eine Erweiterungsfunktion bereitgestellt wird, falls die erforderlichen Kommunikationsfunktionalitäten nicht verfügbar sind. Dann wird untersucht, ob die erforder-liche Zusatzfunktionalität, die auf dem entfernten SCP-Knoten fehlt, auf dem SCU-Knoten (oder auf andere Netzwerkknoten) bereitgestellt werden kann und die fehlende Funktionalität kompensieren kann. Falls dies möglich ist, wird eine entsprechende Verbindungsanfrage an den Ersatz-Knoten gesendet und falls diese erfolgreich beantwortet werden kann, kann die Kommunikationsfunktionalität als verfügbar gekennzeichnet werden (auf dem SCU).
Im Folgenden wird im Zusammenhang mit 2 der Ablauf des Verfahrens gemäß einer bevorzugten Ausführungsform beschrieben.
Wie in 2 ersichtlich, gliedert sich der Ablauf bei Inbetriebnahme eines neuen DICOM-Gerätes üblicherweise in eine Konfigurationsphase und eine Betriebsphase (die in 2 als Runtime gekennzeichnet ist). Die Konfigurationsphase dient zur Installation des Gerätes und die Betriebsphase bezieht sich auf die Ausführung des konfigurierten DICOM-Knotens und somit auf die Laufzeit der Applikationen, die auf dem DICOM-Knoten installiert bzw. zum Ausführen der jeweiligen Dienste und Funktionen.
In einem ersten Schritt 100 wird ein Auftrag zur Konfiguration (bzw. zur Installation) eines DICOM-Knotens erfasst.
Im Schritt 110 wird der Knoten, für den die Konfiguration durchgeführt werden soll, (provisorisch) in das DICOM-Netzwerk eingebunden.
Darauf wird in Schritt 120 erfasst, welche Applikationen auf dem zu konfigurierenden Knoten installiert sind.
In Schritt 130 wird erfasst, welche Kommunikationsfunktionalitäten die Applikationen und damit der Knoten erfordert. Dabei werden auch die Konnektivitäts-parameter für die Kommunikationsfunktionalitäten erfasst.
In Schritt 140 wird eine (Test-)Verbindungsanfrage generiert. Diese wird von dem SCU an den SCP (als Kommunikationspartner) gesendet. Die konkrete Verbindungsanfrage wird also in Schritt 140 ausgeführt.
Die Schritte 100 bis einschließlich 140 werden üblicherweise auf dem Verbindungsanalysator 20 ausgeführt.
Auf die Verbindungsanfrage hin wird dann auf dem SCP eine Antwort auf die jeweilige Verbindungsanfrage 1, 3, 5 generiert. Die Antwort auf die Verbindungsantrage (diese ist in 1 mit dem Bezugszeichen 2, 4 und 6 gekennzeichnet) wird daraufhin von dem SCP an den SCU gesendet.
Daraufhin kann in Schritt 160 das Ergebnis der Verbindungsanfrage bzw. die Verbindungsantwort 2, 4 und 6 auf dem SCU empfangen werden.
In Schritt 170 wird das Ergebnis der Verbindungsanfrage 2, 4, 6 analysiert. Insbesondere wird hier analysiert, ob die Verbindung erfolgreich beantwortet werden konnte oder nicht.
Daraufhin kann in Schritt 180 der jeweilige Knoten anhand des Ergebnisses konfiguriert werden.
Die Schritte 170 und 180 werden üblicherweise ebenfalls auf den Verbindungsanalysator 20 ausgeführt.
In Schritt 190 kann dann der konfigurierte Knoten in Betrieb genommen werden (Runtime). Dabei sind die Kommunikationsfunktionalitäten an die jeweiligen Kommunikationspartner des Knotens angepasst.
Die Punkte in 2 unter dem Schritt 190 sollen kennzeichnen, dass es auch möglich ist, weitere Anpassungsschritte zur Laufzeit auszuführen.
Des Weiteren soll der in funktionaler Hinsicht nach unten weisende und in einer Schleife nach oben führende Pfeil in 2 kennzeichnen, dass erfindungsgemäß nicht nur Neu-Konfigurationen möglich sind, sondern dass auch nach Inbetriebnahme eines Knotens eine wiederholte oder modifizierte Konfiguration möglich ist. Beispielsweise kann dies sinnvoll sein, falls sich die Verarbeitungsbedingungen geändert haben (zum Beispiel weitere Kommunikationspartner hinzugetreten sind oder weitere Applikationen den jeweiligen Knoten hinzugefügt worden sind).
Wesentlich ist, dass während der Konfigurationsphase die Einstellung des jeweiligen Knotens vorgenommen werden, wie beispielsweise die Definition der Adresse, der Ports, der Services und weiterer Funktionalitäten definiert werden. Dabei ist zu beachten, dass diese Einstellungen und Konfigurationen Hersteller- und Modell-abhängig sind. Vorteilhafterweise können mit dem erfindungsgemäßen Werkzeug alle verfügbaren Kommunikationsfunktionalitäten bereits in der Konfigurationsphase bereitgestellt werden und zwar unabhängig von dem jeweiligen Hersteller und dem jeweiligen Modell des DICOM-Knotens. Mit anderen Worten können mit einem gezielten Verfahren alle verfügbaren Kommunikationsfunktionalitäten Hersteller- und Modell-übergreifend bereitgestellt werden. In jedem Fall erfolgt das Bereitstellen automatisch, sodass es nicht notwendig ist, die Konformitätserklärung zu analysieren (weder manuell noch automatisch).
Als Vorteil ist nochmal hervorzuheben, dass der erfindungsgemäße Ansatz auch zur Umkonfiguration von bereits konfigurierten DICOM-Knoten verwendet werden kann. Dies ist beispielsweise dann sinnvoll, falls neue Bestandsknoten weitere Funktionalitäten zur Verfügung stellen oder weitere Geräte dem DICOM-Netzwerk hinzugeschaltet werden.
Nochmals zurückkommend auf den in 2 geschilderten Ablauf ist hervorzuheben, dass es grundsätzlich zwei Möglichkeiten gibt, die Test-Verbindungsanfragen 1, 2, 3, 5 zu generieren. Zum einen ist es möglich, diese sequentiell auszuführen, sodass also auf eine erste Verbindungsanfrage 1 immer die jeweilige Verbindungsantwort 2 abgewartet und ausgewertet wird. Dann wird in einem nächsten Schritt die nächste Verbindungsanfrage 3 und deren Antwort 4 verarbeitet. Zum Anderen ist es möglich, von diesem sequentiellen Vorgehen abzuweichen und bereits parallel alle oder ausgewählte Test-Verbindungsanfragen 1, 2, 3, 5, ... zu generieren und an die unterschiedlichen Kommunikationspartner SCP zu versenden, um daraufhin deren Antworten 2, 4, 6 zu verarbeiten.
Die in 1 dargestellten weiteren Knoten SCU, SCP sollen kennzeichnen, dass dem DICOM-Netzwerk eine Vielzahl von DICOM-Knoten angehören kann, deren Interoperabilität mit dem erfindungsgemäßen Werkzeug überprüft werden kann.
Das Ergebnis des Verbindungsanalysators 20 wird gespeichert und kann für die weitere Betriebsphase oder für weitere Konfigurationsvorgänge bzw. für eine Anpassung des bestehenden DICOM-Netzwerkes wiederverwendet werden.
Da die DICOM-Kommunikation auf einem Client-Servermodell basiert, kann auch das erfindungsgemäße Verfahren nach dem Client-Serverprinzip ablaufen. Dabei können einzelne Verfahrensschritte auch auf unterschiedlichen Computer-basierten Instanzen und sozusagen in einem verteilten System ausgeführt werden. So kann insbesondere das Erfassen der verfügbaren Kommunikationsfunktionalität auf einer anderen Computerbasierten Instanz ausgeführt werden als das Bereitstellen der erfassten Kommunikationsfunktionalität. Üblicherweise erfolgt das automatische Erfassen auf dem Verbindungsanalysator 20 und das Bereitstellen der erfassten Kommunikationsfunktionalität erfolgt auf der jeweiligen SCU bzw. auf der Benutzeroberfläche der SCU.
Bezugszeichenliste

DICOM: DICOM-Netzwerk
SCU: Service Class User
SCP: Service Class Provider
20: Verbindungsanalysator/DICOM Connectivity Analyzer – DNCA
1, 3, 5 ...: (Test-)Verbindungsanfrage
2, 4, 6, ...: (Test-) Verbindungsantwort
100: Erfasse Konfigurationsauftrag für einen DICOM-Knoten
110: Binde zu konfigurierenden Knoten in Netzwerk ein
120: Erfasse Applikationen auf den zu konfigurierenden Knoten
130: Erfasse für die Applikationen erforderliche Kommunikationsfunktionalitäten
140: Automatisches Generieren einer Test-Verbindungsanfrage
150: Ausführen der Test-Verbindungsanfrage
160: Empfange Test-Ergebnis als Antwort auf die Test-Verbindungsanfrage
170: Verarbeite Test-Ergebnis der Verbindungsantwort 2, 4, 6,
180: Konfiguriere den Knoten anhand des Ergebnisses
190: Inbetriebnahme des konfigurierten Knotens

Claims

Verfahren zur Bestimmung von verfügbaren Kommunikationsfunktionalitäten bei der Konfiguration von zumindest einem DICOM-Gerät in einem DICOM-Netzwerk, mit folgenden Verfahrensschritten: – Automatisches Erfassen der verfügbaren Kommunikationsfunktionalität des DICOM-Gerätes (SCU, SCP) – Bereitstellen der erfassten Kommunikationsfunktionalität zur Konfiguration des DICOM-Gerätes (SCU, SCP) vor einer Verbindungsanfrage des DICOM-Gerätes (SCU, SCP).
Verfahren nach Anspruch 1, bei dem das Bereitstellen der erfassten Kommunikationsfunktionalität automatisch und bereits in einer Konfigurationsphase für das DICOM-Gerät (SCU, SCP) und somit vor dessen Inbetriebnahme mit konkreten Verbindungsaushandlungen ausgeführt wird.
Verfahren nach zumindest einem der vorstehenden Ansprüche, bei dem ein DICOM-Gerät als Service Class Provider (SCP) und/oder ein DICOM-Gerät als Service Class User (SCU) fungiert.
Verfahren nach zumindest einem der vorstehenden Ansprüche, bei dem für mehrere DICOM-Geräte (SCU, SCP) Kommunikationsfunktionalitäten bestimmt werden.
Verfahren nach zumindest einem der vorstehenden Ansprüche, bei dem das Verfahren zusätzlich folgenden Verfahrensschritt umfasst: – Bestimmen aller für eine Anwendung erforderlichen Kommunikationsfunktionalitäten.
Verfahren nach Anspruch 5, bei dem die bestimmten erforderlichen Kommunikationsfunktionalitäten mit den erfassten verfügbaren Kommunikationsfunktionalitäten verglichen werden und bei dem automatisch bei Nicht-Übereinstimmung eine Fehler-Nachricht generiert wird.
Verfahren nach Anspruch 6, bei dem bei Nicht-Übereinstimmung eine Zusatzkommunikationsfunktionalität bereitgestellt wird, wobei die Zusatzkommunikationsfunktionalität insbesondere auf einem Service Class User (SCU) für einen entfernten Service Class Provider (SCP) bereitgestellt wird.
Verfahren nach zumindest einem der vorstehenden Ansprüche, bei dem nicht verfügbare Kommunikationsfunktionalitäten auf einer Benutzeroberfläche eines Service Class Users (SCU) als nicht unterstützt dargestellt werden, während verfügbare Kommunikationsfunktionalitäten als unterstützt dargestellt werden.
Verfahren nach zumindest einem der vorstehenden Ansprüche, bei dem die verfügbaren Kommunikationsfunktionalitäten für ein entferntes DICOM-Gerät (SCU, SCP) unter Verwendung des DICOM-Protokolls erfasst werden.
Computerprogrammprodukt, das direkt in einen internen Speicher eines digitalen Computers geladen werden kann und Softwarecodeabschnitte umfasst, mit denen die Schritte gemäß zumindest einem der Verfahrensansprüche ausgeführt werden, wenn das Computerprogrammprodukt auf einem Computer läuft.
Verbindungsanalysator (20) zur Verwendung mit einem DICOM-Gerät (SCU, SCP) bei der Konfiguration eines DICOM-Gerätes zur Bestimmung von dessen verfügbaren Kommunikationsfunktionalitäten in einem DICOM-Netzwerk, mit: – Zumindest einem Erfassungsmodul, das zum automatischen Erfassen der verfügbaren Kommunikationsfunktionalität des DICOM-Gerätes ausgebildet ist; – Zumindest einem Bereitstellungsmodul, das zum Bereitstellen der erfassten Kommunikationsfunktionalität zur Konfiguration des DICOM-Gerätes (SCU, SCP) vor einer Verbindungsanfrage des DICOM-Gerätes bestimmt ist.
System aus medizinischen und/oder informationstechnologischen DICOM-Netzwerkgeräten (SCU, SCP, 20), umfassend: – Eine Vielzahl von DICOM-Geräten – Zumindest ein zu konfigurierendes DICOM-Gerät – Zumindest einen Verbindungsanalysator (20) nach Anspruch 11.