DESIGN UND PROTOTYPMÄẞIGE
IMPLEMENTIERUNG VON KOMPONENTEN ZUM
DATENAUSTAUSCH VON DICOM-OBJEKTEN IN EINEM
DICOM-VERARBEITUNGSFRAMEWOR
K
Daniel Gosch & Hannes Stornig
Themen
Überblick DICOM Problembeschreibung Fragestellungen Software Prototyp
Themen
ÜberblickBachelorarbeitAnforderungsbeschreibungAnforderungen an das System
DICOM Problembeschreibung Fragestellungen Software Prototyp
Bachelorarbeit
Detaillierter Überblick über einzelne Probleme und Fragestellungen
Lösungsansätze zu konkreten Fällen präsentieren
Grundlagenforschung für ein Framework
Kritische Punkte im Entwicklungsprozess
Anforderungsbeschreibung Framework entwickeln
PersistentFehlerfreiVerarbeitung von DICOM FilesProzesse in Transaktionen gliedernFehlverhalten -> RollbackKonsistenter Datenstand des Framework
Anforderungen an das System
Technische Ansprüche an die InfrastrukturApplikation Server (Glasfish 3.x)Java Development Kit 1.6Relationale Datenbank Postgres 9.x
Themen
Überblick DICOM
AllgemeinWas ist DICOMDICOM File
Problembeschreibung Fragestellungen Software Prototyp
Allgemein
Medizinische Bilder für Diagnostik Art der Bildgebung
Organe, Skelett, Muskel, Blutgefäße Verfahren
RöntgenMagnet Resonanz TomographiePositronen Emissions Tomographie
Was ist DICOM
Richtlinien für digitale Medien
Standard für medizinische Bilder -> Bilder in einem einheitlichen Format speichern
DICOM File
Bild (Röntgen) / Bilderserie (MRT) Liste von Datenelementen
Informationen zum PatientenIdentifikationsnummerInformationen zur Aufnahme
DICOM Standard definiert exakt welche Informationen enthalten sein müssen bzw. welche optional sindJedes Bild verfügt über die notwendigen
Informationen
Themen Überblick DICOM Problembeschreibung
ProgrammiersprachePersistenzQueueDatenbankanforderungenPerformance
Fragestellungen Software Prototyp
Programmiersprache
JAVA Enterprise EditionFunktionalitätKlassenbibliotheken des Toolkits dcm4che2Objektorientierte ProgrammierspracheGNU LizenzEigene Laufzeitumgebung -> verschiedenen
Rechenarchitekturen einsetzbar
Persistenz
Java Persistence API (JPA) -> Speicherung der Daten in eine DatenbankDaten bleiben über die Ausführungszeit des
Frameworks erhalten Java Transaktion API (JTA) –> Zugriff auf
DatenGewährleistet vollständige oder keine
Übertragung der DatenRollback im FehlverhaltenKonsistenter Datenstand
Queue
Datenstruktur FiFo (First in First out) Verfahren
Erste Datei die in die Queue aufgenommen wird ist auch die erste die diese wieder verläst
Konstante Reihenfolge
DcmFile DcmFile
DcmFile
DcmFileadd()
pool()
peek()
DcmFile
Queue
Datenbankanforderungen ACID Richtlinien
Transaktionen müssen○ Atomar -> ganz oder gar nicht○ Konsistenz -> definierte
Integritätsbedingungen (Primärschlüssel / Fremdschlüssel)
○ Isoliert -> Transaktionen○ Dauerhaft -> nach Transaktionsende
persistent zur Verfügung stehen
Performance
DICOM Files mehrere 100 MB groß Persistierung in der Datenbank
Schlechte Performance Speicherung auf sekundär Datenträger Surrogaten (Platzhalterobjekte) in der
DatenbankReferenz auf DICOM FileBedarfsfall Informationen nachladen
Performance
Überlegungen:Mehrere Referenzen auf ein DICOM FileEin und dasselbe DICOM File kommt
mehrmals vorGroßer Speicherbedarf
○ Wenn ein DICOM File in mehreren Queues
DcmFile
DcmFile
DcmFile
Surrogat
Queue 1
Surrogat
Queue 2
Surrogat
Queue 3
Performance
Lösung:Nur beim ersten mal ins Filesystem
schreibenSurrogat bekommen beim kopieren in eine
weitere Queue nur mehr eine Referenz auf das DICOM File
DcmFileSurrogat
Queue 1
Surrogat
Queue 2
Surrogat
Queue 3
Performance
Wann darf ein DICOM File gelöscht werden?
afterCompletion() Methode des Transaktions-ManagersMethodenaufruf nach jeder abgeschlossenen,
jedoch noch nicht beendeten TransaktionÜberprüfung auf Referenz in der Datenbank
auf ein DICOM File○ Falls NEIN -> Freigabe zur Löschung
Themen Überblick DICOM Problembeschreibung Fragestellungen
Data Queue (DQ)Processing Node (PN)Beziehungen zwischen PN und DQVerarbeitungsgraphHelper Processing NodeTransaktionsmanagement
Software Prototyp
Data Queue
Datenhaltung -> Prinzip einer Queue Umsetzung dieser wird als Data Queue
bezeichnet Prototyp -> DcmQueue
Data Queue kümmert sich um Datenhaltung und Reihenfolge
Processing Node
Managed die Zugriffe auf die Data Queue Repräsentiert Geschäftslogik
2 ArtenProducer -> Inputseitig => Erzeugung der
Data Queue bzw. SurrogatenConsumer -> Outputseitig => Verwaltung und
Löschung der Data Queue bzw. Surrogaten
Beziehungen zwischen PN und DQ Verschiedene Möglichkeiten
Nutzen für unser Framework im Mittelpunkt
4 FälleVorteileNachteile
Beziehungen zwischen PN und DQ
Fall 1Kardinalität 1 zu 0PN steht mit keiner DQ in
Verbindung -> nicht möglich Objekte an die DQ zu senden
Processing Node
Data Queue
Processing Node
Output
Input
1
0
0
1
Beziehungen zwischen PN und DQ
Fall 2Kardinalität 1 zu 1Jede PN ist genau mit
einer DQ verbundenJede DQ ist genau mit
einer PN verbundenKommunikation
zwischen PN und DQ möglich -> komplexes Verhalten nicht möglich
Processing Node
Data Queue
Processing Node
Output
Input
1
1
1
1
Beziehungen zwischen PN und DQ
Fall 3Kardinalität 0…n zu 0…nJede PN steht mit beliebig
vielen DQ in VerbindungJede DQ steht mit beliebig
vielen PN in VerbindungKomplexe Kommunikation
möglich -> kann jedoch schnell unübersichtlich Ausmaß annehmen => komplexe Verfahren zur Datenbewältigung
Processing Node
Data Queue
Processing Node
Output
Input0…n
0…n
0…n
0…n
Beziehungen zwischen PN und DQ
Fall 4Kardinalität 1 zu 0…nJede PN kann mit beliebig
vielen DQ in Verbindung stehen
Jede DQ jedoch nur mit einer PN
Ausreichende Kommunikation zwischen PN und DQ -> Verhinderung zu komplexer Strukturen
Processing Node
Data Queue
Processing Node
Output
Input
1
1
0…n
0…n
Verarbeitungsgraph Anzahl der DQ welche durch PN
repräsentiert werden hängt von der Art der PN ab
NormalfallPN hat ein oder mehrere Input und Output DQ`s
PN ist für den Datenfluss zwischen den einzelnen DQ verantwortlich
Jede DQ hat dabei eine genau definierte Input als auch Outputseite und steht immer mit genau einer PN in Verbindung
Verarbeitungsgraph
Zwei Typen von PN haben nur eine Input- bzw. eine OutputseiteJene die sich am äußeren Rand des
Verarbeitungsgraphen befindenProducer PN können Daten empfangen und
in den Verarbeitungsgraphen einfügenConsumer PN können Daten aus dem
Verarbeitungsgraphen in ein File System speichern
Verarbeitungsgraph
Helper Processing Node Vereinigung /
MergingObjekte
unterschiedlicher DQ`s werden durch die HPN auf eine DQ zusammengefasst
Data Queue 1
Helper Processing
Node
Data Queue 2
Data Queue 3
Data Queue
Helper Processing Node Verteilung / Sharing
Objekte einer DQ werden durch die HPN auf mehrere DQ`s verteilt
Data Queue 1
Helper Processing
Node
Data Queue 2
Data Queue 3
Data Queue
Helper Processing Node Aufteilung / Splitting
Ein Objekt wird durch die HPN an unterschiedliche DQ`s gesendet und unterschiedlich verarbeitet○ Bsp.: ein Objekt wird
anonymisiert und pseudonymisiertData Queue
Helper Processing
Node
Data Queue
Data Queue
Processing Node
+anonymisieren()
Processing Node
+pseudoymisieren()
Transaktionsmanagement