DICOM Gateway

DICOM Gateway
1. Einführung
Das DICOM Gateway empfängt DICOM Bilder und verteilt sie an die angeschlossenen
DICOM Workstations in Abhängigkeit von DICOM Attributen wie z.B. den Referring
Physician (0008,0090). Das DICOM Gateway hat auch PACS Funktionalität und speichert
die Bilder lokal. Über DICOM Query/Retrieve werden die Bilder an anfordernde Stellen
gesendet.
2. Historie des Dokumentes
22.11.2013
hw
V0.1
Erstellung
26.11.2013
hw
V0.2
Einarbeitung Diskussion mit A.Vogel
27.11.2013
hw
V0.3
Definition Struktur DICOM Gateway, Prototype Intermediate
06.12.2013
hw
V0.4
Query/Retrieve, Prototype Q/R, Logging
09.12.2013
hw
V0.5
UI Prototyping
15.12.2013
hw
V0.6
Dicom Gateway Web, Active, Testcenter, Q/R
17.12.2013
hw
V0.7
Datenbank Query
10.01.2014
hw
V0.8
Query, Queue Manager/Watchdog
3. Architektur
Das DICOM Gateway ist ein Rechnersystem mit konfigurierbaren Services (DICOM
Empfänger, Sender, Query/Retrieve). Die empfangenen Bilder können optional lokal
gespeichert werden. Die Speicher-Struktur könnte folgendermaßen aussehen.
In einem weiteren Schritt können Query Services implementiert werden, die Domain
spezifisch Bilder an anfordernde Services ausliefern.
4. Workflow
5. Tools
Für den DICOM Empfänger wird storescp aus dem DICOM Toolkit dcmtk von OFFIS
verwendet (http://dicom.offis.de/dcmtk.php.de). Storescp ist geeignet, weit verbreitet,
kostenfrei und flexibel, daher für den Einsatz in einem DICOM Gateway erste Wahl
(http://support.dcmtk.org/docs/storescp.html)
Storescu ist ein DICOM Sender mit dem die empfangenen DICOM Bilder beliebig
weitergeschickt werden können (http://support.dcmtk.org/docs/storescu.html)
Für DICOM Query/Retrieve kann dcmqrscp von OFFIS eingesetzt werden
(http://support.dcmtk.org/docs/dcmqrscp.html). Zum Indexieren der Bilddateien wird Tool
dcmqridx verwendet (http://support.dcmtk.org/docs/dcmqridx.html). Die Index Datenbanken
können mit Tool dcmqrti getestet werden (http://support.dcmtk.org/docs/dcmqrti.html). Als
Testtools für die Q/R SCU stehen findscu und movescu z.V
(http://support.dcmtk.org/docs/findscu.html, http://support.dcmtk.org/docs/movescu.html). Eine
Anleitung für dcmqrscp und dcmqrti steht in http://support.dcmtk.org/docs/file_dcmqrset.html
sowie http://support.dcmtk.org/docs/file_dcmqrcnf.html
6. Prototype Basic
Die prinzipielle Funktionsweise kann mit einfachen Mitteln demonstriert werden. Hierfür
werden DICOM Bilder mit storescu and den storescp geschickt. Innerhalb storescp wird das
Batch File ShowDicom.bat aufgerufen das mit dem Programm dcmdump den Referring
Physician ausgibt.
Die Programme des dcmtk werden auf ein Verzeichnis extrahiert, die Path Variable
ensprechend erweitert.
Fenster 1 (Sender): sendet 4 Testbilder (Enhanced MR Image) an localhost auf Port 105
Fenster 2 (Empfänger): empfängt auf Port 105 die Bilder und ruft für jedes Bild das Script
ShowDicom.bat auf.
ShowDicom.bat: Ausgabe des Attributes Referring Physician (0008,0090)
ShowDicom.bat läßt sich um regelbasierte Entscheidungen erweitern aufgrund derer die
Bilder an die Zielsysteme weitergeroutet werden können.
7. Prototype Intermediate
In einem weiteren Prototypen sind Rules, Actions und Receiver definiert. Anbei Beispiele, die
als Windows Ini File Format implementiert sind.
Rules: 3 verschiedene Rules + NO_ACTION, config-Datei AET1_Rules.conf
Section
Rule1
Rule2
Rule3
NO_ACTION
Key
Matching_00080090
Action
Matching_00080090
Action
Matching_00080090
Action
Action
Value
Physician_1
Action1
Physician_2
Action2
Physician_3
Action3
NoAction
Actions: 4 verschiedene Actions mit SCU Aktion und/oder lokaler Speicherung auf dem
Gateway Rechner, config-Datei AET1_Actions.conf
Section
Action1
Action2
Action3
NoAction
Key
ScuCommand
StoreRoot
ScuCommand
ScuCommand
ScuCommand
StoreRoot
Value
storescu localhost 106
d:\DICOM_GatewayRoot\Domain1
storescu localhost 106
storescu localhost 106
storescu –aet GARBAGE localhost 107
d:\DICOM_GatewayRoot\UndefinedRule
Die 80 Beispielsbilder wurden gepatched (10 – Physician_1, 10 – Physician_2, 10 –
Physician_3, 10 – Physician_4, 40 Bilder ohne Referring Physician)
Bilder mit Physician_1 werden an Port 106 weitergeleitet und auf dem Gateway in Domain1
gespeichert.
Bilder mit Physician_2 werden an Port 106 weitergeleitet.
Bilder mit Physician_3 werden an Port 106 weitergeleitet.
Alle anderen Bilder werden an Port 107 und AET GARBAGE weitergeleitet und auf dem
Gateway in UndefinedRule gespeichert
Receivers: 3 verschiedene DICOM Empfänger. config-Datei Receivers.conf
Section
Port106
Port107
Port105
Key
WorkingDirectory
Port
WorkingDirectory
Port
WorkingDirectory
Port
GatewayOption
Value
d:\DICOM_GatewayRoot\incoming\Port106
106
d:\DICOM_GatewayRoot\incoming\Garbage
107
d:\DICOM_GatewayRoot\incoming\Port105
105
-xcr "DGHandleInstance #f #a"
Auf Basis dieser Attribute kann ein Job Controller die verschiedenen DICOM Receiver
starten. Im einfachsten Fall ist dies ein Batch File wie z.B.
In einem weiteren Schritt übernimmt ein Job Controller den Start der verschiedenen Services
Der Test-Sender verschickt die 80 Bilder an Port 105 und mißt die Zeit.
8. Prototype Q/R
Fallbeispiel: Erzeugen von 10 Bildern mit



2 Patienten (Pat1, Pat2)
4 Studien
5 Serien
Pat1 soll in DB Index AET1, Pat2 in AET2 indexiert werden. Dies kann auf 3 verschiedene
Arten implementiert werden:



Index image files (e.g. dcmqridx –v d:\ DICOM_GatewayRoot\DB\AET1 Pat1*.dcm)
Send images to storescp mit DGHandleInstance und integriertem dcmqridx
Send images directly to dcmqrscp
Nachfolgend Snapshots mit dcmqrscp als DICOM Empfänger und Q/R Service.
Dcmqrscp ConfigDatei und Start von dcmqrscp
Senden der AET spezifischen Bilder
Test der Q/R Datenbank
Move der AET spezifischen Daten, AET1 -> AET1SEND auf Port 107, AET2 -> AET2SEND
auf Port 108
AET1SEND, AET2SEND Storage SCP’s mit Test der empfangenen Bilder
9. UI Prototyping
Im Wesentlichen soll aufgezeigt werden, wie das DICOM Gateway einfach visualisiert
werden kann. Hierbei geht es um die Darstellung der Server sowie der AET spezifischen
Eigenschaften (was geschieht mit den Bildern?). Darüberhinaus kann Dokumentation
jeglicher Art hinterlegt werden.
In einem weiteren Schritt können Editier-Funktionen sowie Restart-Operationen integriert
werden (TBD).
Homepage
Receiver
AET Rules
10. Dicom Gateway Web
Änderungen zum UI Prototype:




Q/R
RestartAll/StopAll
Testcenter
Logging
Homepage Erweiterung
RestartAll
Testcenter
Testcenter Submit
Q/R
Logging
11. Datenbank Query
Die verschiedenen Datenbank Speicherbereiche (Root Directories) können selektiert
werden. Daraufhin werden alle Bilder gelesen und in einem Tree Control gemäß der DICOM
Hierarchie Patient/Study/Series dargestellt. Die Serien-Ebene ist als Hypertext Link
dargestellt. Die DICOM Bilder der ausgewählten Serie werden im WebBrowser dargestellt
(PNG Format).
Homepage
Database locations
TreeControl
Image Viewer
Query
Neben der Darstellung einer DB Location in einem Treeview wird eine Query über alle
angeschlossenen Datenbanken angeboten.
Query form
Query results
Queue Manager/Watchdog
Fehlerhafte Kopieraufträge aus dem Testcenter werden gequeued.
Testcenter
Sendelog
Der Watchdog versucht zyklisch, die aufgelaufenen Aufträge abzuarbeiten und verschiebt sie
bei Erfolg in den Done Ordner.
D:\DICOM_GatewayRoot\Queue>dg_wd
handleJob>>root_dir=D:\DICOM_GatewayRoot\Queue,
file=D:\DICOM_GatewayRoot\Queue\02_CJ_20140110100727.539.
system_command storescu localhost 106
D:\UserLib\DICOM_Gateway\test\images_qr\*<br>
handleJob>>root_dir=D:\DICOM_GatewayRoot\Queue,
file=D:\DICOM_GatewayRoot\Queue\02_CJ_20140110100728.743.
system_command storescu localhost 107
D:\UserLib\DICOM_Gateway\test\images_qr\*<br>
handleJob>>root_dir=D:\DICOM_GatewayRoot\Queue,
file=D:\DICOM_GatewayRoot\Queue\02_CJ_20140110100729.966.
system_command storescu localhost 106
D:\UserLib\DICOM_Gateway\test\images_anon\*<br>
D:\DICOM_GatewayRoot\Queue>dir done
Datenträger in Laufwerk D: ist DATA
Volumeseriennummer: E90D-F090
Verzeichnis von D:\DICOM_GatewayRoot\Queue\done
10.01.2014 10:14 <DIR>
.
10.01.2014 10:14 <DIR>
..
10.01.2014 10:07
64 02_CJ_20140110100727.539
10.01.2014 10:07
64 02_CJ_20140110100728.743
10.01.2014 10:07
66 02_CJ_20140110100729.966
10.01.2014 10:07
66 02_CJ_20140110100731.176
4 Datei(en),
260 Bytes
2 Verzeichnis(se), 183.143.002.112 Bytes frei
D:\DICOM_GatewayRoot\Queue>
12. Performance
Die Integration eines DICOM Gateways hat Auswirkungen auf die Performance. Bilder
müssen auf dem Gateway Rechner zwischengespeichert, ausgewertet und weitergeleitet
werden.
Nachfolgend eine Performance Untersuchung mit 80 Bildern a 340 kB und den Testfällen:




Fall 1: Kein Routing, Bildern werden empfangen und gespeichert
Fall 2: Nach jedem empfangenen Bild wird es auf einem anderen Port
weitergeschickt
Fall 3: Am Ende der Association bzw. bei Änderung der Study werden die Bilder auf
einmal weitergeschickt
Fall 4: Parsen aller Bilder und Weiterschicken an AET Garbage (kein Matching)
Fall
Beschreibung
Fall 1
Fall 2
storescp 105
storescp -xcr " RouteDicom.bat #f" 105
Elapsed
Zeit im
Sender
1.4 sec
4.5 sec
RouteDicom.bat: storescu localhost 106 %1
Fall 3
Weiterer Dicom Empfänger mit storescp 106
storescp -sp -tos 1 -xcs " RouteDicomAll.bat #p" 105
1.6 sec
RouteDicomAll.bat: storescu +sd localhost 106 %1
Weiterer Dicom Empfänger mit storescp 106
Fall 4
Das Weiterschicken Bilder wird mit einen Delay von 1
Sekunde (-tos 1) asynchron gestartet, nachdem alle Bilder
empfangen wurden.
storescp -xcr "DGHandleInstance #f #a" 105
5.8 sec
DGHandleInstance.exe: lädt Bild, prüft Regeln und appliziert
Actions.
Dicom Empfänger mit storescp –aet GARBAGE 107
Da Referring Physician’s Name (0008,0090) ein Attribute des General Study Module ist, ist
es möglich, Fall 3 ohne nennenswerten Performance-Verlust zu implementieren. Es ist
ausreichend lediglich ein Bild zu untersuchen zu untersuchen, um die Routing Regel zu
bestimmen.
16. Logging
Jeder Server aus dem OFFIS dcmtk protokolliert seine Aktionen in separaten Logfiles.
Gesteuert wird dies über die Direktive –lc (z.B. -lc d:\DICOM_GatewayRoot\conf\log2file.cfg)
Die LogFile Config ist z.B.
Der Inhalt solch eines LogFiles ist z.B.
13. Offene Punkte
o
o
o
o
o
Art der Konfiguration (Editor, Win32, Web basiertes UI)? Format?
Antwort: Editor Lösung reicht für den Anfang.
Welche DICOM Attribute sollen für die Entscheidungen im Gateway berücksichtigt
werden?
Antwort: Study und Series Attribute konfigrierbar
Art des JobControllers (Batch File, Windows Prozeß)? Parallele Receiver?
Antwort: DICOM Gatweway kann einfach gestaltet sein, mehrere Empfänger
Weiterverteilung der Bilder mit storescu oder mit anderen Programmen?
Antwort: storescu und lokale Speicherung im Gateway
Error Logging? Was ist, wenn keine Regel zutrifft?
Antwort: Logging Konzepte sehr wichtig, konfigrierbare NO_ACTION Aktionen.
o
o
o
o
Fremdsoftware Betrachtungen? Produkte wie z.B. Compass
(http://www.laurelbridge.com/compass.html)
Antwort: irrelevant
Performance Einbußen?
Antwort: vorerst nicht so wichtig
Integrationsstrategie?
Antwort: extra System, erster Prototyp sollte ASAP geliefert werden
Hardware?
Antwort: wird von Alex Vogel gestellt