Was ist "DICOM"?

Dieser Post ist Teil der Serie “Medizinische Datenformate”. Wie immer gilt: Kommentare, Korrekturen, Ergänzungen willkommen.

Legen wir los.

Was ist DICOM?

Einleitend, damit das klar ist: DICOM ist nicht mehr länger Teil der Familie von HL7-Standards.

Die Kerndaten.

• DICOM = “Digital Imaging and Communications in Medicine”
• Ein Standard für die Erstellung, Austausch und Speicherung medizinischer Bilddaten
• Entwickelt durch das “DICOM Standard Committee”
  • Das Urheberrecht hält jedoch die “National Electrical Manufactures Association (NEMA)”
• Entstehung: 1985 (“ACR/NEMA 300”, nocht nicht dudrch das Committee)
• “Finale” DICOM Fassung: 3.0, 1993
• Aktuelle Revision: 2021e

Ein Standard der früh notwendig wurde weil bildgebende Geräte einen Standard für die produzierten Daten und die Datenübertragung brauchten. Das Selbstverständnis ist “the standard for the communication and management of medical imaging information and related data”.

Man kann das vielleicht sehr lose mit dem Standard “DVD” vergleichen: Würde jedes Studio (Sony, Universal, etc.) einge Video-Formate nutzen (h.264, AV1, etc), und auf eigenen Medien verkaufen (DAT Tape, Blu Ray etc), wäre das nicht besonders hilfreich. So hat man sich auf den Standard “DVD” geeinigt, und eine Sony-DVD mit einem Universal-Film spielt auch in einem Toshiba Player.

Und für DICOM gibt es DICOM Viewer :-)

Die erste DICOM-Version ist “Version 3.0”, welche bis heute die aktuelle Version ist. Das liegt daran dass der Standard ein “rollierender” Standard ist (meine Bezeichnung). Damit ist gemeint, dass nur abwärtskompatible Änderungen (“effective compatibility”) eingeführt werden. Aufgrund dieser Arbeitsweise gibt es auch keine Pläne für eine “Version 4.0”. Neuere Ausgaben des Standards werden als “Edition” bezeichnet und bestehen aus einer Jahreszahl mit einem angehängten Buchstaben (zB “2021e”).

Das funktioniert gut für Neuaufnahmen oder Änderungen. Manchmal möchte man aus Standards allerdings auch etwas entfernen. DICOM handhabt das sehr pragmatisch und “empfiehlt” in diesem Fall, den betreffenden Teil nicht mehr zu nutzen, und die Dokumentation dafür wird eingestellt. Es wird allerdings weder verboten noch wäre es im Sinne des Standards “falsch” diesen Teil weiter zu nutzen.

DICOM ist generell ein riesiger Standard mit enormer Komplexität. Er regelt nicht nur Datenformate, Kompressions- und Darstellungsalgorithmen, Auftragsverwaltung, Service-APIs, Terminologien, Security-Aspekte, Prozessschritte, sondern geht auch auf inhaltlich-fachliche Themen wie Nuklearmedizin, 3D-Verfahren, Mammographien, Dermatologen, Zahnärzte, etc. ein. All diese Themen werden in spezifischen Arbeitsgruppen weiterentwickelt.

Mit diesem Hintergrund ist “Gerät od. Software X kann DICOM” keine sinnvolle Aussage (welche Edition? Welche Features werden unterstützt?). Das weiß DICOM auch, und verlangt verlangt von Herstellern um sich DICOM-konform nennen zu dürfen zwei Dinge:

• Eine Mindestmenge an unterstützten Features
• Die Bereitstellung eines sog. “Conformance Documents”, in dem das gesamte unterstützte DICOM feature set aufgeführt ist (Beispiele: VISUS, GE Healthcare)

Das Information Model & die IODs

Zentral für den Standard ist das sog. “DICOM Real World Information Model” (dazu kommt gleich ein Beispiel). Diese spezifiziert (sinngemäße Übersetzung durch mich) …

… abstrakte Informationsobjekte (Information Object Definitions, IODs) auf Basis derjenigen real existierenden “Dinge”, die an der Kommunikation und Verarbeitung von digitalen medizinischen Daten beteiligt sind.

Oder viel unschärfer und platter, aber einfacher zu verstehen: Alles was irgendwie was Bilddaten produziert, speichert, verarbeitet, oder daran beteiligt ist, wird als abstraktes IOD spezifiziert. Komplett zufällig ausgewählte Beispiele sind: Patient, Service Episode, Clinical Trial Subject, Color Palettes, Worklists, Radio Therapy Radiation Record, Unique Device Identifier, etc. Die Liste ist lang.

Zu jedem IOD werden ebenfalls notwendige Attribute definiert (ein “Bild” kann zB ein “Datum” haben, das wäre ein Attribut). Zusammengehörige Attribute werden zu sog. “Modulen” zusammengefasst (Part 2 - Conformance, A3.4 - Modules). DICOM nennt das “Patient Module” als Beispiel, welches Name, ID, Geburtsdatum und Geschlecht enthält. So kann man IODs ganze Module zuweisen und muss die enthaltenen Attribute nicht jedesmal einzeln aufführen.

IOD-Beispiel: Das “DICOM-Bild”

Frage vorweg: Was ist denn so ein “Bild”?
Ein Röntgenbild?
Allerdings macht man das doch fast immer aus mehreren Perspektiven?
Also mehrere Bilder?
Oder “ein” MRT “Bild”? Das kann gar nicht nur “ein Bild” erzeugen, bzw. dafür ist es gar nicht da.
Sind das dann einfach “viele Bilder”?
Und wie ist es mit einem Ultraschall-Video?
Mit dem man allerdings auch Bilder machen kann?

Hier kommt das Real World Information Model ins Spiel. Was man naiv unter “einem Bild” versteht ist in DICOM ein eher komplexes Konstrukt:

Patient -> Studie -> Serie -> Instanz

Unser naives “Röntgenbild” ist die das tiefste Element, die sog. “Instanz”. Jedes “Bild” enthält dabei grundsätzlich alle Metadaten zu den höheren Teilen, und kann anhand derer einer Serie, Studie, und einem Patienten zugeordnet werden. Die Antwort auf “wann startet man eine neue Serie?” gibt Christian Johner vom Johner-Institut:

Bei jeder neuen Modalität, bei jedem neuen Aufnahmeparameter wie T1/T2-Gewichtung bei Kernspin-Aufnahmen, bei der Gabe von Kontrastmitteln oder einer Umlagerung des Patienten beginnt eine neue Serie.

Das ist wichtig weil alle, aber auch wirklich alle, die mit DICOM-Daten arbeiten, immer von “Studien” sprechen. Lizenzkosten von Software werden anhand von abgelegten Studien errechnet. Statistiken sprechen von soundsovielen Studien pro Jahr bei einer Radiologie. Und so weiter.

DICOM in seiner natürlichen Umgebung

Wenn man ein Röntgenbild erstellt kommen folgende “typischen” Komponenten zum Einsatz:

• Ein bilgebendes Gerät (CR, MRT, Röntgen), …
• angeschlossen an ein RIS (“Radiologie-Management-System”), wobei die …
• Bilddaten in einem PACS gespeichert werden (“Picture Archiving and Communication System”)
• Meistens gibt es noch spezielle Befundungs-Arbeitsplätze, mehr dazu gleich.

Das RIS ist dabei für die Verwaltung zuständig: Stammdaten, Auftrags-Verwaltung (Worklists!), Bild-Indizierung, Befundung, etc. Das PACS ist “nichts weiter” als ein riesiger Ablageort für die erzeugten Bilddaten, natürlich über DICOM-Interfaces angeschlossen. Das bildgebende Gerät ist die Datenquelle.

Ein “Befundungs-Arbeitsplatz” ist hierbei ein speziell genormter Arbeitsplatz, der konkret definierte Anforderungen an Betriebssystem (muss definierte Farbtiefe unterstützen), Monitor (muss kalibriert sein), Grafikkarte (muss das alles leisten können), und Software (darf Bilddaten nicht verfälschen) erfüllen muss. Rechtlich ist eine Befunderstellung nur an einem solchen genormten Arbeitsplatz möglich. Natürlich ist der auch teuer. (Hinweis: Dies ist meines Wissens nach keine DICOM-Vorgabe; DICOM ist ein technischer Standard)

Und wo “wohnt” DICOM in diesem Szenario? In den Schnittstellen und Datenformaten. Sämtliche für die Bildgebung relevanten technischen Aspekte dieses Prozesses werden jetzt über DICOM geregelt:

• Sämtliche Aspekte der erzeugten Daten (Kompressions- und Encoding-Algorithmen, Datenstrukturen, Metadaten, etc.)
• Schnittstellen zwischen den Systemen (RIS, PACS, Modalität, etc.), sofern sie Bilddaten oder Arbeitslisten betreffen
• Unter Umständen die Darstellung der Bilddaten auf entsprechenden Geräten bzw. mittels Software
• In den von den Systemen verwendeten Terminologien (“Studie”, “Serie” - nur zwei von vielen von DICOM spezifizierten Begriffen)

Akzeptanz von DICOM

(Hinweis: Das Folgende ist mein entstandener Eindruck)

Für CT, MRT, Röntgen würde ich den Akzentanzgrad bei 100% einordnen. Das gesamte Softwaresystem ist auf die Verarbeitung von DICOM-Daten ausgerichtet. Nicht-DICOM-Geräte wurden vermutlich schon vor vielen Jahren aussortiert, und man könnte sie gar nicht mehr an heutige Infrastrukturen anschließen.

Anders sieht es aus für “kleinere” Geräte, zB für Lungenfunktions-Messgeräte, EKGs, etc. Diese könnten auch mit DICOM arbeiten (mindestens für die Auftragsverwaltung), tun es offenbar oft nicht. Ob und wann das überhaupt sinnvoll wäre ist eine ganz andere Diskussion.

Ultraschallgeräte (zumindest die neuen) scheinen weitestgehend DICOM-konform zu sein.

Veränderungen & Herausforderungen

DICOM ist ein stabiler und bewärter Standard. Für viele Teile gilt: Hier gibt es wenig Handlungsbedarf. Das könnten zB die Bild-Kompressionsalgorithmen sein. Die sind da, und funktionieren. Sicherlich werden nach und nach neue, effizientere hinzukommen, im Großen und Ganzen ist das allerdings kein “Schmerz”.

Veränderungen finden gerade sehr stark in den Prozessen statt, in denen DICOM zu Hause ist. Das betrifft weniger den Standard selbst, als mehr die Komponenten, die DICOM “können” müssen. Zum Beispiel gibt es Bestrebungen, “klassische” Systeme in einer Klinik (RIS und KIS (Klinik-Informationssytem)) nach und nach durch flexiblere Systeme zu ergänzen und/oder zu ersetzen. So müssen vermutlich über die Zeit immer mehr Systeme ein immer kleineres Subset von DICOM “können”. Den starken Trend zu REST-APIs und “schlanken” Schnittstellen hat DICOM selbst mit DICOMWeb aufgegriffen, hier passt sich der Standard also bereits an.

Neue Möglichkeiten in der IT werden ebenfalls zu Veränderungen führen. Hier würde ich Storage als treibenden Faktor nennen. Früher waren die Bilddaten “riesig”, und der Umgang mit ihnen aufwendig. Heute ist ein TikTok-Video größer als manche MRT Studie, man hat 25MBit über LTE, und GBit in der Klinik (hoffentlich), die interne Verkabelung ist mindestens CAT6, und ein Terabyte kostet 30 € (schneller Check bei Amazon, 2022-01-18). Das verändert natürlich viele Notwendigkeiten und ermöglicht ein anderes Arbeiten. Teleradiologie wäre daher ein offensichtliches Stichwort was hier ganz oben stehen könnte.