Benutzer:ZEEs/DICOM

Dieser Artikel ist im Entstehen und noch nicht Bestandteil der freien Enzyklopädie Wikipedia.

Solltest du über eine Suchmaschine darauf gestoßen sein, bedenke, dass der Text noch unvollständig sein und Fehler oder ungeprüfte Aussagen enthalten kann. Wenn du Fragen zum Thema hast, nimm Kontakt mit dem Autor ZEEs auf.

Digital Imaging and Communications in Medicine (DICOM) ist ein offener Standard zum Austausch von Informationen in der Medizin.

Diese Informationen können beispielsweise digitale Bilder, Zusatzinformationen wie Segmentierungen, Oberflächendefinitionen oder Bildregistrierungen sein.

DICOM standardisiert sowohl das Format zur Speicherung der Daten, als auch das Kommunikationsprotokoll zu deren Austausch.

Datenformat

Real World Information Model

Real World Information Model

DICOM fasst Daten in einem sogenannten Real World Information Model auf, das in die Stufen Patient, Studie, Serie und Instanz unterteilt ist. Jede Instanz eines DICOM-Objektes hält somit alle Informationen, um sie einer bestimmten Serie (beispielsweise Bild-Serie), Studie (einem bestimmten Aufenthalt im Klinikum) und Patienten zuordnen zu können.

Die Eindeutigkeit der Information wird anhand von Eindeutigen Kennzeichnern (Unique Identifier) umgesetzt.

Information Object Definition

Beispiel einer Bild IOD

Alle Objekte in DICOM werden über eine sogenannte Information Object Definition festgelegt. Diese besteht aus mehreren Modulen, die wiederum einzelne Attribute bzw. Sequenzen von Attributen enthalten.

Es wird hierbei zwischen normalisierten (Normalized) und zusammengesetzten (Composite) Objekten unterschieden. Normalisierte Objekte stimmen mit Objekten der realen Welt überein, während zusammengesetzte Objekte Attribute enthalten, die zwar durchaus mit dem Objekt der realen Welt in Verbindung stehen, ihnen aber nicht unmittelbar zuzuordnen sind.

Die Composite-Objekte haben normalerweise alle die folgenden Module gemein: SOP Common, Patient, Study, Series und Equipment. Weitere Module variieren je nach Modalität des Objektes. Über diese, auch Header-Information genannten Module lässt sich jedes beliebige Objekt eindeutig einem bestimmten Vorgang zuordnen.

Module Definition

Modul-Definitionen sind im DICOM-Standard in Kapitel 3 zu finden.

Attribute Definition

DICOM Data Element

Ein Attribut wird über eine festgelegte achstellige Hexadezimalzahl, ein sogenanntes Data Tag definiert. Die ersten vier Stellen definieren die Zugehörigkeit des Attributes zu einer bestimmten Gruppe (wie beispielsweise File Meta Information), die weiteren vier bestimmen das Element. Zur besseren Lesbarkeit wird ein DICOM Data Tag normalerweise in der Form (aaaa,bbbb) mit einem Komma in der Mitte dargestellt. Somit entspricht das Tag 0x00100010 - Patient's Name - dem Dezimalwert 1048608 und wird als (0010,0010) dargestellt.

DICOM-Standard-Attribute haben immer eine geradzahlige Gruppenzahl, wobei die Gruppen 0000, 0002, 0004 und 0006 für DIMSE-Kommandos und DICOM File Sets reserviert sind. Ungerade Gruppenzahlen sind privaten Datenelementen vorbehalten, die durch jeden Implementierer vergeben werden können.

Ein weiteres Charakteristikum eines Attributes ist dessen Value Representation (VR), beispielsweise DS (Double String), IS (Integer String) oder ST (Short Text). Hierzu gehört die maximal mögliche Länge eines Feldes und der erlaubte Zeichensatz, bzw. explizit nicht erlaubte Zeichen.

Des weiteren ist die Definition der Multiplizität eines Attributes notwendig. Als Beispiel hat die Angabe eines Winkels innerhalb eines Double String die Mulitplizität 1. Eine Koordinate, ebenfalls vom Typ DS, hat die Mulitplizität 3, um die Position in allen Raumrichtungen angeben zu können.

Die vierte notwendige Eigenschaft ist der Typ des Elements. Es gibt die Unterscheidungen zwischen Typ 1 - zwingend notwendig und Inhalt muss vorhanden sein -, Typ 2 - zwingend notwendig, kann aber leer sein - und Typ 3 - nicht zwingend notwendig. Desweiteren können die Typen durch den Zusatz des Buchstabens C ("1C", "2C") an Bedingungen geknüpft werden. Daraus ergibt sich dann, dass beispielsweise ein Element des Typs 1 auch tatsächlich nur zwingend vorhanden sein muss, wenn die in der dazugehörigen Beschreibung definierte Bedingung auch tatsächlich erfüllt ist.

Während die Value Representation und die Value Multiplicity konstant bleiben, kann sich der Typ ändern, je nachdem in welchem Modul das Attribut verwendet wird. Bedingungen für die Typen 1C und 2C können sich somit auch entsprechend ändern und sind in der jeweiligen Modul-Definition in der Beschreibung des Attributes einzeln aufgeführt.

Beispiele

 (0010,0010) - Patient's Name, VR: PN, VM: 1, Type: 2 

 (0010,0020) - Patient ID, VR: LO, VM: 1, Type: 2

Attribut- und dazugehörige Typ-Definitionen sind im DICOM-Standard in Kapitel 3 zu finden. Value Representation und Value Multiplicity sind für alle Attribute in Kapitel 6 definiert. Die Definitionen der Value Representation-Werte sind in Kapitel 5 "Data Structures and Encoding" aufgeführt.

Service Classes

Service-Klassen beschreiben Aktivitäten bzw. Dienste der realen Welt. Zum einen können diese zum Transport von Objekten verwendet werden, andererseits existieren auch Dienste, die Operationen auf bestehenden Objekten ausführen. Als Beispiele hierfür: Die Storage-Service-Class dient dem Transfer von DICOM-Objekten. Query/Retrieve ermöglicht es in einem Archiv nach Daten zu suchen und daraufhin das Archiv anzuweisen, die Daten an die Instanz von der die Anfrage stammt zu senden.

Aus dieser Definition geht auch hervor, welche Applikation in einer DICOM-Verbindung der Anwender einer Service Class und wer der Bereitsteller ist. Man spricht hierbei vom Service Class User bzw. Service Class Provider. Wenn zum Beispiel ein CT-Scanner DICOM-Objekte zu einem PACS überträgt, so stellt das PACS die Service Class für die entsprechende Modalität zur Verfügung und agiert somit als SCP. Der CT-Scanner wiederum verwendet diesen Service um die Objekte zu senden als SCU. Überträgt daraufhin das PACS Objekte zu einer weiteren Instanz, ist nun diese Instanz SCP und das PACS in der Rolle des SCU.

Service Object Pair Classes

Service Object Pair Classes oder einfach nur SOP Classes definieren die Verbindung aus Objekt und Service, da es nicht ausreichend ist, dass eine Applikation als Beispiel Storage unterstützt. Es muss immer eine SOP Class, wie beispielsweise CT Image Storage spezifiziert werden.

Netzwerkkommunikation

Der DICOM-Standard setzt auf den unteren beiden Ebenen des OSI-Modells auf und verwendet TCP/IP zur Übertragung der Information. Um eine DICOM-Kommunikation zwischen zwei Knoten, bzw. Entitäten (Entities) aufzubauen ist somit eine IP-Adresse und der Port des Zielsystems notwendig. Standardmässig ist hierfür laut IANA Port 104 vorgesehen.

Der erste Schritt einer jeden DICOM-Verbindung ist die sogenannte Association Negotiation, die Aushandlung der SOP Classes und der Transfer Syntax.

ping and echo

Reservierung von Port 104

Association Negotiation

Presentation Context, Abstract Syntax

Standard

Geschichte

Im Zuge der Entwicklung digitaler Bildgebungssysteme zu Beginn der 1970er Jahre, allen voran getrieben durch die Entwicklung des Computertomografen durch Godfrey Hounsfield, erwuchs der Bedarf Bilddaten zwischen Systemen verschiedener Hersteller austauschen zu können. Daraufhin gründeten 1982 das American College of Radiology (ACR) als Interessenvertretung der Anwender und die National Electrical Manufacturers Association (NEMA) als Berufsverband der nordamerikanischen Hersteller eine Arbeitsgruppe, die den Austausch digitaler Bildinformationen definieren sollte.

1985 wurde die erste Version des ACR/NEMA-Standards veröffentlicht, 1988 eine zweite und mit der Version 3.0 von 1993 erfolgte die Umbenennung von "ACR-NEMA" in DICOM. Seither erscheinen in regelmäßigen Abständen neue Revisionen des Standards, doch verwendet man hierbei nicht die Bezeichnung "3.0", sondern man bezieht sich auf das Erscheinungsjahr der jeweiligen Version. Aktuell ist die Version 2008 erhältlich.

Struktur

Der DICOM-Standard, der bei der NEMA (siehe Weblinks) in der aktuellen Fassung bereitgestellt wird, besteht aus mehreren Teilen (Stand 2008):

• Part 1: Introduction and Overview (Einführung und Überblick)
• Part 2: Conformance (Konformität)
• Part 3: Information Object Definitions (Informationsobjekt Definitionen)
• Part 4: Service Class Specifications (Serviceklassen Spezifikationen)
• Part 5: Data Structures and Encoding (Datenstrukturen und Kodierung)
• Part 6: Data Dictionary (Datenlexikon)
• Part 7: Message Exchange (Nachrichtenaustausch)
• Part 8: Network Communication Support for Message Exchange (Netzwerkkommunikationsunterstützung für Datenaustausch)
• Part 10: Media Storage and File Format for Media Interchange (Speicherung auf Medien und Dateiformat für den Medienaustausch)
• Part 11: Media Storage Application Profiles (Anwendungsprofile für die Speicherung auf Medien)
• Part 12: Media Formats and Physical Media for Media Interchange (Medienformate und physische Medien für den Medienaustausch)
• Part 14: Grayscale Standard Display Function (Grauskala-Standard-Anzeigefunktion)
• Part 15: Security and System Management Profiles (Profile für Sicherheit und Systemmanagement)
• Part 16: Content Mapping Resource (Hilfsquelle zur Inhaltszuordnung)
• Part 17: Explanatory Information (Erklärende Informationen)
• Part 18: Web Access to DICOM Persistent Objects (WADO) (Web-Zugriff auf persistente DICOM-Objekte (WADO))

Die Teile 9 und 13 sind nicht mehr im Standard enthalten.

Standardisierungsvorgang

Der DICOM-Standard wird noch heute von mehreren Arbeitsgruppen (Working Groups) kontinuierlich erweitert, um der fortwährenden Entwicklung von Medizin-, Hard- und Softwaretechnologie zu begegnen. Derzeit existieren 26 Working Groups (Stand: Juni 2008), die DICOM um verschiedene Teilbereiche (z.B. Biosignale (EKG), Nuklearmedizin, Datenkompression, Datensicherheit, 3D, Chirurgie, ...) erweitern. Mitglieder der Working Groups sind Mitarbeiter von Medizintechnik-Herstellern, Kliniken, Universitäten und anderen Forschungseinrichtungen. Als Beispiel befassen sich die aktuellen Entwicklungen der Working Group 6 ("Base Standard") und Working Group 7 ("Radiotherapy") mit der Einführung einer neuen Definition von Arbeitsabläufen innerhalb der verschiedenen Domänen einer Klinik und der damit notwendigen Einführung neuer DICOM-Objekte.

Weiterentwicklungen werden durch sogenannte Supplements dem Standard hinzugefügt. Diese werden zunächst von einer oder mehrerer Working Groups verfasst und dann der Working Group 6 (Base Standard) zur Sichtung vorgelegt. Erscheint die Erweiterung sinnvoll, wird dem Supplement eine Nummer zugeteilt. Sobald die Arbeitsgruppen ihre Zusätze finalisiert haben, werden diese den stimmberechtigten NEMA-Mitgliedern (DICOM Voting Members) zur Abstimmung vorgelegt. Nach einer positiven Abstimmung erhält die Information innerhalb des Zusatzes Gültigkeit und wird in die darauffolgende Version des DICOM-Standards eingearbeitet.

Änderungen am Standard oder Fehler in den Dokumenten können bei den verschiedenen Working Groups durch ein Änderungsgesuch (Change Proposal) eingereicht werden und werden ebenfalls durch die DICOM Working Group 6 (Base Standard) den stimmberechtigten Mitgliedern vorgelegt.

Aus dem DICOM-Standard entfernte Elemente (retired) sollen bei Neuimplementierungen nicht mehr berücksichtigt werden. Generell werden jedoch aus Gründen der Abwärtskompatibilität nur Elemente entfernt, die im Konflikt mit anderen Konzepten des Standards stehen oder nie bzw. nur selten implementiert wurden.

Anwendung

DICOM ist auch die Grundlage für die elektronische Bildarchivierung in Praxen und Krankenhäusern (Picture Archiving and Communication System, PACS).

Vorteile

Fast alle Hersteller bildgebender oder bildverarbeitender Systeme in der Medizin wie z.B. Digitales Röntgen, Magnetresonanztomographie, Computertomographie oder Sonografie implementieren den DICOM-Standard in ihren Produkten. Dadurch wird im klinischen Umfeld Interoperabilität zwischen Systemen verschiedener Hersteller erreicht.

Weblinks

Standard-Informationen

• DICOM-Seite der NEMA
• Aktueller Zustand der Supplements und Change Proposals
• Aufbau des Kopfdatenbereiches

Weiterführende Literatur

• Einführung auf medizin-informatik.org
• Frei erhältliches DICOM "Kochbuch"
• Seminar Medzininformatik der FH Giessen

DICOM Toolkits

• Freies DICOM-Toolkit, Referenzimplementierung der Universität Oldenburg
• Open Source Mono/.NET DICOM-Bibliothek, Konsolenwerkzeuge und DICOM-Betrachter
• Open Source Java DICOM-Bibliothek mit einigen Beispielprogrammen
• DICOM Informationsmaterial + Pixelmed Java DICOM toolkit (Open Source)

DICOM-Betrachter

• Tudor Dicom Viewer: Open Source DICOM Viewer
• OsiriX - Free Open Source Software (FOSS) Viewer für Mac OS X
• DICOM-Viewer unter KDE

Beispieldaten

• Beispielbilder im DICOM-Format