Daniel Gosch & Hannes Stornig

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

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 Queue 1 Queue 2 Queue 3 Surrogat Surrogat Surrogat DcmFile DcmFile DcmFile

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 Queue 1 Queue 2 Queue 3 Surrogat Surrogat Surrogat DcmFile

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 • Fall 1 • Kardinalität 1 zu 0 • PN steht mit keiner DQ in Verbindung -> nicht möglich Objekte an die DQ zu senden Processing Node 1 0 Input Data Queue Output 0 1 Processing Node

25. Beziehungen zwischen PN und DQ • 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 Processing Node 1 1 Input Data Queue Output 1 1 Processing Node

26. Beziehungen zwischen PN und DQ • 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 Processing Node 0…n 0…n Input Data Queue Output 0…n 0…n Processing Node

27. Beziehungen zwischen PN und DQ • 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 Processing Node 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