Digital Imaging and Communications in Medicine

Digital Imaging and Communications in Medicine (DICOM) ist ein weltweiter offener Standard zum Austausch von digitalen Bildern in der Medizin. DICOM standardisiert sowohl das Format zur Speicherung von Bilddaten, als auch das Kommunikationsprotokoll zum Austausch der Bilder. Fast alle Hersteller medizinisch bildgebender Systeme wie z.B. Digitales Röntgen, Magnetresonanztomographie, Computertomographie oder Sonografie implementieren den DICOM-Standard in diesen Geräten. Dadurch wird im klinischen Umfeld Interoperabilität zwischen medizinischen Systemen verschiedener Hersteller erreicht. Hersteller, die DICOM-konforme Medizinprodukte anbieten, müssen ein sogenanntes Conformance Statement für ihre Produkte anbieten. Form und Inhalt des Conformance Statements sind ebenfalls in DICOM standardisiert. DICOM ist auch die Grundlage für die (herstellerübergreifende) elektronische Bildarchivierung in Praxen und Krankenhäusern (Picture Archiving and Communication System, PACS).

Die derzeit aktuelle Version DICOM 3.0 ist seit 1992 verfügbar und baut auf den inzwischen veralteten ACR-Nema 1.0/2.0 Standards auf. 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. Zum Zeitpunkt (Mai 2006) existieren 26 Working Groups, die DICOM um verschiedene Teilbereiche (z.B. Biosignale (EKG), Nuklearmedizin, Datenkompression, Datensicherheit, 3D, Chirurgie, ...) erweitern. Mitglieder der Working Groups sind Mitarbeiter von Medizintechnik-Herstellern (Manufacturer), Kliniken, Universitäten und anderen Forschungseinrichtungen.

Hersteller von Medizinsystemen haben innerhalb von DICOM auch die Möglichkeit, eigene private Objekte zu definieren. Diese proprietären Objekte sind jedoch unter Umständen nicht mehr kompatibel zu anderen Herstellern, was die Absicht der Interoperabilität wieder konterkariert.

Weiteres empfehlenswertes Fachwissen

Wie erhalten Sie Tag für Tag genaue Wägeresultate?

Wie kann man Pipetten schnell überprüfen?

Richtiges Wägen mit Laborwaagen: Die Wägefibel

Datenformat

  DICOM beinhaltet neben Datenfeldern (z.B. Informationen über Bilder, Befunde, Patienten, Studien, Serien, ...) auch die Syntax und Semantik von Kommandos und Nachrichten. Weiterhin legt der Standard Vorschriften für die Beschreibung von DICOM-kompatiblen Geräten und Software fest, da für jedes DICOM-kompatible Gerät eine exakte Beschreibung der Systemfähigkeit vorhanden und veröffentlicht sein muss (DICOM Conformance Statement).

Ein DICOM-Datensatz dient als Container. Er enthält außer einem oder mehreren Bildern auch Metainformationen wie Patientenname, Aufnahmedatum, Geräteparameter oder Arztname.

Das Bild rechts basiert auf einer DICOM-Datei. Zur Anzeige wurde es in ein Web-taugliches Format konvertiert.

DICOM speichert bzw. überträgt Bilder verlustlos oder verlustbehaftet, angelehnt an das TIFF und JPEG-Format. Es kann Bildserien zusammenfassen. Die verschiedenen Kompressionsverfahren werden in eigenen Transfersyntaxen definiert.

Nutzen von DICOM für Anwender

DICOM soll die Interoperabilität zwischen verschiedenen medizinischen Anwendungen („application entity“) gewährleisten.

Mit DICOM als offenem Standard kommunizieren Geräte der bildgebenden Medizin unabhängig von der verwendeten Systemplattform oder dem Hersteller. Ein Anwender hat somit die Freiheit, die Geräte zu verwenden, mit denen er seine Aufgaben am Besten lösen kann.

DICOM unterstützt den Arbeitsablauf in radiologischen Einrichtungen. Das „DICOM Model of the Real World“, das in Part 3 des Standards vorgestellt wird, standardisiert die Verwaltung von Untersuchungen und Bilddaten. Damit ist eine filmfreie Arbeitsweise möglich, die das vormals allfällige „Filmtüten und Zettel suchen“ erübrigt und eine computerbasierte Langzeitarchivierung ermöglicht.

Conformance Statements

In Conformance Statements beschreiben die Hersteller von Systemen, welche DICOM Funktionen ihre Produkte unterstützen. Ein Conformance Statement ist zwingende Voraussetzung für die Behauptung, dass ein Gerät oder System „DICOM-fähig“ ist.

DICOM schreibt ebenfalls vor, wie Conformance Statements zu verfassen sind, welche Struktur sie haben müssen und welche Information enthalten sein muss. Ein Anwender mit DICOM Kenntnissen kann die Conformance Statements seiner Geräte (oder der zu beschaffenden Geräte) analysieren und daraus Vorhersagen über die möglichen Datenkommunikationsvorgänge treffen. Die Statements können sich auch nur auf Teilimplementierungen beziehen.

Unique Identifiers (UIDs)

DICOM identifiziert jedes Informationsobjekt durch Unique Identifiers (UIDs). UIDs sind weltweit eindeutig entsprechend ISO Standard 9834-3. Das wird erreicht, indem jeder Implementator eine „UID Root“, einen Stammeintrag beantragen muss, auf dem er dann seine Identifikationen aufbaut. Damit sind Bilddaten eindeutig identifizierbar, auch Bildserien und ganze Untersuchungen (Studies) bekommen UIDs. Die DICOM-eigenen Objekte wie Datenobjekt-Beschreibungen und Transfersyntaxen, mit denen Datenobjekte übertragen oder ausgetauscht werden, haben ebenfalls eine eigene UID. Das Format der UIDs wird durch ISO 8824 definiert, DICOM spezifische Informationen dazu befinden sich in Part 5, Section 9 der Dokumentation.

DICOM File Sets

DICOM definiert keine unabhängigen „Dateien“. Die auszutauschenden Daten können als Datei gespeichert werden, aber nur als Teil eines DICOM File Sets. Diese DICOM File Sets können auf Wechseldatenträgern existieren, eine Standardisierung für DICOM Dateisysteme auf Festplatten oder Netzwerk-Laufwerken gibt es nicht – trotzdem hat sich unter den Herstellern eingebürgert, auch mit einzelnen Dateien aus DICOM File Sets umgehen zu können; diese werden im Jargon dann als „DICOM-Dateien“ bezeichnet.

In einem DICOM File Set wird der kleinste gemeinsame Nenner für das Dateisystem gewählt. CDs sollten streng der ISO9660 Norm entsprechen: Der Dateiname sollte aus max. 8 Zeichen (Großbuchstaben, Ziffern) bestehen und überhaupt keine Dateiendung tragen. Zusätzlich muss im niedrigsten Verzeichnis-Niveau („File System Root“) eine Datei mit dem Namen DICOMDIR liegen, die ihrerseits genau festgelegte Informationen über Inhalt und Pfad der Dateien auf dem Datenträger enthält.

Im Umgang mit DICOM File Set Members als selbständige Datenobjekte haben sich aber auch Dateiendungen etabliert, beispielsweise .ima, .img und .dcm. Diese ermöglichen einfachen Programmen, die Datei anhand der Dateiendung zuzuordnen. – Das ist allerdings außerhalb des DICOM-Standards.

Standardisierung

  Entwickelt wurde der Standard seit 1983, ursprünglich vom American College of Radiology (ACR) und der National Electrical Manufacturers Association (NEMA). DICOM ist mittlerweile weltweit akzeptiert und wird in Working Groups gepflegt. Der DICOM-Standard, der bei der NEMA (siehe Weblinks) in der aktuellen Fassung bereitgestellt wird, besteht aus mehreren Teilen (Stand 2006):

• 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 Profiles (Sicherheitsprofile)
• Part 16: Content Mapping Resource (Hilfsquelle zur Inhaltszuordnung)
• Part 17: Explanatory Information (Erklärende Information)
• 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, dafür gibt es eine Reihe sog. supplements, die aber auch nach und nach in den Standard eingearbeitet werden.

Aus dem DICOM Standard entfernte Elemente (retired) sollten bei Neuimplementationen nicht mehr berücksichtigt werden. Generell werden nur Elemente entfernt, die im Konflikt mit anderen Konzepten des Standards stehen oder nie implementiert wurden.

DICOM unterscheidet zwischen verschiedenen Modalitäten (Röntgen, Ultraschall, Computertomographie, Magnetresonanztomographie, PET usw.) bzw. SOP-Klassen (Service Object Pair Classes), die die Modalitäten ggf. noch weiter unterteilen.

DICOM ist ein Binärformat. Die Metadaten im Kopfdatenbereich bestehen aus einer Liste von DICOM-Attributen, ggf. mit verschachtelten weiteren Listen (Sequences). Part 5 des Standards erklärt die Struktur der einzelnen Attribute. Es existieren spezielle Anwendungen zum Anzeigen und Bearbeiten der Attribute; allein mit einem Hex-Editor können die Daten nicht verständlich angezeigt werden.

Begriffsdefinitionen

• IOD (Information Object Definition): Informationsobjekte repräsentieren Objekte der (realen) medizinischen Welt (z.B. Patient, Study, Series, Image, ...) und deren Beziehungen zueinander.
• SC (Service Class): Dienstklassen beschreiben Aktionen, welche mit den Informationsobjekten ausgeführt werden können. Beispiele: Store, Print, Query, Retrieval, Modality Worklist, Storage Commitement, Modality Performed Procedure Step (MPPS). Es ist nicht notwendig alle Dienstklassen zu unterstützen um sich als „DICOM kompatibel“ bezeichnen zu dürfen. Die meisten Applikationen bzw. Geräte unterstützen nur jene Dienstkklassen, die für ihren Verwendungszweck notwendig sind.
• SOP Class (Service Object Pair Class): Die Kombination aus Informationsobjekt und die damit auszuführende Aktion bildet ein Service-Object-Paar (z.B. „MR-Bild speichern“, „Ultraschallbild drucken“, etc.) SOP's bilden die funktionellen Grundeinheiten von DICOM.
• Transfer Syntax: Die Daten können in unterschiedlichen Datenrepräsentationen ausgetauscht werden, dazu dienen Transfer Syntaxes. In ihnen wird beschrieben, wie Zahlen und Bilddaten repräsentiert werden und wie gegebenenfalls Bilddaten komprimiert werden. Dazu nützt DICOM auch eingebettete Formate wie JPEG.
• SCU (Service Class User): Ein Service Class User ist ein Gerät bzw. eine Applikation, die Daten einer bestimmten Service Class versenden kann.
• SCP (Service Class Provider): Ein Service Class Provider ist ein Gerät bzw. eine Applikation, die Daten einer bestimmten Service Class empfangen kann.
• DICOM Storage Service Class: Service Class, die das Versenden, Empfangen und Abspeichern von medizinischen Bildern umfasst. Siehe auch PACS (Picture Archiving and Communication System).
• DICOM Print Management Service Class: Service Class, die das Drucken von medizinischen Bildern umfasst.
• DICOM Worklist Management Service Class: Service Class, die sich mit der Übertragung von Patientendaten von der Eingabestation zu der jeweiligen Modalität (Bsp.: Ultraschallgerät, CT) befasst.
• DICOM Verification Service Class : Service Class, die sich mit der Verifkation der Netzwerkverbindung zweier DICOM Systeme befasst. Dieser Vorgang wird oft auch als Echo bezeichnet.
• AE Title = Application Entity Title : „Name“ eines DICOM Knotens.

Siehe auch

• HL7 (Health Level 7) internationaler Standard für den Austausch von Daten zwischen Computersystemen im Gesundheitswesen.
• IHE (Integrating the Healthcare Enterprise) eine Initiative, um die Standards im Gesundheitswesen unter einen Hut zu bringen.

• DICOM Informationsmaterial + Pixelmed Java DICOM toolkit (Open Source)
• Beispielbilder im DICOM-Format
• Aufbau des Kopfdatenbereiches