Folge #52 – DICOM

2 DICOM ist das Thema des heutigen Podcasts, wofür steht es? DICOM steht für Digital Imaging and Communication in Medicine. Und natürlich wirst du jetzt zumindest auch wissen, wer das herausgibt und was das für eine Organisation ist. Und du wirst vermutlich auf eine gewisse Folge unseres Podcasts verweisen. Alles kann überraschung mehr. Ich bin mit meinem Delorean hier. Zurück in die Zukunft. Es geht um die Nema. Also die Nema gibt den DICOMstandard heraus. Und die Nema, also die Abkürzung, Nema steht für National Electrical Manu-Factors Association. Und das Action, dass das ein Zusammenschluss von Herstellern, elektrischer Geräte oder Elektrik ist. Wer mehr zu diesem Thema Nema hören wollt, wir haben in der Folge 26 mal über Organisationen im Gesundheitswesen gesprochen. Und da war neben HL7 und was ich, was noch alles war, eben die Nema auch ein kurzes Thema. Haben wir etwas darüber gesprochen? 

Gut, bevor du dann gleich in die technischen Tiefen von DICOM einsteigen willst, und ich dich gegebenenfalls dann wieder hochholen muss, falls du zutiefst, darum tauscht, möchte ich eine grobe Übersicht geben, was DICOM so alles kann oder macht. Weil es häufig auch falsch verstanden wird, viele Leute verstehen meiner Meinung nach, so was wie JPEG für Digitalkameras oder für normale Fotos im Consumer-Bereich, ist dann halt DICOM ein medizinisches Bild einfach nur oder ein Speicheralgerhythmus oder ein Dateiformat. Das ist es aber nicht, sondern DICOM kann mehr. Ich nenne jetzt einfach mal vier Sachen. 

Das erste ist DICOM Datenstrukturen und zwar mit DICOM dreht sich natürlich schon alles um Bilder. Nachdem das ein Standard ist für Bildgebende Verfahren dreht sich dann natürlich viel um Bilder. Im DICOM wird definiert, wie die Daten, die Metadaten zu einem Bild auszusehen haben. Also wenn zum Beispiel ein CT-Bild gemacht wird, dann wird in dem Bild auch gespeichert. Was es für ein Patient ist, Name, Geburtsdatum, vielleicht die Patienten-ID. Es wird gespeichert, was es genau für ein CT-Gerät war, es wird gespeichert. Wie waren die Geräteparameter, wo Kontrastmittel gegeben worden, die Auflösung der Bilder etc. Also DICOM-Datenstrukturen definieren, wie Metadaten zu solchen DICOMbildern gespeichert werden. 

Das zweite, was DICOM auch definiert, sind die Netzwerk-Dienste. Falls ihr euch das OSI-Schichtenmodell vorstellt, dann sind wir hier in dem Podcast ja hauptsächlich auf der Ebene 7 unterwegs. Deswegen ja auch die 7, weil es sich dort nur auf der obersten Ebene bewegt. DICOM geht hier aber ein Stückchen weiter runter. Das heißt DICOM definiert eigenen Netzwerk-Dienste und dort wird unter anderem geregelt werende Verbindung aufbaut, wie die Verbindung ausgehandelt wird, wer klein ist, wer server ist, wie die Daten übertragen werden, wie werden die Daten komprimiert bevor sie übertragen werden und so kann man dann die Anwendung auch direkt definieren. Also wie schaut ein Druckdienste aus bei DICOM, wie schaut ein Bildarchivdienste aus bei DICOM? 

Das dritte ist etwas, mit dem die meisten von euch vermutlich leider schon Berührung hatten. Nämlich DICOM definiert auch Formate für den Daten austausch oder den Datenträger austausch. Wenn ihr mal in der Röhrelag zum Beispiel CT-MAT, da werdet ihr dann von der Licht-Patienten-CD mitbekommen haben. Die kann man auch ganz normal am PC einlesen und wird dann einen DICOM-Directory vorfinden und da drunter dann standardisierte Unterverzeichnisse. DICOM legt also fest, in welchem Format Patienten-CD gebrannt werden soll, wie die Datei-Verzeichnisse heißen und das ganze deswegen, damit es dann, wenn ihr mit der CD wieder zu ihrem Hausarzt geht, das Hausarztprogramm weiß, in welchem Verzeichnis es schauen muss. Also alle CD’s, die gebrannt werden, sind nach diesem DICOM-Format hoffentlich und dadurch ist gegeben, dass das automatisch eingelesen werden kann. Es wird also definiert in welchem Format, wie das DICOM-Directory ausschaut, Patient, Name, Modalität, etc. 

Und als Viertes definiert DICOM auch, ja, kann man sich vorstellen, wie eine To-Duliste für die Modalitäten. Modalitäten sind die Geräte, die die Bilder erzeugen. Also CD, NMRT, ein C-Bogen, klassisches Röntgen, aber auch sowas wie ein Ultraschall. Es ist ja meistens so, dass die Ärzte in der Software festlegen, was denn jetzt beim Patienten gemacht werden sollen. Also ich muss zum Beispiel zur Abklärung, ob sie irgendwelche Schatten, bei der Lunge gibt den Thorax in zwei Ebenen Röntgen, also von vorne und von der Seite. Das wird dann in der Software gemacht und das ist total praktisch, wenn das sowieso per Software beauftragt wird, wenn dann das Röntgengerät direkt weiß, dass es was Neues zu tun gibt, also beim Christian-Wache. Wie er den Thorax Röntgen-Säulen von vorne und von der Seite und dafür wird eben in DICOM-D-Modellity Worklist genutzt. Also das RIS, das radiologische Information-System wird in dem Beispiel eine To-Duliste für das Röntgengerät bereitstellen, wo drin steht, Achtung, es gibt einen neuen Auftrag für dich, Christian-Wache Röntgen-Thorax in zwei Ebenen. 

Zusammenfassend, also die vier Bereiche, die ich so nenzwärt finde, das ist nochmal die DICOM-Daten-Strukturen. DICOM-Netzwerkdienste Formate für den Datenträger Austausch, stichwort CD, und die To-Duliste für die Geräte, die sogenannte DICOM-Modellity Worklist. Wenn man DICOM-Metal 7 vergleichen möchte, wobei ich mich da ein bisschen streube, kann man sagen, dass bei vielen Bereichen DICOM eher die Pull-Technik nutzt, wie zum Beispiel gerade bei DICOM Modality Worklist genutzt, dort sendet also nicht das RIS, das ein neues Bild gemacht werden soll, sondern in der Regel fragt das Gerät, gibt es was Neues für mich zu tun, und dann sagt die Software ja, da ist was. Generell kann man auch noch sagen, das ist nicht so gut lesbar, wie zum Beispiel andere Kommunikationsstandard ist aber ein gutes Stück kompakter. Ich glaube nicht kompakter, als HL7 vor 2, da kann man ja nicht mehr viel weg optimieren, zumindest von der Nachrichtenlänge her. Es ist technisch vielleicht ein bisschen anspruchsvoller, weil es herzere Kriterien hat, weil es strengere Constrains hat, und somit ein weniger Freiheitsgrade, die Profis unter euch werden dann aber auch schon ahnen, dass wenn man weniger Freiheitsgrade hat, was vielleicht ja erst mal negativ klingt, ist bei der Implementierung gutes Stück einfacher ist, weil man eben sich nicht für Weg A oder B entscheiden kann, ist es so, dass wir bei Diacom ein halbwegs Plug-and-Play garantieren können, wenn man also Neues Gerät ins Netzwerk bringt, sollte es eigentlich so sein, dass man bei den anderen Geräten eigentlich nur IP-Adresseport und vielleicht noch 2-3 weitere Informationen einstellen muss, und dann sollte es eigentlich funktionieren. 

So, jetzt bin ich fertig mit meiner oberflächlichen Einführung von Diacom, jetzt kannst du man ein bisschen abtauchen, also Nase, Zuhalten und runter. Aber vorher tief einladen. 

Gut, also ich will am Anfang vielleicht ein paar Begriffe klären, die, wenn man sich mit Diacom beschäftigt, immer mal wieder auftauchen. Du hattest vorhin schon angedeutet, dass Diacom nach dem kleinen Serverprinzip arbeitet, und da kommunizieren zwei Partner miteinander. Also zum Beispiel RIS, auf der einen Seite, also das Radiologienformationsystem und das Freundgengerät, das bei dem Radiologienformationsystem, nach der Arbeitslist, also nach der Wirklist-Frat. Beide Kommunikationspartner heißt ein Application Entity und abgekürzt ist das AE. Und beide haben einen Namen, der für diese Kommunikation eindeutig ist und das ist der AE Title, also der AE Title kommt häufiger mal vor, wenn man eine Schnittstelle einrichten muss. Jetzt ist es bei Diacom so, dass der Kleint nicht kleinteist, sondern der Kleint ist in dieser Kommunikation der Service Class User und der Server ist der Service Class Provider. Warum sollte man es auch so online, dass es hier direkt versteht? Genau, abgekürzt ist das einmal SCU und SCP, auch diese Begriffe findet man häufiger, wenn man sich mit Diacom beschäftigt. 

Dann kommen wir zum Objektmodell, also wie sind die Daten in Diacom strukturiert? Da haben wir zum einen die IOD (Information Object Definition), das ist das, was man in der Programmierung am ersten und der Klasse verstehen würde. Das ist dann die Definition, wie ein Patient auszusehen hat, also was für Attribute muss ich speichern, damit ich einen Patient speichere, oder was für Attribute muss ich speichern, damit ich einen Aufenthalt speichern muss, was für Attribute gehören zu einer Serie, was für Attribute gehören zu einem Bild. Das ist also die IOD, die Klasse. Auf eine Klasse kann man mehrere Methoden anwenden, zum Beispiel abrufen eines Objekts oder ändern von Werten innerhalb eines Objekts, das sind die Services. Wenn man diese beiden Sachen zusammenbringt, also eine IOD und einen Service, dann entsteht eine SOP, also eine Service Object-Pair. Das hat auch nichts zu tun mit SOPs, die man vielleicht aus dem Klinikalter kennt, also es ist keine Standard Operating Procedure, damit auch also wie ein Begriff der doppeldeutig ist. Genau, also dieses SOP ist eine Kombination aus IOD und Service und definiert quasi welche Methoden man auf eine Klasse anwenden kann. Also was kann ich jetzt mit diesem Bild machen? Ich kann es zum Beispiel speichern, ich kann es abrufen, ich kann es löschen, ich kann das Bild verschieben und so weiter. Dann gibt es in Diacom Unique Identifier. Das sind weltweit eindeutige Identifier, die zum Beispiel SOP-Klases haben, aber auch eine SOP-Instance, also zum Beispiel ein bestimmtes Bild, hat einen Unique Identifier, der es dann weltweit eindeutig macht. Du hattest ja vorhin gesagt, dass sich Diacom auch dafür eignet, dass man eine Art Plakken Play machen kann. Das liegt unter anderem daran, dass im Vorfeld jeder Kommunikation die beiden Kommunikationspartner abstimmen, was sie genau untereinander austauschen wollen. Also wollen sie jetzt ein Bild austauschen oder will ich jetzt bei dir die Diacom Wirklist abfragen und so weiter. Das wird im Vorfeld jeder Kommunikation abgefragt, das reduziert den Aufwand im Vorfeld Sachen zu konfigurieren. Trotzdem kann man in diesem Handshake, also in dieser Negotiation, kann man nicht alles definieren, was man braucht. Deswegen gibt es Conformance Statements. Das sind Dokumente, in denen wichtige Informationen drin stehen, zum Beispiel, was ist der A-E-Titel von dem Gerät, was ist eine Rolle, welche SOPs werden unterstützt, also welche Klassen werden unterstützt. Welche Kodierungen haben, meine Daten haben, meine Bilder, all das wird in diesen Conformance Statements definiert. Und dann kann man sich im Vorfeld, wenn man mit einem Gerät kommunizieren will, kann man das Conformance Statements anfordern und kann schauen, wie muss ich jetzt mein Gerät darauf einstellen, damit hier eine möglichst optimale Kommunikation stattfinden kann. 

Nicht unerwähnt bleiben sollten die Diacom Web Services, also es gibt eine Art modernes Diacom, das auf Rest und HTTP basiert, aber ich will da jetzt gar nicht zugenaut darauf eingehen, das würde die Zuhörer verunsichern. 

Ja, das war es von meiner Seite, vom Technischen. Ich bin jetzt hoffentlich nicht zutief abgesunken und ich hoffe, die Technik hat uns nicht zu sehr im Stich gelassen, falls es zwischendurch mal einige Aussätze gab, dann bitten wir dies zu entschuldigen, aber wir wollen vielleicht abschließend noch eine Bewertung machen. Wie ist jetzt Diacom im Vergleich zu den anderen Standards zu bewerten, Christian, was denkst du denn? 

Was denke ich, machen wir es mal als Bild, also wenn Diacom eine Person wäre und wenn FHIR eine Person wäre und wenn HL7 v2 eine Person wäre, würde ich am liebsten mit FHIR ein Bier trinken gehen und danach mit HL7 v2 und gar nicht gerne mit Diacom. Das ist sicher gut, aber mir ist das alles acht zu altbacken und technisch, aber hochstandardisiert von da ist es gut, aber weil es hochstandardisiert ist, glaube ich, wäre das ein langweiliger Kompane in einer Kneipe. Obwohl es ja vorher dieses Gespräch gibt über was man sich unterhält, aber ich sehe es anders, ich mag Diacom, aber vielleicht auch weil ich mich da so ein bisschen tiefe eingearbeitet habe und dann lernt man solche Sachen zu schätzen, wie zum Beispiel, dass es eine Status-Einschen gibt und so weiter. Da ist der Initialaufwand höher, also zum einen die Einarbeitung ist höher als bei HL7 und auch das Einrichten und das Programmieren der Diacom-Schnittstelle ist höher als bei HL7. Dafür hat man dann, wenn man Schnittstellenprojekte hat, wesentlich weniger Aufwand in Diacom-Projekten als in HL7-Projekten, weil dort dann doch relativ viel mit Plug-and-Play geht. 

Vielleicht eine Anmerkung noch, damit es jetzt nicht so negativ bleibt. Diacom ist an und für sich schon gut, denn wir haben ja, wir plädieren ja immer für Telemedizin-Projekte. Man muss sagen im radiologischen Bereich ist das überhaupt gar kein Problem und dort wird schon viel gemacht und ein Grund dafür ist eben unter anderem sicher auch der Standard Diacom. Also es gibt zum Beispiel den Westdeutschen Teleradiologieverbund, hauptsächlich gestartet im Herurgebiet, sind da man zwischen Deutschland weit, Praxen und Krankenhäuser dabei, die haben über 320 Teilnehmer. Dort können dann eben Dank Diacom, ich glaube über Diacom-E-Mail, das haben wir hier noch gar nicht erwähnt, Bilder ausgetauscht werden und es können also Ärzte auch auf Daten zugreifen, ohne dass der Patient die CD ist mitnimmt. Also das ist etwas, was eine Super-Sache ist meiner Meinung nach und das klappt auch nur eben weil es Diacom gibt. Also von daher ist es schon gut, aber ich finde es halt nicht so richtig, persönlich nicht so richtig spannend. Ja, ist doch ein persönliches Ende genau und damit schließen wir den heutigen Podcast. 

DICOM, Digital Imaging and Communications in Medicine, Radiologie, Medizinische Bildgebung, PACS, Gesundheitswesen, Medizinische Informatik, Bilddaten, eHealth, Gesundheitsdaten, Interoperabilität, Digitale Gesundheit, Krankenhauswesen, Bildarchivierung, Medizinische Standards, Healthcare IT, Radiologische Systeme, Datenaustausch, Bildkommunikation, Klinische IT