iftm Institut für Telematik in der Medizin
     Home Das Institut Telemedizin Bildverarbeitung e-Learning
 

Up

Telemedizin

DICOM Einführung

 

 

        DICOM - Eine Einführung

(Digital Imaging and Communication in Medicine)

 

Entwicklung des Standards 
Aufbau des Standards 
Datenformat 
Nachrichten  
Aufbau eines Informationsobjektes 
Kommunikationsstruktur 
DICOM Structured Reporting

 

Entwicklung des Standards

Im Jahre 1983 gründeten das American College of Radiology (ACR) und die National Electrical Manufactures Association (NEMA) einen Ausschuß, dessen Ziel es war, einen Standard für medizinische Bilder zu entwickeln.

Nach 2 Jahren wurde die erste Version dieses Standards (ACR-NEMA 300-1985 oder ACR-NEMA Version 1.0) vorgestellt. In den folgenden Jahren wurden Fehler und Inkonsistenzen beseitigt und Erweiterungen eingearbeitet, so daß 1988 ACR-NEMA 300-1988 (ACR-NEMA Version 2.0) veröffentlicht wurde. Neben dem Dateiformat wurde hier lediglich eine elektrische Punkt zu Punkt Verbindung zwischen zwei Geräten definiert.

Erst der 1993 vorgestellte weiterentwickelte DICOM-Standard ermöglichte eine Kommunikation verschiedener Partner über ein Netzwerk. Im Jahr 2000 umfasst der Standard 16 Hauptteile und mehreren Ergänzugen (http://www.dclunie.com/dicom-status/status.html).

Als Einstieg für Informationen über die Norm kann die nachfolgende Liste dienen:

Ein Einführung in DICOM. Philips.
ftp://ftp.philips.com/pub/pms-3003/DICOM_Information/CookBook.pdf

Eine nicht-technische Einführung in DICOM. RSNA.
http://www.rsna.org/Technology/DICOM/intro/index.cfm

Offizielle DICOM-Homepage der NEMA mit den Texten der Norm als PDF-Dateien.
http://medical.nema.org/dicom.html

Allgemeine Informationen. Radiological Society of North America.
http://www.rsna.org/REG/practiceres/dicom/index.html

Linksammlung von David Clunie.
http://www.dclunie.com/

Eine freie Referenzimplementation in Java von Gunter Zeilinger.
http://sourceforge.net/projects/dcm4che/

Eine freie Referenzimplementation in C++. Uni-Oldenburg.
http://dicom.offis.de/

 

Aufbau des Standards

DICOM 3.0 besteht aus neun zusammenhängenden aber unabhängigen Dokumenten. Die Teile 10 bis 12 sind die zwischenzeitlich eingefügten Erweiterungen, die sich auf die Speicherung auf externen Speichermedien beziehen. Abbildung 1 zeigt diese Teile in einem ungeschichteten Modell, wobei die Teile, die für Netzwerk oder Point-to-Point Kommunikationen relevant sind, auf der linken Seite dargestellt werden, während auf der rechten Seite die Teile dargestellt sind, die für die Kommunikation mit transportablen Medien benötigt werden.


Abbildung 1: Die Bestandteile des DICOM Standards (aus PS 3.10 - 1999 Page 11)

 

Datenformat

Die Datenstrukturen basieren auf einem objektorientierten Informationsmodell. Es beschreibt, wie eine Problemgruppe in der "realen Welt" 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 (Abbildung 2a). 


Abbildung 2a: Das DICOM Model der realen Welt (aus PS 3.3 - 2000 Page 15)

 

Für die Modellierung wird ein Entity-Relationship (E-R) Modell verwendet, wobei die einzelnen Entitäten die Objekte darstellen. Abbildung 2b zeigt dieses anhand des DICOM Information Model. Es beschreibt die komplexen Darstellungsmöglichkeiten für Objekte der realen, medizinischen Welt durch abstarkte Größen, den Information Object Definitons (IOD's). Der DICOM Standard setzt dieses Modell in Datenstrukturen um.


Abbildung 2b: Das DICOM Information-Model (aus PS 3.3 - 2000 Page 17)

 

Nachrichten

Beim DICOM Standard werden nicht nur "nackte" Daten, sondern es werden auch Instruktionen und Informationen über die beabsichtigte Verwendung der Daten innerhalb einer Nachricht mit ü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 Welt liefern. Es werden zwei Typen unterschieden:
bulletNormalisierte Informationsobjektklassen (Normalized Information Object Classes) enthalten nur die Attribute, die innerhalb der realen Welt existieren.
bulletZusammengesetzte Informationsobjektklassen (Composite Information Object Classes) können zusätzlich Attribute enthalten, die zwar mit der realen Welt in Verbindung gebracht werden können, aber nicht innerhalb dieser existieren.

Eine Nachricht besteht entweder aus einer normalisierten oder einer zusammengesetzten Informationsobjektklasse. Tabelle 1 zeigt die in den Anhängen von Teil 3 definierten Information Object Definitions.

 

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 1: 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 (Service Class Provider, SCP) und Benutzer (Service Class User, SCU) 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 decken folgende Einsatzbereiche ab:
bulletKommunikationsüberprüfung zwischen zwei DICOM-Applikationen
bulletBilddatenübertragung
bulletBilddatenbankdienste
bulletBenachrichtigung über Existenz, Inhalt und Standort von Bildern einer Untersuchung

DIMSE-N Nachrichten sind für normalisierte Datenstrukturen vorgesehen und behandeln folgende Einsatzbereiche:
bulletVerwaltung von Patientendaten
bulletVerwaltung von Untersuchungen
bulletVerwaltung von Untersuchungsergebnissen
bulletAusdruck von Bildern

 

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. Anhand von Tabelle 2 läßt sich der Aufbau nachvollziehen.

 

Information Entity 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 2: Computed Tomography Image IOD Module Table

In der Spalte Information Entity (IE) stehen die Entitäten aus dem DICOM Information Model (siehe Abbildung 2b). 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:
bulletM steht für Mandatory Module. Dieses Modul muß in der Datenstruktur escheinen.
bulletC steht für Conditional Module. Diese Modul muß unter bestimmten Bedingungen in der Datenstruktur erscheinen.
bulletU steht für User Option Module. Dieses Modul kann in der Datenstruktur erscheinen, muß es aber nicht.

 

Tabelle 3 zeigt nun das Patient Module, auf das in Tabelle 2 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. 

 

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 3: Patient Module 

Es werden drei grundlegende Typ-Klassen unterschieden:
bulletTyp 1: Das Attribut muß in die Datenstruktur kodiert werden und einen gültigen Wert haben.
bulletTyp 2: Das Attribut muß in die Datenstruktur kodiert werden, braucht aber keinen Wert zu enthalten.
bulletTyp 3: Das Attribut ist optional und muß daher auch keinen Wert enthalten.
bulletTyp nC: Falls ein beschriebenes anderes Attribut in der Datenstruktur vorhanden ist , muß bezüglich des Types n das Attribut kodiert werden (n = 1, 2 oder 3).

 

Alle verfügbaren Datenelemente (Data Elements), die bereits erwähnten Attribute, werden im DICOM Data Dictionary definiert. Jedes Datenelement erhält hierzu:
bulleteinen Attributbezeichner (Data Element Tag), der aus einer Gruppen- und einer Elementnummer in hexadezimaler Codierung besteht;
bulleteinen Namen;
bulleteine Wert-Repräsentation (Value Representation, VR);
bulletund eine Wert-Häufigkeit (Value Multiplicity);

 

Solche Attribute werden in einer DICOM Nachricht in Form von einzelnen Datenelementen abgelegt. Aus ihnen besteht die eigentliche Nachricht. Eine Nachricht, die als auch Data Set bezeichnet wird, ist daher die Verkettung von beliebig vielen Attribute (siehe Abbildung 3).



Abbildung 3: Aufbau eines Data Sets

 

Für jedes Attribut ist die Value Representation festgelegt. So sind beispielweise für das Beispiel in Tabelle 3 auszugsweise die folgenden Werte in Teil 6 der Norm definiert. 

 

Tag Tag VR VM  
(0010, 0010)   Patient's Name   PN   1
(0010, 0020) Patient ID LO 1
(0008, 1150) Referenced SOP Class UID   UI 1
 

Tabelle 3: Auszug aus der Liste der DICOM Daten Element 

Die Abkürzungen für die Value Representation bedeuten dabei:
bulletPN : Person Name, eine Zeichenkette von maximal 64 Zeichen
bulletLO : Long String, eine Zeichenkette von maximal 64 Zeichen
bulletUI : Unique Identifier, maximal 64 Zeichen aus [0..9] und '.'.

Hätte der Patient beispielweise den Namen "Hans Mustermann" würde das erste Data Element lauten:

Tag VR   Value Length   Value Field  
Group    Element       
0010   0010 PN  16  Mustermann, Hans  
 

Tabelle 4: Beispielhaftes Daten Element 

Das Feld Value Length gibt die Länge des Value Field in Byte an. Um ein Data Element über einen Übertragungskanal zu transportieren oder auch auf einem Speichermedium zu archivieren, muss noch festgelegt werden, wie die felder auf Byte-Ebene kodiert werden. Dies wird durch die Transfer Syntax festgelegt, die bei der Verbindungsaufnahme zwischen den Kommunikationspartnern ausgehandelt und festgelegt wird. Für die Transfer Syntax Explicit Value Representation and Little Endian würde die Bytefolge des Beispiels aus Tabelle 4 lauten

Tag VR   Value Length   Value Field  
Group    Element       
0x10, 0x00  0x10, 0x00  'P', 'N'  0x10, 0x00  'M', 'u', ... ,
'n', 's' 
 

Tabelle 5: Kodierung des Beispiels in Tabelle 4 mit der Transfer Syntax: Explizit VR Little Endian  

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.

 

Kommunikationsstruktur

In DICOM 3.0 gibt es drei Möglichkeiten, Daten zwischen DICOM Applikationen auszutauschen. 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.

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

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

3. Durch die Teile 10-12 des DICOM Standards wird das Speichern von DICOM Dateien auf transportablen Medien ermöglicht. 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.

 

DICOM Structured Reporting

Innerhalb von DICOM wurde ein Richtlinie verabschiedet, nach der medizinisch Befundberichte strukturiert werden können. Dieser Dienst wird als "DICOM Structured Reporting" oder auch "DICOM SR" bezeichnet.

Die Richtlinie definiert eine einheitliche Architektur für Befundberichte und bietet die Möglichkeit, Befunde zwischen unterschiedlichen Arbeitsplätzen, Workstations und Archivierungssystemen auszutauschen. Es werden eine Reihe von Dokumenttypen unterstützt, die von einfachen Textdokumenten bis hin zu multimedialen Dokumenten reichen.

Durch seine allgemeine Definition kann DICOM-SR in allen Disziplinen der Medizin mit ihren unterschiedlichsten Anforderungen an Komplexität und Detailtiefe eingesetzt werden.

Eine kurze Übersicht über den Aufbau und Möglichkeiten von DICOM SR findet man in einer Dia-Präsentation von David Clunie mit dem Titel "DICOM structured reporting - an object model as an implementation boumdary".

Das Buch "Clunie, DA: DICOM Structured Reporting" (ISBN 0-9701369-0-0)  ist als online Version im PDF Format bei PixelMed Publishing abrufbar.

 

Dieser Text wurde in Anlehnung an den Seminarvortrag Schlump T: "DICOM". Standards und Modelle zur Telekommunikation, Universität Oldenburg. http://www.schlump.net/Studium/dicom/dicom.html erstellt.