KIS/RIS Kopplung

• Die Kopplung von Krankenhaus- und Radiologieinformationssystem ist vor allem wichtig, um die Patientendaten in der Radiologie zu empfangen, damit sie dort nicht noch einmal erfaßt werden müssen. Dies erspart nicht nur Arbeit sondern verhindert auch Fehler bei der Dateneingabe. Nur so gibt es krankenhausweit eindeutige Identifikationsnummern für die Patienten.
• Desweiteren werden die Behandlungsdaten und Bilder von der Radiologie wieder an das Krankenhausinformationssystem bzw. direkt an das Archiv zurückgeschickt. Dabei können die Bilder den Krankenakten beigelegt, digital übermittelt, oder nur als Referenz gespeichert werden. Bei Referenzen hat die Speicherung der Bilder in der Radiologie zu erfolgen. So wird auf jeden Fall eine vollständige Patientenakte erreicht, da alle Dokumente (zumindest als Referenz) gemeinsam abgelegt werden und nicht für einen Patienten verschiedene Akten existieren. Nur so ist eine redundanzfreie Datenhaltung bzw. eine Datenhaltung mit gezielter Redundanz möglich. Die Kommunikation ist in See Kopplung von KIS und RIS kurz zusammengefaßt.

• Für diese Schnittstelle wird vor allem HL-7 benutzt, da dieser Standard im Bereich der Krankenhausinformationssysteme sehr weit verbreitet ist. Die Kommunikation könnte aber genausogut mit DICOM erfolgen bzw. mit einer Umsetzung von DICOM auf HL-7. Dadurch könnte man den Datenverkehr innerhalb der Radiologie komplett mit DICOM realisieren. Voraussetzung dafür ist natürlich ein DICOM/HL7 Umsetzer, oder ein KIS, das DICOM beherrscht. Vielleicht wird ein Teil der Funktionalität von DICOM auch in zukünftigen Versionen von HL-7 enthalten sein. Ein weiterer Standard für diese Kommunikation ist EDIFACT, der in der Radiologie aber nicht häufig benutzt wird.
• Eine wichtige Aufgabe des RIS ist es, über ein geeignetes Prefetching alte Bilder von gerade aufgenommenen oder zur Befundung anstehenden Patienten schon aus einem Archiv in die Befundungsworkstations oder in einen schnelleren Zugriff zu laden. Unter Prefetching versteht man das automatische Anfordern alter Bilder eines Patienten, der gerade befundet wird. Der befundende Arzt kann dann die neuen Bilder gegebenenfalls gleich mit den alten Bildern vergleichen. Dadurch wir eine neue Qualität der Patientenversorgung erreicht, weil der Radiologe die Bilder sofort miteinander vergleichen kann und alte Bilder nicht aufwendig besorgen muß. Es gibt verschiedene Konzepte für ein intelligentes Prefetching. So möchte der Arzt bei einem gebrochenen Bein nicht unbedingt Bilder des letzten Armbruchs haben, sondern möglichst nur Bilder, die ein ähnliches Körperteil betreffen.
• Die Organisation innerhalb der Radiologie ist auch eine wichtige Aufgabe des RIS. Hierbei werden die verschiedenen Arbeitsschritte für einen Patienten wie "terminiert", "aufgenommen" und "befundet" organisiert. Hiermit können zum Beispiel die verschiedenen Geräte optimal ausgelastet werden, und die Arbeit kann optimal auf die unterschiedlichen Radiologen und die Befundungsstationen aufgeteilt werden. Es ist also vor allem ein ökonomisch sehr interessanter Aspekt. Dieser Bereich heißt in der DICOM Terminologie auch Worklist Management.

PACS

• Ein PACS (Picture Archiving and Communication System) dient vor allem der Speicherung und dem Wiederfinden von Bildern. Das digitale Archiv besteht dabei aus einer Datenbank, in der die entsprechenden Daten über Bilder wie die Patienteninformationen eingetragen werden und vor allem der Ablageort der Bilder vermerkt wird. Weitere Informationen zu PACS-Systemen sind in der Arbeit von Osteaux zu finden See [Osteaux 92] .
• Außerdem gehört zu einem PACS-System ein Massenspeicher, in dem die Bilder abgelegt werden. Dieser Massenspeicher ist evtl. in mehreren Ebenen mit unterschiedlich schnellem Zugriff organisiert. So sollte auf gerade abgelegte Bilder möglichst schnell zugegriffen werden können, während mit zunehmendem Alter der Bilder der Zugriff langsamer werden kann. Alte Bilder können teilweise auch im Offline Zugriff sein. Außerdem muß es die Möglichkeit geben, Bilder in einen schnelleren Zugriff zu holen, weil von diesem Patienten zum Beispiel neue Bilder mit den alten Bildern verglichen werden sollen. Sind die Bilder z.B. auf CD archiviert, so dauert das Finden und Kopieren der Bilder eine längere Zeit. Dieses "Finden" sollte nicht erst geschehen, wenn mit der Befundung angefangen wird.

• Wichtig ist bei einem PACS vor allem der Zugriff auf alte Bilder. Es sollten die verschiedensten Möglichkeiten bestehen, um nach alten Bildern zu suchen und diese anzufordern. Gegebenfalls müssen die Bilder ausgedruckt oder auf Film belichtet werden können.
• Zu einem kompletten PACS-System gehört natürlich auch der Anschluß an die digitalen Modalitäten wie Computer- oder Magnetresonanztomographiegeräte. Die gesamte Kommunikation ist in See Kommunikation des PACS schematisch aufgezeigt. Besonders werden hier die zwei verschiedenen Schnittstellen des Systems klar.
• Mit DICOM ist dabei sowohl eine Kommunikation mit den Modalitäten möglich als auch eine Schnittstelle zum Abfragen der Datenbank und Anfordern der Bilder. Somit ist gewährleistet, daß es keinen Unterschied macht, welche Modalitäten man mit welchem PACS- oder RIS-System zusammen einsetzt. Wenn alle konform zum DICOM Standard sind, gibt es keine Probleme.

Modalitäten und Viewing Stations

• Unter Modalitäten versteht man die verschiedenen Großgeräte wie CTs oder MRs, aber auch digitales Röntgen und die Nuklearmedizin. Es sind also allgemein die Geräte, in denen digitale Bilder erzeugt werden.
• Auf den Viewing Stations können die so aufgenommenen Bilder betrachtet und vor allem befundet werden. Die Bilder können aber auch auf einem Film ausgegeben und dann herkömmlich befundet werden.

• Viewing Stations stellen darüber hinaus noch eine Reihe von zusätzlichen Funktionen zur Verfügung wie die Änderung der Level/Window Einstellungen und das Betrachten und Vergrößern von Ausschnitten der Bilder. Manche bieten Funktionen der digitalen Bildverarbeitung bis hin zur dreidimensionalen Rekonstruktion von Tomographiedaten. Je nach Hersteller sind diese Eigenschaften sehr unterschiedlich.
• Meistens werden die Viewing Stations in Verbindung mit den Modalitäten gekauft und sind vom selben Hersteller. Daher sind die Geräte optimal aufeinander abgestimmt. Ein Nachteil kann sein, daß diese Viewing Stations nur mit den Modalitäten eines Herstellers zusammenarbeiten. Es müssen dann für die verschiedenen Geräte der unterschiedlichen Hersteller verschiedene Viewing Stations beschafft werden. Wenn die Viewing Stations über eine korrekte DICOM Schnittstelle verfügen, ist eine Kommunikation über Herstellergrenzen hinweg kein Problem.
• Dann ist nur eine Viewing Station nötig, auf der die Radiologen befunden und die Bilddaten weiterverarbeitet werden können. Auf jeden Fall besteht dann die Möglichkeit, daß auf allen Viewing Stations die Bilder aller Patienten angezeigt werden. Dadurch muß der Radiologe bei der Befundung verschiedener Aufnahmen (z.B. CT und MR) des selben Patienten nicht den Arbeitsplatz wechseln.

Teleradiologie

• Die Teleradiologie ist sicherlich einer der jüngsten Bestandteile der Radiologie. Nähere Informationen speziell zum Teleradiologiesystem CHILI sind in der Arbeit von Engelmann zu finden See [Engelmann 97] . In dieser Arbeit sind auch die Voraussetzungen für Teleradiologie und die Einteilung von Teleradiologiesystemen in Generationen enthalten.
• Die Teleradiologie beschäftigt sich nicht nur mit dem einfachen Verschicken von radiologischen Bildern, sondern bietet eine weit höhere Funktionalität. Zuerst müssen die Bilder von den digitalen Modalitäten möglichst ohne Qualitätsverlust empfangen werden können. Dazu sind digitale Schnittstellen nötig. Gängige Schnittstellen hierfür sind DICOM oder auch die älteren ACR/NEMA Standards. Werden die Bilder von Filmen abgescannt, um sie zu digitalisieren, so ist dies immer mit einem Qualitätsverlust verbunden. In der Regel haben die digitalen Bilder zwölf oder 16 Bit Grauwertauflösung, während beim Scannen normalerweise maximal acht Bit erreicht werden.
• Neben dem Empfangen der Bilder muß ein ausgereiftes Teleradiologiesystem auch über eine Datenbank verfügen, in der die empfangenen Bilder verwaltet werden. Dazu gehört eine grafische Oberfläche zur Betrachtung der Bilder, sowie einfache Bildverarbeitungsoperationen wie z.B. Level/Window-Einstellungen. Dies macht die Funktionalität einer Teleradiologiestation der einer Viewing Station sehr ähnlich.
• Wichtigstes Unterscheidungskriterium zur Viewing Station ist, daß zwei Partner mit Teleradiologiestationen kooperative Sitzungen miteinander halten können. Sie betrachten also zur selben Zeit dieselben Bilder und können dabei gemeinsam diese Bilder besprechen. Dazu ist es sehr hilfreich, wenn man jeweils den Mauszeiger der Gegenseite auch auf dem eigenen Bildschirm sieht und dem Partner im Bild bestimmte Bereiche zeigen und markieren kann. Genauer beschrieben sind die Grundsätze und Voraussetzungen für Teleradiologiesysteme in den Standards der ACR/NEMA für die Teleradiologie See [ACR 94] .

• Die gesamte Kommunikation ist in See Der Platz der Teleradiologie einmal zusammengestellt.
• Wichtig für die Teleradiologiesysteme sind die Schnittstellen zur Außenwelt. Es muß sowohl mit dem PACS, den Modalitäten als auch den Viewing Stations kommuniziert werden können. Dafür bietet sich wieder DICOM an.
• Das Teleradiologiesystem CHILI ist von den Datenstrukturen und dem Aufbau her komplett an DICOM orientiert, so daß die verschiedenen Konzepte gut zu implementieren sind.

CHILI Radiologie

• In See Die CHILI Radiologie wird die für das Teleradiologiesystem CHILI wichtigste Kommunikation dargestellt, die wenn möglich mit den DICOM Routinen erreicht werden soll.

• Dabei werden die Bilder direkt von den digitalen Modalitäten ohne Qualitätsverlust empfangen. Es besteht die Möglichkeit, sie dann auf der Teleradiologiestation CHILI weiterzubearbeiten. Es können kooperative Sitzungen mit anderen Teleradiologiepartnern abgehalten werden. Natürlich ist es möglich, die Bilder nicht nur auf der Workstation zu befunden, sondern auch auf Film oder Papier mit DICOM auszudrucken. An ein vorhandenes Archiv können die Bilder zum Archivieren geschickt, und natürlich kann dieses Archiv auch wieder abgefragt werden. Dadurch kann man alte Bilder wieder auf die Befundungsstation transferieren.
• Mit einer vorhandenen Viewing Station können Bilder ausgetauscht werden. Außerdem besteht die Möglichkeit, Anfragen an die andere Datenbank zu stellen, wenn die Viewing Station dies zuläßt.

Optimale Radiologie

• Gegenüber dem vorigen Kapitel wird in See Modell einer optimalen Radiologie noch auf einige weitere Kommunikationsmöglichkeiten eingegangen. Es wird sich noch zeigen, ob hierbei wirklich alles mit DICOM zu realisieren ist, oder ob hier vielleicht wieder auf proprietäre Protokolle zurückgegriffen werden muß.

• Neben den oben bereits beschriebenen Funktionen, die alle mit DICOM zu verwirklichen sind, ist hier noch einiges hinzugekommen. Sehr wichtig ist vor allem die Kopplung von KIS und RIS, über die die Patientendaten vom KIS an das RIS und weiter zu den Modalitäten gelangen. Dies ist sehr wichtig, um Fehler zu vermeiden und Identifikationsnummern eindeutig zu vergeben. Außerdem werden so die Befunde direkt digital an das KIS verschickt. Über das Empfangen von Patientendaten ist vom RIS auch ein einfaches Prefetching möglich.
• Innerhalb der Radiologie ist vor allem das Worklist Management sehr wichtig. Dabei wird jeweils der Status des Patienten im Behandlungsablauf kontrolliert und verwaltet (z.B. "aufgenommen", "befundet"). Hierdurch ist eine Optimierung der Auslastung der Geräte und insgesamt der Arbeitsabläufe möglich, was ökonomisch sehr interessant ist.
• Eine wirklich sichere Kommunikation ist über DICOM leider noch nicht möglich, da hierbei die verschiedensten Sicherheitsaspekte betrachtet werden müssen. Genaueres ist im Sicherheitskonzept von Baur zu lesen See [Baur 96] . Bisher muß dafür noch auf proprietäre Protokolle zurückgegriffen werden. Allerdings gibt es für DICOM eine Arbeitsgruppe, die sich mit Datenschutz und Datensicherheit beschäftigt. Bisher sind die Gesetze in den einzelnen Ländern noch zu unterschiedlich, als daß eine allgemein gültige Lösung gefunden werden kann.

Beispiel Siemens

• Die MRs ( Magnetom) und CTs (Somatom) von Siemens benutzen beide unterschiedliche Formate, die aber in den Grundcharakteristika übereinstimmen.
• So haben beide Formate eine feste Länge von z.B. 133120 Bytes für ein Bild mit 256x256 Pixeln. Im ersten Teil sind die Informationen wie Matrixgröße oder Level/Window Einstellungen jeweils an einer festen Stelle gespeichert. Auch die Pixelinformationen haben einen festen Offset vom Beginn des Bildes. Für die Patienteninformationen existieren keine eigenen Felder, sie sind aber über das Overlay des Bildes zu erhalten.
• Für die Codierung von Zahlen wird Little Endian benutzt.
• Neben diesem internen Format bieten die Siemens-Geräte eine Exportfunktion in das SPI-Format (Standard Product Interconnect), das von ACR/NEMA 1.0 abgeleitet ist. Leider benutzt Siemens anstelle der existierenden Felder des Standards oft eigene private Felder für die verschiedenen Inhalte. Das erschwert eine Weiterverarbeitung der Bilder ungemein.
• Die neuen Geräte von Siemens unterstützen alle DICOM, zumindest die Store-Funktion. Ein solches Gerät wurde im Rahmen der Arbeit mit DICOM angeschlossen.

Beispiel GE

• GE benutzt als internes Bildformat für die CT und MR Geräte Genesis. Dieses Format enthält einen Header fester Länge, in dem jeweils Zeiger auf die wichtigsten Datenblöcke innerhalb der Datei sind. Wichtige Datenblöcke sind z.B. die Pixeldaten und die Patienten- oder Studiendaten. Diese einzelnen Datenblöcke haben auch wieder jeweils eine feste Länge, in der die Informationen direkt hintereinander abgelegt sind. Jedes Datenfeld hat eine feste Länge. Die Bilder können komprimiert oder unkomprimiert abgelegt werden.
• Für die verschiedenen Geräte werden bei GE verschiedene Rechnerarchitekturen benutzt. So laufen die MR Signa 3.x und 4.x auf 68000ern, die neueren auf MR Signa 5.x auf Suns und die Advantage Windows Viewing Station auf Sun Sparcstations. Dadurch haben die internen Darstellungen von Zeigern oder Real-Werten, die in den Headern benutzt werden, eine unterschiedliche Länge. Entsprechend unterscheidet sich je nach Plattform die Länge der Header, die eigentlich einheitlich sein sollte.
• Solche Bilder können also nur mit Kenntnis der Systemarchitektur problemlos gelesen werden.
• Die neueren GE Geräte unterstützen alle DICOM. Zwei CT Prospeed und ein MR Signa wurden im Rahmen dieser Arbeit per DICOM angeschlossen.

Weitere Hersteller

• Die Geräte von Philips bieten genauso wie die Geräte von Siemens eine Exportfunktion in das SPI-Format. Es wird auch Little Endian benutzt. Im Gegensatz zu Siemens hält sich Philips an die Standardfelder und benutzt nicht so viele private Datenelemente. Dadurch sind diese Bilder wesentlich besser zu verarbeiten.
• Eine Besonderheit bei Philips ist, daß die 12-Bit Bilddaten nicht als zwei Byte gespeichert werden, sondern als 12 Bit hintereinander weg. Dadurch haben die Bilddaten einen geringeren Speicherbedarf.

ACR/NEMA 1.0

• Aus den Forderungen nach einem einheitlichen Standard für die medizinische Bildverarbeitung wurde 1983 mit einem gemeinsamen Komitee der ACR und der NEMA der Grundstein für diesen Standard gelegt. Es wurden verschiedene Eigenschaften existierender Standards betrachtet, die aber alle nur teilweise den Bedürfnissen entsprachen. So wurden einige der Grundsätze aus diesen existierenden Standards gewonnen. Die Feldinhalte sollten eine variable Länge haben, und jedes Datenfeld sollte durch eine eindeutige Bezeichnung ( Tag) gekennzeichnet sein. Dies ist quasi der Name des Feldes. Außerdem wurde die Erstellung eines Data Dictionary mit sämtlichen Datenfeldern beschlossen.
• So wurde 1985 die erste Version des Standards mit dem Namen ACR-NEMA 300-1985 auf der RSNA vorgestellt und die Unterlagen wurden publiziert.
• Als Kommunikationsschnittstelle war nur eine Punkt-zu-Punkt Kommunikation vorgesehen, allerdings keine Netzwerkverbindung.
• Bei den ersten Versuchen mit diesem Standard und dem Einsatz in der Praxis wurden allerdings einige kleine Fehler und Probleme des Standards klar. Es gab eine Arbeitsgruppe, die all diese Fehler aufnahm und den Standard entsprechend umgestaltete. Daraus entstand schließlich die nächste Version des Standards.
• Ein von ACR/NEMA abgeleitetes Bildverarbeitungsprotokoll ist SPI, das von Siemens und Philips benutzt wird. Allerdings werden zum Teil nicht die Standardfelder benutzt, sondern eigene definiert, so daß eine standardisierte Bildverarbeitung nur schwer möglich ist.

ACR/NEMA 2.0

• Die Version 2.0 des ACR-NEMA Standards behob einen Großteil der Fehler der ersten Version, so daß es ein häufig benutzter Standard wurde. Die Grundkonzepte sind denen der ersten Version sehr ähnlich. An einigen Stellen wurde der Standard erweitert, er war also wesentlich umfangreicher als die Vorgängerversion.
• Allerdings wurden dieselben Hardwarespezifikationen benutzt wie bei der ersten Version des Standards, also nur Punkt-zu-Punkt Verbindungen. Eine Netzwerkkommunikation war nur über eine NIU (Network Interface Unit) möglich. Eine solche Einheit setzt die Kommandos einer Punkt-zu-Punkt-Verbindung auf das Netzwerkprotokoll um.
• Allerdings war schon 1988, als der Standard publiziert wurde, eine sehr hohe Nachfrage nach einer solchen Netzwerkkommunikation vorhanden. Die Computer hatten zu dieser Zeit eine Leistungsfähigkeit erreicht, die das Kommunizieren über Netzwerke überhaupt erst möglich machte.
• Es wurde zu dieser Zeit überlegt, ob man die Netzwerkprotokolle über kleinere Veränderungen in den Standard einarbeiten könnte. Dann aber wurde beschlossen, einen völlig neuen Standard zu implementieren.

DICOM 3.0

• Für DICOM 3.0 (Digital Image COmmunications in Medicine) wurde ein völlig neues Entwurfskonzept erstellt. Der gesamte Standard sollte objektorientiert entworfen werden, um ihn leichter änderbar und erweiterbar als die Vorgängerversionen zu machen.
• Die Dokumentation wurde nicht mehr als ein Dokument herausgegeben, sondern in mehreren Teilen veröffentlicht, so daß bei Veränderungen nicht mehr alles neu gemacht werden muß, sondern gezielt einzelne Teile der Dokumentation umgeschrieben werden können. Der Aufbau der Dokumentation wird im Kapitel 4 noch näher beschrieben.
• 1990 wurde mit der Arbeit am Standard begonnen, und 1992 wurden auf der RSNA die ersten Teile veröffentlicht. Die Teile 1 (Einführung) und 8 (Netzwerkkommunikation) wurden als fertige Teile herausgegeben, während die Abschnitte zwei bis sieben erst als Draftversionen vorgestellt wurden. 1992 wurde auf der RSNA bereits eine Demonstration der DICOM Netzwerkkommunikation mit den alten ACR-NEMA 2.0 Datenelementen gemacht. 1993 schließlich war der Standard komplett publiziert und es wurde eine DICOM Demonstration verschiedener Hersteller gemacht. Die zentralen Routinen für diesen DICOM Test lieferte das " Mallinckrodt Institute of Radiology" in S t. Louis. Eine aktuelle Version dieser Quelltexte ist unter [ftp://ftp.erl.wustl.edu/pub/dicom] erhältlich.
• DICOM hat auch die Kennzeichnung der Datenfelder mit eindeutigen Tags wie die Vorgänger. Dadurch wurde eine gewisse Abwärtskompatibilität erhalten, da einige dieser Tags identisch zu den Vorgängerversionen sind. In DICOM nennt man nicht mehr benutzte Tags der alten Versionen " Retired".
• Die Datenfelder wurden in Gruppen zusammengefaßt. So existieren Gruppen für die Patienten- und für Studien- oder Serien-Information. Die Kennzeichnung erfolgt dabei über zwei 16-Bit Zahlen, eine für die Gruppe und eine für das Element innerhalb der Gruppe. In DICOM gibt es genaue Beschreibungen dieser Gruppen über Entity-Relationship Diagramme. Es ist also für die einzelnen Objekte genau klar, welche Elemente wozu gehören. Siehe hierzu auch Anhang A und See Entity-Relationship Diagramm für die composite Informationsobjekte .
• Bei der Netzwerkkommunikation gibt es Modelle für TCP/IP und für das ISO/OSI-Schichtenmodell. Außerdem gibt es noch die Punkt-zu-Punkt Verbindung, die allerdings in der europäischen Version des Standards (MEDICOM) nicht mehr vorhanden ist. In Europa spielt dieses Protokoll keine Rolle. Das DICOM Schema läßt sich problemlos auf andere Netzwerkmodelle erweitern.
• Die Stärke von DICOM liegt in der Kommunikation. Es können nicht nur Bilder oder andere Objekte verschickt werden, sondern es sind auch Aktionen auf diesen Elementen definiert. So können Bilder zum Archivieren versand werden, sie können zum Ausdrucken verschickt werden, oder es können an ein Archiv einfache Abfragen mittels DICOM gestellt werden. Es werden also Methoden auf den Objekten definiert, wie es einem objektorientierten Entwurf entspricht.
• Interessant ist das Aushandeln der Kommunikation. Zwei Partner, die miteinander kommunizieren möchten, prüfen erst einmal, ob eine Kommunikation einen Sinn macht, ob sie also die gleiche Sprache (Protokoll) sprechen. Dann muß geprüft werden, ob der Partner überhaupt die Aktion ausführen kann, die die Gegenstelle gerade benötigt. Sind diese Dinge abgeglichen, kann eine Kommunikation stattfinden. Nur dann ist eine sinnvolle Verbindung möglich.
• Außerdem gibt es die sogenannten Conformance Statements. Hierin beschreibt jeder Hersteller von DICOM Software oder DICOM Geräten genau, welche Teile des Standards er beherrscht. Dadurch kann schon anhand des Conformance Statements erkannt werden, ob zwei Geräte oder Programme per DICOM zusammenarbeiten können oder nicht. Das kann viel Zeit und auch Geld sparen.
• Wichtig ist auch die eindeutige Identifikation von Objekten in DICOM. Jedes Objekt erhält eine weltweit eindeutige Bezeichnung, und es kann immer auf den Ersteller geschlossen werden.
• Alles weitere zu DICOM wird im See Beschreibung des DICOM Standards erläutert.

Objektorientiertheit

• DICOM ist ein objektorientiert aufgebauter Standard. Allerdings entsprechen nicht alle Konzepte dem, was in der Programmierung im allgemeinen als objektorientiert verstanden wird. Diese Objektorientierung hat den großen Vorteil, daß Änderungen im Standard relativ problemlos durchzuführen sind.
• Konzepte der Objektorientiertheit sind zum Beispiel die verschiedenen Klassen für die einzelnen Objekte, denen bestimmte Eigenschaften zugeordnet sind. Wird ein Objekt einer Klasse mit Werten belegt, so nennt man es eine Instanz, es ist also eine Ausprägung einer Objektklasse. Diesen Objektklassen und damit auch den Instanzen sind Methoden bzw. Aktionen zugeordnet. So kann der Objektklasse der CT Bilder die Methode Speichern oder Drucken zugeordnet sein.
• Nicht ganz konform mit der objektorientierten Terminologie sind die Methoden nicht direkt den Objektklassen zugeordnet, sondern es entstehen neue Klassen, die sogenannten Service Object Pairs. Ein Beispiel für eine solche Klasse ist das Verschicken von CT Bildern. Eine Instanz dieser Klasse ist das Verschicken eines ganz bestimmten CT Bildes.
• Weitere Informationen zur Objektorientiertheit sind in den Büchern von Booch und Coad zu finden See [Booch 91] , See [Coad 72] .

Attribute und Attributwerte

Attribute sind die kleinsten Einheiten der Objekte. Tabelle 4-1 zeigt einige Beispiele für Attribute.

• Alle elementaren Bestandteile der Objekte sind also Attribute. Für diese gibt es ein eigenes Data Dictionary, in dem sämtliche unter DICOM erlaubten Attribute verzeichnet sind See [DICOM Part6 93] . Sind die Attribute belegt, ist dies der Attributwert. So ist für das Attribut Name ein möglicher Attributwert "Müller".
• Aus diesen elementaren Attributen mit gewissen Zusatzinformationen setzen sich DICOM Dateien zusammen. Die Attribute sind sortiert und einfach hintereinander in einem Datenstrom angeordnet (siehe See DICOM Datenstrom ).

• Dieser DICOM Datenfluß ist in allen Objekten gleich. Die zugehörigen Informationen zu den Attributen, die mit gespeichert werden, werden in den Abschnitten See Tags und See Value Representation erläutert.

Tags

• Jedes der Attribute hat eine Bezeichnung, um das Attribut eindeutig identifizieren zu können. Diese eindeutige Bezeichnung nennt man Tag. Sie besteht aus zwei 16-Bit-Zahlen.
• Die erste dieser Zahlen steht für eine bestimmte Gruppe, die zweite für das Element innerhalb dieser Gruppe. Die DICOM Attribute sind also in Gruppen aufgeteilt, die zusammengehörige Informationen kennzeichnen. Solche zusammengehörigen Gruppen sind zum Beispiel die Informationen zu einem Patienten oder die Informationen zu einer Studie oder einer Serie. Diese Gruppen sind wie die Attribute und die Tags im Data Dictionary festgehalten. Beispiele für solche Tags sind in See Beispiele für die Tags zusammengefaßt.

Beispiele für die Tags

Attribut	Gruppen-Tag	Element-Tag
Name	0010	0010
Geburtsdatum	0010	0030
Geschlecht	0010	0040
Serviceklasse	0008	0016
Modalität	0008	0060
Pixeldaten	7FE0	0010

• Anhand der Nummern kann man erkennen, daß der Standard gut für Erweiterungen vorbereitet ist. Es ist problemlos möglich, weitere Informationen mit sinnvollen Nummern sowohl für Gruppen als auch für Elemente in den Standard einzufügen.
• Es ist in DICOM auch möglich, sich eigene private Attribute und die dazugehörigen Tags zu definieren, um in DICOM nicht vorgesehene Informationen abzuspeichern. Dafür sind die ungeraden Gruppennummern vorgesehen, während die Standardelemente immer gerade Gruppennummern haben. Möchte man private Tags benutzen, muß man die Gruppe am Beginn des DICOM Objektes dafür reservieren. So können DICOM-konforme Applikationen erkennen, welche Objekte privat definiert sind. Private Attribute können zur Aufnahme in den Standard vorgeschlagen werden.

Value Representation

• In DICOM kann explizit angegeben werden, in welchem Format bestimmte Daten gespeichert sind, also ob es sich zum Beispiel um einen String, eine Integer Zahl oder eine Real Zahl handelt. Das ist wichtig, um beim Lesen eines DICOM Objektes die Werte auch richtig interpretieren zu können.
• Zusätzlich ist zu jedem Attribut eine Value Representation im Data Dictionary abgelegt. Das entspricht der Default Value Representation. Sie muß bei Objekten nicht unbedingt angegeben werden, wenn sie nicht von der Vorgabe abweicht. Beispiele dazu sind in See Beispiele für die Value Representation zu finden.

Beispiele für die Value Representation

Attribut	Value Representation	Gruppe	Element
Name	PN	0010	0010
Geburtsdatum	DA	0010	0030
Geschlecht	CS	0010	0040
Serviceklasse	UI	0008	0016
Modalität	CS	0008	0060
Pixeldaten	OW	7FE0	0010

• Zu den kryptischen Abkürzungen für die Value Representation gibt es auch eine ausgeschriebene Version, so steht PN für "Patient Name". Hinter "Patient Name" verbirgt sich als Typ beispielsweise ein String.
• Für alle diese Typen gibt es in der DICOM Dokumentation See [DICOM Part5 93] eine exakte Beschreibung, in der die maximale Länge und die erlaubten Zeichen beschrieben sind. In See Beschreibung einer Value Representation sind diese Angaben beispielhaft für den Typ DA (Datum) aufgeführt.

Beschreibung einer Value Representation

VR Name	Definition	Character Repertoire	Länge
DA Date	Ein String aus Buchstaben im Format "yyyymmdd", y für Jahr m für Monat d für den Tag. (Eventuell ist auch das Format "yyyy.mm.dd" zugelassen, um eine Abwärtskompatibilität zu gewährleisten)	Character "0"-"9" (evtl auch ".")	8 Byte fest (evtl. auch 10 Byte)

• Leider wird gerade beim Datum oft von dieser eigentlich sehr exakten Beschreibung abgewichen. Manchmal werden Punkte in das Datum geschrieben, manchmal ist ganz einfach die Reihenfolge von Tag, Monat und Jahr umgedreht.

Informationsobjekte

• In DICOM Informationsobjekten sind verschiedene Attribute der unterschiedlichen Gruppen zu Objektklassen zusammengefaßt. Ein Beispiel für eine solche Objektklasse ist die Klasse der CT Bilder, der bestimmte Attribute angehören.
• Man unterscheidet generell zwei Arten von Informationsobjekten, die normalized Informationsobjekte und die composite Informationsobjekte.
• Die normalized Informationsobjekte beinhalten nur Attribute aus einer Gruppe. So ist die reine Patienteninformation normalized, da nur Attribute aus der Gruppe der Patientendaten enthalten sind. Weitere Beispiele sind die Studieninformation oder die Serieninformation.
• Composite Objekte beinhalten Attribute aus verschiedenen Gruppen. Ein Beispiel dafür ist die Klasse der CT Bilder. Hier sind nicht nur Informationen über den Patienten, sondern auch Informationen aus den Gruppen Serie und Studie enthalten.
• Für diese zusammengesetzten Objekte gibt es in der Regel Entity-Relationship Diagramme, die den hierarchischen Aufbau eines solchen Objektes zeigen. Ein Beispiel dafür zeigt See Entity-Relationship Diagramm für die composite Informationsobjekte .

• Die Rauten geben in diesen Diagrammen die Beziehung der über sie verbundenen Rechtecke an. Die Zahlen an den Pfeilen geben die Mengenbeziehung an. So hat ein Patient zwischen einer und n verschiedene Studien. Während eine Serie null bis n Bilder enthalten kann. Weiteres über Entity-Relationship Diagramme ist in dem Buch von Chen zu lesen See [Chen 77] .
• Innerhalb der Informationsobjekte gibt es verschiedene Arten von Attributen.
• Notwendige Objekte sind Objekte, die auf jeden Fall belegt sein müssen. Beim CT Bild ist dies zum Beispiel der Patientenname.
• Bei notwendig aber leer erlaubt kann es sein, daß das Feld leer übergeben wird. Dieses Attribut muß aber in dem Informationsobjekt angelegt sein.
• Unter bestimmten Voraussetzungen notwendig wäre zum Beispiel der Name des Kontrastmittels, allerdings nur dann, wenn auch wirklich Kontrastmittel gegeben wurde.
• Alle weiteren Attribute sind nicht notwendig, es kann also jeder Hersteller für sich entscheiden, ob die Attribute belegt werden oder nicht. Auf solche Elemente kann man sich bei der Programmierung nicht verlassen.
• See Verschiedene Arten von Attributen faßt diese unterschiedlichen Attributarten mit der DICOM Abkürzung nochmal zusammen.

Verschiedene Arten von Attributen

Abkürzung	Beschreibung
1	Notwendig
1C	Unter bestimmten Voraussetzungen notwendig
2	Notwendig, aber leer ist erlaubt
2C	Unter bestimmten Voraussetzungen notwendig, aber leer ist erlaubt
3	nicht notwendig

• Die notwendigen Informationen sind für jede Informationsobjektklasse unterschiedlich. So werden bei einem MR-Bild andere Informationen gespeichert als bei einem CT Bild. Genauere Informationen über den Aufbau der Objekte sind in der DICOM Dokumentation zu finden See [DICOM Part3 93] .
• So wird beim CT der "Rescale Intercept" (0028, 1052)in Hounsfield Einheiten unbedingt benötigt, während beim MR die "Scanning Sequence" (0018, 0020) unbedingt benötigt wird.

Serviceklassen

• Die Serviceklassen bezeichnen die Dienste in DICOM. Es sind also die Aktionen, die auf bestimmten Informationsobjekten definiert sind, wie es beispielhaft in See Beispiele für Serviceklassen gezeigt ist.

Beispiele für Serviceklassen

Serviceklassen
Store
Query/Retrieve
Verify
Print Management
Worklist Management

• Jeder dieser Dienste kann auf bestimmte Objekte angewandt werden. Für die Ausführung der Dienste sind unterschiedliche Voraussetzungen nötig. Entgegen den eigentlichen Prinzipien der Objektorientierung sind die Dienste allerdings nicht direkt in den Objekten, sondern bilden mit den Objekten wieder neue Klassen.
• Store dient dabei zum Verschicken von Bildern zur Speicherung. Mit Query/Retrieve können einfache Datenbankanfragen gestellt werden und bestimmte Bilder von Patienten oder Serien angefordert werden. Verify dient zum Überprüfen von einfachen DICOM Funktionalitäten. Das Print Management behandelt das Drucken von Bildern auf Drukkern oder Laser Imagern. Das Worklist Management beschäftigt sich mit der Verwaltung der einzelnen Arbeitsschritte, die für einen Patienten notwendig sind.
• In See Entity-Relationship Diagramm für die SOP Klassen können gut die Beziehungen zwischen den Serviceklassen und den in Kapitel See Service Object Pairs beschriebenen SOP Klassen gesehen werden, sowie der Aufbau aus Servicegruppen, den Informationsobjekten und den einzelnen Attributen.

• In dieser Abbildung ist ebenfalls die Unterscheidung von Serviceklasse und Servicegruppe gut zu erkennen. Die Serviceklasse bezeichnet einen bestimmten Dienst, der auf verschiedene Objekte angewandt werden kann, während die Servicegruppe letztendlich dieser spezielle Dienst angewandt auf ein Objekt ist.

Service Object Pairs

• Die Verbindung von einem Dienst, also einer Serviceklasse, und einem Objekt, z.B. der Klasse der CT Bilder, ergibt ein sogenanntes Service Object Pair. Dabei handelt es sich wieder um eine Klasse (SOP Klasse). Die konkrete Ausführung eines solchen Dienstes mit einem speziellen Bild ist dann die Instanz der Klasse. Ein Beispiel ist das Verschicken eines bestimmten CT Bildes (siehe See Verbindung von Dienst und Objekt zu einer SOP Klasse ).

• Das Verschicken unterschiedlicher Bildarten wie das Verschicken von CT Bildern und das Verschicken von MR Bildern gehören dabei zu unterschiedlichen SOP Klassen.
• Diese SOP Klassen bilden den Kern der DICOM Kommunikation. Auch bei ihnen gibt es private Klassen, die nur von einzelnen Herstellern unterstützt werden.

Client/Server

• Sämtliche Dienste in DICOM bauen auf einem klaren Client/Server-Konzept auf. Für jede der Serviceklassen muß zum Funktionieren einer Kommunikation ein Client und ein Server vorhanden sein. Im DICOM Standard nennt man sie anders, hier heißt der Server Serviceclass Provider ( SCP) und der Client Serviceclass User (SCU).
• Vor Beginn einer Kommunikation fragt der Serviceclass User an der Gegenadresse an, ob sie als User für die gewünschten Dienste fungieren kann. Erst wenn das geklärt ist, wird mit der eigentlichen Kommunikation begonnen.
• In See Kommunikation von SCU und SCP beim Store Befehl und See Kommunikation von SCU und SCP beim Move Befehl sind zwei einfache Beispiele für eine solche Aufteilung von User und Provider gegeben. Man sieht, daß ein Programm als Provider für bestimmte Befehle und als User für andere Befehle auftreten kann.

• In See Kommunikation von SCU und SCP beim Store Befehl stellt der User zuerst eine Anfrage, ob der Provider das Bild abspeichern kann. Der Provider testet, ob noch genügend Kapazität vorhanden ist und versucht das Bild abzuspeichern. Hat das geklappt, dann wird ein OK an den User zurückgeschickt, ansonsten wird gemeldet, daß das Bild nicht gespeichert werden kann.

• Beim Move Befehl wird zuerst die Anforderung eines bestimmten Bildes an den Move Provider geschickt. Dieser dient gleichzeitig als Store User und versucht, das angeforderte Bild an den Store Provider zu schicken. Kommt vom Store Provider ein OK, dann wird auch an den Move User ein OK zurückgeschickt (siehe See Kommunikation von SCU und SCP beim Move Befehl ).

Unique Identifier

• In DICOM sind sämtliche Objektinstanzen und Objektklassen mit eindeutigen Identifiern ausgestattet. Diese nennt man Unique Identifier oder auch UIDs. UIDs gibt es zum Beispiel für Studien-, Serien- und Bilddaten, aber auch für CT Bilder, MR Bilder, für die Dienste auf Objekten und für Übertragungssyntaxe.
• Das hat verschiedene Gründe. Man kann so zum Beispiel von jedem DICOM Objekt feststellen, von welchem Gerät das Objekt erstellt wurde, da jedes DICOM Objekt weltweit eine eigene eindeutige ID hat. Deswegen muß man als Softwarehersteller eine eigene UID beantragen, wenn man selber Bilder (z.B. Secondary Capture) erzeugen möchte. In Deutschland ist die DIN für die Vergabe der UIDs zuständig, in den USA die ANSI.
• Desweiteren kann man beim Vergleich von zwei Applikationen feststellen, ob diese zusammenarbeiten können. Es kann abgeglichen werden, ob sie dieselbe Sprache sprechen, und ob sie dieselben Dienste in der richtigen Art (SCU/SCP) unterstützen.
• Beispiele für UIDs sind:

Beispiele für UIDs

Beschreibung	UID
MR Image Storage	1.2.840.5.1.4.1.1.4
CT Image Storage	1.2.840.5.1.4.1.1.2
Patientenquery	1.2.840.5.1.4.1.2.1.1
Implicit Little Endian	1.2.840.10008.1.2

• Die UID des "Steinbeis Transferzentrums Medizinische Informatik" in Heidelberg ist 1.2.276.0.23. Es ergibt sich also ein Namensbaum mit folgender Bedeutung:

1 ISO

2 Member Body

276 DE

0 DIN Certco

23 TZMI

• Die weiteren Ebenen können frei belegt werden. Es bietet sich an, dafür einen logischen Baum für die verschiedenen Anwendungszwecke zu entwerfen.

Transfersyntaxe

• Bevor eine Kommunikation stattfinden kann, müssen User und Provider von Diensten abgleichen, ob sie dieselbe Sprache sprechen. Es muß also eine gemeinsame Transfersyntax gefunden werden. Dabei wird abgeglichen, ob
• die Value Representation explizit oder implizit angegeben wird,
• mehr als ein Byte lange Integerzahlen in Little Endian oder Big Endian codiert werden,
• die Bilder gepackt sind oder nicht. Möglich ist z.B. eine JPEG Codierung.
• Das Aushandeln der Transfersyntax ist Sache des Providers, es müssen aber beide Partner diese Transfersyntax verstehen. Auch die möglichen Transfersyntaxe haben eine eigene UID, über die sie identifiziert werden können.
• Beispielsweise hat der Transfersyntax "Implicit Little Endian" die UID 1.2.840.10008.1.2. Dies ist die Standardtransfersyntax von DICOM.

Netzwerkkonzepte

• Für DICOM sind drei verschiedene Arten der Netzwerkkommunikation vorgesehen. Zum einen ist es das Punkt-zu-Punkt Protokoll der alten ACR/NEMA-Standards. Es hat nur noch in den USA eine gewisse Bedeutung und ist deswegen in der europäischen Version von DICOM (MEDICOM) nicht mehr vorhanden.
• Des weiteren kann DICOM auf dem ISO/OSI 7-Schichtenmodell aufsetzen, da dies ein fester Standard in der Netzwerkkommunikation ist. Beispielroutinen hierfür gibt es an der Penn-State University [ See ftp://ftp.xray.hmc.psu.edu/ ].
• Am weitesten verbreitet ist allerdings eine auf TCP/IP aufsetzende Kommunikation. Dies ist der Standard des Internets. Die meisten Netzwerke arbeiten momentan mit dieser Adressierung. Auch das Steinbeis-Transferzentrum arbeitet mit diesem Netzwerkstandard und benutzt deswegen Basisroutinen, die auf TCP/IP aufsetzen.
• Schematisch ist das ganze einmal in der See DICOM Netzwerkschema dargestellt.

• Aufbauend auf dem ISO/OSI Sieben-Schichtenmodell gibt es verschiedene Netzwerkstandards, die von DICOM unterstützt werden. Diese Netzwerkstandards müssen lediglich in das ISO/OSI-Modell umgesetzt werden.

TCP/IP

• TCP/IP ist das mit Sicherheit am häufigsten gebrauchte Netzwerkprotokoll, denn es ist auch das Protokoll des Internets. Das Steinbeis-Transferzentrum benutzt diese Form der Adressierung.
• Da die oberen Schichten hier nicht definiert sind, übernimmt dies das DICOM Upper Layer Protocol für TCP/IP ( DUL). Hier sind die entsprechenden Aktionen definiert.

• In See Modell für TCP/IP ist der Aufsatz auf TCP/IP gut zu erkennen. Für eine eindeutige Kennzeichnung der Kommunikationspartner sind hier der Host, die Portnummer und die Präsentationsadresse der Programme notwendig.
• Dabei entspricht die TCP-Ebene (Transfer Control Protocol) der Schicht 4 des ISO/OSI 7-Schichtenmodells. Die IP-Ebene (Internet Protokoll) entspricht den unteren drei Schichten des 7-Schichten Modells.
• Die beiden unteren Schichten DL (Dynamic Link Layer) und PH (Physical Layer) sind dabei für die unterste Netzwerkebene zuständig. In dieser Ebene wird die Art des Netzwerkes bestimmt, also zum Beispiel ob es sich um Ethernet oder ATM handelt.

ISO/OSI

• Das 7-Schichtenmodell ISO/OSI ist die Grundlage für die verschiedensten Netzwerkprotokolle. Die Schichten werden in See ISO/OSI 7-Schichten-Modell aufgeführt.

• Für DICOM Netzwerkkommunikation wird diese Form der Adressierung aber selten verwendet. Eine Beispielinstallation bieten die DICOM Quelltexte der Penn-State University.
• Weiteres über die verschiedenen Netzwerkkonzepte kann in Conrads Buch zur Datenkommunikation oder direkt im OSI-Standard nachgelesen werden See [Conrads 93] , See [ISO 87] .

Application Entity und Presentation Address

• Jedes DICOM Programm ist ein Application Entity, also eine eigenständige DICOM Anwendung. So ein Application Entity hat einen Namen, den Application Title, über den es in einem Netzwerk identifiziert werden kann. Über diesen Applikationstitel können DICOM Anwendungen also Kontakt miteinander aufnehmen
• Die Presentation Address sorgt für die eindeutige Adressierung eines DICOM Programmes bei der Kommunikation. Unter TCP/IP sind einer solchen Präsentationsadresse immer eine IP Nummer und ein TCP Port zugeteilt, über die eine Kommunikation mit einem Partner ohne Verwechselungen durchgeführt werden kann. Sie heißt Presentation Address, weil sie in der Applikationsebene des ISO/OSI-Schichtenmodells liegt.

Verbindungsaufbau

• Der Aufbau von Verbindungen läuft in DICOM immer auf die gleiche Art und Weise ab. Der User einer Serviceklasse stellt eine Anfrage an den Provider. In dieser Anfrage wird mitgeteilt, welche Art der Verbindung gewünscht wird. Es werden dabei die Transfersyntaxe übertragen, die der User unterstützt. Das heißt, es wird geschickt, wie Zahlen codiert werden, ob die Value Representation explizit angegeben wird und ob die Bilder gepackt sind. Außerdem werden die SOP Klassen übertragen, die der User unterstützt. Zu jeder SOP Klasse wird übertragen, ob sie als User oder Provider unterstützt wird.
• Der Provider schickt auf eine Verbindungsanfrage die unterstützten Präsentationskontexte zurück.
• Es werden auch die Application Entities übertragen, so daß der Provider entscheiden kann, ob mit diesem Applikationsnamen eine Kommunikation möglich ist.
• In See Verbindungsaushandlung ist der Verbindungsaufbau einmal schematisch zusammengefaßt.

• Nach dem Aufbau der Verbindung findet die eigentliche DICOM Kommunikation statt. Bei der gesamten Kommunikation wird auf jede Anfrage geantwortet, ob es erfolgreich war oder nicht. Am Ende kann die Verbindung von beiden Seiten wieder sauber abgebaut werden.

Präsentationskontext

• Für jede SOP Klasse wird beim Verbindungsaufbau eine bestimmte Transfersyntax ausgehandelt, die eindeutig sein muß. Dabei schickt der User alle für eine bestimmte SOP Klasse unterstützten Transfersyntaxe an den Provider. Der Provider wählt aus diesen Transfersyntaxen eine aus, die dann für diese SOP Klasse benutzt wird. Diese eindeutige Transfersyntax für eine bestimmte SOP Klasse nennt sich auch Präsentationskontext.
• Bei einer ausgehandelten Verbindung kann es verschiedene Präsentationskontexte für die einzelnen SOP Klassen geben.

Dateiformat

• DICOM Dateien, die archiviert werden sollen, haben ein anderes Format als DICOM Dateien die zwischen Applikationen verschickt werden. Es wird der Datei in diesem Fall ein Header vorangestellt. Der Aufbau des Headers kann See Beschreibung des DICOM Archivdateiformats entnommen werden.
• Eine genaue Beschreibung befindet sich in Teil 10 der DICOM Dokumentation See [DICOM Part10 93] .

Beschreibung des DICOM Archivdateiformats

Attributname	Tag	Art	Beschreibung
Präambel	kein Tag	1	Applikationsprofil, oder aber leer (00h)
DICOM Prefix	kein Tag	1	String "DICM"
Gruppenlänge	0002, 0000	1	Gruppenlänge
Meta Information	0002, 0001	1	Zwei Bytes, in denen jedes Bit eine bestimmte Version kennzeichnet
Media Storage SOP Class UID	0002, 0002	1	UID der entsprechenden SOP Klasse
Media Storage SOP Instance UID	0002, 0003	1	Instanz der entsprechenden SOP Klasse
Transfersyntax	0002, 0010	1	Transfersyntax
Implementation Class UID	0002, 0012	1	Eindeutige Bezeichnung des Erstellers
Implementation Version Name	0002, 0013	3	Version des Erstellers
Source Application	0002, 0016	3	Applikationstitel des Er-stellers
Private Information UID	0002, 0100	3	UID des Erstellers der privaten Information
Private Information	0002, 0102	1C	Private Information

• Dabei dient das DICOM Präfix hinter der Präambel der Unterscheidung von DICOM Files und Nicht-DICOM Files.
• Außer diesen zusätzlichen Attributen entspricht der Aufbau des DICOM Objektes noch dem vorher beschriebenen.

Verzeichnisformat

• Im Hauptverzeichnis des Speichermediums muß sich eine sogenannte DICOMDIR Datei befinden, in der die Orte und Verzeichnisse sämtlicher DICOM Objekte gespeichert sind. Dabei werden die Pfade zu den einzelnen Objekten wie Pfadnamen in DOS mit einem Backslash angegeben.
• Ein Beispiel für eine solche Datei ist im Anhang B zu finden.
• Für die Daten der DICOMDIR Datei werden die Elemente der Gruppe 0004 benutzt. Es können nicht nur für Patientenobjekte, sondern auch für Studien und Serien Einträge im DICOMDIR File gemacht werden. Es werden dazu immer bestimmte Schlüsselattribute mit abgespeichert, wie der Patientenname oder die Patienten ID.
• Der Header der DICOMDIR Datei sieht genauso wie der der archivierten DICOM Files aus, so daß auch DICOMDIR von Dateien in einem anderen Format unterschieden werden kann.

Medien

• Bisher ist das Archivieren von DICOM Files auf folgenden Medien erlaubt.
• 1.44 MB Diskette,
• 90 mm 128 MB magneto optical disk,
• 130 mm 650 MB magneto optical drive,
• 130 mm 1.2 GB magneto optical drive,
• 120 mm CR-R Medium,
• CD-ROM.
• Es gibt aber bereits Supplements, die diese Palette erweitern. Diese Liste wird sich durch die Bedürfnisse sicherlich in der nächsten Zeit noch vergrößern.

Einführung und Überblick

• Dieses Buch gibt eine kurze Einführung in den Sinn und Zweck von DICOM See [DICOM Part1 93] . Es werden die grundsätzlichen Ziele des Standards beschrieben sowie der objektorientierte Aufbau. Ein Teil der häufig benutzten Abkürzungen wird hier erläutert.
• Weiterhin wird der Aufbau der Dokumentation erklärt und die einzelnen Teile der Standarddokumentation aufgeführt.
• Außerdem werden die verschiedenen Normungsgremien aufgelistet, die am Standard mitarbeiten und den Standard als Norm benutzen.

Conformance

• In diesem Buch wird genau beschrieben, wie ein Conformance Statement in DICOM auszusehen hat See [DICOM Part2 93] .
• Es werden die einzelnen Kapitel eines Conformance Statements mit den minimalen Inhalten erläutert. Dies geschieht mit Hilfe eines Beispiels, an dem alles für ein Conformance Statement Relevante erkannt werden kann.
• Sinn des Conformance Statements ist, daß bei zwei Applikationen schon anhand des Conformance Statements erkannt werden kann, ob sie zusammenarbeiten können und den Bedürfnissen entsprechen, ohne die Geräte erst vor Ort zusammenschalten zu müssen.

Definition der Informationsobjekte

• Dies ist der umfangreichste Teil der Dokumentation See [DICOM Part3 93] . Er enthält eine Beschreibung sämtlicher Informationsobjekte, die unter DICOM definiert sind. Zu unterscheiden sind dabei die composite (zusammengesetzten) Objekte und die normalized (einfachen) Objekte (siehe Kapitel See Informationsobjekte ). Beispiele für composite Objekte sind CT Bilder oder MR Bilder. Beispiele für normalized Objekte sind die Patienten Information oder die Studien Information.
• Neben einer generellen Einführung in Entity-Relationship Diagramme werden die Abhängigkeiten innerhalb von Objekten durch zugehörige ER Diagramme beschrieben.
• Außerdem sind für alle Objekte sämtliche Attribute mit einem entsprechenden Status (benötigt, benötigt aber leer erlaubt, unter einer Voraussetzung nötig, optional) angegeben, so daß genau erkannt werden kann, welche Information bei einem Objekt auf jeden Fall enthalten sein muß. Auf freiwillige Attribute können keine wichtigen Auswertungen gemacht werden, da diese Attribute nicht immer vorhanden sind.

Serviceklassen

• Die Serviceklassen bilden die Grundlage für die gesamte Kommunikation unter DICOM See [DICOM Part4 93] . Hier wird beschrieben, wie eine solche Kommunikation abläuft.
• Dabei werden die einzelnen Serviceklassen wie z.B. die Verification Service Class oder die Storage Service Class, die zur Überprüfung einer DICOM Kommunikation bzw. zum Speichern von Bildern dienen, erläutert.
• Es werden jeweils die verschiedenen Untergruppen der Serviceklassen aufgeführt sowie die Rollenaufteilung als User oder als Provider. Die Beschreibung der Serviceklassen-Funktionalitäten in einem Conformance Statement wird hier auch gezeigt.
• Die Zusammenführung einer Serviceklasse mit einem Informationsobjekt zu einer SOP Klasse wird in diesem Kapitel erklärt. Diese Zusammenführung erfolgt jeweils am Ende einer entsprechenden Serviceklasse mit Angabe der UID der SOP Klasse.

Datenstrukturen und Verschlüsselung

• In diesem Teil werden die verschiedenen Strukturen und Konstrukte erklärt, die es in DICOM zur Darstellung von Informationen gibt See [DICOM Part5 93] . Dazu gehört die Codierung von Zahlen in Little oder Big-Endian, aber auch die Darstellung von Zahlen allgemein z.B. als 32 Bit Integer oder als 64 Bit Integer.
• Die verschiedensten Value Representations werden in diesem Kapitel erläutert. Dazu gibt es eine Reihe kryptischer Abkürzungen, die im Data Dictionary benutzt werden. Hier wird exakt beschrieben, was diese Abkürzungen bedeuten. Beispiele sind die Codierung von Datum oder Zeit sowie die Darstellung einer UID oder eines Namensstrings.
• Es wird auch aufgeführt, wie die Value Representation angegeben werden kann (explizit oder implizit) und ob die Länge der Datenfelder angegeben wird.
• Natürlich wird die Darstellung von Pixeldaten beschrieben. Es wird sowohl auf die Bittiefe eingegangen als auch auf die Codierung des Bildes als einfache Pixeldaten oder als JPEG (verlustfrei oder verlustbehaftet).
• Am Ende dieses Teils werden die verschiedenen Transfersyntaxe mit den jeweiligen UIDs zusammengefaßt. Diese sind für die Kommunikation sehr wichtig, denn nur wenn zwei Kommunikationspartner in diesem Bereich dieselbe Sprache sprechen, können sie zusammenarbeiten.
• Es wird außerdem erklärt, wie man eine eigene UID beantragen kann und wie man diese dann benutzt.

Data Dictionary

• In diesem Teil sind sämtliche in DICOM zugelassenen Attribute mit den wichtigsten Informationen zusammengefaßt, wie in See Auszug aus dem Data Dictionary zu sehen ist See [DICOM Part6 93] . Dazu gehört neben den Tags und dem Namen des Attributs auch die Value Representation und die Value Multiplicity, also die Häufigkeit, mit der ein Element vorkommt oder vorkommen darf.

Auszug aus dem Data Dictionary

Gruppen Tag	Element Tag	Attribut Name	Value Representation	Value Multiplicity
0008	0020	Study Date	DA	1
0010	0000	Group Length	UL	1
0010	0010	Patient Name	PN	1
0010	1001	Other Patient Names	PN	1-n
0020	0026	LUT number	IS	1
0020	0032	Image Position (Patient)	DS	3

• Dieser Teil wird am schnellsten und am häufigsten durch Supplements erweitert oder durch Correction Proposals verändert, da sich der Bedarf an Attributen für DICOM ständig vergrößert.

Nachrichten

• In diesem Kapitel sind sämtliche in DICOM erlaubten Nachrichtentypen exakt beschrieben See [DICOM Part7 93] . Es ist immer genau erläutert, welche Attribute in einer Nachricht vorhanden sein müssen und welche zusätzlich hinzukommen können. Zu den Nachrichten gehört natürlich das Aushandeln von Parametern für die Verbindungsaufnahme, aber auch die Nachrichten zum Anfordern von bestimmten Serviceklassen wie z.B. dem Speichern von Bildern und die Antwort auf eine solche Serviceanfrage. So kann der Service angenommen oder abgelehnt werden. Das alles erfolgt in einem fest vorgegebenen Format.
• Ebenso gehören zu den Nachrichtentypen Nachrichten zum kurzfristigen Beendigen einer Kommunikation, wenn z.B. Fehler aufgetreten sind oder zum sicheren Abbauen einer Kommunikationsverbindung.
• In diesem Teil sind alle Objekte beschrieben und es wird eine Auflistung aller möglichen Fehlerzustände gegeben. All diese Fehlerzustände können übermittelt werden.

Netzwerkkommunikation

• In diesem Teil werden die verschiedenen Netzwerkmodelle beschrieben, mit denen DICOM arbeiten kann See [DICOM Part8 93] . Das ist zum einen das ISO/OSI Modell, das sieben Schichten der Kommunikation beschreibt. Dieses Netzwerkschema kann auf die meisten Netzwerkmodelle angewandt werden.
• Außerdem wird TCP/IP beschrieben, daß wohl das am meisten benutzte Protokoll für eine DICOM Kommunikation ist. Es wird dabei gezeigt, wie die einzelnen DICOM Teile auf diesem Netzwerkprotokoll aufsetzen.
• Am Ende des Teils erfolgt eine Beschreibung, wie man die entsprechenden Netzwerkprotokolle in das Conformance Statement aufzunehmen und zu beschreiben hat.

Punkt-zu-Punkt Kommunikation

• Dieser Teil des Standards ist in die europäische Version (MEDICOM) nicht mehr mit eingearbeitet worden, da die Punkt-zu-Punkt Kommunikation in Europa keine Bedeutung mehr hat. Sie wird lediglich in den USA noch benutzt See [DICOM Part9 93] .
• Es erfolgt eine Beschreibung der physikalischen Spezifikation der Punkt-zu-Punkt Verbindung.
• Ansonsten ist alles recht ähnlich zu Teil 8 der Dokumentation, der die verschiedenen Netzwerkprotokolle beschreibt.

Speicherung auf festen Medien

• In diesem Buch wird das Format beschrieben, in dem DICOM Dateien auf Datenträgern abgelegt werden können See [DICOM Part10 93] . Es ist vor allem für die Archivierung auf optischen Platten und CD ROMs vorgesehen sowie für den Austausch von Bildern über feste Medien.
• Es wird die der Meta Header von Dateien erklärt, die in diesem Format abgelegt werden. Beim Meta Header handelt es sich um zusätzliche Informationen, die für das spätere Lesen der Daten wichtig sein können. Dazu gehört zum Beispiel eine Präambel und ein DICOM Header sowie die Transfersyntax und die UID der Applikation, die die Datei erstellt hat. Zusätzlich können private Informationen in dem Header abgespeichert werden.
• Sehr wichtig ist die Beschreibung der DICOMDIR Datei, die im Hauptverzeichnis des Datenträgers stehen muß. Hier werden alle DICOM Dateien auf dem Datenträger mit dem Verzeichnis, in dem sie stehen, aufgelistet. Dazu können für die einzelnen Dateien noch identifizierende Informationen wie die Patienten ID oder die Studien Instanzen UID mit in dieser Datei gespeichert werden, um so eine Suche nach bestimmten Attributen auf dem Datenträger zu erleichtern.
• Ein Beispiel für eine DICOMDIR Datei ist in Anhang B zu finden.

Applikationen für die Speicherung

• Ein solches Applikationsprofil bezieht sich auf mehrere Teile des Standards See [DICOM Part11 93] . Es soll dabei klar werden, welche Eigenschaften eine Applikation haben muß, damit eine Kommunikation über Datenträger mit einer anderen Applikationen stattfinden kann.
• Dazu gehören
• die SOP Klassen, die unterstützt werden,
• die Transfersyntaxe der einzelnen SOP Klassen,
• die Informationen, die im Basic Directory vorhanden sein müssen,
• die Rolle der Applikation als File Set Creator (FSC), File Set Reader (FSR) oder File Set Updater (FSU),
• die Medienformate, die unterstützt werden.
• Es ist im Standard die Angiographie als ein Beispiel für ein solches Applikationsprofil angegeben.

Physische Medienformate

• In diesem Buch werden die verschiedenen Medienformate für das physikalische Archivieren von DICOM Daten beschrieben See [DICOM Part12 93] . Dabei werden vor allem die Filesysteme beschrieben, die dem Datenträger zugrunde liegen. Das PC Filesystem wird detailliert aufgeführt, da dieses am weitesten verbreitet ist.
• Es wird eine genaue Beschreibung der Datei DICOMDIR auf den verschiedenen Datenträgern gegeben.
• Auf folgende physische Datenträger wird näher eingegangen:
• 1.44 MB Diskette,
• 90 mm 128 MB magneto optical disk,
• 130 mm 650 MB magneto optical drive,
• 130 mm 1.2 GB magneto optical drive,
• 120 mm CR-R Medium.
• Zusätzlich zu diesen Datenträgern gibt es noch einige Supplements, in denen weitere Medien beschrieben werden.

Print Management Punkt-zu-Punkt

• In diesem Teil wird das DICOM Protokoll zum Drucken von Bildern über eine Punkt zu Punkt Verbindung nach RS232 oder RS422 beschrieben.
• Dazu werden die gesamten SOP Klassen aufgeführt, die zum Ausdrucken zur Verfügung stehen. Neben den Serviceklassen werden die verschiedenen Möglichkeiten und Probleme mit den entsprechenden Fehlermeldungen erläutert.
• Dieser Teil war erst ein Supplement und wurde 1995 in den Standard aufgenommen.

Supplements

• Supplements sind Erweiterungen des Standards. So werden ständig Supplements für neue Bereiche der Radiologie entwickelt. Dazu gibt es verschiedene Arbeitsgruppen. Die Supplements sollten, sobald sie verabschiedet sind, direkt an die Original-Standardunterlagen angeheftet werden, um diese immer auf einem aktuellen Stand zu halten.
• Beispiele zu Supplements sind in der See Beispiele für Supplements zusammangefaßt.

Beispiele für Supplements

Supplement	DICOM Teile	Beschreibung	Status
Supplement 6	Parts 3,4,6	X-Ray Flouroscopic Image Object	Standard
Supplement 7	Parts 3,4,6	Nuclear Medicine Image Object	Standard
Supplement 8	Parts 3,4,6	Storage Commitment Service Class	Standard
Supplement 9	Parts 2,3,4,5,6	Multi-byte Character Set Support	Standard
Supplement 10	Parts 3,4,6	Basic Worklist Management - Modality	Standard

• In See Beispiele für Supplements kann man gut sehen, daß die meisten Supplements gleich mehrere Teile des Standards erweitern, also große Änderungen beinhalten. Es werden normalerweise mindestens die Teile 3 (Informationsobjekte), 4 (SOP Klassen) und 6 (Data Dictionary) geändert.
• Der Status macht eine Aussage darüber, ob die Änderung nur öffentlich bekannt gemacht ist, ob sie schon in den Standard aufgenommen ist oder ob sie bisher nur als Draft publiziert wird.

Correction Proposals

• In den Correction Proposals werden Änderungen des aktuellen Standards beschrieben. Meistens beziehen sich diese Änderungen nur auf einen kleinen Teil der DICOM Dokumentation.
• Momentan gibt es über 100 Correction Proposals für den Standard. Diese Änderungen müssen sofort in die Bücher des Standards eingearbeitet werden, damit man nicht evtl. in eine falsche Richtung entwickelt. Ansonsten muß man immer nachschauen, ob es für den momentan bearbeiteten Bereich bereits Correction Proposals gibt.
• Beispiele zu Correction Proposals sind in See Beispiele für Correction Proposals zusammengefaßt.

Beispiele für Correction Proposals

Correction Prop.	DICOM Teil	Beschreibung	Status
CP 19	Part 4	Image Deletion in Film Session	Standard
CP 20	Part 3	Clarification of Pixel Aspect Ratio	Standard
CP 21	Part 3	Same Attribute in Multiple Modules	Standard
CP 22	Part 3	Units for Frame Time and Vector	Standard
CP 23	Part 3	Numbering of Pixel Origin	Standard

• Der Status macht eine Aussage darüber, ob die Änderung nur öffentlich bekanntgemacht, ob sie schon in den Standard aufgenommen ist oder ob sie bisher nur als Draft publiziert wird.

Freie Quelltexte

• Bei freier Software handelt es sich um Programme, die kostenlos benutzt werden dürfen, und deren Basisroutinen man auch kostenlos in die eigenen Programme einbinden kann. Bei manchen Programmen ist die Nutzung nur für Universitäten und Forschungseinrichtungen kostenlos. Kommerzielle Nutzer müssen in diesem Fall zahlen. Im folgenden werden einige Quellen für DICOM Software aufgeführt.

Kommerzielle Quelltexte

• Für die Benutzung kommerzieller Quelltexte muß bezahlt werden, allerdings besteht dann auch ein wesentlich höherer Anspruch an den gebotenen Service und die Wartung.
• Zu unterscheiden sind dabei die Stand alone Programme und DICOM Toolkits. Stand alone Programme sind Routinen, die bestimmte DICOM Funktionalitäten anbieten, aber nicht verändert werden können, weil kein Quellcode mitgeliefert wird. Hierbei ist es kaum möglich, eigene Wünsche oder Anpassungen einzubringen.
• Die Toolkits liefern eine Reihe von Basisroutinen, mit denen eigene Applikationen für DICOM entwickelt werden können. In der Regel sind auch hier eine Menge an Beispielprogrammen vorhanden.
• Im folgenden werden exemplarisch zwei kommerzielle Implementierungen vorgestellt. Der Kauf eines kommerziellen Produktes kam für das Steinbeis-Transferzentrum nicht in Frage, da die Kosten den finanziellen Rahmen gesprengt hätten. Für die Basisroutinen und die Wartung müssen in der Regel hohe Beträge bezahlt werden.

Vorteile der Mallinckrodt Quelltexte

• Die Routinen des "Mallinckrodt Institute of Radiology" bieten eine Vielzahl an Vorteilen gegenüber anderen DICOM Toolkits. Zum einen sind sie frei erhältlich und zum anderen ist auch die Benutzung in kommerziellen Systemen gestattet.
• Durch die jährlichen Demonstrationen auf der RSNA stellen die Routinen immer wieder unter Beweis, daß sie mit den verschiedenen Herstellern zusammenarbeiten. Außerdem bieten diese jährlichen Demonstrationen die Gewähr, daß Änderungen im Standard auch schnell in die Routinen übernommen werden. Die Wartung der Routinen ist sehr gut. Etwa alle zwei bis drei Monate gibt es eine neue Version, in der Fehler behoben werden, oder neue Services und ein aktualisiertes Data Dictionary angeboten werden.
• Ein weiterer großer Pluspunkt sind die Dokumentation und die mitgelieferten Beispielprogramme. Es existiert eine sehr umfangreiche (etwa 1000 Seiten lange) Programmierdokumentation, in der die verschiedenen Libraries erläutert werden und genau beschrieben wird, wie man mit ihnen eigene Programme zu entwickeln hat. Durch die Beispielprogramme kann man sich die Routinen einmal an lauffähigen Programmen ansehen und so die Funktionalität besser verstehen.
• Der Quellcode ist sehr umfangreich und vor allem einheitlich dokumentiert, was die eigene Entwicklung deutlich beschleunigt.
• Das System ist zudem plattformübergreifend programmiert, so daß alle für die Entwicklung im Steinbeis Transferzentrum wichtigen Betriebssysteme unterstützt werden.

Unterstützte Plattformen

• Die Routinen unterstützen eine ganze Reihe von Betriebssystemen, die in See Unterstützte Plattformen einmal aufgelistet sind. Für das Steinbeis-Transferzentrum ist vor allem die Unterstützung von SGI Irix und Linux wichtig, da dies die Hauptentwicklungsplattformen im CHILI Projekt sind. Außerdem nimmt die Bedeutung von Windows NT immer mehr zu. Dies wird bisher noch nicht unterstützt, ist aber in Arbeit. Im Sommer 1997 ist es geplant, eine Windows NT Version fertigzustellen.

Unterstützte Plattformen

Betriebssystem	Versionen
SunOS	4.1.3, 5.5
Solaris	2.3, 2.4
DEC Alpha OSF/1	verschiedene
Irix	5.2, 5.3, 6.2
Linux	2.0
AIX	verschiedene
HP UX	verschiedene
Ultrix	verschiedene

• Generell wird die Palette an unterstützten Betriebssystemen immer größer. Anfangs mußten auch für Irix und Linux noch per Hand Änderungen gemacht werden. Mittlerweile sind diese Änderungen schon in die aktuellen Releases eingearbeitet.

Vorhandene Routinen

• Die vorhandenen Programmteile lassen sich grob in die für die Programmierung benötigten Basisroutinen und Beispielapplikationen einteilen.
• Die Basisroutinen stellen einen Satz an Libraries zur Verfügung, die die Programmierung von eigenen DICOM Routinen unterstützen. Dazu gehören die Datenstrukturen sowie die zugehörigen Funktionen.
• Die Beispielprogramme sind dabei vor allem zum Verständnis der Basisroutinen notwendig. An ihnen kann sich bei der Entwicklung eigener Routinen orientiert werden.

Gründe für Eigenentwicklungen

• Bei den ganzen vorhandenen DICOM Applikationen kann man sich leicht fragen, warum man noch etwas Eigenes entwickeln soll, wo doch ein Großteil der Funktionalität schon vorhanden ist.
• Es gibt zwar Programme für das Senden und das Empfangen der Bilder und die Basisroutinen bieten die Möglichkeit entsprechende Libraries einzubinden, um diese Funktionalität auch in eigenen Programmen zu haben. Leider bieten die mitgelieferten Programme nicht immer genau die Funktionalität, die man gerade braucht. So ist die mitgelieferte Datenbank mSQL nicht für jeden Zweck optimal, und auch nicht jeder arbeitet mit Sybase. Das Teleradiologiesystem CHILI arbeitet zum Beispiel mit der Datenbank Postgres. Für solche Anpassungen muß immer selber programmiert werden, auch wenn die fertigen Anwendungen noch so gut sind.
• Außerdem ist die Benutzung der Routinen nicht immer intuitiv. So werden sie teilweise mit einer großen Zahl an Kommandozeilenparameter aufgerufen, die gelegentlich schlecht dokumentiert sind. Für eine einfache Benutzung auch durch Nicht-Insider sollten auf jeden Fall die Parameter dokumentiert sein und grafisch konfiguriert werden können. Eine solche Funktionalität muß selber hinzugefügt werden.
• Für den Einbau der Libraries steht zwar Einiges zur Verfügung, aber die Schnittstelle ist doch recht umständlich zu programmieren. So war es das Ziel, eine möglichst einfache Schnittstelle für den Einbau der Funktionen in eigene Programme zu ermöglichen, damit sich nicht jeder erst in die gesamten Mallinckrodt Quelltexte einarbeiten muß.
• Und für besondere Schnittstellen wie für den Datenbanktreiber muß natürlich alles selber entwickelt werden. Eine so spezielle Schnittstelle hat für das Teleradiologiesystem einen großen Nutzen. Es sind keine Änderungen im Quellcode des CHILI Systems nötig, um auf DICOM Routinen zugreifen zu können. Es wird so eine sehr mächtige und umfassende Schnittstelle geschaffen.

Wartbarkeit

• Der Quellcode der Routinen ist so gegliedert und strukturiert, daß Änderungen nicht nur vom Entwickler selbst durchgeführt werden können, sondern auch andere ohne großen Einarbeitungsaufwand die Routinen verstehen und verändern können.
• Dazu gehört eine umfangreiche und vor allem einheitliche Dokumentation. Es muß nicht nur sofort der Aufbau des gesamten Programmes klar werden, sondern es müssen auch die einzelnen Funktionen klar dokumentiert sein. Dazu gehört eine umfangreiche Dokumentation direkt im Quellcode.
• Zu Beginn jeder Funktion wird ihre Aufgabe sowie die Übergabe- und die Rückgabe parameter beschrieben:

/* BearbeiteDiesesKommando */

/* */

/* Aufgabe: Verteilungsfunktion, die die Anfragen aus dem Netz liest */

/* und sie an die entsprechenden Unterroutinen verweist */

/* */

/* Parameter : */

/* association Variable, die die Verbindung beschreibt, auf */

/* der die Anfragen empfangen werden */

/* ctx Zeiger auf den Presentations-Kontext */

/* messageType Die Art der Meldung, die wir erhalten haben */

/* message Zeiger auf eine Struktur, die die Meldung */

/* enthält */

/* Rueckgabe : Variable mit dem Zustand des Systems, also fuer */

/* Fehlermeldungen */

/* */

• Dadurch ist ein Verständnis der Programme relativ schnell gewährleistet.
• Als eine Art Versionsmanagement werden sämtliche Änderungen am Beginn des Programmcodes dokumentiert. Dazu wird immer das Datum aufgeschrieben und die Initialen desjenigen, der etwas geändert hat. Dadurch ist das Arbeiten mehrerer Personen an einem Projekt nur noch ein geringeres Problem, weil jeder sofort sieht, was der andere gerade geändert hat.

/* Liste der Aenderungen */

/* */

/* HM 12.02.97 sscond aufgeloest */

/* HM 12.02.97 alles in die Headerdatei ausgelagert */

/* HM 07.02.97 Ausgabe von Parametern im Ruhemodus behoben */

/* HM 21.01.97 Bei Ruhemodus die Konfigurationsdatei nicht mehr ausgeben */

/* HM 29.11.96 Library fuer ExpandPath eingebunden */

/* HM 28.11.96 gsn-Routinen ohne Pfad eingebunden */

• Hiermit dürfte es auch nicht mehr zu Problemen kommen, wenn mehrere Personen gleichzeitig an verteilten Quelltexten arbeiten. Denn hiermit kann schnell abgeglichen werden, was noch verändert werden muß, damit wieder alle auf dem selben Stand sind.
• Außerdem hat jede einzelne Datei, egal ob Headerdatei, Library oder ausführbares Programm einen Dokumentationskopf in dem die Versionsnummer, der Ersteller und die Aufgaben erläutert werden.

/* */

/* chili_server : DICOM Server fuer CHILI */

/* */

/* Erstellt von : Henning Mueller */

/* */

/* Version : 1.0.0, 07.02.97 */

/* */

/* Dieser Server ist erstellt unter der Benutzung der DICOM Routinen */

/* des Mallinckrodt Institute of Radiology */

/* */

Erweiterbarkeit

• Unter Erweiterbarkeit wird verstanden, daß schon beim Entwickeln der Routinen darauf geachtet wird, daß das Programm auch für andere Zwecke benutzt werden kann. So müssen die gesamten Routinen möglichst allgemein geschrieben werden. Es müssen die Erweiterungen schon im Quellcode vorgesehen sein, damit andere Programmierer diese Stellen auch schnell finden. So soll es beim DICOM Server nicht nur möglich sein, die Bilder direkt in die Datenbank zu schreiben, sondern auch diese Bilder im DICOM Format oder einem anderen Format auf die Platte zu speichern. Weitere Standards sind bei Bedarf problemlos einzubauen.
• Im folgenden werden einige Beispiele aus den DICOM Routinen gegeben:
• Beim Stellen von Queries kann man sie entweder per Hand aufbauen, sie in einer Konfigurationsdatei eintragen, oder sie in einer grafischen Benutzeroberfläche eingeben. Dies alles ist über eine Konfigurationsdatei ohne Quellcodeänderung möglich. Dadurch ist eine kurzfristige Erweiterung, wie es durch den Datenbanktreiber geschehen ist, problemlos möglich.
• Es gibt verschiedene Debug Stati, die in der Konfigurationsdatei eingetragen werden. So können problemlos weitere Bildschirmausgaben unter einer bestimmten Konfiguration eingetragen werden, die in anderen Konfigurationen keine Seiteneffekte haben können. Damit ist das Programm für die verschiedensten Zwecke nutzbar.
• Auch der Datenbanktreiber ist so ausgelegt, daß man zusätzliche SQL Funktionalitäten problemlos einbauen kann. Anfangs konnten nur bestimmte Funktionen übernommen werden, aber solche Funktionalitäten wie das Optimieren von Anfragen sind schon von vorneherein im Quelltext vorgesehen.

Dokumentation

• Zur Dokumentation gehören die verschiedensten Bereiche, die hier kurz erläutert werden.
• Zum einen gibt es die Dokumentation direkt im Quellcode, die wichtige Teile der Quelltexte beschreibt und vor allem zum Verständnis einzelner Programmodule dient.
• Die standardisierte Dokumentation von Funktionen und Dateien dient vor allem dazu, daß sich jeder schnell in die Funktionsweise des gesamten Programmes bzw. der Funktionalität einer Library einarbeiten kann. Hierauf ist im Kapitel See Wartbarkeit schon eingegangen worden.
• Dies beiden Dinge werden noch in einer Programmierbeschreibung zu den Routinen zusammenfaßt, damit problemlos DICOM Funktionalitäten in verschiedene Programme eingebaut und die Routinen leicht erweitert oder verändert werden können.
• Zusätzlich gibt es eine Dokumentation der Konfigurationsparameter. Dabei wird der Name des Konfigurationsparameters, der Datentyp und die Funktion angegeben. Außerdem wird beschrieben, ob der Parameter notwendig oder optional ist. Und natürlich muß für ein solches Dokument auch immer die Versionsnummer der Routine angegeben werden, damit immer mit dem Quellcode abgeglichen werden kann, ob die Parameterliste noch aktuell ist.
• Diese Konfigurationsdokumentation ist ein Teil der Benutzerdokumentation, in der generell auf die Benutzung, also den Aufruf und die Konfiguration der Routinen eingegangen wird. Dies soll es dem Benutzer möglichst einfach machen, die Routinen zu konfigurieren, sie aufzurufen und mögliche Fehler zu beseitigen.

Benutzbarkeit

• Die Benutzbarkeit läßt sich in diesem Fall in zwei Teilbereiche untergliedern. Zum einen ist der Benutzer derjenige, der die Routinen aufruft und konfiguriert. Zum anderen ist der Benutzer aber auch derjenige, der die Routinen in seine eigenen Programme einbaut und gegebenenfalls verändert.
• Für den Programmierer ist dabei vor allem ein Programmierhandbuch und die einheitliche Dokumentation der Quelltexte wichtig. Dies ist in den obigen Kapiteln schon erläutert worden.
• Für den Benutzer, der die Routinen aufruft, ist dagegen neben dem Benutzerhandbuch auch noch eine einfache Konfiguration der Routinen wichtig. Es müssen also bei den in dieser Arbeit entwickelten Routinen keine kryptischen Kommandozeilenparameter eingegeben werden, wie dies unter Unix oft üblich ist. Die Konfiguration erfolgt über eine Konfigurationsdatei. Diese kann mit einem einfachen Texteditor verändert werden.
• Um das ganze noch einfacher zu machen ist für die verschiedenen DICOM Routinen eine einfache grafische Oberfläche erstellt worden (siehe Abbildung See Bildschirmausdruck der Konfiguration ). Näheres über Benutzerschnittstellen und Ergonomie kann in dem Buch von Preece nachgelesen werden See [Preece 96] .

• Auf der rechten Seite sind dabei die Tasks für die verschiedenen DICOM Routinen zu sehen, die konfiguriert werden können. Jedes dieser Programme hat einen eigenen Konfigurationsbildschirm, der über die Taskleiste aktiviert werden kann. Im Hauptbildschirm können die Parameter in die dafür vorgesehenen Felder eingetragen oder verändert werden. Die so veränderten Parameter werden mit dem Befehl Speichern in die entsprechende Konfigurationsdatei geschrieben.
• Dieses Konfigurierungstool der DICOM Routinen ist als PlugIn für CHILI vorgesehen.

DICOM Server

• Der DICOM Server ist mit Sicherheit das Programm mit der größten Funktionalität. Neben der Fähigkeit, Bilder zu empfangen, kann der Server auch Queries an die Datenbank beantworten und angeforderte Bilder an bestimmte Applikationen verschicken, sowie den C-Echo Befehl als Provider zur Verfügung stellen.

Aufgaben

• Der DICOM Server hat eine ganze Reihe von Aufgaben. So dient er als C-Echo Provider, er liefert also ein OK auf eine Anfrage von einem C-Echo User und überträgt dabei den Namen der Applikation.
• Die im Zusammenhang mit dem Teleradiologiesystem CHILI wichtigste Funktion ist das C-Store als Provider. Dieser Dienst regelt das Empfangen der Bilder in DICOM. Dabei werden alle in DICOM definierten Bildarten unterstützt. Erweiterungen auf andere Bildarten werden hier eingebaut. Unterstützte Bildarten sind zur Zeit:
• COMPUTED RADIOGRAPHY, digitales Röntgen,
• CT, Computertomographie,
• MR, Magnetresonanztomographie,
• NM, Nuklearmedizin,
• US, Ultraschall,
• SECONDARYCAPTURE, eingescannte Bilder,
• XRAYANGIO, Angiographie,
• XRAYFLUORO, Fluoroskopie,
• PET, Positronen Emissions Tomographie,
• STANDALONEPETCURVE, PET Kurve,
• RT, Radiotherapie,
• PRTDOSERadiotherapie Dosis,
• RTSTRUCTURESET, Radiotherapie Struktursatz,
• RTPLAN, Radiotherapieplanung.
• Queries werden als Provider unterstützt ( C-Find Provider), die interne CHILI-Datenbank kann von einer entsprechend autorisierten Gegenstelle abgefragt werden. Eine solche Gegenstelle kann zum Beispiel eine andere CHILI-Station sein.
• Genauso wird das Anfordern von Bildern unterstützt ( C-Move Provider). So können andere Applikationen Bilder von CHILI anfordern. Damit dies möglich ist, muß der Server auch Bilder verschicken können ( C-Store User).
• Abbildung See Der DICOM Server und seine Funktion zeigt den DICOM Server mit seinen verschiedenen Funktionen und die jeweils zugehörige Kommunikationsrichtung.

• Bei C-Find und C-Move werden sowohl Patient Root als auch Study Root unterstützt, damit eine möglichst große Funktionalität gegeben ist. Die Unterscheidung von Study Root und Patient Root ist in Abbildung See Patient Root und Study Root beschrieben.

Query/Retrieve als User

• Dieser Bereich bietet eine sehr hohe Funktionalität an, die Queries auf den Ebenen Patient, Studie, Serie und Bild sowie das Retrieve auf den Ebenen Patient, Studie, Serie und Bild. Zusätzlich kann auf allen Ebenen zwischen Patient Root Anfragen und Study Root Anfragen unterschieden werden.

Aufgaben

• Diese Routinen bieten die Möglichkeiten, DICOM Archive und DICOM Datenbankbanken abzufragen ( C-Find User). Außerdem können Bilder von diesen Stationen angefordert werden ( C-Move User). Zum Empfangen der Bilder ist die Zusammenarbeit mit einem C-Store Provider nötig.
• Diese oben erläuterten Funktionen sind in Abbildung See Funktionalität des Query Clients einmal zusammengestellt:

• Für diese Aufgaben werden verschiedene Modi zur Verfügung gestellt. Im Teleradiologiesystem CHILI werden Patient Root Anfragen und Study Root Anfragen unterstützt, da dies die gängigsten Anfragemechanismen sind. Sie werden von den meisten Providern zur Verfügung gestellt. Genaueres zu Patient Root und Study Root ist in Kapitel See Implementierung zu finden.
• Nicht unterstützt wird die gemischte Patient/Study Root Serviceklasse.

Implementierung

• Bei der Implementierung ist zwischen den Find Anfragen (Queries), den Move Anfragen (Retrieves) und den allgemeinen Routinen zu unterscheiden. Näheres zu den Diensten kann in Kapitel 4 nachgelesen werden.
• Allgemeine Routinen
• Zu den allgemeinen Routinen gehören sämtliche Routinen für das Einlesen und bearbeiten der Konfigurationsparameter und der Queryparameter. Treten hier grobe Fehler auf, so wird eine Fehlermeldung zurückgeliefert und das Programm beendet. Wird es als Stand alone Programm benutzt, so wird noch ein Hinweis zum Aufruf des Programmes angegeben.
• Bei den allgemeinen Routinen gibt es zusätzlich Funktionen für den Aufbau einer DICOM Verbindung mit allen dazugehörigen Parametern, sowie eine Routine für das saubere Beenden einer Verbindung. Außerdem gibt es noch ein paar generelle Routinen für das Handling von DICOM Objekten.
• Queries
• Es gibt für die unterschiedlichen Ebenen wie die Patienten-, die Studien-, die Serien- und die Bilderebene einzelne Anfragen, in denen jeweils die Primärschlüssel der darüberliegenden Ebenen mitgeschickt werden. Die Primärschlüssel sind in See Primärschlüssel der einzelnen Ebenen zusammengefaßt.

Primärschlüssel der einzelnen Ebenen

Ebene	Primärschlüssel
Patient	Patienten ID
Studie	Studien Instanzen UID
Serie	Serien Instanzen UID
Bild	SOP Instanzen UID

• Welche Elemente abgefragt werden können hängt jeweils von der Gegenstelle ab. Wir versuchen auf den einzelnen Ebenen möglichst viele Elemente abzufragen. Allerdings unterstützen nicht alle DICOM Programme sämtliche DICOM Attribute bei den Queries.
• Zu unterscheiden sind Patient Root und Study Root. Bei Patient Root bildet der Patient die höchste Ebene. Von hier an müssen alle Primärschlüssel übergeben werden, wenn man untere Ebenen abfragen möchte. Bei Study Root bilden die Studiendaten zusammen mit den Patientendaten die oberste Ebene. Bei Abfragen der Serienebene muß hier z.B. nur der Primärschlüssel der Studien übertragen werden. Study Root wird häufig benutzt, wenn die Patienten IDs nicht eindeutig vergeben werden. Eine schematische Übersicht über Study Root und Patient Root bildet Abbildung See Patient Root und Study Root . Es ist gut die Verschachtelung der Ebenen Patient, Patient/Studie, Studie, Serie und Bild zu sehen. Mit zunehmenden Verschachtelungen der Ebenen steigt die Komplexität der Anfragen.

• Für diese beiden Ebenen müssen unterschiedliche Routinen entwickelt werden, die sich allerdings sehr ähnlich sind.
• Generell bestehen die Queries immer aus drei Bereichen. Der erste dient dem Erstellen des Query-Objektes, der zweite ist für das Verschicken zuständig und der dritte Bereich ist eine Callback Funktion, die jede einzelne Antwort auf eine Anfrage bearbeitet. In der Callback Funktion können Bildschirmausgaben zwischen dem Empfangen jedes einzelnen Antwortobjektes geschehen, und die erhaltenen Objekte weiterbearbeitet werden.
• Beim Erstellen einer Query werden vor allem die Parameter für die Query und die Konfigurationsparameter des Programmes benötigt. Aus diesen Parametern wird ein DICOM Objekt erstellt, das die entsprechenden Angaben enthält. Es besteht auch die Möglichkeit, eine solche Query aus einer Datei einzulesen.
• Das Verschicken einer Query ist schon etwas aufwendiger. Es werden neben dem Queryobjekt, das vorher erstellt wurde, noch Informationen über das Netzwerk und die anzufordernde Verbindung benötigt. Der generelle Ablauf sieht in etwa folgendermaßen aus:

/* Ablauf des Verschickens eines Objektes */

Stelle Verbindungsanfrage für eine bestimmte Serviceklasse

Belege Parameter für die Serviceklasse

Stelle Query mit dem Objekt und den Verbindungsparametern

Baue Verbindung sauber ab

• Wichtig ist dabei noch, daß eine Callback Funktion angegeben wird, in der die Queryergebnisse verarbeitet werden. Diese Queryergebnisse werden von der Funktion für das Verschicken einfach weitergereicht. Wenn man sich im Debug Status befindet, dann werden hier noch zusätzliche Funktionen ausgegeben.
• Die Callback Funktion wird nach jeder Antwort aufgerufen. Hier wird eine verkettete Liste angelegt, in der die Anwortelemente nacheinander abgelegt werden, damit sie später weiterverarbeitet werden können. Es erfolgt außerdem eine Umsetzung der Datenelemente in ein internes Datenformat, nachdem sie aus den DICOM Objekten gelöst worden sind.
• Folgende Ebenen und Modi der Queries werden unterstützt:
• Patient Query Patient Root
• Patient/Study Query Study Root
• Study Query Patient Root
• Series Query Patient Root und Study Root
• Image Query Patient Root und Study Root
• Die Art der Studie (Patient, Study, Series, Image) gibt dabei die Datenelemente an, über die eine Abfrage geschehen darf. Der Modus (Patient Root, Study Root) dagegen gibt die Hierarchieform an, nach der die Primärschlüssel übertragen werden müssen.
• Retrieves
• Der Aufbau der Retrieves entspricht ungefähr dem der Queries. Es gibt auch hier die verschiedenen Ebenen, in denen jeweils Bilder angefordert werden können und auch die Unterscheidung in Study Root und Patient Root. Der Unterschied ist, daß bei den Moves nur Primärschlüssel benutzt werden dürfen. Es ist also nicht möglich, Anfragen über den Patientennamen oder andere Attribute zu machen. Möchte man Anfragen auf diese Art formulieren, dann muß man erst mit Find die Suche einschränken und mit den so erhaltenen Primärschlüsseln die Bilder per Move anfordern.
• Somit können sowohl sämtliche Bilder eines Patienten, einer Studie oder einer Serie angefordert werden als auch Einzelbilder.
• Der Aufbau mit den drei Funktionen Erstellen, Verschicken und Callback ist auch hier gleich. Hier hat die Callback Funktion nicht mehr viele Aufgaben. Es kann lediglich eine Meldung ausgegeben, oder eine Fortschrittsanzeige gemacht werden.

DICOM Datenbanktreiber

• Der DICOM Datenbanktreiber baut im wesentlichen auf den Routinen des Query/Retrieve Users auf. Die Konfigurationsdateien unterscheiden sich nur darin, daß die des Datenbanktreibers noch die Strukturparameter für die Datenbank enthält, die vom Benutzer aber nicht verändert werden sollen.
• Der Datenbanktreiber ist sicherlich das interessanteste Programm der DICOM Routinen!

Aufgabe

• Der Datenbanktreiber baut auf den Query/Retrieve Routinen auf, er stellt also dieselbe Funktionalität mit denselben Serviceklassen zur Verfügung.
• Interessant macht den Datenbanktreiber die Funktionalität, die der einer SQL Datenbank sehr nahe kommt. So sind im elementaren DICOM keine Joins möglich und es können auch keine Parameter sortiert angefordert werden. Diese Funktionen sowie das Parsen SQL-ähnlicher Kommandos werden von dem Datenbanktreiber vorgenommen.
• Es wird außerdem eine Schnittstelle mit den verschiedensten Funktionen zur Verfügung gestellt, wie beispielsweise zum Auf- und Abbau einer Verbindung oder zur Weiterverarbeitung der Daten.
• Interessant ist es auch, die Abfragen zu optimieren. So sind Studienanfragen bei Study Root wesentlich schneller, als wenn erst eine Abfrage über alle Patienten und dann einzeln über die Studien der Patienten abgefragt wird. Die Anfragen werden bei Joins also je nach den Fähigkeiten der Gegenseite optimiert.
• Das Teleradiologiesystem CHILI unterscheidet nicht zwischen der Funktion des DICOM Datenbanktreibers und der internen Datenbank. Es müssen also keine Quelltexte von CHILI verändert oder angepaßt werden.

• In Abbildung See Datenbankverbindungen von CHILI erkennt man gut, daß nicht zwischen den unterschiedlichen Datenbanken unterschieden wird. Es werden immer dieselben Datenbankbefehle erzeugt, die von den entsprechenden Treibern umgesetzt werden.

Echo als User

• Dies ist mit Sicherheit die einfachste aller DICOM Routinen. Es können hiermit Verify Anfragen an andere Programme gestellt werden.

Store als User

• Store als User ist auch ein sehr einfacher Service. Damit können die verschiedensten Bildarten per DICOM verschickt werden.

Implementation Model

• Diese DICOM Routinen bieten die verschiedensten Funktionalitäten als User und als Provider an. Der Server wartet auf Anfragen aus dem Netzwerk. Die anderen Applikationen versuchen selber eine Kommunikation mit einem Partner aufzubauen.

• Alle Programme können von der Kommandozeile aus aufgerufen werden, oder aber in eigenen Routinen eingebaut werden.
• Die Konfigurationsparameter des Systems können entweder in der Konfigurationsdatei der einzelnen Applikationen eingetragen werden, oder aber den aufgerufenen Funktionen direkt übergeben werden.
• Es werden hier die Programme
• CHILI_server,
• CHILI_query_client,
• CHILI_dbTreiber,
• CHILI_send,
• CHILI_echo,
• in einem einzigen Conformance Statement beschrieben.

Spezifikationen der Applikations Entities

• Hier werden die unterschiedlichen Funktionen und Syntaxe aufgelistet, die von den verschiedenen Applikationen unterstützt werden.

Kommunikationsprofile

• Hier werden die verschiedenen Möglichkeiten erläutert, mit den Routinen in einem Netzwerk umzugehen.

Erweiterungen und Spezialisierungen

• Die Routinen bieten keine konkreten Erweiterungen oder Spezialisierungen der DICOM SOP Klassen. Allerdings ist die Funktionalität vor allem bei den Serveranfragen so ausgelegt, daß die Anfragen besser optimiert werden können. So sind Anfragen über mehrere Ebenen erlaubt, was in einer Datenbank einem Join entspricht. Dies sorgt für eine Steigerung der Effektivität, vor allem, wenn zwei CHILI Workstations per DICOM miteinander kommunizieren.

Konfiguration

• Sämtliche Routinen bieten Textdateien an, über die sie konfiguriert werden können. Diese Textdateien können entweder mit einem einfachen Editor geändert, oder aber grafisch konfiguriert werden.

[ACR 94]

American College of Radiology: " ACR Standards for Teleradiology (Res. 21-1994)". Reston, VA: [http://www.acr.org/standards.new/teleradiology_standard. html], 1994.

[Bahner 97]

M. L. Bahner, U. Engelmann, H. P. Meinzer, G. van Kaick: "Anforderungen an ein Teleradiologiesystem". Radiologe, No. 4 (1997), S. 269-S. 277.

[Bakker 91]

A. R. Bakker: "HIS, RIS and PACS".Computerized Medical Imaging and Graphics, Vol. 15, No. 3 (1991), S. 157-S. 160.

[Baur 96]

H. J. Baur, F. Sauerbier, U. Engelmann, A. Schröter, H.P. Meinzer: "Aspects of Data Security and Privacy in Teleradiology". In H.U. Lemke, K. Inamura, C.C. Jaffe, R. Felix (Eds.): Computer Assisted Radiology CAR 1996. Amsterdam: Elsevier, 1996.

[Booch 91]

G. Booch: " Object-Oriented Design with Applications". Redwood CA: Benjamin Cummings,1991.

[Chen 77]

P. Chen: "The Entity-Relationship Approach to Logical Database Design". Wellesley, MA, USA: 1977.

[Choplin 92]

R. H. Choplin, J. M. Boehme, C. D. Maynard: "Picture Archiving and Communication Systems. An Overview". Radiographics, Vol. 12, No. 1 (1992), S. 127-S. 129.

[Clunie 97]

D. Clunie: "Medical Image Format FAQ". Milwaukee: [http://idt.net/~clunie/medical-image-faq/html/index.html], 1997.

[Coad 72]

P. Coad, E. Yourdan: "Object-Oriented Analysis".Englewood Cliffs, NJ, USA: Prentice Hall, 1972.

[Conrads 93]

D. Conrads: " Datenkommunikation". Braunschweig, Wiesbaden: Vieweg, 1993.

[DICOM 94]

"The DICOM FAQ". University Park, PA, USA: [http://www.xray.hmc.psu.edu/dicom/faq.html], 1994.

[DICOM Part1 93]

DICOM Part 1: "Introduction and Overview". Washington, D. C., USA: NEMA Standards, 1993.

[DICOM Part2 93]

DICOM Part 2: " Conformance". Washington, D. C., USA: NEMA Standards, 1993.

[DICOM Part3 93]

DICOM Part 3: "Information Object Definitions ( IOD)". Washington, D. C., USA: NEMA Standards, 1993.

[DICOM Part4 93]

DICOM Part 4: " Service Class Specifications". Washington, D. C., USA: NEMA Standards, 1993.

[DICOM Part5 93]

DICOM Part 5: "Data Structures and Encoding". Washington, D. C., USA: NEMA Standards, 1993.

[DICOM Part6 93]

DICOM Part 6: " Data Dictionary". Washington, D. C., USA: NEMA Standards, 1993.

[DICOM Part7 93]

DICOM Part 7: "Message Exchange". Washington, D. C., USA: NEMA Standards, 1993.

[DICOM Part8 93]

DICOM Part 8: "Network Communication Support for Message Exchange". Washington, D. C., USA: NEMA Standards, 1993.

[DICOM Part9 93]

DICOM Part 9: " Point-to-Point Communication Support for Message Exchange". Washington, D. C., USA: NEMA Standards, 1993.

[DICOM Part10 93]

DICOM Part 10: " Media Storage and File Format for Media Interchange". Washington, D. C., USA: NEMA Standards, 1993.

[DICOM Part11 93]

DICOM Part 11: "Media Storage Application Profiles". Washington, D. C., USA: NEMA Standards, 1993.

[DICOM Part12 93]

DICOM Part 12: "Media Formats and Physical Media for Media Interchange". Washington, D. C., USA: NEMA Standards, 1993.

[DICOM Part13 93]

DICOM Part 13: " Print Management Point-to-Point Communication Support". Washingotn, D.C., USA: NEMA Standards, 1993.

[Dudeck 95]

J. Dudeck: "Communication Standards in Healthcare". In H. U. Prokosch, J. Dudeck (Eds.): Hospital Information Systems: Design and Development Characteristics; Impact and Future Architecture. Amsterdam: North Holland, 1995.

[Duke 95]

Duke University: "HL-7 Frequently Answered Questions". Durham, NC, USA: [http://www.mcis.duke.edu/standards/HL7/faq/HL7FAQ10.HTM #X4X4X1X], 1995.

[Eichelberg 94]

M. Eichelberg: "Entwurf einer objektorientierten Client/Server Architektur für DICOM V3.0 und Implementierung eines Print Management Dienstes". Diplomarbeit der Universität Oldenburg, Fachbereich Informatik, 1994.

[Engelmann 96]

U. Engelmann, M. L. Bahner, A. Schröter, U. Baur, M. Schwab, S. Seeber, W. Müller, H. J. Baur, H. P. Meinzer: "Practical and Clinical Experiences with a Teleradiology System". In: S. Orphanoudakis (Ed.): EuroPACS'96. Proceedings 14th International EuroPACS Meeting. Institute of Computer Science, Foundation for Research and Technology - Hellas. Heraklion: 1996, S. 78-S. 82.

[Engelmann 97]

U. Engelmann, A. Schröter, U. Baur, O. Werner, M. Schwab, H. Müller, M. Bahner, H.P. Meinzer: "Second Generation Teleradiology". In: H. U. Lemke, M. W. Vannier, K. Inamura (Eds): Computer Assisted Radiology and Surgery CAR 97. Amsterdam: Elsevier, 1997, S. 632-S. 637

[Fritz 95]

S.L. Fritz, S. Munjal, J. Connors, D. Csipo: "Implementation of a DICOM to HL7 Gateway for RIS/PACS Communication". In H.U. Lemke, K. Inamura, C. C. Jaffe, R. Felix: Computer Assisted Radiology CAR 1995. Berlin: Springer, 1995, S. 425-S. 431.

[Fromme 94]

M. Fromme, L. Grünberg, et al.: "Software Engineering, Eine Einführung", Universität Hannover, Lehrgebiet Rechnernetze und Verteilte Systeme, 1994.

[ Framemaker 95]

"Framemaker Benutzerhandbuch". Frame Technology Corporation. San Jose, CA, USA: 1995.

[Garfagni 95]

H. Garfagni, B. Klipfel: "Integrating HIS and PACS: The DICOM Solution". In H.U. Lemke, K. Inamura, C.C. Jaffe, R. Felix: Computer Assisted Radiology CAR 1995. Berlin: Springer, 1995, S. 438-S. 444.

[Gilly 95]

D. Gilly: "UNIX in a Nutshell, Deutsche Ausgabe". Bonn, Cambridge, Paris: O'Reilly & Associates, 1995.

[Glombitza 95]

G. Glombitza, M. Makabe, H. P. Meinzer: "Illusory Contour Models can be used as Fuzzy Operators in Medical Image Processing".In H.U. Lemke, K. Inamura, C.C. Jaffe, R. Felix: Computer Assisted Radiology CAR 1995. Berlin: Springer, 1995, S. 438-S. 444.

[Hindel 94]

R. Hindel: "Implementation of the DICOM 3.0 Standard - A Pragmatic Handbook". Chicago: RSNA, 1994.

[HL7 90]

HL-7: "Application Protocol for Electronic Exchange in Healthcare Environments". Ann Arbor, MI, USA: Version 2.1, 1990.

[Huang 92]

H. K. Huang: "Three Methods of Implementing a Picture Archiving and Communication System". Radiographics, Vol. 12, No. 1 (1995), S. 157- S. 162.

[ISO 87]

International Standards Organization: "Open System Interconnection". ISO, 1987.

[Janßen 90]

H. Janßen, A. Winter: "Das Heidelberger Kommunikationssystem HeiKo". In G. Giani, R. Repges (Eds): Biometrie und Informatik - Neue Wege zur Erkenntnisgewinnung in der Medizin. Berlin: Springer, 1990, S. 195-S. 198.

[Jonas 92]

C. Jonas: " Datenfernübertragung mit Personal Computern". Würzburg: Vogel, 1992.

[Keayes 95]

R. Keayes: "White Paper on HL7/DICOM Interoperability". Durham, NC, USA: [http://dumccss.mc.duke.edu/standards/HL7/sigs/image-management/im-home.html], 1995.

[Kelley 95]

A. Kelley, I. Pohl: "A Book on C", Third Edition. Menlo Park, CA, USA: Addison-Wesley, 1995.

[Kernighan 90]

B. W. Kernighan, D. M. Ritchie: "Programmieren in C". München, Wien: Hanser; London: Prentice-Hall International, 1990.

[Köhler 82]

C. O. Köhler: "Ziele, Aufgaben, Realisation eines Krankenhausinformationssystems". Berlin und Heidelberg: Springer, 1982.

[Kotter 97]

E. Kotter, U. Schrader, K.-H. Allmann, A. Einert, B. Schneider, M. Langer: "Integration of HIS, RIS, Modalities and a large scale PACS". In: H.U. Lemke, M. W. Vannier, K. Inamura (Eds.): Computer Assisted Radiology CAR 1997. Amsterdam: Elsevier, 1997, S. 538-S. 543.

[Kuba 96]

A. Kuba e.a.: "DICOM based PACS and its applications in the education". In: S. Orphanoudakis (Ed): EuroPACS '96. Proceedings 14th International EuroPACS Meeting. Institute of Computer Science, Foundation for Research and Technology - Hellas. Heraklion: 1996, S. 46- S. 55.

[Leiner 95]

F. Leiner: "Lehrbuch der medizinischen Dokumentation". Stuttgart: Schattauer, 1995.

[Lemke 88]

H. U. Lemke, R. Klar, A. Jakob: "Das PACS-Modellvorhaben am Universitätsklinikum Freiburg". Radiologe, Vol. 28, No. 1 (1988), S. 209-S. 211.

[Ligier 96]

Y. Ligier et al.: "A multiplatform software for viewing cardiac images stored on a DICOM-based CD-ROM". In: S. Orphanoudakis (Ed): EuroPACS '96. Proceedings 14th International EuroPACS Meeting. Institute of Computer Science, Foundation for Research and Technology - Hellas. Heraklion: 1996, S. 132-S. 135.

[London 93]

J. W. London, U. Engelmann, D.E . Morton, H. P. Meinzer, P. Degoulet: "Integration of HIS Components through Open Standards: An American HIS and a European Image Processing System". Proceedings SCAMC 1993. New York: McGraw Hill, 1993.

[Loose 96]

R. Loose, M. Walz, M. Schinkmann, J. Koepke, F. Gückel, K. J. Lehmann, M. Georgi: "Experiences with a DICOM3-based manufacturer- independent multi-modality network". In: H. U. Lemke, M. W. Vannier, K. Inamura, A. G. Farman (Eds.): Computer Assisted Radiology CAR 1996, Amsterdam: Elsevier, 1996, S. 425-S. 428.

[Meinzer 96]

H. P. Meinzer, U. Engelmann: "Medical Images in Integrated Workstations in Healthcare". IMIA Yearbook, Stuttgart: Schattauer, 1996.

[Mildenberger 97]

P. Mildenberger, H.-U. Kauczor, C.-P. Heußel, M. Thelen: "DICOM PACS with CD-ROM Jukebox - routine use in a heterogenous network". In: H. U. Lemke, M. W. Vannier, K. Inamura (Eds.): Computer Assisted Radiology CAR 1997. Amsterdam: Elsevier, 1997, S. 438-S. 440.

[Offenmüller 97]

W. Offenmüller, N. Wirsz, E. Wirsz, H. Gnoyke: "Effocient Workflow Management for Radiology". In: H. U. Lemke, M. W. Vannier, K. Inamura (Eds.): Computer Assisted Radiology CAR 1997. Amsterdam: Elsevier, 1997, S. 438-S. 440.

[Osteaux 92]

M. Osteaux: "A Second Generation PACS Concept". Berlin-Heidelberg: Springer, 1992.

[Ousterhout 95]

J. K. Ousterhout: " Tcl und Tk". Bonn, Paris: Addison-Wesley, 1995.

[Preece 96]

J. Preece: " Human-Computer Interaction". Menlo Park, CA, USA: Addison-Wesley, 1996.

[Prior 93 ]

F. W. Prior: "Specifying DICOM compliance Report prepared under contract DAMD17-93-M-4464, U.S. Army Medical Research and Development Command for modality interfaces". University Park, PA, USA: 1993.

[Ratib 96]

O. Ratib et al.: "Is my DICOM file compatible?". In: S. Orphanoudakis (Ed): EuroPACS '96. Proceedings 14th International EuroPACS Meeting. Institute of Computer Science, Foundation for Research and Technology - Hellas. Heraklion: 1996, S. 112-S. 116.

[Rau 97]

W. S. Rau, C. Schwabe, K. Marquardt: "Integration of RIS, PACS and modalities - Different conceptions of users and providers". In: H.U. Lemke, M. W. Vannier, K. Inamura (Eds.): Computer Assisted Radiology CAR 1997. Amsterdam: Elsevier, 1997, S. 526-S. 535.

[Revet 97]

B. Revet: "DICOM Cook Book". Eindhoven, Niederlande: Philips Medical Systems, 1997.

[RSNA 96]

RSNA: "DICOM: The Value and Importance of an Imaging Standard". Chicago, IL, USA: [http://www.rsna.org/practice/DICOM/dicom.html], 1996.

[RRNZ 95]

RRNZ Hannover: "Die Programmiersprache C, Ein Nachschlagewerk". Uni Hannover, 1995.

[RRNZ 95/2]

RRNZ Hannover: " C++ für C-Programmierer". Uni Hannover, 1995.

[Sallinen 94]

S. Sallinen et al.: "An evaluation of DICOM 3 implementation experiences". Europacs 1994. Oulu, Finnland: [http://stekt.oulu.fi/~sjs/europacs94.html], 1994.

[ Schröter 94]

A. Schröter: "The Pic Library". Interner Technical Report 1994. Heidelberg: Abteilung Medizinische und Biologische Informatik, Deutsches Krebsforschungszentrum, 1994.

[Schwab 97]

M. Schwab: "Evaluation von MEDICUS". Diplomarbeit der Universität Heidelberg/Fachhochschule Heilbronn, Fachbereich Medizinische Informatik 1997.

[Sedat 97]

J. Sedat: "The integrated RIS/PACS solution for efficient information flow in radiology and clinic wide". In: H.U. Lemke, M. W. Vannier, K. Inamura(Eds.): Computer Assisted Radiology CAR 1997. Amsterdam: Elsevier, 1997, S. 477-S. 483.

[Smedema 96]

K. Smedema, C. Franx: "Challenges for integrated information Management in radiology departments". In: S. Orphanoudakis (Ed): EuroPACS '96. Proceedings 14th International EuroPACS Meeting. Institute of Computer Science, Foundation for Research and Technology - Hellas. Heraklion: 1996, S. 122-S. 126.

[Steven 94]

C. Steven, F. W. Prior, W. D. Bidgood, C. Parisot, G. Claeys: "DICOM: An Introduction to the Standard". University Park, PA, USA: [http://www.xray.hmc.psu.edu/dicom/dicom_intro/DICOMIntro.html], 1994.

[Weaver 94]

E. Weaver: "Understanding DICOM 3.0". Rochester, NY, USA: Kodak Health Imaging Systems, 1994.

[Voellmy 97]

D. R. Voellmy, C. N. Burger, R. Rechid, F. Hieber, G. K. Schulthess: "Image Prefetching and routing in an integrated HIS/RIS/PACS/modality environment - experiences with a filmless workflow". In: H.U. Lemke, M. W. Vannier, K. Inamura (Eds.): Computer Assisted Radiology CAR 1997. Amsterdam: Elsevier, 1997, S. 521-S. 525.

David Clunie's Medical Image Format Site

http://www.rahul.net/dclunie/html/

Hier sind Beschreibungen zu verschiedenen medizinischen Bildformaten zu finden.

Es enthält außerdem Verweise auf die Bildformate von verschiedenen CT und MR Geräten sowie Tips, wie man auch ohne Kenntnis von Formaten an die Bilddaten herankommen kann.

DICOM 3.0: The ACR / NEMA Standard Home Page

http://www.xray.hmc.psu.edu/dicom/dicom_home.html

Homepage der ACR/NEMA mit vielen wichtigen Links auf Dokumente, Bilder und Sourcecodes.

OFFIS HOMEPAGE

http://www.offis.uni-oldenburg.de/

Homepage von OFFIS in Oldenburg. Diese Gruppe beschäftigt sich mit der Umsetzung des DICOM Standards für Europa. Sie habe einen eigenen Sourcecode für DICOM Demo Applikationen entwickelt. Es besteht eine enge Zusammenarbeit mit CEN.

Current (unofficial) DICOM Supplement Status

http://www.rahul.net/dclunie/dicom-status/status.html

Hier sind Verweise auf einen Großteil der in der Entwicklung befindlichen DICOM Dokumente enthalten. Es ist jeweils der Status der Entwicklung angegeben und in der Regel auch eine Referenz auf das Dokument im PDF-Format.

Central Test Node Configuration

http://xray.swan.ac.uk/ctn

Dies ist die Beschreibung eines öffentlich zugänglichen DICOM Servers. Es können Bilder geschickt werden und Queries gemacht werden. Für das Anfordern von Bildern mit dem Move Befehl kann man sich dort eintragen lassen

DICOM Seite des MIT

http://icmit.mit.edu/

Einführung in DICOM und Verweise auf weitere Dokumente.

The Graphics File Format Page

http://www.dcs.ed.ac.uk/%7Emxr/gfx/

Eine Beschreibung von sehr vielen verschiedenen Grafikformaten.

JIRA

http://www.osaka-med.ac.jp/ jami.html

Die in Japan für DICOM zuständige Normierungsbehörde.

CEN

http://miginfo.rug.ac.be:8001/

Adresse der europäischen Normungsbehörde CEN.

NEMA

http://www. nema.org/

Homepage der Nema.

ACR

http://www. acr.org/

Homepage der ACR.

DICOM: The Value and Importance of an Imaging Standard

http://www. rsna.org/practice/DICOM/dicom.html

Eine geschichtliche Einführung zu DICOM und weitere Links auf DICOM Dokumente.

Directory of DICOM Resources - Table of Contents

http://www.merge.com/web96/subpage96/DICOM_Resources.html

Viele Links auf Resourcen im Netz. Hier befinden sich auch (offizielle) Links auf aktuelle DICOM Dokumente.

Conformance Statements

http://www.med-informatik.uni-hildesheim.de/%7Eniemann/dicom.htm#Contents

Links auf Dokumentationen und Artikel über DICOM und vor allem eine große Auswahl von Conformance Statements.

DICOM Machines you can Query

http://www.indyrad.iupui.edu/cgi-bin/wwwdcmnew

Dies ist ein einfaches WWW-Interface für mehrere DICOM Maschinen. Es können einfache Queries gestellt werden und die Ergebnisse können gleich am Bildschirm betrachtet werden.

Papyrus 3.0

http://expasy.hcuge.ch/www/UIN/papyrus.html

Beschreibung von Papyrus 3.0, eines zu DICOM kompatiblen Dateiformats.

Official DICOM Resource Web-page

http://www. merge.com/web96/subpage96/DICOM.html

Hier werden Links auf die verschiedensten Inhalte zu DICOM im Netz gegeben. Links auf Bilder, Bücher und die verschiedenen DICOM Implementierungen.

Health Level 7

http://spwww.mcit.med.umich.edu/projects/hkit/standards/hl7.html

Informationen und Links über Health Level 7. Hier sind auch Verweise auf Public Domain Sources vorhanden.

HL7 FAQ

http://www.mcis.duke.edu/standards/HL7/faq/HL7FAQ10.HTM#X4X1X1X

Die am häufigsten gestellten Fragen zu HL-7.

FTP-Adressen

Medical Image Format FAQ

ftp://rtfm.mit.edu/pub/usenet/news.answers/medical-image-faq

Hier sind die häufigsten Fragen aus der Newsgroup alt.image.medical zusammengefaßt. Außerdem sind eine Menge von Bildformaten beschrieben.

ftp://ftp.rahul.net/pub/dclunie/dicom3tools

David Clunie's DICOM3 Tools

Hier sind eine Menge von Tools, um DICOM Bilder anzusehen, sie zu bearbeiten und um Informationen über die Bilder zu bekommen.

Oldenburg

ftp://ftp.offis.uni-oldenburg.de/pub/dicom

Hier ist sowohl die Software von OFFIS zu finden als auch ein Mirror der Sourcen des Mallinckrodt Institutes. Außerdem enthält das Archiv eine Reihe von Bildern.

Mallinckrodt Institute of Radiology

ftp://ftp.erl.wustl.edu/pub/dicom

FTP-Server des Mallinckrodt Institute of Radiology, der neben der jeweils aktuellen Software des Institutes auch eine Reihe von Beispielbildern enthält.

UC Davis

ftp://imrad.ucdmc.ucdavis.edu/pub/dicom/UCDMC

Hier kann man den Source Code der UC Davis bekommen.

General Electrics

ftp://ftp.med.ge.com/pub/DICOM/IMAGES

Eine Sammlung von Beispielbildern für DICOM.

Philips

ftp://ftp.philips.com/pub/ms/dicom

Conformance Statements von Philips und weitere Informationen zu DICOM.

NEMA

ftp://ftp.nema.org/dicom/

Hier sind aktuelle Versionen von Supplements und Draftdokumenten zum DICOM Standard zu finden.

Penn State University

ftp://ftp.xray.hmc.psu.edu/

Hier sind die Sourcen der Penn-State University zu erhalten.

Usenet:

comp.protocols.dicom

Hier werden Fragen rund um DICOM und die verschiedenen Implementationen von DICOM Sourcen behandelt.

alt.image.medical

Diese Newsgroup beschäftigt sich vor allem mit der Bildverarbeitung in der Medizin.

sci.med.radiology

Hier werden Fragen rund um die Radiologie behandelt.

sci.med.telemedicine

In dieser Newsgroup ist alles zum Thema Telemedizin also auch der Teleradiologie zusammengefaßt.

sci.med.informatics

Hier wird alles die medizinische Informatik betreffende behandelt.

ACCP

American College of Chest Physicians.

ACG

American College of Gastroenterology.

ACR

American College of Radiology.

Vereinigung amerikanischer Radiologen

Es existiert in der ACR ein gemeinsames Komitee mit der NEMA, das sich mit der Entwicklung eines Standards für die digitale Bildaufnahme und Kommunikation in der Medizin (DICOM) beschäftigt.

ACSE

Association Control Service Element.

AE

siehe "Application Entity".

ANSI

American National Standards Institute.

API

Application Programing Interface.

Application Entity

Dies ist eine bestimmte Anwendung, also ein Programm mit einem bestimmten Namen.

Application Title

Name einer bestimmten DICOM Anwendung.

ASCII

American Standard Code for Information Interchange.

ASGE

American Society for Gastrointestinal Endoscopy.

Association Handling

Dies ist die Phase, in der zwei Partner prüfen, ob eine Verbindung zwischen ihnen möglich ist. Es werden die verschiedenen SOP Klassen und die Rollen als User und Provider abgeglichen.

Außerdem werden die Transfersyntaxe ausgetauscht.

ATM

Asynchronous Transfer Mode.

Netzwerkprotokoll wie Ethernet, das allerdings deutlich schneller arbeitet.

Attribute

Attribute sind die Grundbestandteile von DICOM Objekten. Objekte können sich aus Standard Attributen ( See Standard Attribute ) und privaten Attributen ( See Private Attribute ) zusammensetzen.

Attribute Tag

Ein Attribute Tag ist eine eindeutige Bezeichnung für ein Attribut in DICOM. Es besteht aus einer Gruppennummer und einer Elementnummer.

AUA

American Urological Association.

B

Basic Offset Table

Eine Tabelle mit Zeigern auf einzelne Bilder in einem Objekt, in dem mehrere Bilder zusammengefaßt sind.

Big Endian

Beschreibt die Codierung von Zahlen, die mehrere Bytes lang sind. Bei Big Endian wird zuerst das höherwertigste Byte genommen und dann absteigend die Bytes bis zum niederwertigsten.

C

CAR

Computer Assisted Radiology.

Internationaler Kongreß, der sich mit RIS und PACS Systemen sowie mit DICOM beschäftigt.

CEN

Comitê Europeen de Normalisation-

Europäische Normungsbehörde.

CEN/TC251

Technical Commitee 251.

Diese Untergruppe der CEN beschäftigt sich mit medizinischer Informatik.

CEN/TC251/WG4

Working Group 4-

Working Group on Medical Imaging and Multimedia.

Diese Arbeitsgruppe beschäftigt sich unter anderem mit der Umsetzung des DICOM Standards für die Europäische Union.

Character Repertoire

Eine endliche Menge von Buchstaben, die als komplett für einen bestimmten Zweck angesehen wird. Das Character Repertoire ist unabhängig von der Codierung.

Coded Character Set

Ein Coded Character Set ist jeweils die eineindeutige Zuordnung einer Codierung zu einer Menge von Zeichen ( See Character Repertoire ).

Composite IOD

Eine IOD ( See IOD ), die ein Objekt beschreibt, das aus verschiedenen elementaren Objekten besteht.

So bestehen CT Bilder zum Beispiel aus den Objekten Patient, Studie, Serie, Bild.

Command

DICOM Kommandos gibt es für die verschiedenen Operationen, die auf Objekten ausgeführt werden können.

Control Character

Buchstaben, die innerhalb eines Textfeldes zur Formatierung oder zu Ähnlichem benutzt werden.

Conformance Statement

Ein Conformance Statement ist eine formale Aussage über eine bestimmte Implementierung von DICOM Routinen. Es spezifiziert die Serviceklassen, die Informationsobjekte und die Kommunikationsprotokolle dieser Implementierung.

Correction Proposal

Änderung von einzelnen Teilen des DICOM Standards.

CR

Computed Radiography-

Digitales Röntgen.

CT

Computed Tomography.

D

Data Dictionary

Auflistung aller DICOM Informationsobjekte mit den eindeutigen Bezeichnern (Tags) dieser Objekte und der Wertedarstellung. Dies ist in Teil 6 des DICOM Standards beschrieben.

Data Element

Eine bestimmte Menge an Information, die durch einen Eintrag im Data Dictionary beschrieben ist. Beschrieben wird es durch einen eindeutigen Bezeichner (Tag), die Länge des Attributwertes und den Wert des Feldes.

Data Element Tag

Ein eindeutiger Bezeichner für ein Datenelement bestehend aus Gruppennummer und Elementnummer.

Data Element Register

siehe Data Dictionary

Data Element Type

Bezeichnet, ob ein Attribut einer "Information Object Definition" vorgeschrieben, unter bestimmten Bedingungen vorgeschrieben oder optional ist.

Data Set

Ein Data Set ist eine strukturierte Menge von Attributwerten, die direkt oder indirekt mit einem Informationsobjekt verbunden sind. Sie sind nach aufsteigenden Gruppen- und Elementnummern sortiert. Der Wert jedes Attributs ist ein Datenelement.

Defined Term

Der Wert eines Datenelementes ist ein "Defined Term", wenn es ein fester Wert aus einer bestimmten Wertemenge ist. Diese Mengen können von der Herstellern erweitert werden.

Derived Image

Ein Bild, dessen Pixeldaten aus einem oder mehreren anderen Bildern berechnet werden. So kann ein Bild zum Beispiel aus den Bilddaten und den Overlaydaten bestehen.

DICOM

Digital Image COmmunications in Medicine

Ein Standard für die Bilddarstellung, Bildspeicherung und Bildkommunikation in der Medizin.

DICOM Application Model

Dies ist ein Entity-Relationship Diagramm, das die Beziehungen zwischen Objekten der realen Welt mit den für DICOM benötigten Objekten herstellt.

DICOM Information Model

Ein Entity-Relationship Diagramm, das die Beziehungen zwischen "Information Object Definitions" und Objekten der realen Welt herstellt.

DIMSE

DICOM Message Service Element

Bestimmte "Message Service Elements" für den Datenaustausch.

DIMSE-C

DICOM Message Service Element Composite

Eine Nachricht, die sich auf composite Objekte bezieht.

DIMSE-C Services

Dies sind Services, die auf den entsprechenden Serviceklassen beruhen.

DIMSE-N

DICOM Message Service Element Normalized

Eine Nachricht, die sich auf normalisierte Objekte bezieht.

DIMSE-N Services

Dies sind Services, die auf den entsprechenden Serviceklassen beruhen.

DIMSE Service Provider

Jeder, der entsprechende Servicedienste bereitstellt, ist ein Provider.

DIMSE Service User

Jeder, der die entsprechenden Servicedienste benutzt, ist der User.

DSA

Digital Subtraction Angiography-

Digitale Subtraktionsangiographie.

E

Element number

Die zweite Zahl eines eindeutigen Tags eines Datenelementes.

Endian

Beschreibt die Ordnung der Bytes in Zahlen, die mehrere Bytes lang sind. Es gibt Big Endian See Big Endian und Little Endian See Little Endian .

ES

Endoscopy.

ESGE

European Society for Gastrointestinal Endoscopy.

Explicit VR

Angabe der Value Representation bei jeden Datenfeld.

F

FAQ

Frequently Asked Questions.

Dies sind Sammlungen von häufig gestellten Fragen zu einem Thema mit den entsprechenden Antworten.

FSC

File Set Creator.

FSR

File Set Reader.

FSU

File Set Updater.

FTP

File Transfer Protocol

Dieses Protokoll wird benutzt, um über das Internet oder ein Netzwerk Dateien von einem Rechner auf einem anderen Rechner zu übertragen.

G

GENESIS

Bildformat, daß von GE für die CT und MR Geräte benutzt wird.

Group Number

Die erste Zahl eines eindeutigen Tags eines Datenelementes.

Ist diese Zahl ungerade, so handelt es sich um ein privates Datenelement. Ansonsten sind es öffentliche DICOM Elemente.

GUI

Graphical User Interface-

Grafische Benutzeroberfläche.

H

HCI

Human Computer Interaction-

Mensch Maschine Schnittstelle.

HIS

Hospital Information System-

Krankenhausinformationssytem.

HISPP

Healthcare Informatics Standards Planning Panel.

Dies ist eine Behörde der ANSI, die sich mit Standards für verschiedene Bereiche der medizinischen Informatik beschäftigt.

HL-7

Health Level 7.

Ein triggergesteuerter Standard für die Kommunikation zwischen den einzelnen Komponenten eines Krankenhausinfor-mationssystems oder für die Kommunikation zwischen Krankenhaus- und Radiologie-informationssystemen.

I

IE

Information Entity.

Das ist die Information, die durch eine Composite IOD für ein bestimmtes Objekt der realen Welt definiert wird.

IEEE

Instititute of Electrical and Electronical Engineers.

Amerikanische Vereinigung, die sich mit der Standardisierung im Bereich der Elektronik beschäftigt.

IMACS

Image Management and Communication System.

Dies ist ein System, das sich mit dem Abspeichern und Wiederauffinden von Bildern beschäftigt. Die Bilder sollen zur richtigen Zeit am richtigen Ort verfügbar sein.

Implicit VR

Es erfolgt keine Angabe der Value Representation. Man muß sich die Wertdarstellung also aus dem Data Dictionary holen.

Information Entity

Dies ist ein Objekt der realen Welt, das eine Eins-zu-Eins-Beziehung zu einer DICOM IOD hat.

IOD

Information Object Definition

Eine Abstraktion von mehreren Objekten der realen Welt, die in einer Klasse zusammengefaßt sind. Es sind die Attribute und die Art der Attribute definiert.

IPI

Image Processing and Interchange.

ISO

International Standards Organization.

Dies ist eine Behörde, die sich mit Standards auf der internationalen Ebene beschäftigt.

ISP

International Standardized Profile.

Item delimination Element

Dies wird benutzt, um in einem Element mit unbekannter Länge das Ende des Objektes zu kennzeichnen.

J

JIRA

Japanese Industrial Association of Radiology Apparatus.

Dies ist die japanische Behörde, die für den DICOM Standard zuständig ist.

K

KIS

Krankenhausinformationssytem.

Ein solches System ist für das Management der Patienten- und Behandlungsdaten im Krankenhaus nötig. Es ist wichtig, daß Schnittstellen zu allen Abteilungen und abteilungsspezifischen Systemen vorhanden sind.

L

Length (undefined)

Length ist die Länge in Bytes eines Datenelementes. Ist die Länge nicht angegeben, so muß es ein Item Delimination Element geben, das das Ende des Objektes kennzeichnet.

Level/Window

Hiermit wird die Anzahl der angezeigten Grauwerte bestimmt, sowie das Grauwertfenster, also der Bereich der Grauwerte, der angezeigt werden soll.

LIS

Laboratory Information System

Ein solches System hat die Verarbeitung der im Labor anfallenden Daten zur Aufgabe. Es können Anforderungen angenommen sowie Befunde erstellt und verschickt werden.

Little Endian

Bei dieser Byteordnung werden mehrere Byte lange Zahlen beginnend mit dem niederwertigsten Byte codiert und dann Byte für Byte aufsteigend.

M

Media Storage Directory

Ein bestimmtes DICOM Objekt, das hierarchische Verzeichnisinformationen über die auf dem Medium gespeicherten Dateien enthält.

MEDICOM

Medical Image Communication.

Dies ist die europäische Variante des DICOM Standards. Sie entspricht bis auf wenige Kleinigkeiten dem DICOM Standard. So ist keine Punkt-zu-Punkt Verbindung vorgesehen, da diese in Europa keine Relevanz hat.

MI-MEDICOM

Media Interchange for Medical Image Communication.

MIPS

Japanische Umsetzung des DICOM Standards.

MR/MRT

Magnetresonanztomographie.

MSDS

Healthcare Message Standard Developers Sub-Commitee.

MSDEVC

Message Standard Data Element Value Sets Table of the SDM Module.

Eine Menge von Attributen innerhalb eines Information Entity, die logische Beziehungen miteinander haben.

N

NEMA

National Electronic Manufacturers Association.

Die Vereinigung der amerikanische Elektrogerätehersteller. Sie sind mit an der Entwicklung des DICOM Standards beteiligt, und sie publizieren die Standarddokumente.

NEMA Standards Publishing

Verlag, der den DICOM Standard publiziert.

Nested Data Set

Dies ist ein Datensatz, der innerhalb eines Datenelementes eines anderen Datensatzes enthalten ist.

NIU

Network Interface Unit.

NM

Nuklearmedizin.

Normalized

Ein DICOM Objekt, daß nur Daten einer bestimmten Objektart besitzt. Zum Beispiel Patient, Studie, Serie.

O

OFFIS

Oldenburger Forschungs- und Entwicklungs-institut für Informatik-Werkzeuge und Systeme.

Dieser Verein hat eigene DICOM Software herausgegeben und ist auch eng verbunden mit den Normungsgremien der CEN.

OMED

Organisation Mondial d'Endoscopie Digestiv.

Weltorganisation für digestive Endoskopie.

OSI

Open Systems Interconnection.

Organisation die sich mit der Kommunikation zwischen verschiedenen Geräten beschäftigt.

Beispiel ist das ISO/OSI Sieben-Schichten-Modell.

P

PACS

Picture Archiving and Communication System

Ein System, das das Anzeigen von Bildern, die Speicherung und Archivierung sowie das Auffinden alter Bilder erleichtern soll.

Wichtig ist dabei die Kommunikation mit dem RIS.

Patient Root

Abfragen (Queries) werden ausgehend vom Patienten gestellt. Die weiteren Ebenen sind Studie, Serie und Bild. Bei Abfragen auf einer Ebene müssen immer die Primärschlüssel aller darüberliegenden Ebenen übertragen werden.

PET

Positronen-Emmissions-Tomographie.

PDU

Protocol Data Unit.

PDV

Presentation Data Value.

Pixel Data

Graphische Daten wie Bilder oder Overlays, die in einer bestimmten Bittiefe codiert sind.

Prefetching

In Zusammenarbeit mit einem Archiv können die alten Bilder eines Patienten, der untersucht wird, automatisch von dem Archivmedium auf eine schnellere Speicherform geladen werden, damit sie in einem schnelleren Zugriff sind.

Dies steht in Zusammenhang mit dem DICOM Worklist Management ( See Worklist Management ).

Preloading

Dies ist eine ähnliche Funktion wie das Prefetching, es werden dabei aber immer nur ganze Bilder vorausschauend geladen und nicht gezielt bestimmte Informationen.

Private Attribute

Dies sind selbstdefinierte Attribute. Sie sind also nicht Bestandteil des DICOM Standards. Sie können von den Herstellern selbst definiert werden und haben ungerade Gruppennummern.

Private Data Element

Private Datenelemente sind Datenelemente, die nicht im Standard definiert sind. Es sind Objekte, die von Herstellern selber definiert sind, um weitere Information zu übertragen. Diese Datenelemente haben ungerade Gruppennummern.

Private SOP Class

Dies sind selbstdefinierte SOP Klassen, die von bestimmten Herstellern definiert sind, aber nicht Bestandteil des DICOM Standards sind.

Q

Query/Retrieve

Dies sind die Serviceklassen, die zum Stellen von Datenbankenanfragen und zum Anfordern von Bildern benutzt werden.

R

Registration Authority

Hiermit wird die Behörde bezeichnet, die sich mit der Wartung und der Verfügbarkeit von Listen mit Datenelementen, SOP Klassen und Transfersyntaxen beschäftigt.

Repeating group

Dies sind bestimmte Datenelemente, die mit demselben eindeutigen Bezeichner innerhalb eines Objektes mehrfach vorkommen können, wie zum Beispiel Overlays.

Retired Data Element

Ein Datenelement, das mit der Version 3.0 des Standards nicht mehr unterstützt wird. Einige Implementierungen könnten solche Elemente noch benutzen, um eine Abwärtskompatibilität zu gewährleisten.

RIS

Radiologieinformationssystem

Dieses System beschäftigt sich mit der Datenverarbeitung in der Radiologie. Dazu gehört eine Schnittstelle mit dem KIS, damit Patientendaten übernommen werden können sowie eine Schnittstelle zum PACS.

S

SAGES

Society of American Gastrointestinal Endoscopic Surgeons.

SC

Secondary Capture.

Solche Bilder werden zum Beispiel erzeugt, wenn analoge Röntgenfilme digitalisiert werden.

SCP

Service Class Provider.

Dies ist ein Bereitsteller von einer oder mehreren Serviceklassen.

SCU

Service Class User.

Dies ist ein Benutzer von einer oder mehreren Serviceklassen.

SDM

SNOMED-Data Element Microglossary-

Glossar der Nomenklatur SNOMED.

Sequence delimination item

Dies bezeichnet das Ende einer Sequenz von Objekten mit unbekannter Länge. Dieses Zeichen kommt nach dem letzten Elemente der Sequenz.

Sequence of items