Digital Imaging and Communications in Medicine

Digital Imaging and Communications in Medicine (DICOM; deutsch digitale Bildgebung und -kommunikation in der Medizin) ist ein offener Standard zur Speicherung und zum Austausch von Informationen im medizinischen Bilddatenmanagement. 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.

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

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

Datenformat mini|DCM-Beispielbild (siehe Text)

DICOM enthält 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, der außer einer oder mehrerer Objektdefinitionen auch Metainformationen wie Patientenname, Aufnahmedatum, Geräteparameter oder Arztname enthalten kann. Die Objektdefinitionen können Bilddaten, geometrische bzw. mathematische Informationen und auch behandlungsspezifische Informationen sein, wie beispielsweise in den sogenannten DICOM RT-Objekten, die selbst nur Behandlungsdaten enthalten und Bilddatensätze nur referenzieren.

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

Der DICOM-Standard erlaubt es auch, eigene, sogenannte private Objekte, Module oder Attribute zu definieren. Diese proprietären Informationen sind jedoch im Normalfall nicht mehr kompatibel mit Implementierungen anderer Hersteller.

Das Bild rechts basiert auf einer DICOM-Datei. Zur Anzeige wurde es in ein Standard-Grafikformat konvertiert.

Real World Information Model mini|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 bzw. einer einzelnen Untersuchung) und Patienten zuordnen zu können.

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

Information Object Definition mini|Beispiel der IOD eines Bildes

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 gruppieren DICOM-Attribute in logischen Einheiten. So enthält beispielsweise das Patienten-Modul alle den Patienten betreffende Informationen, wie beispielsweise Name, ID, Geschlecht oder Alter. Module können in verschiedenen Composite-Objekten wiederverwendet werden. In jeder Definition eines Composite-Objektes ist auch definiert, ob ein bestimmtes Modul zwingend notwendig ist und vorhanden sein muss (M – Mandatory), ob das Vorhandensein an bestimmte Bedingungen geknüpft ist (C – Conditional) oder ob es im Ermessen des Anwenders liegt (U – User Option).

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

Attribute Definition mini|DICOM Data Element

Ein Attribut wird über eine festgelegte achtstellige 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 1048592 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 (Decimal 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 Value Multiplicity (VM), d. h. der Multiplizität eines Attributes notwendig. Als Beispiel hat die Angabe eines Winkels innerhalb eines Decimal String die Multiplizität 1. Eine Koordinate, ebenfalls vom Typ DS, hat die Multiplizitä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. Des Weiteren 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) – PatientID, VR: LO, VM: 1, Type: 2 (0010,0021) – IssuerOfPatientID, 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.

Dienstklassen Die im DICOM-Standard definierten Service Classes bezeichnen verschiedene Dienste. Werden diese auf ein Objekt angewandt, bilden sie eine Dienstgruppe. Es gibt folgende Dienste: Verify Store Query/Retrieve Procedure Step (Notification) Print Management Media Storage Management Storage Commitment Worklist Management Presentation State Storage Structured Reporting Storage Application Event Logging Relevant Patient Information Query Instance Availability Notification Media Creation Management Hanging Protocols Storage Hanging Protocols Query/Retrieve Substance Administration Query (Beschreibungen finden sich in Part 4 des Standards, kursiv gesetzte Serviceklassen sind von geringerer Bedeutung oder werden von Geräteherstellern noch nicht weitgehend unterstützt).

Die wichtigsten Dienste Verify Mit Verify kann überprüft werden, ob ein externer Netzwerkknoten DICOM mit den konfigurierten Parametern unterstützt. Storage Der Storage Service speichert einen Großteil der persistenten Datenobjekte. Query/Retrieve Mit Query und Retrieve kann ein PACS oder ein anderes DICOM Gerät nach Objekten durchsucht werden (Query) und gefundene Objekte dann auf ein anderes Gerät übertragen werden (Retrieve). Procedure Step (abgekürzt auch MPPS für Modality performed procedure Step) Mittels Procedure Steps können DICOM-Geräte andere über durchgeführte Untersuchungsschritte benachrichtigen. Typischerweise werden diese Prozeduren auf einer Worklist dem Gerät zur Bearbeitung mitgeteilt, das diese dann ausführt, abbricht oder ändert. Diese Information kann per Performed Procedure Step Notification an das planende System übermittelt werden. Storage Commitment Mittels Storage Commitment kann die speichernde Modalität abfragen, ob die von ihr übermittelten Daten sicher gespeichert wurden. Hintergrund: Jedes Speichersystem verfügt über einen Cache, der eingehende Daten zunächst in einem flüchtigen Datenspeicher zwischenpuffert. Es ist eine Situation denkbar, bei der ein Bilddatensatz zunächst vollständig an das PACS übergeben und im Cache gespeichert wurde. Stürzt das PACS bzw. das Speichersystem aber ab, bevor der Inhalt auf die nichtflüchtigen Datenträger (meist Festplatten) geschrieben wurde, wären diese Daten weg, obwohl an die übermittelnde Modalität eine fehlerfreie Übertragung rückgemeldet wurde. Da der Speicherplatz an der Modalität nur für wenige Tage ausreichend ist, könnten die Bilder folglich dort gelöscht werden, obwohl sie nie im PACS gespeichert wurden. Die Meldung Storage Commitment wird vom PACS erst ausgelöst, wenn die Daten nicht nur vollständig empfangen, sondern auch sicher auf nichtflüchtigen Speichern abgelegt wurden. Damit kann ein durch das beschriebene Szenario verursachter Datenverlust ausgeschlossen werden. Worklist Management (auch MWL für Modality Worklist oder auch DICOM Modality Worklist genannt) Mit Worklist Management kann ein planendes System (typischerweise das RIS) einem (meist bildgebenden) Gerät eine Liste der nächsten Untersuchungen, zusammen mit den Patientendaten übermitteln. Damit entfällt die Eingabe der Patientendaten und der angeforderten Untersuchung am Untersuchungsgerät (z. B. CT, MR, Ultraschall). Presentation State Storage Mit Presentation State Storage kann Information übermittelt werden, wie ein Bild dargestellt wurde oder dargestellt werden soll. Presentation States beinhalten z. B. Informationen zum Graustufenabgleich, zu Anmerkungen und Markierungen und zu Ausschnittvergrößerungen. Structured Reporting Storage Mit Structured Reports ist es möglich, einen medizinischen Befund kodiert zu übermitteln. Hanging Protocols Storage Mit Hanging Protocols Storage kann eine konsistente Darstellung der Bilderserien und Studien auf verschiedenen Anzeigen für verschiedene Benutzer gespeichert werden. Hanging Protocols Query/Retrieve Mit Hanging Protocols Query/Retrieve können Anzeigeeinstellungen gesucht und übertragen werden (vergleiche Query/Retrieve Serviceklasse).

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 primär 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.