Bachelorarbeit Medizininformatik

Präsentation zum Thema: "Bachelorarbeit Medizininformatik"—  Präsentation transkript:

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

2 Themen Überblick DICOM Problembeschreibung Fragestellungen
Transaktionsmanagement Software Prototyp

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

4 Bachelorarbeit Detaillierter Überblick über einzelne Probleme und Fragestellungen Lösungsansätze zu konkreten Fällen präsentieren Grundlegende Techniken für ein Framework erarbeitet Kritische Punkte im Entwicklungsprozess

5 Anforderungsbeschreibung
Framework entwickeln Persistent Korrekte Fehlerbehandlung 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 DICOM Allgemein Was ist DICOM DICOM File Überblick
Problembeschreibung Fragestellungen Transaktionsmanagement 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 Digital Imaging and Communications in Medicine
Richtlinien für digitale Medien Standard für medizinische Bilder DICOM regelt unter anderem eine einheitliche Speicherung von Bildern

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 Problembeschreibung Überblick DICOM Programmiersprache
Persistenz / Transaktion Datenstruktur Datenbankanforderungen Performance Fragestellungen Transaktionsmanagement Software Prototyp

12 Programmiersprache JAVA Enterprise Edition
Klassenbibliotheken des Toolkits dcm4che2 Objektorientierte Programmiersprache Eigene Laufzeitumgebung  unabhängig von Rechenarchitektur Funktionalität

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

14 Datenstruktur Queue Konstante Reihenfolge
Primär FiFo (First in First out) Verfahren Erweiterter Zugriff auf Elemente in der Queue DcmFile add() pool() peek() Queue

15 Datenbankanforderungen
ACID Richtlinien Transaktionen müssen Atomar ganz oder gar nicht Konsistent definierte Integritätsbedingungen (Primärschlüssel / Fremdschlüssel) Isoliert Transaktionen Dauerhaft nach Transaktionsende persistent zur Verfügung stehen

16 Performance DICOM Files Persistierung in der Datenbank
oft >= 100 MB Persistierung in der Datenbank Schlechte Performance Speicherung auf sekundär Datenträger Surrogate (Platzhalterobjekte) in der Datenbank Referenz auf DICOM File Bedarfsfall Informationen nachladen

17 Performance Überlegungen:
Ein und dasselbe DICOM File kommt mehrmals vor Mehrere Referenzen auf ein DICOM File Großer Speicherbedarf Wenn DICOM File in mehreren Queues DcmFile ID 0112 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 ID 0112 Surrogat ID 0112 Queue 1 Queue 2 Surrogat Queue 3

19 Performance Wann darf ein DICOM File gelöscht werden? DcmFile ID 0112
Surrogat ID 0112 Queue 1 Queue 2 Surrogat Queue 3

20 Performance Wann auf Löschen überprüfen? Transaktions-Manager bietet:
afterCompletion() Methode Aufruf nach jeder abgeschlossenen, jedoch noch nicht beendeten Transaktion Überprüfung ob Referenz in der Datenbank auf ein DICOM File Falls NEIN -> Freigabe zur Löschung

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

22 Data Queue (DQ) Datenhaltung  Prinzip einer Queue
Umsetzung dieser wird als Data Queue bezeichnet Prototyp  DcmQueue Data Queue kümmert sich um Datenhaltung und Reihenfolge

23 Processing Node (PN) PN nutzt DQ um DICOM Objekte auszutauschen
Verarbeitungselement des Framework das DICOM Images verarbeitet 2 Rollen Producer  Inputseitig => Weitergabe der Ergebnisse Consumer  Outputseitig => DICOM Objekte die zur Bearbeitung anstehen zuzugreifen

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

25 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

26 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

27 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

28 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

29 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 Output-Seite und steht immer mit genau einer PN in Verbindung

30 Verarbeitungsgraph Zwei Typen von PN haben nur eine Input- bzw. eine Output-Seite Jene die sich am äußeren Rand des Verarbeitungsgraphen befinden Import PN bringen externe DICOM Daten zur Verarbeitung in den Verarbeitungsgraphen ein Export PN ermöglichen den Export von DICOM Daten aus dem Verarbeitungsgraphen z.B. als File in ein File System

31 Verarbeitungsgraph

32 Helper Processing Node (HPN)
Spezieller Typ einer PN Strategie Menge von PN -> eine Bestimmte Aufgabe übernehmen Zur Verteilung von Information Zur Vereinigung von Datenströmen

33 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

34 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

35 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 +pseudonymisieren()

36 Themen Transaktionsmanagement Überblick DICOM Problembeschreibung
Fragestellungen Transaktionsmanagement Container Managed Transaction Verhalten des Containers Rollback Software Prototyp

37 Transaktionsmanagement
Container Managed Transaction (CMT) EJB Container verwaltet automatisch Transaktionen innerhalb einer EJB Klasse oder Methode Entscheidet selbstständig ohne explizite Deklaration Keine Nested Transactions Transaktionskontext Durch EJB Container bestimmt

38 Verhalten des Containers
Container steuert Transaktionen weitgehend selbst Mittels Callback auf Verhalten des Container Einfluss nehmen @afterBeginn @beforeCompletion @afterCompletion

39 Rollback Im Falle eines Fehlers
Möglichkeiten zur Auslösung eines Rollback System Exception vorgemerkte Exceptions Methode setRollbackOnly() ermöglicht Jederzeit konsistenter Datenstand

40 Themen Software Prototyp Überblick DICOM Problembeschreibung
Fragestellungen Software Prototyp Interface DcmQueueProducerServiceRemote Interface DcmQueueConsumerServiceRemote Sequenzdiagramm

41 Software Prototyp Prototyp des Frameworks namens „DcmSPL“
Prototyp bietet Möglichkeit Warteschlange (Queue) erstellen DICOM Dummy Files an das Framework zu übergeben Persistierung der DICOM Dummy Files ins File System Übergibt Queue eine Referenz auf das DICOM Dummy File Bearbeitungsknoten können modular implementiert werden

42 Interface DcmQueueProducerServiceRemote
Inputseitig Methoden zur Erzeugung und Befüllung der DcmQueue creatDcmQueue() removeDcmQueue() addDcmFile() findDcmQueue()

43 Interface DcmQueueConsumerServiceRemote
Outputseitig Methoden zur Verwaltung der DcmQueue findDcmQueue() removeDcmQueue() removeDcmFile() findDcmFile() peekDcmFile() poolDcmFile()

44 Sequenzdiagramm Erzeugung einer neuen dcmQueue
Client greift mittels Producer Remote Interface auf dcmQueueService zu dcmQueueService erzeugt neue dcmQueue Entity Manager persistiert diese in die Datenbank

45 Sequenzdiagramm

46 Resümee Komplexität der Java EE Umgebung wurde völlig unterschätzt
Genauer Betrachtung Voraussetzungen um Arbeit zum Erfolg zu führen Bibliotheken von Java EE optimale Lösung für unsere Arbeit

47 Ausblick Nächste Schritte: Einbindung von Dcm4che2
Konkrete Implementierung der abstrakten Processing Nodes Implementierung der Helper Processing Nodes

48 Vielen dank für ihre Aufmerksamkeit