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