Daniel Gosch & Hannes Stornig

Präsentation zum Thema: "Daniel Gosch & Hannes Stornig"—  Präsentation transkript:

1 Daniel Gosch & Hannes Stornig
Design und prototypmäßige Implementierung von Komponenten zum Datenaustausch von DICOM-Objekten in einem DICOM-Verarbeitungsframework

2 Themen Überblick DICOM Problembeschreibung Fragestellungen
Software Prototyp

3 Themen Überblick DICOM Problembeschreibung Fragestellungen
Bachelorarbeit Anforderungsbeschreibung Anforderungen an das System DICOM Problembeschreibung Fragestellungen Software Prototyp

4 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

5 Anforderungsbeschreibung
Framework entwickeln Persistent Fehlerfrei Verarbeitung von DICOM Files Prozesse in Transaktionen gliedern Fehlverhalten -> Rollback Konsistenter Datenstand des Framework

6 Anforderungen an das System
Technische Ansprüche an die Infrastruktur Applikation Server (Glasfish 3.x) Java Development Kit 1.6 Relationale Datenbank Postgres 9.x

7 Themen Überblick DICOM Problembeschreibung Fragestellungen
Allgemein Was ist DICOM DICOM File Problembeschreibung Fragestellungen Software Prototyp

8 Allgemein Medizinische Bilder für Diagnostik Art der Bildgebung
Organe, Skelett, Muskel, Blutgefäße Verfahren Röntgen Magnet Resonanz Tomographie Positronen Emissions Tomographie

9 Was ist DICOM Richtlinien für digitale Medien
Standard für medizinische Bilder -> Bilder in einem einheitlichen Format speichern

10 DICOM File Bild (Röntgen) / Bilderserie (MRT) Liste von Datenelementen
Informationen zum Patienten Identifikationsnummer Informationen zur Aufnahme DICOM Standard definiert exakt welche Informationen enthalten sein müssen bzw. welche optional sind Jedes Bild verfügt über die notwendigen Informationen

11 Themen Überblick DICOM Problembeschreibung Fragestellungen
Programmiersprache Persistenz Queue Datenbankanforderungen Performance Fragestellungen Software Prototyp

12 Programmiersprache JAVA Enterprise Edition Funktionalität
Klassenbibliotheken des Toolkits dcm4che2 Objektorientierte Programmiersprache GNU Lizenz Eigene Laufzeitumgebung -> verschiedenen Rechenarchitekturen einsetzbar

13 Persistenz Java Persistence API (JPA) -> Speicherung der Daten in eine Datenbank Daten bleiben über die Ausführungszeit des Frameworks erhalten Java Transaktion API (JTA) –> Zugriff auf Daten Gewährleistet vollständige oder keine Übertragung der Daten Rollback im Fehlverhalten Konsistenter Datenstand

14 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 add() pool() peek() Queue

15 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

16 Performance DICOM Files mehrere 100 MB groß
Persistierung in der Datenbank Schlechte Performance Speicherung auf sekundär Datenträger Surrogaten (Platzhalterobjekte) in der Datenbank Referenz auf DICOM File Bedarfsfall Informationen nachladen

17 Performance Überlegungen: Mehrere Referenzen auf ein DICOM File
Ein und dasselbe DICOM File kommt mehrmals vor Großer Speicherbedarf Wenn ein DICOM File in mehreren Queues DcmFile Surrogat Queue 1 Queue 2 Queue 3

18 Performance Lösung: Nur beim ersten mal ins Filesystem schreiben
Surrogat bekommen beim kopieren in eine weitere Queue nur mehr eine Referenz auf das DICOM File DcmFile Surrogat Queue 1 Queue 2 Queue 3

19 Performance Wann darf ein DICOM File gelöscht werden?
afterCompletion() Methode des Transaktions-Managers Methodenaufruf 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

20 Themen Überblick DICOM Problembeschreibung Fragestellungen
Data Queue (DQ) Processing Node (PN) Beziehungen zwischen PN und DQ Verarbeitungsgraph Helper Processing Node Transaktionsmanagement Software Prototyp

21 Data Queue Datenhaltung -> Prinzip einer Queue
Umsetzung dieser wird als Data Queue bezeichnet Prototyp -> DcmQueue Data Queue kümmert sich um Datenhaltung und Reihenfolge

22 Processing Node Managed die Zugriffe auf die Data Queue
Repräsentiert Geschäftslogik 2 Arten Producer -> Inputseitig => Erzeugung der Data Queue bzw. Surrogaten Consumer -> Outputseitig => Verwaltung und Löschung der Data Queue bzw. Surrogaten

23 Beziehungen zwischen PN und DQ
Verschiedene Möglichkeiten Nutzen für unser Framework im Mittelpunkt 4 Fälle Vorteile Nachteile

24 Beziehungen zwischen PN und DQ
Processing Node Fall 1 Kardinalität 1 zu 0 PN steht mit keiner DQ in Verbindung -> nicht möglich Objekte an die DQ zu senden 1 Input Data Queue Output 1 Processing Node

25 Beziehungen zwischen PN und DQ
Processing Node Fall 2 Kardinalität 1 zu 1 Jede PN ist genau mit einer DQ verbunden Jede DQ ist genau mit einer PN verbunden Kommunikation zwischen PN und DQ möglich -> komplexes Verhalten nicht möglich 1 1 Input Data Queue Output 1 1 Processing Node

26 Beziehungen zwischen PN und DQ
Processing Node Fall 3 Kardinalität 0…n zu 0…n Jede PN steht mit beliebig vielen DQ in Verbindung Jede DQ steht mit beliebig vielen PN in Verbindung Komplexe Kommunikation möglich -> kann jedoch schnell unübersichtlich Ausmaß annehmen => komplexe Verfahren zur Datenbewältigung 0…n 0…n Input Data Queue Output 0…n 0…n Processing Node

27 Beziehungen zwischen PN und DQ
Processing Node Fall 4 Kardinalität 1 zu 0…n Jede 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 1 0…n Input Data Queue Output 0…n 1 Processing Node

28 Verarbeitungsgraph Anzahl der DQ welche durch PN repräsentiert werden hängt von der Art der PN ab Normalfall PN 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

29 Verarbeitungsgraph Zwei Typen von PN haben nur eine Input- bzw. eine Outputseite Jene die sich am äußeren Rand des Verarbeitungsgraphen befinden Producer PN können Daten empfangen und in den Verarbeitungsgraphen einfügen Consumer PN können Daten aus dem Verarbeitungsgraphen in ein File System speichern

30 Verarbeitungsgraph

31 Helper Processing Node
Vereinigung / Merging Objekte unterschiedlicher DQ`s werden durch die HPN auf eine DQ zusammengefasst Data Queue 1 Data Queue 3 Data Queue 2 Helper Processing Node Data Queue

32 Helper Processing Node
Verteilung / Sharing Objekte einer DQ werden durch die HPN auf mehrere DQ`s verteilt Data Queue Helper Processing Node Data Queue 1 Data Queue 3 Data Queue 2

33 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 pseudonymisiert Data Queue Helper Processing Node Data Queue Data Queue Processing Node +anonymisieren() Processing Node +pseudoymisieren()

34 Transaktionsmanagement