Der DICOM-Standard

DICOM (Digital Imaging and Communications in Medicine) ist ein spezieller Standard für die Radiologie, der weltweit gilt. Er wurde nach dem OSI Modell, dem Open System Interconnection Modell, entworfen, welches Kommunikation zwischen heterogenen Systemen erlaubt. Mit ihm können Bilder und Daten von unterschiedlichen bildgebenden und bildverarbeitenden Geräten untereinander ausgetauscht werden.
Um dies zu erreichen sind im DICOM Standard DICOM ist zum Datenaustausch mit medizinisch-radiologischen Informationssysteme konzipiert. Er ist aber auch fähig, Daten mit anderen Informationssystemen wie KIS/RIS auszutauschen.

Geschichte

In den 70´er Jahren wurden Computertomographie - Systeme in den radiologischen Praxen eingeführt. Inzwischen sind weitere bildgebende Modalitäten dazugekommen. Ihnen ist gemeinsam, daß sie ihre Bilddaten digital verarbeiten.
Diese Daten können nun unabhängig von der Bedienkonsole dargestellt und weiterverarbeitet werden. Über Netzwerkverbindungen können die Bilder, zum Beispiel in Kliniken, in schnellerer Zeit an die betreffenden Abteilungen weitergeleitet werden. Es kann somit schneller auf die Problemstellungen reagiert werden.
Deswegen entwickelten die Hersteller zwar leistungsfähige, aber stark spezialisierte Bildkommunikationssysteme. Nachteil dieser Systeme war, daß sie fast nur isoliert betrieben werden konnten. Damit aber Daten von unterschiedlichen Systeme trotzdem zusammen genutzt werden konnten, sollte DICOM als herstellerunabhängiger Standard entwickelt werden.
Dazu entstand eine gemeinsame Arbeitsgruppe Anfang 1983, die aus dem American College of Radiology (ACR) und der National Electrical Manufacturers Association (NEMA) bestand. Diese Arbeitsgruppe publizierte 1985 den ACR-NEMA Standard 1.0 auf der RSNA (Radiological Society of North America). In ihm sind das Hardware - Interface und alle notwendigen Datenelemente und Protokolle für einen zuverlässigen und fehlerfreien Datentransfer spezifiziert.
Im Jahre 1988 erschien dann die Version 2.0, in dem dieser Standard weiter verbessert und erweitert wurde.
Dieser Standard war aber noch nicht netzwerkfähig, es waren nur Punkt-zu-Punkt Verbindungen möglich. Deswegen waren weitreichende Änderungen notwendig.
1991 erschien darum der neue Standard: DICOM 3.0. Ihm lagen erstmals genaue und ausführliche Modelle zugrunde. Und DICOM 3.0 wurde von Anfang an mit objektorientierten Methoden entwickelt.
Als zentrales Element dieses Modells wurden die Service Object Pairs (SOP´s) entwickelt, die neben dem Objekt, wie zum Beispiel CT-Bild, MR-Bild, auch dessen ausführbare Aktionen, wie zum Beispiel "Drucken eines CT-Bildes", beinhalten. Objekte und dessen Aktionen werden zu SOP-Klassen verknüpft.
Alle unterstützten SOP-Klassen werden in einem sogenannten "Conformance Statement" dokumentiert. Dieses muß vom Hersteller erstellt und veröffentlicht werden. Wenn nun zwei Geräte dieselben SOP-Klassen unterstützen, können sie problemlos miteinander verknüpft werden. Der Anwender kann somit leichter entscheiden, welche Geräte zusammenpassen.
DICOM 3.0 ist in klar voneinader getrennte Bereiche untergliedert (vgl. Abbildung unten). Insgesamt existieren 13 Dokumente, die teilweise noch nicht vollständig sind.

Part 1: Introduction and Overview

             



Part 2:

Confor-mance

 

Part 4: Service Class Specification

 

Part 6:

Data Dictionary

   

Part 3: Information Objects Definitions

 
         
 

Part 5 Data Structures and Encoding

 

 

Part 7: Message Exchange

       
 

Part 8: Network Communication Support

 

Part 9:

Point-to-Point Communication

 

TCP / IP

OSI

 
Abbildung 37: Beziehungen der einzelnen Teile von DICOM 3.0 untereinander

DICOM-Standard, Version 3.0

Introduction and Overview

Hier ist das dem Standard zugrundeliegende Entwurfsprinzip beschrieben. Ebenso sind die verwendeten Abkürzungen und Fachausdrücke definiert. In sehr kompakter Weise wird ein Überblick über DICOM 3.0 gegeben.

Conformance

Die Kriterien, die ein Hersteller erfüllen muß, damit er sein Gerät als DICOM - kompatibel erklären kann, sind hier dargestellt. Diese Erklärungen, die Conformance Statements, müssen in einer bestimmten Form erfolgen. Alle DICOM relevanten Eigenschaften des Gerätes müssen in den SOP-Klassen zusammengefaßt sein. Dieses Conformance Statement muß veröffentlicht werden, damit den Anwendern die Auswahl kompatibler Geräte erleichtert wird. Ebenso kann das Conformance Statement als Anforderungsspezifikation in einer Ausschreibung verwendet werden.

Information Object Definition

Im Standard werden Informationsobjekte verwendet, die Attribute bzw. bestimmte Eigenschaften besitzen. Diese Informationsobjekte werden hier definiert. Die "Information Object Definitions (IOD)" sollen die Objekte der realen Welt möglichst präzise abbilden. Ein Beispiel für ein Informationsobjekt ist "Patient".
Diese Informationsobjekte werden nun in Klassen zusammengefaßt, wenn sie ähnliche Eigenschaften besitzen. Diese Klassen werden wiederum in den Typ "Normalized" oder "Composite" eingeteilt. Als "Normalized" werden die Klassen bezeichnet, wenn alle Attribute eindeutig zum Objekt zugeordnet werden können. (Zum Beispiel: IOD "Patient Information"; alle Attribute, wie Patientenname, Geschlecht, etc. sind eindeutige Bestandteile des Informationsobjekts). Klassen werden "Composite" genannt, wenn die Attribute auch indirekt mit dem Objekt verknüpft werden können. (Zum Beispiel: dem Informationsobjekt "CT-Bild" kann auch das Attribut Patientenname zugeordnet werden.)

Service Class Specification

Mit dem Informationsobjekt können Dienstleistungen oder Aktionen durchgeführt werden. Diese sind hier definiert, wobei gleichartige Dienstleistungen eine Serviceklasse bilden. Wenn gleichartige Dienstleistungen aktiv zur Verfügung gestellt werden, spricht man dann vom "Service Class Provider" (SCP); wenn die Dienstleistungen passiv in Anspruch genommen werden, ist die Rede vom "Service Class User" (SCU).

Data Structures and Encoding

Um Informationen über das Netzwerk zu versenden, müssen sie eine bestimmte Struktur besitzen, in einem Datensatz geordnet sein, die auch die empfangende Applikation kennt. Die Regeln für diesen Aufbau und mögliche Alternativen, die bei einem Verbindungsaufbau vereinbart werden, werden hier definiert.

Data Dictionary

Alle gültigen Datenelemente sind hier in Form einer Liste aufgeführt, wobei verwandte Datenelemente zu Gruppen zusammengefaßt sind. Jede Gruppe besteht aus mehreren Elementen, die den Informationsobjekten des Teils 3 entsprechen. Damit jetzt zwei Geräte kommunizieren können, müssen den Elementen, die im Standard als Platzhalter dienen, noch Werte zugewiesen werden (z. B. Patientengeschlecht = männlich). Teil 6 legt die übergeordnete Struktur und die Kennzeichnung der einzelnen Datenelemente fest.

Message Exchange

Der Ablauf und die Protokollstruktur für den Austausch zwischen zwei Geräten, die einen Datenaustausch durchführen wollen, ist hier definiert. So macht der Anwender dem Anwendungsprogramm durch eine Aktion deutlich, daß er einen Datentransfer wünscht. Das Anwendungsprogramm übersetzt diesen Befehl für die Netzwerkschnittstelle. Die Regeln für diese Kommunikation und die Protokollstruktur sind im Teil 7 festgelegt.

Network Communication Support

Hier sind alle notwendigen Systemkomponenten für den Austausch von DICOM - Nachrichten in einem Netzwerk definiert. Der Aufbau ist dabei modular nach dem "OSI (Open System Interconnection) Referenz Modell". Er beginnt auf der Hardwareebene, in der Bytes über ein Netzwerkkabel von Gerät zu Gerät versendet werden, und endet bei der Anwendungsebene, die die Schnittstelle zum Benutzer bildet. In jeder dieser Schichten müssen bestimmte Kommunikationsaufgaben mit steigendem Abstraktionsgrad erfüllt werden. Aufgrund dieses modularen Aufbaus ist es möglich zu früheren Umsetzungen des Standards kompatibel zu sein, sowie auf unterschiedliche Netzwerkstandards aufzusetzen.

Point-to-Point Communication Support for Message Exchange

Hier sind die Komponenten definiert, die für eine Punkt-zu-Punkt Verbindung zwischen zwei Geräten notwendig sind

Media Storage and File Format

Im Teil 10 ist der Überbau für die Speicherung von Bildinformationen auf verschiedenen Datenträgern definiert. Er spezifiziert das allgemeine DICOM Speichermedium, als auch das Dateiformat, mit dem DICOM definierte Informationsobjekte verpackt werden. So können die Daten "Offline" über Datenträger, wie magnetische oder optische Wechselplatten, von einem Gerät zum anderen übertragen werden. Teil 10 ist somit die Grundlage für die Teile 11 und 12.

Media Storage Application Profile

Teil 11 definiert, welche Informationen bei bestimmten Applikationen zusätzlich zu den Grundinformationen gespeichert werden müssen. Dabei sollen sich die Anforderungen an den klinischen Bedürfnissen orientieren.

Media Formats and Physical Media

Hier wird sowohl das physikalische Medium, als auch das medienabhängige Datenformat eines Datenträgers, der für einen Datentransfer geeignet ist, spezifiziert. Zum Beispiel sind abhängig von der Anwendung CD-ROM, magnetooptische Platten und 3 ½ Zoll HD-Disketten für den Datentransfer im medizinischen Umfeld geeignet.

Print Management Point-to-Point Communication Support

Die Beschreibung aller Protokolle und Dienste, die benötigt werden, um bei einer Punkt-zu-Punkt Verbindung den Druckdienst zu ermöglichen, erfolgt im Teil 13. Dies ist eine Alternative für nicht-netzwerkfähige Geräte.

Das Datenformat von DICOM

Die Datenstrukturen basieren auf einem objektorientierten Informationsmodell. Es beschreibt wie eine Problemgruppe modelliert wird. So hat zum Beispiel ein Patient einige Untersuchungen, die in eine oder mehrere Serien aufgeteilt und mit einer bestimmten Ausrüstung durchgeführt wurden. Ein hierbei aufgenommenes Bild ist Teil eines Untersuchungsabschnittes und wird durch eine ,,Image Box`` dargestellt, die von einem Drucker gedruckt werden kann.
Für diese Modellierung wird ein Entity-Relationship (E-R) Modell verwendet, wobei die einzelnen Entitäten die Objekte darstellen. Abbildung 38 zeigt dieses anhand des ,,DICOM Applikation Model``. Es beschreibt die komplexen Darstellungsmöglichkeiten für Objekte der realen (medizinischen) Welt. Der DICOM Standard setzt dieses Modell in Datenstrukturen um.

Abbildung 38: Das DICOM Applikation Model

DICOM Nachrichten

Beim DICOM Standard werden nicht nur "nackte" Daten, sondern es werden Instruktionen und Informationen über die beabsichtigte Verwendung der Daten innerhalb einer Nachricht übertragen. Mit Hilfe dieser Nachrichten werden bei DICOM Daten über Netzwerke ausgetauscht.
Zur Aufnahme der Informationen definiert der DICOM Standard Informationsobjektklassen (Information Object Classses), die eine abstrakte Definition der realen (medizinischen) Welt liefern. Es werden zwei Typen unterschieden: Eine Nachricht besteht entweder aus einer normalisierten oder einer zusammengesetzten Informationsobjektklasse. Tabelle 12 zeigt die in den Anhängen von Teil 3 definierten "Information Object Definitions (IODs)".

Composite IODs

Normalized IODs

Computed Radiography Image

Patient Information

Computed Tomography Image

Visit Information

Magnetic Resonance Image

Study Information

Nuclear Medicine Image

Study Component Information

Ultrasound Image

Results Information

Ultrasound Multi-Frame Image

Interpretation Information

Secondary Capture Image

Basic Film Session

Stand alone Overlay

Basic Film Box

Stand alone Curve

Basic Annotian Presentation

Basic Study Description

Basic Print Job Information

Standalone Modality Lookup Table (LUT)

Basic Printer Information

Standalone Value of Interest (VOI) LUT

VOI LUT

Image Overlay Box

Tabelle 12: Die Information Object Definitions von DICOM 3.0

Zum Nachrichtenaustausch definiert DICOM einen Dienst zur Nachrichtenübertragung, "DICOM Message Service Element (DIMSE)", der auf der TCP/IP, ISO-OSI oder Point-to-Point Schnittstelle aufgesetzt ist. Die Kombination eines Informationsobjektes und solch eines Dienstes wird ,,Service-Object Pair (SOP)`` genannt. Die SOP Klasse stellt die grundlegende Funktionalitätseinheit dar, die von DICOM definiert wird. Durch Festlegung einer SOP Klasse ist es möglich, eine bestimmte Untermenge der DICOM Funktionalität zu definieren.
Beim Verbindungsaufbau werden nun zunächst SOP Klassen bestimmt, die von beiden Programmen unterstützt werden. Ferner werden Anbieter und Benutzer des Dienstes bestimmt. Ein Benutzer nutzt den Dienst, indem er über DIMSE eine Nachricht an den Anbieter sendet, der dann die Nachricht bearbeitet und eine Antwort zurückschickt. Einer Nachricht kann optional ein weiterer Datenstrom folgen.
DICOM unterstützt zwei verschiedene Gruppen von Nachrichten. DIMSE-C Nachrichten sind für zusammengesetzte Datenstrukturen vorgesehen. Diese dek-kcken folgende Einsatzbereiche ab: DIMSE-N Nachrichten sind für normalisierte Datenstrukturen vorgesehen und behandeln folgende Einsatzbereiche:

Aufbau eines Informationsobjektes

Exemplarisch soll jetzt der Aufbau der "Computed Tomography Image Information Object Class" verdeutlicht werden. Hierbei handelt es sich um ein zusammengesetztes Informationsobjekt, da es aus mehreren Objekten verschiedener Objektklassen zusammengesetzt wurde (siehe auchTabelle 12). Anhand von Tabelle 13läßt sich der Aufbau nachvollziehen.

IE

Module

Usage

Patient

Patient

M

Study

General Study

M

Patient Study

U

Series

General Series

M

Frame of Reference

Frame of Reference

M

Equipment

General Equipment

M

Image

General Image

M

Image Plane

M

Image Pixel

M

Contrast/Bolus

C

CT Image

M

Overlay Plane

U

VOI LUT

U

SOP COMMON

M

Tabelle 13: Computed Tomography Image IOD Module Table

In der Spalte IE (Information Entity) stehen die Entitäten aus dem ,,DICOM Applikation Model`` (siehe Abbildung 38). Die zweite Spalte verweist auf Module, die das Objekt genauer beschreiben, den sogenannten Attributen. Die letzte Spalte sagt aus, ob das beschriebende Modul in der Datenstruktur erscheinen muß oder nicht: Tabelle 14 zeigt nun das Patient Module, auf das in Tabelle 13 verwiesen wurde. Die Spalten Attribut Name und Tag beschreiben Attribute der Entität Patient. In der Spalte Attribut Beschreibung steht der Wert des jeweiligen Attributes. Die Spalte Type beschreibt, ob es notwendig ist, dieses Attribut in die Datenstruktur zu kodieren. Es werden drei grundlegende Typ-Klassen unterschieden:

Attribut Name

Tag

Type

Attribut Beschreibung

Patient's Name

(0010,0010)

2

Name des Patienten

Patient ID

(0010, 0020)

2

Patienten Identifikationsnummer

Patient's Birth Date

(0010, 0030)

2

Geburtsdatum des Patienten

Patient's Sex

(0010, 0040)

2

Geschlecht des Patienten

Referenced Patient Sequence

(0008, 1120)

3

Referenz auf eine andere Sequenz

Referenced SOP Class UID

(0008, 1150)

1C

Referenz auf SOP Class UID

Referenced SOP Instance UID

(0008, 1155)

1C

Referenz auf SOP Instance UID

Patient's Birth Time

(0010, 1132)

3

Geburtszeit des Patienten

Other Patient ID

(0010, 1000)

3

Eine andere Patienten Identifikationsnummer

Other Patient Name

(0010, 1001)

3

Anderer Name des Patienten

Ethnic Group

(0010, 2160)

3

Glaubenszugehörigkeit des Patienten

Patient Comments

(0010, 4000)

3

Andere Informationen über den Patienten

Tabelle 14: Patient Module Table

Alle verfügbaren Datenelemente (Data Elements), die bereits erwähnten Attribute, werden im "DICOM Data Dictionary" definiert. Jedes Datenelement erhält hierzu: Solche Attribute werden in einer DICOM Nachricht in Form von einzelnen Datenelementen abgelegt. Aus ihnen besteht die eigentliche Nachricht. Eine Nachricht, die als ,,Data Set`` bezeichnet wird, ist daher die Verkettung von beliebig vielen Datenfeldern. Der Aufbau läßt sich anhand der Syntaxdiagramme in Abbildung 39 nachvollziehen.

Abbildung 39: Syntax für den Aufbau von Data Sets

Um eine DICOM Nachricht zu erhalten, muß einem Data Set noch ein "Command Set" vorangestellt werden. Der Aufbau des "Command Sets" ist analog zum "Data Set", allerdings besitzt er keinen Datentyp.

Die Kommunikationsstruktur von DICOM

In DICOM 3.0 gibt es 3 Möglichkeiten, Daten zwischen DICOM Applikationen auszutauschen. Diese werden in Abbildung 40 dargestellt. Über jeden dieser Datenkanäle können Daten ausgetauscht werden. Einzige Voraussetzung ist, daß Empfänger und Sender den gleichen Datenkanal benutzen. Laut DICOM Standard ist allerdings das Wechseln der Datenkanäle möglich, ohne die Applikation neu implementieren zu müssen.

Medical Imaging Application

DICOM Application Message Exchange

DICOM

Session/
Transport/
Network

(STN)

DICOM

Upper Layer protocol for TCP / IP

OSI Association Control Service Element (ACSE)

   

OSI Presentation Kernel

   

OSI Session Kernel

     

OSI Transport

 

TCP

 

OSI Network

DICOM
Data Link

 

IP

 

LLC

DICOM
Physical (50-pin)

 

Standard network physical layers
(Ethernet, FDDI, etc.)

Point-to-point Networked environment
environment

Abbildung 40: Das DICOM Kommunikationsprotokoll

Bereits in ACR-NEMA Version 2.0 war die Kommunikation über eine Point-to-Point Schnitstelle realisiert. Hierzu wurden, in Anlehnung an das ISO-OSI-Basisreferenzmodell, mehrere Schichten definiert, über die die Daten weitergegeben wurden. Die DICOM Applikationen greifen nur auf die von der obersten Schicht nach außen zur Verfügung gestellten Funktionalität zurück.
Mit DICOM 3.0 wurden die Kommunikationsmöglichkeiten um die Kommunikation über ein Netzwerk erweitert. Zum einen existiert die Unterstützung des ISO-OSI Protokolles, zum anderen ist auch die Verwendung des TCP/IP Protokolles möglich . Der Aufbau ist vergleichbar mit dem der Point-to-Point Schnittstelle.
Durch diesen Aufbau der Kommunikationsstruktur konnte erreicht werden, daß eine vorhandene unabhängig vom DICOM Standard arbeitende medizinische Anwendung mit einer DICOM Applikation kommunizieren kann. Die Integration dieser Einheit wird mit Hilfe des Standards ermöglicht, eine Modifikation ihrer Implementation ist nicht nötig.
Durch die Teile 10 und 11 des DICOM Standards (bzw. den diesen Teilen entsprechenden Ergänzungen) wird noch eine weitere Möglichkeit des Datenaustausches realisiert: das Speichern von DICOM Dateien auf transportablen Medien. Hierzu werden sämtliche Daten in den Informationsobjekten in Dateien des entsprechenden Typs geschrieben. Anschließend wird die Struktur jedes einzelnen Informationsobjektes in eine entsprechende Verzeichnisstruktur umgesetzt. Im Hauptverzeichnis finden sich also die Informationen über vorhandene Patienten. Jeder Patient hat genau einen Verzeichniseintrag. In diesem Verzeichnis finden sich dann die einzelnen Untersuchungen, die auch jeweils einen Verzeichniseintrag besitzen, usw. Durch diesen Verzeichnisbaum kann wie bei anderen geläufigen Verzeichnisstrukturen (zum Beispiel DOS oder Unix) gewohnt navigiert werden.