- Digital Imaging and Communications in Medicine
-
Digital Imaging and Communications in Medicine (DICOM) 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).
Inhaltsverzeichnis
Datenformat
DCM-Beispielbild (siehe Text)
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, 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, als 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 zu Implementierungen anderer Hersteller.
Das Bild rechts basiert auf einer DICOM-Datei. Zur Anzeige wurde es in ein Standard-Grafikformat konvertiert.
Real World Information Model
Real World Information ModelDICOM 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 IODAlle 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
DICOM Data ElementEin 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 Double String die Mulitplizitä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) - 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.
Serviceklassen
Die im DICOM-Standard definierten Serviceklassen bezeichnen verschiedene Dienste. Werden diese auf ein Objekt angewandt, bilden sie eine Servicegruppe. 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 Services
- 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
- 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 man anfragen, ob die übermittelten Daten sicher gespeichert wurden. Dies ist besonders wichtig, wenn eine Modalität erzeugte Bilder löschen und sicherstellen möchte, dass diese auch archiviert sind.
- Worklist Management
- Mit Worklist Management kann ein planendes System (typischerweise das RIS) einem anderen Gerät eine Liste der geplanten nächsten Untersuchungsschritte übermitteln.
- 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.
DICOM kann auch Arbeitsabläufe in Kliniken unterstützen. Bewährt hat sich hier seit vielen Jahren die „Worklist“-Implementierung in der Radiologie, wie auch im Laborbereich. Dies ermöglicht ein filmfreies Arbeiten und die Langzeitarchivierung in digitalen Systemen.
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. Dies bedeutet jedoch nicht automatisch, dass die Interoperabilität eines Gerätes gewährleistet ist. Dies lässt sich im Normalfall nur durch den Abgleich mehrerer Conformance Statements sicherstellen, oder durch weiterführende Dokumente, wie beispielsweise sogenannte IHE Integration Statements.
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 Implementierer 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 Kapitel 5, Sektion 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. acht 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. Dies ist jedoch kein Teil der DICOM-Standard-Definition.
Standard
Geschichte
Im Zuge der Entwicklung digitaler Bildgebungssysteme zu Beginn der 1970er Jahre, allen voran getrieben durch die Entwicklung des Computertomographen 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 der Standard 2011 erhältlich.
Struktur
Der DICOM-Standard, der bei der NEMA (siehe Weblinks) in der aktuellen Fassung bereitgestellt wird, besteht aus mehreren Teilen (Stand August 2011):
- 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))
- Part 19: Application Hosting (Hosting von Anwendungen)
- Part 20: Transformation of DICOM to and from HL7 Standards (Transformation von DICOM zu und von HL7-Standards)
Die Teile 9 (Point to Point Communication Support for Message Exchange) und 13 (Print Management Point-to-Point Communication Support) 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.
DICONDE
DICONDE (Digital Imaging and Communications for Non-Destructive Evaluation) ist eine Erweiterung von DICOM für zerstörungsfreie Materialprüfung. Dabei werden die Patientendaten durch Komponentendaten ersetzt. DICONDE wird von der ASTM International entwickelt.
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 Commitment, 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.). SOPs 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 JFIF.
- SCU (Service Class User): Ein Service Class User ist ein Gerät bzw. eine Applikation, die einen Dienst in Anspruch nimmt.
- SCP (Service Class Provider): Ein Service Class Provider ist ein Gerät bzw. eine Applikation, die einen Dienst anbietet.
- 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 Verifikation 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.
- IHE PDI (Portable Document Imaging), Empfehlungen zum Austausch von portablen optischen Medien mit Patientenbilddaten konform zum DICOM-Standard.
- OsiriX, DICOM-Viewer
Weblinks
Wikimedia Foundation.
