DICOM Lösung für private radiologische Praxen

DICOM Lösung für private radiologische Praxen
Kerstin Faber1, Dirk Krechel1, Daniel Reidenbach1, Silvio Costa Sampaio2, Aldo
von Wangenheim2, Klaus Blasinger3
1
AG Wissensbasierte Systeme, FB Informatik, Universität Kaiserslautern,
Erwin-Schrödinger-Straße, 67653 Kaiserslautern
Email:{faber,krechel,reidenba}@informatik.uni-kl.de
2
Department of Computer Science
Universidade Federal de Santa Catarina - UFSC
88049-200 Florianopolis - S.C., Brazil
Email: {silvio,awangenh}@inf.ufsc.br
3
Radiologische Gemeinschaftspraxis Dr.Buddenbrock, Dr.Blasinger, Dr.Benz
Rheinstrasse 4 A-C, 55116 Mainz
Email: krechel@goofy.zdv.uni-mainz.de
Einleitung
Für den Bereich der privaten radiologischen Praxen fehlen zur Zeit noch integrierte Lösungen
zur EDV-Unterstützung der täglichen Routine. Es sind zwar einzelne Komponenten verfügbar,
aber eine Unterstützung des Workflow, beginnend mit der Anmeldung bis zum Rücktransfer der
Untersuchungsergebnisse zum überweisenden Arzt, existiert für dieses Umfeld noch nicht. Ein
solcher Ansatz wird zur Zeit in unserem deutsch-brasilianischen Kooperationsprojekt
entwickelt. Das System soll dabei auf die aktuellen Entwicklungen, z.B. Integrating the
Healthcare Enterprise (IHE) [1] im Bereich des DICOM Standards [2] aufbauen.
Ein erster Schritt für diese integrierte Lösung ist die hier vorgestellte Implementierung der
DICOM-Grundlagen und von geeigneten Benutzerschnittstellen.
Dies ist nötig, um das geplante Workflow-System in die heute üblichen PACS-Umgebungen
(Picture Archiving and Communications System) zu integrieren. Abb1. zeigt eine solche PACSArchitektur. Das Workflow-System wird auf den Konzepten der Workflow Coalition aufbauen
und die Prozeßdefinitionen aus dem IHE Technical Framework verwenden. Das System wird
aber nicht nur Standard Funktionalitäten wie z.B. die von Wetter in [3] beschriebenen Ansätze
besitzen, sondern besonders im Bereich der Diagnose neue Ideen, wie zum Beispiel
Wissensmanagement und Bildanalyseverfahren, integrieren. Der von uns entwickelte Client
wird als Diagnose-Arbeitsplatz zur Zeit im täglichen Betrieb getestet.
Bei der Implementierung wurde auf ein sauberes objektorientiertes Design Wert gelegt, damit
neue Entwicklungen des DICOM Standards möglichst schnell integriert werden können. Im
folgenden Kapitel werden die von uns verwendeten Methoden des DICOM Standards und erste
Ergebnisse vorgestellt. Dabei wurden die englischen DICOM-Begriffe übernommen und kursiv
markiert.
Abb.1: PACS Architektur
Methoden
Information Model
DICOM 3.0 [2] beschreibt im dritten Teil des Standards die Objekte der realen Welt sowie die
Beziehungen dieser Objekte untereinander mit Hilfe eines Entity-Relationship Modells. Die
Rechtecke heißen Information Entities (IE) und repräsentieren Objekte der realen Welt,
während die Rauten eine Beziehung zwischen diesen anzeigen.
Zur vollständigen Beschreibung eines Objektes der realen Welt werden meist mehrere
Information Entities in einer sogenannten IOD (Information Object Definition)
zusammengefasst. Die Information Entities können wiederum aus mehreren IOMs (Information
Object Module) bestehen. Dieser hierarchische Aufbau dient der Übersichtlichkeit und
vermeidet Redundanzen bei der Definition verschiedener Objekte, die sich nur durch wenige
Attribute unterscheiden.
Als Beispiel sei ein Bild genannt, z.B. ein CT- oder MR-Bild. Jedes Bildobjekt besteht aus den
IEs Patient, Study, Series, Frame of Reference, Equipment und Image. Das IE Patient beinhaltet
als Attribute unter anderem den Namen und das Geburtsdatum des Patienten; im IE Study und
Series sind beispielsweise Datum und Uhrzeit der Aufnahme abgelegt. Da es zum Bild selbst
Abb. 2: DICOM Modell der realen Welt
sehr viele Informationen gibt, wird dieses Information Entity aus mehreren IOMs aufgebaut.
Jedes Bild hat IOMs, die Attribute zur Pixeldarstellung des Bildes oder Overlay-Informationen
beinhalten. Außerdem gibt es immer ein modalitätsspezifisches IOM, das Attribute enthält, die
nur für diese Modalität relevant sind.
Im dritten Teil des Standards werden alle IODs beschrieben. Dabei wird zwischen Composite
und Normalized IODs unterschieden. Composite IODs bestehen aus mehreren Information
Entities, während Normalized IODs nur aus einem Information Entity bestehen. Komplexe
Objekte wie Bilder werden immer mit Hilfe von Composite IODs modelliert; Normalized IODs
übernehmen hauptsächlich Management-Funktionen.
Unser System ist in der objektorientierten Programmiersprache Smalltalk implementiert. Die
objektorientierte Philosophie unterstützt eine saubere, übersichtliche Modellierung der DICOMIODs:
-
Jedes IOM ist eine eigene Klasse, die von einer abstrakten Oberklasse namens
CyclopsDBObject abgeleitet ist. Die Attribute des IOMs sind Instanzenvariablen der Klasse.
Als Name der Klasse ist immer die Konkatenation der Bezeichnung des IOMs im Standard
und dem Wort "Module" gewählt.
Abb. 3: Klassen-Hierarchie
-
Jedes Information Entity ist eine eigene Klasse, die ebenfalls von der Klasse
CyclopsDBObject abgeleitet ist. Die sie aufbauenden IOMs sind Instanzenvariablen dieser
Klasse. Als Name wird die Bezeichnung des Information Entity im Standard verwendet.
-
Da es einige IOMs gibt, die in allen Bildern unabhängig von der Modalität enthalten sind,
haben wir ein eigenes Objekt CyclopsDicomImage modelliert, von dem alle speziellen
Bilder abgeleitet werden.
Die Klassenhierarchie ist in Abb.3 dargestellt. Wir erweitern unser System jedoch stetig um
neue Objekte. Die nächsten IODs werden den neuen Entwicklungen im Bereich von DICOM Worklist Management und Structured Reporting - entspechen. Sie können dank der
durchdachten Modellierung leicht hinzugefügt werden.
Services
Besonders wichtig für den Einsatz in Praxen ist die Möglichkeit, DICOM-Objekte über ein
Netzwerk austauschen zu können. Die dazu in DICOM verwendete Netzwerk-Architektur
entspricht einem einfachen verteilen Konzept, bei dem zwei auf verschiedenen Systemen
laufende Prozesse miteinander kommunizieren und Daten austauschen. Ein entscheidender
Punkt ist die Rolle der beiden kommunizierenden Partner. Im Kontext von DICOM wird der die
Funktionalität bereitstellende Server als SCP (Service Class Provider) und der die
Funktionalität nutzende Client als SCU (Service Class User) bezeichnet. Das Verhalten des
Server- bzw. Client-Prozesses wird im vierten Teil des Standards mit Hilfe sogenannter Service
Classes genau spezifiziert.
Die Service Classes beinhalten u.a. SOP Classes (Service Object Pair Classes), die eine IOD
mit den auf sie anwendbaren Operationen, z.B. store und move, kombiniert. Diese Operationen
heißen DIMSE (DICOM Message Service Elements) und werden im siebten Teil von DICOM
eingehend beschrieben. Es gibt insgesamt fünf Services, die auf Composite IODs angewendet
werden können (C-STORE, C-GET, C-MOVE, C-FIND und C-ECHO) und sechs Services, die
für Normalized IODs definiert wurden (N-EVENT-REPORT, N-GET, N-SET, N-ACTION, NCREATE und N-DELETE).
Wir haben einen SCU implementiert, der die von uns modellierten IODs über ein TCP/IP
Netzwerk von einem CTN-Server[5] laden und wieder abspeichern kann. Dazu mußten die
Services C-STORE, C-FIND und C-GET implementiert werden. Die Verbindung erfolgt
synchron, d.h. daß SCU und SCP immer wieder auf Nachrichten und Statusmeldungen der
Gegenseite warten müssen, diese auswerten und erst dann den laut Protokoll vorgesehenen
nächsten Schritt ausführen dürfen.
Das Speichern eines Bildes läuft vereinfacht folgendermaßen ab:
-
In der ersten Phase, die Association Establishment genannt wird, benachrichtigt der SCU
den SCP darüber, daß er ein Bild speichern will. Er identifiziert sich und teilt dem SCP
unter anderem die Transfer-Syntaxen, mit denen er umgehen kann, sowie die Größe der
TCP/IP-Pakete, die er dem SCP schicken will, mit. Der SCP muß eine Verbindung des SCU
akzeptieren und ihm u.a. eine ausgewählte Transfer-Syntax mitteilen.
-
In der zweiten Phase schickt der SCU TCP/IP-Pakete der vereinbarten Größe zum SCP.
Zuerst werden die Parameter des C-STORE-Services, anschließend alle Attribute des Bildes
Abb. 4: DicomEditor
geschickt. Die Pixeldaten selbst sind ein Attribut des Bildes.
-
Die letzte Phase wird als Confirmation bezeichnet. Der SCP teilt dem SCU mit, ob das Bild
erfolgreich abgespeichert werden konnte bzw. liefert einen Fehlercode, falls das Speichern
nicht funktioniert hat.
Benutzeroberflächen
In Zusammenarbeit mit der Gemeinschaftspraxis in Mainz haben wir spezielle, einfach zu
bedienende Benutzeroberflächen entwickelt. Sie berücksichtigen die komplexe Struktur der
DICOM-Objekte und zeigen verschiedene Abstraktionsebenen der Objekte.
Auf der höchsten Ebene steht der DicomEditor. Er übernimmt die Kommunikation mit dem
Image Server und verwaltet Patienten, die zugehörigen Studien sowie deren Serien in drei
Auswahllisten. Wird eine Serie angewählt, werden die Bilder am unteren Rand des Editors
verkleinert dargestellt. Jede Notebook-Seite des rechts angeordneten Notebooks entspricht
einem Information Entity, was die Struktur des DICOM-Objekts unterstreicht. Die einzelnen
Attribute der dargestellten Information Entities können einfach abgeändert oder gesetzt werden,
so daß Serien, die nicht DICOM-konform sind (weil erforderliche Attribute nicht gesetzt sind)
in konforme Serien überführt werden können. Selbstverständlich können diese Änderungen im
Image Server dauerhaft abgelegt werden.
Damit der DicomEditor schnell in jeder Umgebung lauffähig ist, wurde der
DicomConnectionConfigurator entwickelt. Hier kann der Benutzer aus einer Liste von SCUs
und SCPs die gerade
gewünschten leicht auswählen. Falls ein Eintrag
nicht in der Liste enthalten
ist, kann dieser in die einer
XML-Syntax folgenden Konfigurationsdatei hinzugefügt
werden. Ein SCP und ein
SCU können als Default
gesetzt werden und werden
zukünftig als Parameter der
Verbindung benutzt, falls der
DicomConnectionConfigurat
or nicht aufgerufen wurde.
Abb.5: DicomConnectionConfigurator
Die mittlere Ebene wird vom
DicomSeriesEditor
eingenommen, der nach der
Auswahl einer Serie im
DicomEditor geöffnet werden kann. Den größten Teil
dieses Editors nimmt ein
"Lichtbrett" ein, auf dem
sämtliche Bilder verteilt
werden. Der untersuchende
Arzt kann die Bilder beliebig
Abb. 6: DicomSeriesEditor
vergrößern oder verkleinern. Außerdem kann er den Farbwert eines bestimmten Punktes bzw.
den durchschnittlichen Farbwert seiner Nachbarschaftspunkte abfragen. Mit Hilfe eines roten
Stifts kann er interessante Regionen markieren und diese Markierungen aus- und wieder
einblenden. Zur Realisierung dieser Funktionalität haben wir das in DICOM beschriebene
Overlay-Konzept verwendet, so daß die Markierungen problemlos im Image Server
abgespeichert werden können.
Im Falle einer Kontrast-Serie werden die Bilder auf dem Lichtbrett anders verteilt: Eine Spalte
beinhaltet ein Volumen, in x-Richtung werden die Volumina zu verschiedenen Zeitpunkten
abgelegt. Diese Anordnung hat den Vorteil, daß die die gleiche Region zeigenden Aufnahmen
nebeneinander liegen und der Arzt signifikante Unterschiede sehr schnell erkennen kann. Als
Hilfsmittel dient ihm das DicomHistogramm, das die Farbwerte eines Pixels (bzw. den
durchschnittlichen Farbwert der Nachbarpixel) über die Zeit aufträgt.
Auf der unteren Ebene ist der DicomImageEditor implementiert, der mit einem im
DicomSeriesEditor markierten Bild geöffnet werden kann. Das Notebook auf linken Seite zeigt
alle Attribute des Information Entities Image; jede Notebookseite zeigt ein dieses Information
Entity aufbauendes IOM.
Oberhalb des Bildes sind die Attribute WindowCenter und WindowWidth aus dem IOM VOI
LUT für den Benutzer änderbar aufgetragen. Bei einer beliebigen Anpassung dieser Werte wird
die Farbpalette des Bildes neu berechnet; die optimalen Werte können auch algorithmisch
bestimmt werden. Der ursprüngliche und tatsächlich dargestellte Grauwert jedes Pixels läßt sich
mit Hilfe eines Informations-Tools abrufen. So lassen sich beispielsweise bei CT-Bildern
Rückschlüsse auf die tatsächliche Hounsfield Unit des aktivierten Pixels ziehen.
Abb. 7: DicomImageEditor
Einfache Bildverarbeitungsfunktionen helfen dem Arzt beim Befund: Eine Stift-Funktion
ermöglicht es, an beliebigen Stellen farbige Markierungen anzubringen. Nützlich ist auch ein
Werkzeug zur Distanzmessung, welches automatisch den Abstand zwischen zwei frei
wählbaren Punkten im Bild ermittelt, diesen in den tatsächlichen umrechnet und ausgibt.
Sämtliche Markierungen lassen sich einzeln wieder entfernen. Um eine bessere Analyse
bestimmter Regionen zu ermöglichen bietet der DicomImageEditor die Option, einen
Bildausschnitt beliebig zu vergrößern.
Ausblick
Die nächsten Schritte sind nun die Implementierung der SCP-Funktionalitäten, einer Wokflow
Engine, eines Reporting Editors und der dafür benötigten DICOM Services.
Ein Funktionalität des Reporting Editors wird eine Wissensmanagement-Komponente sein,
welche es ermöglichen soll, das Wissen über die Standarduntersuchungen einer privaten Praxis
zu modellieren. Diese Prozeßmodelle sollen in der täglichen Routine zur Unterstützung von
jungen Radiologen und zur Generierung von normierten Befundberichten eingesetzt werden.
Dabei werden Worklists für die Untersuchungen erstellt, welche vom befundenden Radiologen
abgearbeitet werden. Einen besondere Stellenwert wird dabei die vollständige Integration einer
solchen Komponente in den Routinebetrieb spielen. Dies soll durch verschiedene
Abstraktionsebenen der Worklists ermöglicht werden. Der erfahrene Radiologe muß nur die
einzelnen Schritte auf höchster Ebene abarbeiten, während für den unerfahrenen Kollegen
Detailinformationen und Beispiele zu den einzelnen Schritten schnell greifbar sind.
Referenzen
[1] Integrating the Healthcare Enterprise IHE Technical Framework, Revision 3.0
Radiological Society of North America, http://www.rsna.org/IHE
[2] ACR/NEMA Standard, Digital Imaging and Communications in Medicine ; NEMA
Standards Publication PS3.x
[3] From Image Management to Workflow Managment, Th. Wendel, Philips Research
Hamburg, CARS 99 page 409
[4] DICOM Cook Book for Implementations in Modalities. Chapters 1 and 2. Version
1.1 (Accepted) 14 January 1997. Copyright Philips Medical Systems Nederland B.V.,
1996, 1997.
[5] http://dicomctn.wustl.edu/DICOM/ctn.html