View
271
Download
0
Category
Preview:
Citation preview
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 Key Value
Rule1 Matching_00080090 Physician_1
Action Action1
Rule2 Matching_00080090 Physician_2
Action Action2
Rule3 Matching_00080090 Physician_3
Action Action3
NO_ACTION Action NoAction
Actions: 4 verschiedene Actions mit SCU Aktion und/oder lokaler Speicherung auf dem
Gateway Rechner, config-Datei AET1_Actions.conf
Section Key Value
Action1 ScuCommand storescu localhost 106
StoreRoot d:\DICOM_GatewayRoot\Domain1
Action2 ScuCommand storescu localhost 106
Action3 ScuCommand storescu localhost 106
NoAction ScuCommand storescu –aet GARBAGE localhost 107
StoreRoot 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 Key Value
Port106 WorkingDirectory d:\DICOM_GatewayRoot\incoming\Port106
Port 106
Port107 WorkingDirectory d:\DICOM_GatewayRoot\incoming\Garbage
Port 107
Port105 WorkingDirectory d:\DICOM_GatewayRoot\incoming\Port105
Port 105
GatewayOption -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
10. Dicom Gateway Web
Änderungen zum UI Prototype:
Q/R
RestartAll/StopAll
Testcenter
Logging
Homepage Erweiterung
RestartAll
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
Image Viewer
Query
Neben der Darstellung einer DB Location in einem Treeview wird eine Query über alle
angeschlossenen Datenbanken angeboten.
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 Elapsed Zeit im Sender
Fall 1 storescp 105 1.4 sec
Fall 2 storescp -xcr " RouteDicom.bat #f" 105 RouteDicom.bat: storescu localhost 106 %1 Weiterer Dicom Empfänger mit storescp 106
4.5 sec
Fall 3 storescp -sp -tos 1 -xcs " RouteDicomAll.bat #p" 105 RouteDicomAll.bat: storescu +sd localhost 106 %1 Weiterer Dicom Empfänger mit storescp 106 Das Weiterschicken Bilder wird mit einen Delay von 1 Sekunde (-tos 1) asynchron gestartet, nachdem alle Bilder empfangen wurden.
1.6 sec
Fall 4 storescp -xcr "DGHandleInstance #f #a" 105 DGHandleInstance.exe: lädt Bild, prüft Regeln und appliziert Actions. Dicom Empfänger mit storescp –aet GARBAGE 107
5.8 sec
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 Art der Konfiguration (Editor, Win32, Web basiertes UI)? Format?
Antwort: Editor Lösung reicht für den Anfang.
o Welche DICOM Attribute sollen für die Entscheidungen im Gateway berücksichtigt
werden?
Antwort: Study und Series Attribute konfigrierbar
o Art des JobControllers (Batch File, Windows Prozeß)? Parallele Receiver?
Antwort: DICOM Gatweway kann einfach gestaltet sein, mehrere Empfänger
o Weiterverteilung der Bilder mit storescu oder mit anderen Programmen?
Antwort: storescu und lokale Speicherung im Gateway
o Error Logging? Was ist, wenn keine Regel zutrifft?
Antwort: Logging Konzepte sehr wichtig, konfigrierbare NO_ACTION Aktionen.
o Fremdsoftware Betrachtungen? Produkte wie z.B. Compass
(http://www.laurelbridge.com/compass.html)
Antwort: irrelevant
o Performance Einbußen?
Antwort: vorerst nicht so wichtig
o Integrationsstrategie?
Antwort: extra System, erster Prototyp sollte ASAP geliefert werden
o Hardware?
Antwort: wird von Alex Vogel gestellt
Recommended