DICOM-Schulung

Montag und Dienstag diese Woche befand ich mich in Oldenburg auf einer Schulung, was mir wieder eine gute Ausrede verschafft, warum ich länger nichts geschrieben habe. 😉 Die Vorträge waren höchst interessant, und ich fühlte mich in die Zeit meines Studiums versetzt, als ich noch die ganze Woche das Glück hatte, dersolchen zu lauschen. So waren die zwei Tage auch trotz des frühen Aufstehens um 04:30 Uhr am Montag fast wie Urlaub: Gemütlich im Vorlesungsraum sitzen, Abends ein wenig durch eine fremde Stadt schlendern und dann im Hotel abhängen. Und am nächsten Morgen ein reichhaltiges Frühstück. 😉

In der Schulung selbst ging es um den Bereich DICOM. Dabei handelt es sich um eine Art Protokollsprache zwischen Modalitäten wie CTs oder MRTs und dem Bildarchivierungssystem PACS. Wie man sich leicht vorstellen kann, benötigt es eines vernünftigen (Quasi-)Standards, damit die zahlreichen Modalitäten verschiedenster Hersteller und die verschiedenen PACS-Systeme miteinander komunizieren können. Der DICOM-Standard liefert diese Funktionalität.

Ein Beispiel: Ein Tomographiegerät soll eine ganze Serie von Bildern liefern, da ein Patient sich den Arm gebrochen hat. Zuerst werden daher die Patientendaten eingeben, was entweder per Hand an der Modalität geschehen kann (wohl kaum noch) oder auf digitalem Wege durch ein Informationssystem, vielleicht ein RIS (Radiologie-IS). Die MTA positioniert den Patienten im Tomographen und stößt die Untersuchung an. Das Gerät erkennt dann die Position und schießt eine ganze Serie von Bildern, die es danach auf bestimmte Weise im DICOM-Format kodiert. Entweder werden die unkomprimierten Pixeldaten einfach so mit den Patientendaten, Aufnahmezeitpunkt, Modalitätsname, etc.pp. im Header verknüpft oder die Bilder werden noch vorher beispielsweise in JPEGs komprimiert, was verlustfrei (z.B. Lauflängenkodierung) oder verlustbehaftet (näheres in JPEG) geschehen kann. Der Bilderstrom wird schließlich über das LAN ans PACS geschickt.

Dummerweise ist der Standard DICOM ein ziemlich weicher Standard. DICOM selbst deckt nämlich extrem viele Funktionalitäten in Form von sogenannten Diensten ab. Und nicht jedes Gerät, das sich DICOM-Konformität auf die Fahnen schreibt, muss wirklich alle Dienste beherrschen, um DICOM-konform zu sein. Ist ja auch sinnvoll: So muß eine Modalität kaum den DICOM-Druckdienst anbieten, wenn sie nicht drucken kann. Jedoch gibt es auch innerhalb der Header-Segmente innerhalb der DICOM-Klassen bestimmte Segmente, die Modalitäten nicht implementieren müssen. Einzig vorgeschrieben ist daher, daß jedes Gerät, das sich DICOM-konform nennt, ein sogenanntes “Conformance Statement” mitführt. Dies ist ein Paper von ungefähr zwanzig Seiten Länge, wo genau aufgeführt ist, was an DICOM-Diensten und Header-Segmenten unterstützt wird und was nicht. Und wenn man selbst als Firma beispielsweise ein neues PACS einführt, muß man selbst genau darauf achten, ob das PACS sich auch mit allen Modalitäten unterhalten kann. Ergo: Haufenweise Conformance Statements wühlen. 😉

2 Kommentare

  • Daniela (elamatrix) schrieb:

    Das ist mal eine Überraschung:
    Dank meiner Diplomarbeit beschäftige ich mich seit einigen Monaten mit diesem inzwischen bei mir sehr unbeliebten DICOM-Standard da ich CT-Daten (im DICOM-Format) umwandeln soll so dass wir diese mit unserem Programm verarbeiten können. Der DICOM-Standard dazu ist unschön (5000 Seiten und die einzelnen Kapitel verweisen immer wieder Referenzweise nach vorn und hinten so dass ein flüssiges Lesen auch schwer ist)

    Hast du für diese Schulung irgendwelches Kursmaterial bekommen?

    Ich geh mal weiter verzweifeln *g*

    lG
    ela (ich hoffe du kennst mich noch)

  • Klar kenn ich Dich noch. 🙂

    Ja, der Standard selbst ist zum Verzweifeln. Auch die Kurs-Leiter meinten, daß kaum jemand den Standard einmal komplett durchgelesen hat. 😉

    Material zu dem Thema habe ich, ich melde mich mal per eMail….

Schreibe einen Kommentar

Deine E-Mail-Adresse wird niemals weitergegeben.Erforderliche Felder sind mit einem * markiert.