BACHELORARBEITMEDIZININFORMATIK

Design und prototypmäßige Implementierung von Komponenten zum Datenaustausch von DICOM-

Objekten in einem DICOM-Verarbeitungsframework

Daniel Gosch & Hannes Stornig0660099 0727963

Themen

Überblick DICOM Problembeschreibung Fragestellungen Transaktionsmanagement Software Prototyp

Themen

ÜberblickBachelorarbeitAnforderungsbeschreibungAnforderungen an das System

DICOM Problembeschreibung Fragestellungen Transaktionsmanagement Software Prototyp

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

Anforderungsbeschreibung Framework entwickeln

PersistentKorrekte FehlerbehandlungVerarbeitung 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

DICOMAllgemeinWas ist DICOMDICOM File

Problembeschreibung Fragestellungen Transaktionsmanagement 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

Digital Imaging and Communications in Medicine

Richtlinien für digitale MedienStandard für medizinische Bilder

DICOM regelt unter anderem eine einheitliche Speicherung von Bildern

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

ProgrammiersprachePersistenz / TransaktionDatenstrukturDatenbankanforderungenPerformance

Fragestellungen Transaktionsmanagement Software Prototyp

Programmiersprache

JAVA Enterprise EditionKlassenbibliotheken des Toolkits dcm4che2Objektorientierte ProgrammierspracheEigene Laufzeitumgebung

○ unabhängig von RechenarchitekturFunktionalität

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 DatenRollback im FehlverhaltenKonsistenter Datenstand

Datenstruktur

Queue Konstante Reihenfolge Primär FiFo (First in First out) Verfahren Erweiterter Zugriff auf Elemente in der

Queue

DcmFile DcmFile

DcmFile

DcmFileadd()

pool()

peek()

DcmFile

Queue

Datenbankanforderungen ACID Richtlinien

Transaktionen müssen○ Atomar

ganz oder gar nicht

○ Konsistentdefinierte Integritätsbedingungen

- (Primärschlüssel / Fremdschlüssel)

○ IsoliertTransaktionen

○ Dauerhaftnach Transaktionsende persistent zur Verfügung

stehen

Performance

DICOM Files oft >= 100 MB

Persistierung in der DatenbankSchlechte Performance

Speicherung auf sekundär Datenträger Surrogate (Platzhalterobjekte) in der

DatenbankReferenz auf DICOM FileBedarfsfall Informationen nachladen

Performance

Überlegungen:Ein und dasselbe DICOM File kommt

mehrmals vorMehrere Referenzen auf ein DICOM FileGroßer Speicherbedarf

○ Wenn DICOM File in mehreren Queues

DcmFileID 0112

DcmFileID 0112

DcmFileID 0112

SurrogatID 0112

Queue 1

SurrogatID 0112

Queue 2

SurrogatID 0112

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

DcmFileID 0112

Surrogat ID 0112

Queue 1

Surrogat ID 0112

Queue 2

SurrogatID 0112

Queue 3

Performance

Wann darf ein DICOM File gelöscht werden?

DcmFileID 0112

Surrogat ID 0112

Queue 1

Surrogat ID 0112

Queue 2

SurrogatID 0112

Queue 3

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 FileFalls NEIN -> Freigabe zur Löschung

Themen Überblick DICOM Problembeschreibung Fragestellungen

Data Queue (DQ)Processing Node (PN)Beziehungen zwischen PN und DQVerarbeitungsgraphHelper Processing Node

Transaktionsmanagement Software Prototyp

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

Processing Node (PN) PN nutzt DQ um DICOM Objekte

auszutauschen Verarbeitungselement des Framework das

DICOM Images verarbeitet

2 RollenProducer Inputseitig => Weitergabe der

ErgebnisseConsumer Outputseitig => DICOM Objekte

die zur Bearbeitung anstehen zuzugreifen

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

Verarbeitungsgraph

Zwei Typen von PN haben nur eine Input- bzw. eine Output-SeiteJene die sich am äußeren Rand des

Verarbeitungsgraphen befindenImport PN bringen externe DICOM Daten zur

Verarbeitung in den Verarbeitungsgraphen einExport PN ermöglichen den Export von

DICOM Daten aus dem Verarbeitungsgraphen ○ z.B. als File in ein File System

Verarbeitungsgraph

Helper Processing Node (HPN)

Spezieller Typ einer PNStrategie

Menge von PN -> eine Bestimmte Aufgabe übernehmenZur Verteilung von InformationZur Vereinigung von Datenströmen

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 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 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

+pseudonymisieren()

Themen Überblick DICOM Problembeschreibung Fragestellungen Transaktionsmanagement

Container Managed TransactionVerhalten des ContainersRollback

Software Prototyp

Transaktionsmanagement Container Managed Transaction (CMT)

EJB Container verwaltet automatisch Transaktionen innerhalb einer EJB Klasse oder Methode

Entscheidet selbstständig○ ohne explizite Deklaration

Keine Nested TransactionsTransaktionskontext

○ Durch EJB Container bestimmt

Verhalten des Containers

Container steuert Transaktionen weitgehend selbst

Mittels Callback auf Verhalten des Container Einfluss nehmen@afterBeginn@beforeCompletion@afterCompletion

Rollback

Im Falle eines FehlersMöglichkeiten zur Auslösung eines Rollback

○ System Exception ○ vorgemerkte Exceptions○ Methode setRollbackOnly()

ermöglicht○ Jederzeit konsistenter Datenstand

Themen Überblick DICOM Problembeschreibung Fragestellungen Software Prototyp

ÜberblickInterface DcmQueueProducerServiceRemoteInterface DcmQueueConsumerServiceRemoteSequenzdiagramm

Software Prototyp

Prototyp des Frameworks namens „DcmSPL“

Prototyp bietet MöglichkeitWarteschlange (Queue) erstellenDICOM Dummy Files an das Framework zu

übergeben○ Persistierung der DICOM Dummy Files ins File

System○ Übergibt Queue eine Referenz auf das DICOM

Dummy FileBearbeitungsknoten können modular

implementiert werden

Interface DcmQueueProducerServiceRemote

Inputseitig Methoden zur

Erzeugung und Befüllung der DcmQueuecreatDcmQueue()removeDcmQueue()addDcmFile()findDcmQueue()

Interface DcmQueueConsumerServiceRemote

Outputseitig Methoden zur

Verwaltung der DcmQueuefindDcmQueue()removeDcmQueue()removeDcmFile()findDcmFile()peekDcmFile()poolDcmFile()

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

Sequenzdiagramm

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

Ausblick

Nächste Schritte:Einbindung von Dcm4che2Konkrete Implementierung der abstrakten

Processing NodesImplementierung der Helper Processing

Nodes

VIELEN DANK FÜR IHRE

AUFMERKSAMKEIT