Digital Imaging and Communications in Medicine (DICOM)

Digital Imaging and Communications in Medicine (DICOM) ist ein Standard sowohl für die Speicherung medizinischer Bilddaten (vergleichbar dem jpeg-Standard für Bilddaten oder den verschiedneen avi.Standards für bewegte Bilddaten) als auch für die Übertragung dieser digitaler Daten: Internisten benutzen den DICOM-Standard beim Ultraschall, in der Kardiologie werden Aufnahmen der Koronarangiographien im DICOM-Standard gespeichert, Chirurgen verwenden den Standard, wenn sie CT-, MR-Bilder Koro-Filme zur Planung der Operation ansehen, usw.<br\> Die Kehrseite der Medaille ist die Zunahme des Umfangs des Standards. Der Standard selbst besteht aus mehreren Teilen mit mehreren 1000 Seiten. Ergänzend zu den eigentlichen Standard-Dokumenten gibt es ergänzende Dokumente:

• Supplements: Ergänznungen im eigentlichen Sinne, welche den Standard um neue Informationsobjekte oder Dienste erweitern
• Correction Proposals: dienen der Klarstellung oder auch der Änderung/Korrektur innerhalb des Standards.

Entwicklung des DICOM-Standard

In den 80er Jahren des vorigen Jahrtausends stieg mit dem exponentiellen Anstieg des Einsatzes von Computer-Tomographen (CT) und dem Aufkommen von anderen digitalisierten bildgebenden Modalitäten wie z.B. dem Ultraschall der Bedarf für eine standardisierte Möglichkeit der Bildübermittlung. Im Jahre 1982 gründeten 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 sich zum Ziel gesetzt hatte, den Austausch von Bildern und Bildinformationen zum Beispiel über das Objekt, Segmentierung und Registrierung in einem Standard zu definieren. Dieser Standard sollte

• die Kommunikation digitaler Bildinformationen unabhängig vom Gerätehersteller und
• die Entwicklung von digitalen Bild- und Kommunikationssystemen (picture archiving and communication systems PACS), die auch mit anderen Krankenhausinformationssystemen kommunizieren können,

ermöglichen.<br\> 1985 wurde der erste Standard, genannt ARC/NEMA, auf dem RSNA-Kongress in Chicago veröffentlicht. In diesem ersten Standard wurden Hardware-Interface und die grundlegenden Elemente und Protokolle für einen Datentransfer spezifiziert. Es folgten zwei Revisionen (Rev. 1.0 im Oktober 1986 und Rev. 2.0 im Januar 1988) dieser ersten Version des Standards bevor 1988 Version 2.0 des ACR-NEMA Standards veröffentlicht wurde. Obwohl Version 2.0 schon viele Verbesserungen gegenüber der 3 Jahre zuvor veröffentlichten Version 1 aufwies war auch diese Version noch nicht netzwerkfähig sondern ermöglichte ausschließlich Punkt-zu-Punkt-Verbindungen.<br\> 1993 wurde Version 3.0 des Standards verabschiedet, der auch heute noch aktuell ist, und zugleich ACR-NEMA durch DICOM ersetzt: DICOM ist der Nachfolger von ACR/NEMA. Seitdem steht der Standard kostenlos auf der NEMA-Homepage als Download zur Verfügung.

Aufbau des DICOM-Standard

Der eigentliche DICOM-Standard besteht aus klar voneinander getrennten Bereichen ("Parts"). Derzeit (2015) existieren 20 Parts:

• Part 1: Introduction and Overview<br\>Hier ist das dem Standard zugrunde liegende Entwurfsprinzip beschrieben. Ebenso sind die verwendeten Abkürzungen und Fachausdrücke definiert. In sehr kompakter Weise wird ein Überblick über DICOM 3.0 gegeben.
• Part 2: Conformance<br\>Die Kriterien, die ein Hersteller erfüllen muss, damit er sein Gerät als DICOM-kompatibel ("DICOM Comformance Statement") erklären kann, sind in diesem Part dargestellt. In einem DICOM Conformance Statement müssen alle DICOM relevanten Eigenschaften des Gerätes in den SOP-Klassen (SOP= Service-Object Pair) zusammengefasst sein. Dieses Conformance Statement muss zudem 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.
• Part 3: Information Object Definitions<br\>Im Standard werden Informationsobjekte verwendet, die Attribute bzw. bestimmte Eigenschaften besitzen. Diese Informationsobjekte werden in diesem Part definiert. Die "Information Object Definitions" (IOD) bilden die Objekte der realen Welt möglichst präzise ab. Ein Beispiel für ein Informationsobjekt ist "Patient" oder "CT-Bild".
• Part 4: Service Class Specifications<br\>Mit dem Informationsobjekt können Dienstleistungen oder Aktionen durchgeführt werden. Diese sind in diesem Part definiert, wobei gleichartige Dienstleistungen eine Serviceklasse bilden. Werden gleichartige Dienstleistungen aktiv zur Verfügung gestellt, spricht man vom "Service Class Provider" (SCP). Wenn die Dienstleistungen passiv in Anspruch genommen werden, ist die Rede vom "Service Class User" (SCU).
• Part 5: Data Structures and Encoding<br\>Um Informationen über das Netzwerk zu versenden, müssen diese sowohl eine bestimmte Struktur besitzen als auch einen Datensatz aufweisen, welchen auch die empfangende Applikation kennt. Die Regeln hierfür, die bei einem Verbindungsaufbau vereinbart werden, werden in Part 7 definiert.
• Part 6: Data Dictionary<br\>Alle gültigen Datenelemente sind in diesem Part hier in Form einer Liste aufgeführt, wobei verwandte Datenelemente zu Gruppen zusammengefasst sind. Jede Gruppe besteht aus mehreren Elementen, die den Informationsobjekten von Part 3 entsprechen. Damit 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). Part 6 stellt im Prinzip eine Übersetzungstabelle für alle Datenelemente, die entsprechend dem DICOM Standard kodiert sind, dar. Damit kann man Part 6 als Semantik der Datenelemente bezeichnen.
• Part 7: Message Exchange<br\>Dieser Part beschreibt den Ablauf und die Protokollstruktur für die Kommunikation zwischen Geräten, die einen Datenaustausch durchführen wollen. Hier werden die Regeln für die Kommunikation und die Protokollstruktur festgelegt, es werden die Services (DICOM Message Service Element = DIMSE) wie C-Store, C-Move usw. beschrieben sowie das Protokoll für die "Negotiation".
• Part 8: Network Communication Support for Message Exchange<br\>In diesem Part sind alle notwendigen Systemkomponenten für den Austausch von DICOM-Nachrichten in einem Netzwerk definiert. Part 8 beschreibt dabei jedoch ausschließlich Ebene 5 und 6, d.h. den DICOM Upper Layer,
• Part 9: Retired (!), formerly: point-to-point communication support for message Exchange<br\>In diesem Teil sind die Komponenten definiert, welche für eine Punkt-zu-Punkt Verbindung zwischen zwei Geräten notwendig sind. Dieser Part ist nur für historische Betrachtungen relevant, er gehört mittlerweile nicht mehr zum DICOM-Standard und wird auf den NEMA-Seiten beim aktuellen Standard auch nicht mehr zum Download angeboten.
• Part 10: Media Storage and File Format for Media Interchange<br\>In diesem Part werden die Grundlagen für die Speicherung von DICOM-Objekten auf verschiedenen Datenträgern definiert. D.h. es wird dargestellt, wie Daten auf ein Medium geschrieben werden. Mittels der Darstellungen dieses Parts können beispielsweise Daten "Offline" über Datenträger von einem Gerät zum anderen übertragen werden. Part 10 stellt die Grundlage für Part 11 und Part 12 dar.
• Part 11: Media Storage Application Profiles<br\>Part 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.
• Part 12: Media Formats and Physical Media for Media Interchange<br\>Hier wird sowohl das physikalische Medium wie auch das medienabhängige Datenformat eines Datenträgers, der für einen Datentransfer geeignet ist, spezifiziert.
• Part 13: Retired (!), formerly: print management point-to-point communication Support<br\>Hier erfolgte die Beschreibung aller Protokolle und Dienste, die zur Bereitstellung eines Druckdienstes bei einer Punkt-zu-Punkt Verbindung benötigt werden. Dies stellte eine Alternative für nicht-netzwerkfähige Geräte dar. Auch dieser Teil ist nicht mehr im Standard enthalten und nur für historische Betrachtungen relevant.
• Part 14: Grayscale Standard Display Function<br\>In der Regel werden die zur Befundung verwendeten Einstellungen, welche die optische Erscheinung des Bildes bestimmen (z.B. Fensterung), nicht im Bild gespeichert. Daher ist de Rekonstruktion der Bildansicht zum Zeitpunkt der Befundung zu einem späteren Zeitpunkt nicht mehr möglich. Die Grayscale Standard Display Function versucht diese Problematik zu lösen. Zu diesem Zweck wird ein neues DICOM-Objekt definiert, welches einen umfangreichen Satz von Parametern enthält, welche beschreiben, wie ein bestimmtes Bild auf einem Monitor angezeigt werden soll. Dieses neue "Presentation State" genannte Objekt enthält Referenzen zu den Bildern, auf welche es sich bezieht. Daher sind Presentation States sehr klein und können mit minimalen Aufwand gespeichert werden.
• Part 15: Security and System Management Profiles<br\>Dieser Teil definiert Mechanismen, welche zur Implementierung von Datenschutz- und Datensicherheits-Anforderungen im Hinblick auf die Kommunikation zwischen DICOM-Geräten benutzt werden können. In diesen Part wird beispielsweise die Überprüfung der Authentizität durch die Nutzung von digitalen Signaturen beschrieben oder die Nutzung Benutzer-orientierter Zugriffsrechte.
• Part 16: Content Mapping Resource<br\>Der Part enthält Tabellen mit Wörter, Begriffen/Konzepten. Dieser Teil sorgt für ein strukturiertes Glossar und kommt dem Begriff einer Ontologie in diesem Standard am nächsten.
• Part 17: Explanatory Information<br\>Dieser Teil enthält ausführliche Beschreibung spezieller DICOM-Tags oder Objekte. Die früher in Part 3 geführten Objekte wurden in Part 17 übernommen, der frühere Annex E aus Part 3 ist jetzt Annex A in Part 17.
• Part 18: Web Access to DICOM Persistent Objects (WADO)<br\>In diesem Part wird ein Web-basierter Service eingeführt mittels dessen auf DICOM-persistente Objekte (Bilder, medizinische Reports, ...) zugegriffen und die Objekte dargestellt werden können. Damit kann ein Arzt einen Webbrowser benutzen um die Bilder eines Patienten irgendwo auf der Welt über das Internet zu betrachten.
• Part 19: Application Hosting<br\>Part 19 des DICOM-Standards definiert eine API zwischen zwei Softwareanwendungen (Hosting System and Hosted Application), beide Anwendungen befinden sich auf dem gleichen System, während sie Daten austauschen.
• Part 20: Transformation of DICOM to and from HL7 Standards<br\>In diesem Part wird beschrieben, wie Structured Reports der "DICOM-Welt" in HL7 CDA Release 2 Dokumente umgewandelt werden können. Ergänzend zu diesem Part sollte man die Ausarbeitung von HL7 International zu diesem Thema betrachten.

Die ersten 9 Parts bilden die Basis des Standards, Parts 10 bis 20 sind Ergänzungen und Modifikationen, die erst später entsprechend den Anforderungen und Bedürfnissen der medizinischen Anwender entwickelt wurden.

Weiterentwicklung des DICOM-Standard

Für die Entwicklung und Fortschreibung des DICOM-Standards sind ca. 30 Arbeitsgruppen (Working Groups, WG) des DICOM-Komitees verantwortlich, die Supplements oder Correction Proposals (CP’s) erarbeiten:

• WG-01: Cardiac and Vascular Information
• WG-02: Projection Radiography and Angiography
• WG-03: Nuclear Medicine
• WG-04: Compression
• WG-05: Exchange Media
• WG-06: Base Standard
• WG-07: Radiotherapy
• WG-08: Structured Reporting
• WG-09: Ophthalmology
• WG-10: Strategic Advisory
• WG-11: Display Function Standard
• WG-12: Ultrasound
• WG-13: Visible Light
• WG-14: Security
• WG-15: Digital Mammography and CAD
• WG-16: Magnetic Resonance
• WG-17: 3D
• WG-18: Clinical Trials and Education
• WG-19: Dermatologic Standards
• WG-20: Integration of Imaging and Information Systems
• WG-21: Computed Tomography
• WG-22: Dentistry
• WG-23: Application Hosting
• WG-24: Surgery
• WG-25: Veterinary Medicine
• WG-26: Pathology
• WG-27: Web Technology for DICOM
• WG-28: Physics
• WG-29: Education, Communication and Outreach
• WG-30: Small Animal Imaging
• WG-31: Conformance

Bzgl. der Strategie der Weiterentwicklung veröffentlichte NEMA 2010 ein entsprechendes Strategie-Papier, in welchem einerseits der Scope beschrieben wird, andererseits auch der Zusammenhang mit anderen Standards wie beispielsweise HL7 beschrieben wird. Wer in einer Working Group mitarbeiten will, kann sich per E-Mail oder über einKontaktformular anmelden, die Mitarbeit steht jedem offen.

Supplements und CPs

Aktuell (September 2015) kennt der DICOM-Standard 187 Supplements und 1519 Correction Items, dieser Umfang kann hier nicht beschrieben werden. Alle Supplements und CPs finden sich auf der Homepage von David Clunie.

Weblinks

1. Standard
   1. DICOM Standard Status (David Clunie) [1]
   2. Homepage der DICOM Organisation [2]
   3. Homepage der DICOM-Gruppe von Offis [3]
2. Literatur (Bücher)
   1. Becker T.; Der DICOM Standard in der Kardiologie als Basis für die Interoperabilität medizinischer Bildsysteme und die Entwicklung eines vernetzten Bildarchivs; Shaker Verlag GmbH; 2002 [4]
   2. Clunie, David A.; DICOM Structured Reporting; PixelMed Publishing, Bangor, PA, 2001 [5]
   3. Pianykh, Oleg S.; Digital Imaging and Communications in Medicine (DICOM) -- A Practical Introduction and Survival Guide; 2008; Springer [6]
   4. Oosterwijk, Herman; DICOM Reference Guide; OTech, Inc., Aubrey, TX; 2001 [7]
   5. Oosterwijk, Herman and Paul T. Gihring; DICOM Basics, 3nd ed.; OTech, Inc., Aubrey, TX; 2002 [8]
3. DICOM-Bibliotheken
   1. dcm4che, eine DICOM Implementierung in JAVA [9]
   2. DICOM.pm – Perl-DICOM-Bibliothek [10]
   3. Grass Root DICOM-C++-Bibliothek [11]
   4. openDICOM.NET[12]
4. Weitere Informationen
   1. David Clunie's Medical Image Format Site [13]
   2. DICOM FAQ [14]
   3. RFC 3240 - Digital Imaging and Communications in Medicine (DICOM) - Application/dicom MIME Sub-type Registration [15]
5. Verwandtes
   1. Debian-Med: Medizinische Bildverarbeitung [16]