Einsatz von DICOM-SR in der Pathologie

Transcription

Universität zu Lübeck
Institut für Medizinische Informatik
Direktor: Prof. Dr.-Ing. Dr. med. habil. Siegfried J. Pöppl
Diplomarbeit
Einsatz von DICOM-SR in der Pathologie
Vorgelegt von
cand. inf. Winfried Schöch
Matr. Nr. 549325
Ausgegeben von
Prof. Dr.-Ing. Dr. med. habil. Siegfried J. Pöppl
Betreut von
PD Dr. rer. nat. Josef Ingenerf
Lübeck, 14. August 2008
Eidesstattliche Erklärung
Ich versichere, die vorliegende Arbeit selbstständig und nur unter Benutzung der angegebenen Hilfsmittel angefertig zu haben. Passagen, die anderen Werken dem Sinne nach entnommen sind, habe
ich mit Quellenangaben kenntlich gemacht und wörtliche Zitate als solche gekennzeichnet.
Diese Erklärung bezieht sich auch auf die Begleitwebseite zu dieser Arbeit [98].
Lübeck, den 14.08.2008
II
Kurzfassung
Mit dem Begriff DICOM Structured Reporting“ (DICOM-SR) wird der Teil des Stan”
dards Digital Imaging and Communications in Medicine“ (DICOM) bezeichnet, der die
”
Speicherung und Kommunikation strukturierter, medizinischer Informationen beschreibt.
In dieser Arbeit wurde untersucht, ob DICOM-SR für die bildgestützte Befundung in der
Pathologie geeignet ist. Dazu wurden zunächst Arbeitsabläufe in der Pathologie betrachtet
und die Rolle digitaler Bilder in der Pathologie evaluiert.
Aufbauend auf einer ausführlichen Einarbeitung in DICOM und DICOM-SR wurde anschließend das Programm GENRE (Generic Report E ditor) entwickelt, mit dem DICOMSR-Dokumente nahezu beliebiger Art erstellt und bearbeitet werden können. GENRE
stellt DICOM-SR-Dokumente auf niedrigem Abstraktionsniveau dar und erlaubt daher
tiefe Eingriffe in Struktur und Inhalt von Dokumenten. Fertige DICOM-SR-Dokumente
können in das HTML-Format exportiert werden. Als erste frei verfügbare Software bietet
GENRE einen einfachen Zugriff auf das mit dem DICOM-Standard ausgelieferte kontrollierte Vokabular. Da GENRE als Open-Source-Projekt konzipiert wurde, ist die grafische
Benutzeroberfläche auf Mehrsprachigkeit ausgelegt.
Für die benutzerfreundliche Erstellung von DICOM-SR-Dokumenten auf höherem Abstraktionsniveau wurde schließlich ein Eingabeassistent entwickelt, der medizinisches Fachpersonal durch eine auf den jeweiligen Anwendungsfall zugeschnittene Grammatik führt
und so die strukturierte Eingabe beschleunigt. Dieser ebenfalls sehr generische Ansatz
wurde um ein einfaches Befundungsformular für die Pathologie ergänzt und mit einer
Testgrammatik für einen typischen Untersuchungsfall versehen. Gemeinsam mit Pathologen wurde diskutiert, inwiefern diese Softwarelösung im Routinebetrieb eingesetzt werden
könnte.
Danksagung
Besonders bedanken möchte ich mich bei Dr. Josef Ingenerf vom Institut für Medizinische
Informatik (IMI) an der Universität zu Lübeck für die hervorragende Betreuung dieser
Diplomarbeit. Selbst vom Familienurlaub aus unterstützte er noch deren Fertigstellung.
Des Weiteren möchte ich mich bei einigen Mitarbeitern des Instituts für Pathologie am
Universitätsklinikum Schleswig-Holstein Standort Lübeck (UK-SH) bedanken. Medieningenieur Harald Hatje zeigte mir das Institut und stellte Kontakte zum klinischen Personal
her. Oberarzt Dr. Christoph Thorns versorgte mich in mehreren ausführlichen Gesprächen
mit pathologischem Fachwissen und Ideen für den sinnvollen Einsatz strukturierter Dokumentation. Oberarzt Dr. Heinz-Wolfram Bernd half bei der Einschätzung der Anwendbarkeit des in dieser Diplomarbeit entwickelten Programms und las freundlicherweise die
medizinischen Kapitel der Arbeit Korrektur.
Dr. Andreas Turzynski von der Gemeinschaftspraxis für Pathologie Lübeck schilderte mir
in einem ausführlichen Gespräch die Situation der Pathologie im niedergelassenen Bereich,
demonstrierte die Befundberichtschreibung mittels Spracherkennung und lieferte Ideen.
Dr. Jörg Riesmeier von der ICSMED AG, Oldenburg, hielt einen hervorragenden Vortrag
zum Thema DICOM-SR in Lübeck und war anschließend stets für Fragen ansprechbar.
Er stellte verschiedene Materialien für diese Arbeit zur Verfügung. Seine Dissertation war
in vielen Punkten Vorbild für diese Diplomarbeit. Bei Dr. David A. Clunie, Mitglied des
DICOM-Komitees, bedanke ich mich für sein Java-DICOM-Toolkit und für seine stets
prompten und ausführlichen Antworten auf Fragen.
Für das Korrekturlesen der Arbeit bedanke ich mich herzlich bei Dr. Gabriele Katalinic
vom IMI und bei meinem Bruder Volker Schöch, der hierfür eine Fahrt von Berlin nach
Lübeck und eine Nachtschicht im Rechnerpool auf sich nahm.
Schließlich bedanke ich mich bei Prof. Dr. Dr. Siegfried J. Pöppl, dem Leiter des IMI,
für einen hervorragend ausgestatteten Arbeitsplatz und bei den bisher nicht genannten
Mitarbeitern des IMI für eine stets angenehme Arbeitsatmosphäre.
III
Inhaltsverzeichnis
1 Einleitung
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Ausgangssituation und Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Grundlagen
2.1 Pathologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Virtuelle Mikroskopie . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Vorteile und Einsatzgebiete der virtuellen Mikroskopie . . .
2.2.2 Bildformate für virtuelle Präparate . . . . . . . . . . . . . .
2.2.3 Anbieter für die virtuelle Mikroskopie . . . . . . . . . . . .
2.3 Computergestützte Detektion (CAD) . . . . . . . . . . . . . . . . .
2.3.1 CAD in der Pathologie . . . . . . . . . . . . . . . . . . . . .
2.4 Strukturierte und standardisierte Dokumentation . . . . . . . . . .
2.4.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.2 Begriffsklärung . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.3 Vorteile strukturierter und standardisierter Dokumentation
2.4.4 Textbausteine versus strukturierte Eingabe . . . . . . . . .
2.4.5 Strukturierte Befundberichte in der Pathologie . . . . . . .
2.5 Der DICOM-Standard . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.1 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.2 Geschichtliche Entwicklung . . . . . . . . . . . . . . . . . .
2.5.3 Standardisierungsprozess . . . . . . . . . . . . . . . . . . .
2.5.4 Aufbau des Standards . . . . . . . . . . . . . . . . . . . . .
2.5.5 Das DICOM-Modell der realen Welt . . . . . . . . . . . . .
2.5.6 Logischer Aufbau von DICOM-Informationsobjekten . . . .
2.5.7 Binäre Kodierung von DICOM-Informationsobjekten . . . .
2.5.8 XML-Kodierung von DICOM-Informationsobjekten . . . .
2.5.9 Netzwerkdienste mit DICOM . . . . . . . . . . . . . . . . .
2.5.10 DICOM-Toolkits . . . . . . . . . . . . . . . . . . . . . . . .
2.5.11 Einsatz von DICOM in der Pathologie . . . . . . . . . . . .
2.5.12 Informationsquellen zum DICOM-Standard . . . . . . . . .
2.6 DICOM Structured Reporting . . . . . . . . . . . . . . . . . . . . .
2.6.1 Allgemeiner Aufbau von DICOM-SR-Dokumenten . . . . .
2.6.2 Der DICOM-SR-Inhaltsbaum . . . . . . . . . . . . . . . . .
2.6.3 Kontextgruppen . . . . . . . . . . . . . . . . . . . . . . . .
2.6.4 Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6.5 DICOM-SR und CAD . . . . . . . . . . . . . . . . . . . . .
2.6.6 Verwandte Standards . . . . . . . . . . . . . . . . . . . . .
2.6.7 Informationsquellen zu DICOM-SR . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
4
5
6
6
8
8
9
10
11
12
13
13
13
14
15
16
17
17
18
19
19
21
23
26
27
27
29
31
33
34
35
37
42
43
46
46
47
3 Allgemeiner Lösungsansatz
50
3.1 Implementierungsplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2 Erwartete Implementierungshindernisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4 Konzeption, Implementierung und Anwendung
4.1 Erstellung einer maschinenlesbaren Version der DICOM-Kontextgruppen
4.1.1 Konzeption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.2 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Konzeption von GENRE . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2 Auswahl der Programmierplattform . . . . . . . . . . . . . . . . .
4.2.3 Auswahl eines geeigneten DICOM-Toolkits . . . . . . . . . . . . .
4.3 Implementierung von GENRE . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
54
54
54
55
61
61
64
68
70
IV
4.4
4.5
4.6
4.3.1 Datenhaltung von DICOM-SR-Dokumenten . . . . . . . . . . . . . . . . . . . .
4.3.2 Grafische Darstellung von DICOM-SR-Dokumenten . . . . . . . . . . . . . . .
4.3.3 Benutzungsfreundlichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.4 Einbinden von Bildern aus einem DICOM-Bildarchiv . . . . . . . . . . . . . . .
4.3.5 Anforderungen an das Java Runtime Environment (JRE) . . . . . . . . . . . .
Konzeption eines Eingabeassistenten für strukturierte pathologische Befundberichte . .
4.4.1 Beispielhafte Untersuchungsfälle aus der Pathologie . . . . . . . . . . . . . . .
4.4.2 Abbildung der strukturierten Eingaben auf DICOM-SR . . . . . . . . . . . . .
Implementierung eines Eingabeassistenten für strukturierte Pathologie-Befundberichte
4.5.1 Strukturierte Formulare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.2 Grammatikgeführte strukturierte Eingabe in Clinic WinData . . . . . . . . . .
4.5.3 Eigene Implementierung einer grammatikgeführten, strukturierten Eingabe . .
4.5.4 Integration in GENRE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anwendung des GENRE-Systems in der Pathologie . . . . . . . . . . . . . . . . . . . .
5 Ergebnisse und Ausblick
5.1 Ergebnisse . . . . . . . . . . . . . . . . . . .
5.1.1 Ergebnisse der theoretischen Arbeit
5.1.2 Vorarbeiten für die Implementierung
5.1.3 Implementierung . . . . . . . . . . .
5.2 Ausblick . . . . . . . . . . . . . . . . . . . .
5.2.1 DICOM-Entwicklung . . . . . . . . .
5.2.2 GENRE-System . . . . . . . . . . .
5.3 Fazit . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
70
73
78
84
88
89
89
92
99
99
99
101
102
103
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
105
105
105
105
106
106
106
107
110
A Auswahl an SNOMED-Kodes
111
B Übersetzungen von DICOM-Begriffen
112
Abkürzungsverzeichnis
113
Literaturverzeichnis
118
V
Abbildungsverzeichnis
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
Histopathologische Untersuchung eines digitalen Präparats (Rattenhirn, 20x-Vergrößerung) [86]
Freitextlicher pathologischer Befundbericht (anonymisiert) . . . . . . . . . . . . . . . . . . . . .
Schematische Skizze des Forschungsprojekts [PIH07] . . . . . . . . . . . . . . . . . . . . . . . .
Präparative Schritte bei der Herstellung eines histologischen Präparates für die konventionelle
Lichtmikroskopie [HS92] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pyramidenartiger Aufbau der Datenrepräsentation eines virtuellen Präparats . . . . . . . . . .
Strukturierte und standardisierte medizinische Dokumentation . . . . . . . . . . . . . . . . . .
Arbeitsteilung der IT im Krankenhaus aus Sicht der Radiologie (nach [Eic08], Bilder aus [125])
Entwicklung der Summe der Seitenzahlen des DICOM-Standards [Eic08] . . . . . . . . . . . . .
Aufbau des DICOM-Standards [Eic08] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DICOM Model of the Real-World“ (PS 3.3, Abb. 7-1a [DIC08a]) . . . . . . . . . . . . . . . . .
”
Ausschnitt aus dem DICOM Data Dictionary (PS 3.6 [DIC08a]) . . . . . . . . . . . . . . . . .
Datenelement ( Data Element“) und Datensatz ( Data Set“) (aus PS 3.5, Abb. 7.1-1) . . . . .
”
”
Erweiterung des DICOM-Modells der realen Welt für die Pathologie, Erweiterungen hervorgehoben (aus Supp. 122 [17]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Entity-Relationship-Modell für DICOM Composite IODs (aus PS 3.3, Abb. A.1-1 [DIC08a]) . .
Modultabelle für die Dokumentenklasse Basic Text“ (aus PS 3.3, Tab. A.35.1-1 [DIC08a]) . .
”
Informationsmodell von DICOM-SR (PS 3.3, Abb. C.17.3-1 [DIC08a]) . . . . . . . . . . . . . .
Einschränkungen bei der Konstruktion von DICOM-SR-Dokumenten der Klasse Enhanced“ (PS
”
3.3, Tab. A.35.2-2 [DIC08a]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Beispiel für einen DICOM-SR-Inhaltsbaum (PS 3.3, Kapitel C17.4 [DIC08a]) . . . . . . . . . .
Beispiele für Kontextgruppen (aus PS 3.16, Anhang B [DIC08a]) . . . . . . . . . . . . . . . . .
Beispiele für DICOM-SR-Templates (aus PS 3.16, Anhang A [DIC08a]) . . . . . . . . . . . . .
Arbeitsablauf in der Pathologie aus Sicht von IHE . . . . . . . . . . . . . . . . . . . . . . . . .
Anwendungsfälle für das Erzeugen und Bearbeiten von DICOM-SR-Dokumenten . . . . . . . .
Drei Abstraktionsebenen für die interaktive Erzeugung und Bearbeitung von DICOM-SR-Befundberichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Einige konzeptionelle Bausteine des GENRE-Systems . . . . . . . . . . . . . . . . . . . . . . . .
Kontextgruppe 230 Yes-No“ (PS 3.16, Anhang B [DIC08a] . . . . . . . . . . . . . . . . . . . .
”
Grafische Oberfläche zur Auswahl kodierter Konzepte . . . . . . . . . . . . . . . . . . . . . . .
Cyclops Dicom Structured Report Editor [BWM03] . . . . . . . . . . . . . . . . . . . . . . . . .
Benutzeroberfläche von DICOMscope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GUI-Klasse StructuredReportBrowser aus dem PixelMed-Toolkit . . . . . . . . . . . . . . . .
Komplexe Datentypen von Inhaltselementen (gruppierte Zusammenstellung nach [Clu00]) . . .
Formulare zur Bearbeitung von wichtigen DICOM-Headerinformationen . . . . . . . . . . . . .
Darstellung kodierter Elemente von DICOM-SR-Dokumenten in GENRE . . . . . . . . . . . .
HTML-Export von DICOM-SR-Dokumenten mit GENRE . . . . . . . . . . . . . . . . . . . . .
Assistent in Eclipse zum Ausgliedern von Zeichenketten in Textdateien . . . . . . . . . . . . . .
GENRE-Benutzeroberfläche auf deutsch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Eingabe eines Datums bei verschieden eingestellter Default Locale . . . . . . . . . . . . . . . .
Landesübliche Eingabe und Anzeige von Zahlenwerten . . . . . . . . . . . . . . . . . . . . . . .
Knöpfe zum Verbergen von Teilen der GENRE-Benutzeroberfläche . . . . . . . . . . . . . . . .
Ablauf der Kommunikation mit dem DICOM-Server bei der Auswahl von Bildern . . . . . . . .
Zuordnung von Application Entity Titles (AET) zu IP-Adressen und Ports in ConQuest . . . .
Plasmozytomzellen mit charakteristischen, exzentrisch gelegenen Zellkernen. [HF97] . . . . . .
Textkörper eines Befundberichts aus dem Institut für Pathologie . . . . . . . . . . . . . . . . .
Triviale Strukturierung eines Befundberichts in DICOM-SR mit GENRE . . . . . . . . . . . . .
Strukturierung eines Befundberichts in einzelne Abschnitte . . . . . . . . . . . . . . . . . . . .
Container Content Items als Abschnittsüberschriften . . . . . . . . . . . . . . . . . . . . . . . .
Messwerte und kodierte Elemente zur weiteren Strukturierung . . . . . . . . . . . . . . . . . . .
Befundungsformulare: Original und Nachbau . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dialoge zur grammatikgestützten, strukturierten Eingabe . . . . . . . . . . . . . . . . . . . . .
Anlegen eines neuen Befundberichts mit Liste der verfügbaren Eingabeassistenten . . . . . . . .
.
.
.
2
3
4
.
.
.
.
.
.
.
.
.
7
9
14
17
19
20
22
24
26
.
.
.
.
32
35
37
38
.
.
.
.
.
.
40
41
43
44
48
50
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
50
52
55
60
61
63
69
71
74
77
79
81
81
82
83
84
86
87
91
93
94
94
95
96
100
102
103
VI
Tabellenverzeichnis
1
2
3
4
5
6
7
8
9
10
11
DICOM 2008 – Teile und jeweilige Seitenanzahl (wichtigste Teile für diese Arbeit fett gedruckt)
Komplexe Datentypen für die Werte von Inhaltselementen (Übersetzung nach PS 3.3, Tab. C.17.37 [DIC08a]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Typen für Relationen (Übersetzung nach PS 3.3, Tab. C.17.3-8 [DIC08a]) . . . . . . . . . . . .
Kontextgruppen des DCMR, die UCUM-konforme Maßeinheiten enthalten . . . . . . . . . . . .
Zweibuchstabige und dreibuchstabige Sprachkodes nach ISO 639 [58] . . . . . . . . . . . . . . .
Zweibuchstabige Länderkodes nach ISO 3166-1 [53] . . . . . . . . . . . . . . . . . . . . . . . . .
Einige Datensätze mit Scale Doc“ aus der LOINC-Datenbank Version 2.22 (ausgewählte Spalten,
”
für eine Beschreibung der Spalten siehe LOINC Users’ Guide [95]) . . . . . . . . . . . . . . . .
Überschriften aus der LOINC-Datenbank für Meldungen an Krebsregister (Auswahl) . . . . . .
SNOMED-Kodes für Überschriften in pathologischen Befundberichten (Auswahl) . . . . . . . .
SNOMED-Kodes für die Untersuchung eines Beckenkamm-Trepanats (Auswahl) . . . . . . . . .
Übersetzungstabelle für Begriffe aus dem DICOM-Standard . . . . . . . . . . . . . . . . . . . .
. 20
.
.
.
.
.
39
40
57
57
58
.
.
.
.
.
58
98
111
111
112
VII
1
EINLEITUNG
1 Einleitung
1.1 Motivation
Computerunterstützung in der Pathologie Computer werden in der Pathologie wie auch in anderen medizinischen Fachdisziplinen vielfältig eingesetzt: Bei der Verwaltung von administrativen Patientendaten, zum
Niederschreiben und Archivieren medizinischer Befundberichte, für die Internetrecherche, für den Zugriff auf
Literaturdatenbanken etc. Bei der eigentlichen diagnostischen Tätigkeit des Pathologen, der anatomischen,
histopathologischen und zytopathologischen Beurteilung von Geweben, wird jedoch bisher meist auf eine Unterstützung durch Computer verzichtet.
Unter dem Schlagwort Digitale Pathologie“ wird derzeit geforscht, wie Computer dem Pathologen1 unmittel”
barer zur Hand gehen könnten. Ein paar Beispiele für den Einsatz von Computern:
In der Ausbildung.
– Das Betrachten mikroskopischer Aufnahmen am Computer soll Studierende unabhängig machen
von Laboröffnungszeiten und der (typischerweise stark beschränkten) Anzahl der Mikroskope und
Präparate.
– Assistenzärzte in der Facharztweiterbildung könnten von checklistenähnlichen, strukturierten Befundungsformularen profitieren, die das Risiko vergessener (Teil-)Untersuchungen vermindern.
Im Routinebetrieb.
– Durch den Einsatz automatischer Bildanalyse möchte man Pathologen von lästigen Routinetätigkeiten
wie z. B. dem Zählen von Zellen befreien.
– Man hofft, mit Computerhilfe das Erstellen von Befundberichten beschleunigen zu können.
– Der Einsatz standardisierter, strukturierter Befundberichte würde die Kommunikation und damit die
Kooperation der verschiedenen an einem Behandlungsfall beteiligten Institutionen verbessern.
– Systeme zur Entscheidungsunterstützung könnten insbesondere bei seltenen Krankheiten einen Beitrag zur Befundqualität leisten, indem sie auf ähnliche Fälle hinweisen und kontextbezogenes Fachwissen zur Verfügung stellen.
In der Forschung.
– Automatische Bildanalyse kann Phänomene quantifizieren, über die ein Mensch nur qualitative Aussagen treffen kann ( Morphometrie“) oder deren Quantifizierung für einen Menschen zu aufwändig
”
wäre (z. B. Auszählung aller krankhaft veränderten Zellen in einem großen Präparat). Mit Hilfe
von Computern könnten daher neue klinisch relevante Grenzwerte ermittelt oder bestehende exakter
festgelegt werden.
– Eine Wiederverwendung klinischer Routinedaten für die Forschung ist nur dann möglich, wenn relevante Fälle schnell und treffsicher im Befundarchiv gesucht werden können. Beide genannten Faktoren könnten durch den Einsatz strukturierter, maschinenlesbarer Befundberichte verbessert werden.
Die Beispiele sollen zwei Stoßrichtungen verdeutlichen: Den Einsatz von digitaler Bildverarbeitung bei der Befundung und die Verwendung standardisierter, strukturierter Befundberichte. Weitere Forschungsbereiche der
Digitalen Pathologie“ wie beispielsweise die Telepathologie werden im Folgenden nicht weiter behandelt.
”
Das virtuelle Präparat“ Möchte man Computer für die pathologische Bildverarbeitung einsetzen, so müssen
”
die zu untersuchenden Präparate zunächst digitalisiert werden. Für makroskopische Untersuchungen ist dies kein
Problem, die immer leistungsfähigeren Digitalkameras bieten längst eine preiswerte und schnelle Digitalisierung
mit ausreichender Bildqualität.
Die Situation bei mikroskopischen Untersuchungen ist wesentlich komplizierter. Die Digitalisierung eines kompletten Präparats bei höchster Vergrößerungsstufe (vgl. Abb. 1) erfordert Spezialhardware und dauert erheblich
länger als das Anfertigen eines Digitalfotos. Außerdem werden bei der Digitalisierung Rohdaten im GigabyteBereich erzeugt. Die Digitalisierung, Speicherung und automatische Analyse solcher Bilder ist seit kurzem mit
vertretbarem finanziellen Aufwand möglich. Für die Langzeitarchivierung tausender virtueller Präparate“, die
”
1 Selbstverständlich
sind hier auch Pathologinnen gemeint. Desgleichen treffen alle im Folgenden gemachten Aussagen über nicht
näher spezifizierte Personen genauso auf weibliche wie auf männliche Individuen bzw. Personengruppen zu.
Seite 1
1
EINLEITUNG
im Routinebetrieb jährlich anfallen, muss man allerdings noch auf weiter steigende Kapazitäten und sinkende
Preise bei Speichermedien hoffen.
Abbildung 1: Histopathologische Untersuchung eines digitalen Präparats (Rattenhirn, 20x-Vergrößerung) [86]
Befundberichte in der Pathologie Der Befundbericht wird üblicherweise vom Pathologen ins Diktiergerät
gesprochen und anschließend von einer Schreibkraft in das Pathologische Informationssystem eingetippt2 . Dabei
kommt meist Freitext zum Einsatz, der maschinell schwer interpretierbar ist (vgl. Abb. 2). Ein Computer kann
beispielsweise ohne zusätzliche Angaben nur schwer zwischen Überschriften und Inhalt unterscheiden, geschweige
denn herausfinden, welche Einzelbefunde im Text auftreten, welche immunhistochemischen Spezialfärbungen
eingesetzt wurden oder welche Befunde welchen Färbungen zuzuordnen sind.
Einige neuere pathologische Informationssysteme unterstützen zumindest die Zuordnung von Inhalten zu Überschriften. Die Semantik des Inhalts kann von Computern aber weiterhin nicht erkannt werden. Bei der Recherche
nach bestimmten Befundberichten müssen Pathologen daher entweder alle relevanten Fallnummern kennen oder
eine Volltextsuche bemühen. Die Volltextrecherche hat zahlreiche Nachteile, so werden beispielsweise synonyme
Begriffe, Begriffe mit Tippfehlern oder Flexionen nicht gefunden, ungewünschte Homonyme bzw. Polyseme
hingegen schon.
Strukturierte Befundberichte kann man sich wie einen Fragebogen vorstellen: Aus einer vorgegebenen Anzahl
von Möglichkeiten kann der Arzt die zutreffende Möglichkeit auswählen. Jede Auswahl kann dabei einen Einfluss
darauf haben, welche Frage als nächstes gestellt wird. Die Einschränkung der Auswahlmöglichkeiten ermöglicht
eine maschinelle Auswertung und die Auswahl der richtigen Option geht im Idealfall schneller als das Erstellen
von Freitext. Durch die inhaltliche Führung kann der befundende Arzt keine Angabe vergessen. Ein standardisierter Aufbau erleichtert zudem die Suche sowie den Vergleich interessierender Befundberichte.
2 Da
Schreibkräfte keine Ärzte sind, kann es bei der Interpretation des Diktats zu Schwierigkeiten kommen.
Seite 2
1
EINLEITUNG
PROFESSOR DR. MED. A. C. FELLER
Institut für Pathologie des Universitätsklinikums Schleswig-Holstein
Campus Lübeck
Professor Dr. med. A. C. Feller - Ratzeburger Allee 160
Institut für Pathologie - 23538 Lübeck
Herrn
Prof. Dr. med. Muster
CA der Klinik f. Chirurgie
Phantasiekrankenhaus
Musterstraße
Telefon (0451)
Fax
500-2720 Eingangslabor
500-2715 Sekretariat
500-2707 Vorzimmer
500-2705 Direktor
500-3328
Eingegangen:
tt.mm.jjjj
Journal-Nr.:
H 12345/67
*H67012345%*
12345 Musterstadt
tt.mm.jjjj
Datum:
Patient/in: Karl Mustermann
geboren am:
tt.mm.jjjj
Klinische Diagnose/ Fragestellung:
V. a. Plasmozytom
Eingesandtes Material:
Beckenkammtrepanat rechts (1,0 cm)
Mikroskopischer Befund:
Subkortikal getroffenes ausreichend langes und intaktes Beckenkammtrepanat mit mittelbreiten
bis leicht verplumpten zumeist glatt konturierten Knochenbälkchen. In den Markräumen diffuse
Infiltrate, bestehend aus atypischen Plasmazellen, diese lassen bereits im Schnittpräparat eine
erhöhte Kern-Plasma-Relation und Nukleolenprominenz erkennen. Einige Zellen auch mit
auffällig gelappten Kernen. Die Granulopoese ist in den Bildungszonen und zum Teil auch
intermediär nachweisbar, diese ist linksverschoben und reift fokal vollständig aus. Die
Erythropoese liegt verstreut bzw. ist in kleinen und mittelgroßen Nestern angeordnet. Zellen der
Megakaryopoese lassen sich insgesamt quantitativ ausreichend nachweisen mit überwiegend
verstreut liegenden Zellen. In der Berliner-Blau-Reaktion vereinzelter Nachweis von
Speichereisen, in der Versilberung keine nennenswerte Faservermehrung.
Immunhistochemisch bestätigt sich die deutliche diffuse Plasmazellvermehrung in der CD38Färbung. Eine CD56-Koexpression ist hieran nicht nachweisbar. In den Leichtkettenfärbungen
eine eindeutige monoklonale Leichtkettenrestriktion vom Typ Lambda. Kein Nachweis von
Amyloid in der Kongorot-Färbung. Nur wenige eingestreute CD20-positive B-Zellen. Keine
signifikante Vermehrung CD34-positiver Blasten.
Begutachtung:
Es handelt sich um die ausgedehnte, überwiegend diffuse Infiltration des Knochenmarks durch
ein hiernach reifzelliges Lambda-monoklonales Plasmazellmyelom von 70 %, bezogen auf die
Gesamtzellularität.
Kein Nachweis von Amyloid.
ICDO: 9732/3
Abbildung 2: Freitextlicher pathologischer Befundbericht (anonymisiert)
Seite 3
1
EINLEITUNG
1.2 Ausgangssituation und Problemstellung
Die Institute für Medizinische Informatik und Pathologie der Universität zu Lübeck planen unter dem Arbeitstitel DICOM-SR-based Representation and Interpretation of Histo-pathological Findings Obtained Automatical”
ly from Microscope Image Processing“ [PIH07] ein Forschungsprojekt, bei dem Zellstrukturen in lichtmikroskopischen Aufnahmen automatisch erkannt, quantifiziert und interpretiert werden sollen. Das Forschungsprojekt
ist dreigeteilt:
1. Automatische Muster- und Objekterkennung
2. Generierung eines strukturierten Befundberichts über die in Schritt 1 erkannten Merkmale
3. Unterstützung des Pathologen bei der Interpretation der Ergebnisse
Abbildung 3: Schematische Skizze des Forschungsprojekts [PIH07]
Im ersten Schritt, der Muster- und Objekterkennung, sollen zunächst fertige kommerzielle Lösungen zur quantitativen und qualitativen Bildanalyse eingesetzt werden, die für die vielfältigen Untersuchungen und Färbungen in
der Pathologie parametrisiert werden müssen. Forschungsziel ist die Erstellung eines fallspezifischen Parameterund Regelkatalogs in Zusammenarbeit mit dem industriellen Kooperationspartner. Die vorgeschlagenen automatischen Analyseergebnisse müssen mit dem Ergebnis von Experten verglichen werden, eine Arbeit, die also
hauptsächlich von Pathologen erbracht werden kann.
Die Ergebnisse des Bildanalyseschrittes (z. B. Zählungen, Distanz- und Flächenmessungen, Koordinaten interessanter Regionen im analysierten Bild) sollen im zweiten Schritt in standardisierter, strukturierter und damit
maschinenlesbarer Form abgelegt werden. Gemeinsam mit den Analyseergebnissen müssen sämtliche für die
spätere Identifikation (z. B. Patientendaten, Lokation der Materialentnahme, Blocknummer etc.) und Interpretation (z. B. klinische Fragestellung, Art des Materials, Art der Färbung) notwendigen Metadaten abgespeichert
werden. Dem zuständigen Pathologen soll ermöglicht werden, den automatisch generierten Befundbericht um
weitere Einzelbefunde zu ergänzen. Dabei soll eine strukturierte Datenerfassung, eventuell in Verbindung mit
computergestützter Spracherkennung, zum Einsatz kommen.
Verbreitete klinische Arbeitsplatzsysteme zur strukturierten Bild- und Befunddokumentation wie E&L Clinic
WinData [28], MEDNOVO MediColor [65] oder die Lösungen von medPACS [66] bieten derzeit keine Unterstützung für die Befundung in der Pathologie. Ein Grund dafür sind vermutlich die im Vergleich zu anderen
Fachdisziplinen erheblich größeren Datenmengen des Bildmaterials in der Pathologie, die (derzeit noch) technische Sonderlösungen erfordern. Ein weiterer Nachteil der genannten Produkte ist die Verwendung proprietärer
Dateiformate. Dies behindert den Austausch strukturierter Berichte zwischen Institutionen oder sogar schon
zwischen verschiedenen Fachbereichen innerhalb der gleichen Institution.
Für die Erstellung strukturierter Befundberichte im Zusammenhang mit Bildern wurde im Jahr 2000 der
Seite 4
1
EINLEITUNG
®
Standard DICOM Structured Reporting 3 (im Folgenden: DICOM-SR“) verabschiedet, eine Erweiterung des
”
verbreiteten Standards Digital Imaging and Communications in Medicine“ (DICOM). Insbesondere erlaubt
”
DICOM-SR die Annotation von Bildern und Signalverläufen, unter anderem durch die Zuordnung von Begriffen im strukturierten Befundbericht zu räumlichen oder zeitlichen Koordinaten. DICOM-SR ist selbst bei den
Hauptnutzern des DICOM-Standards, den Radiologen, noch weitgehend unbekannt. Die Anzahl aller Publikationen zum Thema DICOM-SR in der MEDLINE-Datenbank [117] belief sich Anfang des Jahres 2008 auf etwa
20. Für die Pathologie befindet sich DICOM gerade erst in einer frühen Entwicklungsphase, daher spielt auch
DICOM-SR dort bisher keine Rolle. Auf fertige Lösungen kann also nicht zurückgegriffen werden.
Für den dritten Schritt soll ein Decision Support System (DSS) entstehen, das aus den automatischen Analyseergebnisse einen Diagnosevorschlag ableiten kann. Im DSS soll fallbasiertes Schließen verwendet werden.
Das System soll anhand ähnlicher früherer Fälle und der dazu ermittelten Ergebnisse einen Lösungsvorschlag
für den aktuellen Fall ermitteln. Für die Diagnosefindung notwendige, zusätzliche Angaben sollen über einen
strukturierten Fragebogen vom zuständigen Pathologen eingegeben werden können.
1.3 Zielsetzung
In dieser Arbeit soll die Eignung von DICOM-SR für bildgestützte Befundberichte in der Pathologie untersucht
werden. Dazu zählt die Beantwortung der folgende Fragestellungen:

Welche Bedeutung haben Befundberichte im Alltag der Pathologen? Wie wird bisher dokumentiert?
Welche Rolle spielt DICOM in der Pathologie?
Was ist DICOM-SR und wie wird dieser Standard derzeit eingesetzt?
Welche software-relevanten Aspekte sind im Umgang mit DICOM-SR-Dokumenten zu beachten?
Aus dem theoretischen Wissen heraus soll ein Programm entwickelt werden, mit dem Pathologen Befundberichte
im DICOM-SR-Format neu erstellen, visualisieren und bearbeiten können. Das entstandene Programm soll
gemeinsam mit Pathologen evaluiert werden.
3 DICOM
ist Warenzeichen oder eingetragene Warenzeichen der National Electrical Manufacturers Association (NEMA) in den
USA und/oder in anderen Ländern. Für weitere in dieser Diplomarbeit genannte Firmen- oder Warenzeichen sowie Firmen- und
Markennamen gilt dieser Hinweis entsprechend.
Seite 5
2
GRUNDLAGEN
2 Grundlagen
In diesem Kapitel werden die theoretischen Grundlagen, die für das Erreichen der Zielsetzung notwendig sind,
erarbeitet.
Zunächst wird der medizinische Anwendungsbereich erklärt. Abschnitt 2.1 skizziert die Pathologie als medizinische Fachdisziplin. Die verschiedenen Aufgabenstellungen der Pathologie und assoziierte Arbeitsabläufe werden
erklärt. Die folgenden Abschnitte sind einem wichtigen Teilgebiet der pathologischen Tätigkeit, den lichtmikroskopischen Untersuchungen, gewidmet. Dabei stellt Abschnitt 2.2 aktuelle Bestrebungen zur Digitalisierung im
Bereich der Bildgewinnung vor. In Abschnitt 2.3 wird der Begriff der Computergestützten Detektion (CAD)
eingeführt. Abschnitt 2.4 befasst sich mit der Befundberichtschreibung als Ergebnis einer mikroskopischen Untersuchung.
Im Mittelpunkt dieser Diplomarbeit steht DICOM-SR. DICOM-SR ist Bestandteil des in der bildgebenden
medizinischen Praxis verbreiteten DICOM-Standards und kann nicht isoliert vom Rest des Standards verstanden werden. Daher führt Abschnitt 2.5 zunächst grundlegend in den umfangreichen DICOM-Standard ein. In
Abschnitt 2.6 wird schließlich DICOM-SR detailliert beschrieben.
2.1 Pathologie
Die Pathologie ist ein Teilgebiet der Medizin, das sich mit den abnormen und krankhaften ( pathologischen“)
”
Veränderungen im Organismus von Lebewesen beschäftigt [Psc98]. Bei diesen Veränderungen werden Ursache ( Ätiologie“), Entstehungsmechanismen ( Pathogenese“), strukturelle Änderungen an Zellen und Organen
”
”
( Pathomorphologie“) sowie deren funktionelle Folgen und klinische Bedeutung betrachtet [CKR93].
”
Die Untersuchung morphologischer Veränderungen und deren Beschreibung steht in dieser Diplomarbeit im
Vordergrund. Die Untersuchung kann auf makroskopischer Ebene mit dem bloßen Auge und anderen Sinnen
(Fühlen, Riechen) erfolgen. Auf der Gewebsschnitt-Ebene ( Histopathologie“) oder bei der Betrachtung einzel”
ner Zellen ( Zytopathologie“) bedient sich der Pathologe der Lichtmikroskopie als Hilfsmittel.
”
Den prinzipiellen Arbeitsablauf bei der Vorbereitung einer histologischen Untersuchung sowie einige damit verbundene Begriffe illustriert Abbildung 4. Am Anfang steht die Entnahme einer Gewebeprobe am Lebenden
( Biopsie“) zum Beispiel durch Punktion mit einer Hohlnadel oder chirurgisch mit dem Skalpell ( Exzision“).
”
”
Das Biopsat wird dem Pathologen mit einer entsprechenden klinischen Fragestellung zugestellt und am sogenannten Zuschneideplatz“ makroskopisch untersucht. Dabei erstellt der Pathologe einen makroskopischen
”
Befundbericht und wählt potentiell interessante Gewebsstücke für die histologische Aufbereitung aus. Diese
Gewebsstücke werden von Medizinisch-technischen Assistenten entweder durch Einfrieren (für die Herstellung
eines sog. Schnellschnitts“) oder durch Einbettung in Paraffin schneidbar gemacht und mit einem speziellen
”
Schneidegerät, dem Mikrotom“, in Schnitte von ca. 2-30µm Dicke zerlegt. Die Schnitte werden auf einem Ob”
jektträger aufgezogen und nach einigen weiteren Verarbeitungsschritten eingefärbt. Die Art der Färbung hängt
von der klinischen Fragestellung und der makroskopischen Untersuchung ab. Mithilfe eines breiten Spektrums
histochemischer Färbungen können zum Beispiel Zellkerne, Bakterien, Eisen, kollagene Fasern oder bestimmte
Eiweiße im Schnitt hervorgehoben werden. [Tho92]
Ein Untersuchungsfall besteht typischerweise aus mehreren Präparaten mit verschiedenen Färbungen. Die fertigen Präparate werden schließlich von den Medizinisch-technischen Assistenten für die mikrokopische Untersuchung wieder an einen Pathologen übergeben. Dieser protokolliert detailliert die mikroskopischen Befunde und
stellt anschließend aus makroskopischem und mikroskopischem Untersuchungsergebnis eine zusammenfassende
Diagnose.
Der Befund wird meist als Diktat erfasst und anschließend durch eine mit der pathologischen Terminologie
vertraute Schreibkraft abgetippt. Stehen keine entsprechenden Schreibkräfte zur Verfügung, so wird häufig
automatische Spracherkennung verwendet. Die Bedienung klassischer Eingabemedien wie Maus und Tastatur
ist hingegen problematisch. Sowohl bei der makroskopischen als auch bei der mikroskopischen Untersuchung ist
der Pathologe mit beiden Händen tätig. Bei der makroskopischen Untersuchung kommen noch das Tragen von
Handschuhen und der Umgang mit schmutzigen oder möglicherweise gar infektiösen Materialien hinzu. Für die
händische Eingabe kommt hier höchstens ein Touchscreen infrage.
Seite 6
2
GRUNDLAGEN
Abbildung 4: Präparative Schritte bei der Herstellung eines histologischen Präparates für die konventionelle
Lichtmikroskopie [HS92]
Seite 7
2
GRUNDLAGEN
2.2 Virtuelle Mikroskopie
Die virtuelle Mikroskopie ist eher Voraussetzung als Gegenstand dieser Arbeit und soll im Folgenden kurz
vorgestellt werden.
2.2.1 Vorteile und Einsatzgebiete der virtuellen Mikroskopie
Unter den Schlagwörtern Virtuelle Mikroskopie“, Virtual Slides“ und Digitale Pathologie“ wird zumeist das”
”
”
selbe verstanden: Ein hochauflösend (<=0.5µm/Pixel) digitalisiertes, histologisches oder zytologisches Präparat,
das der Pathologe – analog zur herkömmlichen Mikroskopiebefundung – am Bildschirm in verschiedenen Vergrößerungsstufen betrachten und verschieben kann ( zooming“ und panning“). Eine spezielle Herausforderung
”
”
sind die dabei zu bewältigenden Datenmengen von zum Teil mehreren Gigabyte pro Präparat, die durch Bildgrößen bis in den Gigapixel-Bereich, mehrere Fokussierungsebenen und redundante Speicherung zur Performanzsteigerung entstehen. Der Umgang mit Bildern dieser Größe ist bisher noch relativ wenig erforscht. Im
nicht-medizinischen Bereich findet man sie vor allem als Luftbilder [34, 70, 94] oder Panoramafotos [60, 121].
Vorteile der virtuellen Mikroskopie im klinischen Betrieb und in der Forschung sind:
Schneller Transport des virtuellen Präparats über beliebige Entfernungen (ermöglicht z. B. Telekonsultation)
Gleichbleibende Qualität des virtuellen Präparats (keine physikalische Degradation“)
”
Beliebig häufige Vervielfältigung der virtuellen Präparate
Platzsparende Archivierung von virtuellen Präparaten und zugehörigen Befunden
Schnelles Auffinden im digitalen Archiv
Möglichkeit einer vergleichenden, parallelen Ansicht verschiedener Färbungen eines Präparats
Möglichkeit der softwaregestützten Bildanalyse (siehe auch Kap. 2.3)
Der letzte Punkt ist besonders hervorzuheben. Softwaregestützte Bildanalyse kann dem Pathologen nicht nur
die Arbeit erleichtern, sondern erschließt auch völlig neue diagnostische Möglichkeiten. Die Beurteilung eines
Präparats durch den Pathologen erfolgt üblicherweise anhand von repräsentativen Sichtfeldern. Ein Computer
kann hingegen wesentlich größere Bereiche oder sogar das gesamte Präparat quantitativ auswerten (z. B. Zählen
von Zellen eines bestimmten Typs). Außerdem ermöglichen Computer morphometrische Analysen, also eine
Charakterisierung der Form von Objekten durch Maßzahlen. [KHZ+05]
Einem Einsatz der virtuellen Mikroskopie im klinischen Routinebetrieb stehen nach Ansicht des Autors vor
allem die immer noch beträchtlichen Scanzeiten im Wege. Je nach Vergrößerungsstufe, Präparatgröße, der
Anzahl der notwendigen Fokuspunkte (bei Einschichtaufnahme unebener Präparate) bzw. der Anzahl verschiedener Fokusebenen (mehrere vollständige Aufnahmen entlang der z-Achse) und der Scan-Hardware benötigt
das Scannen eines Präparats derzeit einige Minuten bis hin zu mehreren Stunden [RGM+06]. Die Nachteile der
langen Aufnahmezeiten können durch Slidefeeder mit Barcodeleser zur automatischen Batch-Verarbeitung über
Nacht nur teilweise entschärft werden. Bei der Scan-Hardware sind in verschiedenen Bereichen Beschleunigungen
denkbar, beispielsweise durch Kameras mit größeren CCD-Sensoren, Linsenarrays, schnellere motorgetriebene
Tische, schnellere Lademechanismen für Objektträger und schnellere Datenverbindungen zwischen Kamera und
PC bzw. PC und Datenspeicher. Wenn durch den technischen Fortschritt die Scanzeit deutlich verkürzt werden kann und die Datenspeicher im gleichen Maße wie bisher weiter wachsen und preisgünstiger werden, wird
sich die virtuelle Mikroskopie aufgrund der oben genannten Vorteile wohl auch im klinischen Routinebetrieb
durchsetzen. Für Schnellschnitte wird das herkömmliche Mikroskop aber vermutlich das Werkzeug der Wahl
bleiben, es sei denn, die Scanzeit kann so stark verringert werden, dass sie kürzer ist als die Transportdauer des
Präparats von der Vorbereitung zum Pathologen.
An einigen Universitäten (z. B. Otto-von-Guericke-Universität Magdeburg [Uni06]) wird die virtuelle Mikroskopie bereits in der Lehre eingesetzt. Der für den klinischen Routineeinsatz gravierende Nachteil Scanzeit“ spielt
”
in der Lehre kaum eine Rolle und auch das Datenvolumen ist für die Lehre deutlich beherrschbarer. Für die
Lehre bieten virtuelle Präparate weitere Vorteile:
Gleichzeitiger Zugriff (nahezu) beliebig vieler Personen auf ein virtuelles Präparat
Zugriff auf virtuelle Präparate auch außerhalb von Labors/Mikroskopiersälen (kein Mikroskop notwendig,
Unabhängigkeit von Kurs- und Praktikumszeiten)
Seite 8
2
GRUNDLAGEN
Erheblich bessere Darstellung als an günstigen Kursmikroskopen
Einblenden von Annotationen möglich
Frei zugängliche virtuelle Präparate gibt es im Netz beispielsweise unter [118], [51] oder [1].
2.2.2 Bildformate für virtuelle Präparate
Praktisch alle Hersteller von Lösungen für virtuelle Mikroskopie benutzen proprietäre Bildformate für das Speichern von virtuellen Präparate. Dies mag teilweise rein wirtschaftliche Gründe haben, um Kunden an die eigene
Produktpalette zu binden, es gibt aber auch plausible technische Gründe dafür. Gründe, die gegen den Einsatz
des JPEG-Formats sprechen:
Der JPEG-Standard limitiert die Größe eines Bildes auf 65.535x65.535 Pixel (vgl. NL-Parameter für die
Number of Lines“, Feld Y im SOF [Start of Frame Marker] [ITU93]). Diese auf den ersten Blick großzügige
”
Beschränkung kann bei virtuellen Präparaten überschritten werden.
JPEG-Dateien mit der üblichen DCT-Kompression können nicht ausschnittsweise gelesen werden. Erst
nach dem Lesen des kompletten Bildes ist die Dekompression möglich. Virtuelle Präparate im JPEGFormat können daher nicht über schmalbandige Leitungen betrachtet werden.
Der Algorithmus zur Lossless-Kompression von JPEG-Dateien ist von dem der üblichen DCT-Kompression
völlig verschieden und wird daher von den meisten JPEG-Bibliotheken nicht unterstützt. Für die digitale
Pathologie wird Lossless-Komprimierung aber häufig eingesetzt.
Die ersten beiden Probleme können umgangen werden, wenn man statt eines einzigen riesigen Bildes das Bild
in Kacheln (engl.: Tiles“) aufteilt und speichert. Ein Objektträger wird ohnehin gekachelt digitalisiert: Ent”
weder über ein quadratisches Raster bei motorgetriebenen Mikroskoptischen oder über ein Streifenraster bei
Linienscannern.
Typischerweise besteht ein kompletter Scan aus einigen tausend Kacheln. Diese in einzelnen Dateien vorzuhalten, ist unübersichtlich bei der Datensicherung und Weitergabe von Scans. Außerdem werden neben dem
gekachelten Scan in voller Auflösung für ein virtuelles Präparat üblicherweise weitere (wiederum gekachelte)
Bilder in geringerer Auflösung abgespeichert, um eine schnelle Ansicht bei verschiedenen Vergrößerungsstufen
zu ermöglichen (vgl. Abb. 5). Die Vielzahl an Kacheln und die pyramidenförmigen Datenstruktur erfordern ein
geeignetes Containerformat.
Thumbnail Image
(low resolution)
Intermediate Zoom Image Tile
Intermediate Zoom Image
(intermediate resolution)
Retrieved image region
Baseline Image
(highest resolution)
Baseline Image Tile
(a) Bild in verschiedenen Auflösungen [Kod96]
(b) Unterteilung in Kacheln [Eic07]
Abbildung 5: Pyramidenartiger Aufbau der Datenrepräsentation eines virtuellen Präparats
Seite 9
2
GRUNDLAGEN
Als Standardcontainerformat bietet sich zum Beispiel TIFF (konkret: Multipage-TIFF“) an [Ado92]. Der
”
TIFF-Standard sieht vor, dass als erste Datei das Bild in voller Auflösung vorliegen soll, die Reihenfolge der
weiteren sogenannten Subfiles“ mit geringerer Auflösung wird im Standard offen gelassen (was wiederum zu
”
einer Vielzahl verschiedener Formate bei den Herstellern führen kann). Jedes einzelne Bild kann laut TIFFStandard auf verschiedene Weise gekachelt (rechteckiges Raster oder Streifen) und komprimiert (z. B. JPEG,
LZW) werden.
Eine weitere Möglichkeit für ein Containerformat ist Kodak FlashPix [Kod96]. Die Spezifikation sieht explizit
eine pyramidenförmige, hierarchische Speicherung von Bildern in verschiedenen Auflösungen vor. Die einzelnen
Bilder sind dabei wiederum in Kacheln zerlegt, die verschieden komprimiert werden können (z. B. JPEG). Das
Format scheint allerdings auf maximal 80.000x120.000 Pixel begrenzt zu sein (siehe [8]4 ). Bei einer Auflösung
von 0,25µm/Pixel (typischer Wert bei 40x Vergrößerung) entspricht dies einer maximalen Objektträgergröße
von 20x30 mm.
Das JPEG 2000 Format bietet ebenfalls die Möglichkeit, Container für mehrere Bilder ( contiguous codestream
”
box“) zu sein [ISO00]. Bilder verschiedener Auflösung werden durch den Kompressionsalgorithmus von JPEG
2000 ohnehin schon automatisch erzeugt. Die einzelnen Bilder können in Kacheln beliebiger Größe aufgeteilt
werden. Verlustfreie Kompression ist bei JPEG 2000 üblich und daher in Programmbibliotheken integriert.
Außerdem hat JPEG 2000 keine Größenbeschränkung wie JPEG. Verschiedene Bereiche im Bild können verschieden stark komprimiert werden (Region-of-Interest-Kompression). Außerdem bietet JPEG 2000 mit dem
JPEG 2000 Interactive Protocol (JPIP) einen Mechanismus zum Lesen einzelner Ausschnitte eines Bildes für
die Übertragung über schmalbandige Netzwerkverbindungen. Diese positiven Eigenschaften haben zu einer Aufnahme von JPEG 2000 in den DICOM-Standard geführt (vgl. Supplement 61 JPEG 2000 Transfer Syntaxes“,
”
Supplement 106 JPEG 2000 Interactive Protocol“ u. a. [17]).
”
JPEG 2000 ist derzeit (2008) der neueste infrage kommende und ein sehr vielseitiger Standard, der durch
die Möglichkeit der Einbettung in DICOM auch eine wichtige Rolle für medizinische Anwendungen spielt.
Nur mit einem in DICOM integrierbaren Bildformat können bestehende PACS5 -Lösungen auch für die digitale
Pathologie verwendet werden. Dennoch verzichten viele Anbieter von Lösungen für die virtuelle Mikroskopie auf
JPEG 2000 und verwenden stattdessen auf TIFF- oder FlashPix-Containern aufbauende Bildformate mit JPEGkomprimierten Kacheln. Als Hauptgrund dafür wird die im Vergleich zu JPEG aufwändigere Dekompression
von JPEG 2000 Bildern angegeben, die die Anzeigegeschwindigkeit beim Betrachten virtueller Präparate zu
sehr beeinträchtigt.
Die Vielzahl von proprietären, nicht zueinander kompatiblen Dateiformaten für virtuelle Präparate ist für Anwender und Entwickler lästig. Beispielsweise muss der Experte bei einer Telekonsultation für jedes potentielle
Bildformat ein eigenes Anzeigeprogramm installiert haben. Auch wenn die Anzeigeprogramme in der Regel
kostenlos sind, ist dies eine unrealistische Voraussetzung. Bei der Einigung auf einen gemeinsamen Standard
für virtuelle Präparate hätte DICOM sicherlich gute Chancen, der Standard muss hierzu jedoch noch erweitert
werden (vgl. Kapitel 2.5.11).
2.2.3 Anbieter für die virtuelle Mikroskopie
Der Autor hatte auf der Medica 2007 die Gelegenheit, verschiedene Produkte für die virtuelle Mikroskopie
kennenzulernen. Im Folgenden werden einige Aspekte dieser Produkte vorgestellt, damit sich der Leser ein Bild
vom gegenwärtigen Stand der Technik machen kann.
1. Hamamatsu Photonics. Die japanische Firma stellt sowohl Komponenten wie Bildsensoren und Laser
als auch komplette bildgebende Systeme her. Das für diese Arbeit relevante Produkt heißt NanoZoo”
mer Digital Pathology“ [40] und besteht aus einem Scanner mit Slidefeeder (max. 210 Objektträger) und
Vegrößerungsstufen von 20x (0,46µm/Pixel) oder 40x (0,23µm/Pixel) sowie der dazugehörigen Softwarelösung. Ein Upgrade für Fluoreszenzaufnahmen ist möglich (gleicher Sensor, aber mit FITC-, TxRedoder Triple-Filter). Das Betrachtungsprogramm NDP.View ist sehr schlicht gehalten, beherrscht aber immerhin einfache Annotationen und Messungen.
4 Eine
E-Mail-Anfrage diesbezüglich an die offizielle Kodak-Imaging-Hotline am 20.12.2007 blieb bis zur Abgabe dieser Diplomarbeit unbeantwortet.
5 Die Abkürzung PACS steht für Picture Archiving and Communication System“.
”
Seite 10
2
GRUNDLAGEN
2. Aperio. Produkte des US-amerikanischen Herstellers Aperio werden seit Januar 2007 in Europa von Nikon vertrieben [76]6 . Das Topmodell ScanScope XT“ bietet einen Slidefeeder (max. 120 Objektträger)
”
und die Standardvergrößerungsstufen 20x (0,5µm/pixel) und 40x (0,25µm/pixel). Aperio bietet auch kleinere Versionen für max. fünf Objektträger (ScanScope CS) bzw. ohne Slidefeeder (ScanScope GL) an,
des Weiteren gibt es noch eine Lösung für Ölimmersions-Mikroskopie (ScanScope OS). Die zugehörige
Softwarelösung zum Betrachten einzelner virtueller Präparate heißt ImageScope“ und unterstützt unter
”
anderem Webkonferenzen, Anschluss eines Scanners zum Live Scan“ und das gleichzeitige Betrachten
”
mehrerer Präparate. Für Speicherung, Verwaltung und (Web-)Retrieval von virtuellen Präparaten bietet
Aperio die Software Spectrum (Plus)“ an.
”
3. Zeiss MicroImaging. Diese deutsche Firma vertreibt drei Produkte für die virtuelle Mikroskopie unter dem Namen MIRAX“ [10]: MIRAX Desk“, MIRAX Midi“ (Slidefeeder für zwölf Objektträger)
”
”
”
und MIRAX Scan“ (bis zu 300 Objektträger). Alle Modelle haben standardmäßig eine Auflösung von
”
0,23µm/Pixel, für die beiden Modelle mit Slidefeeder gibt es Fluoreszenz-Optionen. Auch Standardmikroskope von Zeiss lassen sich mit dem Zusatzprodukt MIRAX Micro“ zum Slidescanner aufrüsten. Auch ein
”
solches System lässt sich optional mit einem Slidefeeder für 50 Objektträger ausstatten. Mit der Betrachtersoftware Mirax View“ können Telekonsultationen durchgeführt werden, ein optionales Modul bietet
”
Hilfe bei TMA-Analysen. Die kostenlose Version erlaubt jedoch nicht einmal Annotationen und nur einfache lineare Messungen. Web-Archive können mit der Software MIRAX Digital Slide Desktop“ erstellt
”
werden.
4. Olympus. Lösungen für die virtuelle Mikroskopie bietet der japanische Hersteller Olympus unter dem
Namen dotSlide“ an [85]. Auch dieses System verwendet 20x- und 40x-Objektive und erreicht mit diesen
”
je nach Adapter Auflösungen zwischen 0,16 und 0,51µm/Pixel. Optional sind ein Slidefeeder für 50 Objektträger und ein TMA-Modul erhältlich. Das Betrachtungsprogramm OlyVIA beherrscht etliche Funktionen
für Konferenzschaltungen mit mehreren Pathologen. In der kostenlosen Version stehen im Gegensatz zur
Vollversion keine Möglichkeiten zur Annotation zur Verfügung.
5. Bacus Laboratories. Dieser US-amerikanische Anbieter7 bewirbt Scanner auf Basis von drei verschiedenen Mikroskopen [84]: Als Bacus Laboratories, Inc. Slide Scanner (BLISS)“ für Olympus BX61 und
”
Zeiss Axioplan 2 sowie als COOLSCOPE VS“ für Nikon. Die Betrachtungssoftware gibt es wahlweise als
”
Windows-Programm ( WebSlide Browser v4.00“) oder als Browser-Plugin ( WebSlide Net Viewer Java
”
”
Applet“). Als Server dient der WebSlide Server“. Bacus bietet außerdem Software für die Bildanalyse,
”
zum Beispiel für TMAs ( TMAscore“).
”
Diese Liste erhebt keinen Anspruch auf Vollständigkeit. Neben den genannten Produkten befinden sich zahlreiche
weitere auf dem Markt (vgl. z. B. [RGM+06]).
2.3 Computergestützte Detektion (CAD)
Mit dem Begriff Computergestützte Detektion (engl.: Computer-assisted Detection oder Computer-aided Detection, CAD) wird eine recht junge Technik bezeichnet, die Ärzten bei der Suche nach pathologischen Veränderungen
in Bildern helfen soll. Bei dieser Technik prüft der Arzt das entsprechende Bild bzw. mehrere Bilder im ersten
Durchgang auf herkömmliche Art und Weise. Anschließend lässt er sich vom Computer besonders verdächtige
Regionen markieren, die über Bildanalyse-Algorithmen ermittelt wurden, und untersucht diese noch einmal
genauer. Der Begriff Computergestützte Diagnose (engl.: Computer-assisted Diagnosis oder Computer-aided
Diagnosis, ebenfalls CAD abgekürzt) wird in der Literatur meist synonym zur Computergestützten Detektion
verwendet, zum Teil wird der Begriff aber auch als Erweiterung um eine Interpretation der Fundergebnisse
verstanden. Die historische Entwicklung von CAD und potentielle zukünftige Einsatzmöglichkeiten aus Sicht
der Radiologie werden ausführlich in [Doi07] beschrieben.
Die Computergestützte Detektion/Diagnose soll vor allem die Zweitbegutachtung durch einen weiteren Experten
ersetzen (vgl. z. B. [KOV+03]). Eine Doppelbegutachtung wird überall dort eingesetzt, wo die Zahl der falschnegativen Testergebnisse minimiert werden soll, also zum Beispiel bei den bösartigen Neubildungen. Der Ersatz
des zweiten Arztes durch ein CAD-System ist insbesondere vor dem Hintergrund von Massenuntersuchungen
6 Auf
der Webseite von Nikon findet sich bislang nur das ScanScope XT“. Weitere Slidescanner und Software finden sich nur bei
”
Aperio selbst [6].
7 Seit Mitte Juli 2006 ist Bacus Laboratories eine 100%-ige Tochtergesellschaft von Olympus America.
Seite 11
2
GRUNDLAGEN
wie dem Mammografie-Screening interessant8 . Bei der hohen Zahl an Untersuchungsfällen ist es schwierig,
genügend hochqualifiziertes Personal für die Zweitbegutachtung zu finden [Ast03]. Außerdem müssen Patienten
bei Doppelbegutachtung grundsätzlich länger auf das Ergebnis warten, insbesondere wenn die beiden Gutachter
räumlich entfernt voneinander sind.
Während in anderen Ländern wie den USA die Zweitbefundung mittels Mammografie-CAD bereits abgerechnet
werden kann, wird in Deutschland noch die herkömmliche Doppelbefundung praktiziert. Derzeit wird aber
auch in Deutschland intensiv zum Thema Mammografie-CAD geforscht, mit teils ermutigenden, teils eher
ernüchternden Ergebnissen (z. B. [WJT+07, MBP+07]). In vielen Studien zeigt sich eine recht hohe Sensitivität (ca. 90%), aber niedrige Spezifität (<50%) der CAD-Algorithmen.
Ein weiteres großes Einsatzgebiet von CAD ist die Früherkennung von Lungenkrebs in Thorax-Röntgenaufnahmen. Die Früherkennung ist hier aufgrund der hohen Inzidenz von Lungenkrebs und einer sehr hohen
Mortalität bei Erkennung in späten Stadien besonders wichtig. Ein Indikator zur Früherkennung von Lungenkrebs ist das Vorhandensein von Lungenrundherden in Thorax-Röntgenaufnahmen und -CTs. Es ist bekannt, dass kleine Lungenrundherde (5-15mm Durchmesser) von menschlichen Betrachtern leicht übersehen
werden [WGC+06]. Mit 13% im Jahr 2004 waren konventionelle Röntgenaufnahmen des Thorax eine der
häufigsten Röntgenuntersuchungen in Deutschland [BMU07]9 . Eine routinemäßige CAD auf diesen Aufnahmen
scheint vielversprechend. Bessere Erkennungsraten von Lungenrundherden liefert allerdings die 3D-CAD auf
Computertomografie-(CT)-Aufnahmen. Entsprechende Software ist seit einigen Jahren kommerziell verfügbar
(z. B. [89, 100]). Aktuell gibt es Bestrebungen, auch für Lungenkrebs-Risikopatienten ein Screeningprogramm
mit niedrig-dosierten CT-Aufnahmen zu entwickeln [VBM+08].
Der dritte große Anwendungsbereich ist schließlich die automatische Erkennung von Polypen im Dickdarm
( virtuelle Darmspiegelung“). Auch hierfür gibt es mittlerweile kommerzielle Geräte, die von der FDA in den
”
USA für die Zweitbegutachtung zugelassen wurden (z. B. [101]).
Die Dokumentation von CAD-Ergebnissen mittels DICOM-SR wird in Kapitel 2.6.5 kurz angesprochen.
2.3.1 CAD in der Pathologie
Das Haupthindernis beim Einsatz von CAD in der Pathologie ist die mangelnde Verbreitung digitalisierter
Präparate. Aber selbst wenn digitale Präparate vorliegen, müssen im Vergleich zur Radiologie ungleich größere
Datenmengen verarbeitet werden (vgl. Kap. 2.2). Es wurde bereits dargestellt, dass sich die Verwendung digitaler Präparate vermutlich langfristig durchsetzen wird. Auch das Problem der großen Datenmengen lässt
sich durch Multi-Resolution-Ansätze und die immer höhere durchschnittliche Rechenleistung von Prozessoren
bereits einigermaßen beherrschen. Insofern ist damit zu rechnen, dass sich CAD in naher Zukunft auch in der
Pathologie etablieren wird.
Forschungsarbeiten zu CAD in der Pathologie gibt es zahlreiche, eine Auswahl sei im Folgenden vorgestellt.
Bereits 1982 versuchten Deugnier et al. in [DMB+82] erfolgreich, den Eisengehalt in Leberbiopsien histologisch halbautomatisch zu bestimmen. Dazu wurden je Präparat in Berliner-Blau-Färbung mehrere MikroskopSichtfelder mit einer Videokamera aufgenommen und die Pixel des Bildes mit einem einfachen Schwellwertverfahren in Pixel mit und ohne Eisengehalt unterteilt. Die Schwellwerte wurden vom Pathologen festgelegt, die
Auszählung der relevanten Pixel erfolgte automatisch. Die Entwicklungen auf diesem Gebiet seither sowie ein
neues Verfahren werden in [OLC+05] beschrieben. Im Artikel [SIM+98] wird ein neuronales Netz zur Analyse von Pap-Abstrichen, einer Früherkennungsmethode des Gebärmutterhalskrebses, vorgestellt. In [BPR+06]
wird CAD zum Grading10 von Prostatatumoren verwendet. Es wird also nicht nur nach verdächtigen Gebieten
gesucht, sondern auch eine Diagnoseunterstützung (Klassifikation mittels Support Vector Machines) geboten.
[KSS+07] beschreibt die Entwicklung eines Systems für die Bestimmung des Differenzierungsgrades beim Neuroblastom. Auch hier kommt maschinelle Klassifikation zum Einsatz. Ein aktuelles Paper zum Thema CAD in
der Pathologie ist [HIJ+08]. Hier ermittelt der Computer über Merkmalsextraktion der Membranen in einem
8 Beim
Mammografie-Screening in Deutschland [56] werden möglichst viele Frauen im Alter von 50-69 einer freiwilligen
Röntgenuntersuchung der Brust unterzogen. Diese Untersuchung wird alle zwei Jahre wiederholt. Zahlreiche Länder auf der
Welt haben ähnliche Programme.
9 Aktuellere Zahlen werden im nächsten Jahresbericht des BMU voraussichtlich Ende 2008 veröffentlicht.
10 Im Bereich der Krebsuntersuchungen bezeichnet Grading“ das Bestimmen des sog. Differenzierungsgrades eines bösartigen
”
Tumors (typischerweise von 1 bis 4, je nach Tumorart existieren verschiedene Skalen). Eine höhere Gradzahl bedeutet geringere
Differenzierung und damit höhere Malignität [Psc98].
Seite 12
2
GRUNDLAGEN
HER2-gefärbten Präparat den Score für eine HER2-Protein-Überexpression beim Mammakarzinom.
Der interessierte Leser findet in den Literaturverweisen der genannten Quellen oder im Internet zahlreiche
weitere CAD-Projekte aus dem histologischen und zytologischen Bereich. Firmen, die sich mit diesem Thema
auseinandersetzen, sind beispielsweise SPC [112] und Definiens [22].
2.4 Strukturierte und standardisierte Dokumentation
2.4.1 Einleitung
Während die medizinische Dokumentation ursprünglich überwiegend als Gedächtnisstütze für das medizinische
Fachpersonal gedacht war, spielt sie heute zunehmend auch eine fachrichtungs- und einrichtungsübergreifende
Rolle. Außerdem wird die medizinische Dokumentation mittlerweile nicht nur von Fachpersonal gelesen. So wird
das Interesse des Patienten an einer ordnungsgemäßen Dokumentation seit vielen Jahren von der Ärzteschaft
anerkannt (vgl. [Bun06], §10, Abs. 1) und zahlreiche Länder versuchen zum Wohle der Volksgesundheit, lebenslange Gesundheitsakten für ihre Bürger einzuführen. Kommt es zu einem Streitfall zwischen Patient und
Arzt, so dient die medizinische Dokumentation als Beweismittel. Teile der medizinischen Dokumentation werden
zudem für Abrechnungszwecke benötigt. Mit der Einführung der diagnosebezogenen Fallpauschalen (Diagnosis
Related Groups, DRG) im Jahr 2004 hat beispielsweise die wirtschaftliche Bedeutung einer vollständigen und
korrekten medizinischen Dokumentation im stationären Bereich drastisch zugenommen.
Neben dem vergrößerten menschlichen Leserkreis medizinischer Dokumentation ist auch deren zunehmende maschinelle Verarbeitung zu berücksichtigen. Aktuelle Bestrebungen zielen dabei nicht nur auf die Erstellung und
Archivierung medizinischer Dokumentation am Computer und die Übermittlung von Dokumenten über Netzwerke, sondern insbesondere auf die maschinelle Interpretierbarkeit von Inhalten, die durch eine Strukturierung
und Standardisierung der Dokumentation erreicht werden kann (vgl. Kap. 2.4.2). Maschinell interpretierbare Dokumente ermöglichen neben der schnelleren Verarbeitung großer Datenbestände, zum Beispiel zu Abrechnungsoder Forschungszwecken, unter anderem eine exaktere Recherche und eine bessere maschinelle Weiterverarbeitung durch die gezielte Extraktion von Inhalten (vgl. Kap. 2.4.3).
An die medizinische Dokumentation werden heute also andere Anforderungen gestellt als noch vor wenigen
Jahren.
2.4.2 Begriffsklärung
Folgende Begriffe sind für verschiedene Ausprägungen medizinischer Dokumentation geläufig (vgl. Abb. 6):
Freitext. Reiner Freitext entsteht zum Beispiel beim Diktat eines Befundberichts. Auch Entlassungsbriefe
werden meist als Freitext formuliert. Prinzipiell unterliegt Freitext keinerlei Einschränkungen. Die Bedeutung einzelner Informationseinheiten eines Freitextes ist implizit und muss vom Leser aus dem Kontext
abgeleitet werden. Fehlt dem Leser das notwendige Kontextwissen, zum Beispiel weil er einer anderen
Berufsgruppe angehört, so geht bei der Interpretation von Freitext Information verloren.
Strukturierte Dokumentation. Bei strukturierter Dokumentation wird der Aufbau von Dokumenten
vorgegeben, was im Vergleich zu Freitext die Freiheitsgrade reduziert. Insbesondere wird festgelegt, aus
welchen Informationseinheiten in welcher Reihenfolge ein Dokument bestehen soll und wie diese zueinander
in Beziehung stehen. Eine Strukturierung kann auf inhaltlicher (z. B. klinische Leitlinien: Welche Schritte
sind für die Diagnose einer Krankheit in welcher Reihenfolge notwendig?), formeller (z. B. Vorgaben der
Verwaltung bezüglich der Strukturierung eines Briefkopfes) oder technischer Ebene (z. B. Speicherung
im XML-Format) stattfinden. Vollständig strukturierte Dokumentation findet man in Multiple-ChoiceFormularen, die Dinge durch ihre Merkmale und deren diskrete Ausprägungen beschreiben. Jedem Merkmal wird dazu explizit ein Wert aus einer Menge zulässiger Werte (Wertebereich) zugeordnet11 .
Standardisierte Dokumentation. Mit standardisierter Dokumentation ist das Bestreben gemeint, die
Syntax von Dokumenten und die Beschreibung der Semantik des Dokumenteninhalts an übergeordneten
regionalen, nationalen oder internationalen Standards auszurichten. Auf syntaktischer Ebene werden zum
11 Solche
Formulare werden beispielsweise für Teile der Pflegedokumentation verwendet (Zeitpunktmessungen der Vitalparameter
oder Dokumentation der Arzneimittelgabe in der Patientenkurve).
Seite 13
2
GRUNDLAGEN
Strukturierte
Dokumentation
Freitext / Diktat
Standardisierte
Dokumentation
SNOMED CT 35601003
Überschrift
SNOMED CT 13427003
Aufzählung
SNOMED CT 24028007
SNOMED CT 234330008
UCUM cm
SNOMED CT 117023006
Absatz
LOINC 22635-7
SNOMED CT 20870005
Bild
SNOMED CT 23592000
HL7-CDA, DICOM-SR, SNOMED, LOINC,
UCUM, ICD, OPS, G-DRG, ATC, MedDRA,...
Abbildung 6: Strukturierte und standardisierte medizinische Dokumentation
Beispiel die Standards DICOM-SR (Kap. 2.6) und HL7-CDA (Kap. 2.6.6) verwendet, die Datenstrukturen
für medizinische Dokumente vorgeben. Eine Standardisierung der semantischen Annotation von Inhalten
wird erreicht, indem für Merkmalsausprägungen ausschließlich Begriffe aus standardisierten Wortschätzen,
wie z. B. kontrollierten Vokabularien, Terminologiesystemen oder Klassifikationen, verwendet werden.
Statt natürlicher Sprache werden bei standardisierter Dokumentation Kodes verwendet, um Dinge zu
referenzieren. So werden beispielsweise Diagnosen über ihren ICD-10-Kode beschrieben oder der Dokumententyp und dessen Zwischenüberschriften über LOINC-Kodes. Sowohl DICOM-SR als auch HL7-CDA
unterstützen die Verwendung solcher Kodes.
In der Praxis liegt medizinische Dokumentation zumeist als Mischform der genannten Ausprägungen vor. Freitext ist eigentlich immer zumindest inhaltlich in irgendeiner Weise strukturiert. Der Strukturierungsgrad von
Dokumenten kann stark variieren. Da eine vollständige Strukturierung die Ausdrucksmöglichkeiten medizinischer Befunde stark eingeschränkt, gibt es beispielsweise Formulare mit überwiegend strukturiertem Anteil, die
an einzelnen Stellen Freitextfelder anbieten (z. B. Anamneseformulare), oder überwiegend freitextliche Dokumente, bei denen einzelne Merkmale explizit ausgezeichnet sind (vgl. Beispiel für strukturierte Dokumentation
in Abb. 6). Als Leitformel für die Aufteilung zwischen Freitext und strukturierter Dokumentation hat sich in
der Praxis Struktur für das Häufige, Freitext für das Seltene“ bewährt. Standardisierte Dokumente sind in der
”
Regel auch strukturiert und strukturierte Dokumente zumindest in Teilen standardisiert. Auch beim Grad der
Standardisierung gibt es verschiedene Abstufungen von standardisiert aufgebauten Dokumenten bis hin zur standardisierten semantischen Annotation aller im Text genannten Merkmale und ihrer Ausprägungen. Die Begriffe
strukturierte Dokumentation“ und standardisierte Dokumentation“ sollten also eher als Qualitätsdimensionen
”
”
denn als feststehende Dokumentenklassen aufgefasst werden.
2.4.3 Vorteile strukturierter und standardisierter Dokumentation
Strukturierte und standardisierte Dokumentation hat zunächst einmal Vorteile für die menschlichen Benutzer,
da mit ihrer Hilfe ungenaue, unvollständige und fehlerhafte Angaben vermieden werden können [Rie06]. Wenn
Dokumente strukturiert aufgebaut sind, können sie leichter mit anderen Dokumenten verglichen und von dritten
Personen verstanden werden [Nou06]. Durch die vorgegebene Struktur, die wie eine Checkliste“ abgearbeitet
”
werden kann, wird die Vollständigkeit der Dokumentation schon bei der Erstellung sichergestellt. Dieser Aspekt
ist vor allem auch für die Ausbildung interessant. Beispielsweise kann mit strukturierter Dokumentation die Unterscheidung zwischen Nullbefunden und nicht-erhobenen Befunden erzwungen werden, während eine fehlende
Freitextangabe Raum für Spekulationen lässt. Schließlich reduziert strukturierte Dokumentation in den meisten
Seite 14
2
GRUNDLAGEN
Fällen die Schreib- und Korrekturarbeit [Lan00].
In der Einleitung wurde beschrieben, dass die vollständige oder partielle Wiederverwendung medizinischer Dokumentation in den letzten Jahren stark zugenommen hat. Dabei spielt die maschinelle Verarbeitung aufgrund
ihrer Schnelligkeit und Präzision eine immer größere Rolle. Für eine erfolgreiche Wiederverwendung müssen
Dokumente folgende Eigenschaften erfüllen:
Leichte Auffindbarkeit. Dokumente müssen mit hoher Wahrscheinlichkeit gefunden werden (Recall)
und dann auch relevant sein (Präzision).
Automatische Auswertbarkeit.
Einfache Weiterverarbeitung. Zum Beispiel beim Archivieren oder Kommunizieren.
Im Vergleich zur Volltextsuche in Freitexten können mit standardisierter Dokumentation sowohl Recall als auch
Präzision einer Suchanfrage verbessert werden:
Recall. Der Einsatz von Kodes erlaubt das Durchsuchen von fremdsprachigen Texten mit der gleichen
Suchanfrage. Bei Verwendung eines konzeptorientierten Terminologiesystems können Synonyme automatisch in die Suchanfrage integriert werden.
Präzision. Der Einsatz von eindeutigen Kodes bietet Schutz vor sprachlichen Mehrdeutigkeiten (z. B.
HWI“, kann Harnwegsinfekt“ oder Hinterwandinfarkt“ bedeuten).
”
”
”
Werden in der standardisierten Dokumentation hierarchisch klassifizierte Kodes (Taxonomien) verwendet, so
können Suchanfragen leicht verfeinert oder verallgemeinert werden.
Strukturierte Dokumente mit einer beschränkten Menge an Merkmalsausprägungen lassen sich sehr gut automatisch auswerten. Bei standardisierter Dokumentation sind die Merkmalsausprägungen kodiert und damit maschinell semantisch auswertbar. In vielen Fällen können dadurch automatisch abrechnungsrelevante Diagnosenund Prozedurenkodes abgeleitet ( automatic coding“ [Nou06]) oder Systeme zur Entscheidungsunterstützung
”
(Decision Support Systems, DSS) integriert werden [Lan00].
Das Archivieren und Kommunizieren von Dokumenten wird durch die Verwendung internationaler Standards wie
DICOM-SR und HL7-CDA erleichtert, da für Dokumente in diesen Formaten bereits entsprechende technische
Lösungen existieren. Grundsätzlich fördert die Beschränkung auf wenige, aber flexible Dokumentenformate, die
teilweise maschinell auswertbar sind, die Informationsintegration innerhalb einer Einrichtung.
2.4.4 Textbausteine versus strukturierte Eingabe
Es gibt im Wesentlichen zwei verschiedene Methoden zur Erstellung von strukturierten und standardisierten
Befundberichten: Die Verwendung von Textbausteinen und die strukturierte Eingabe (engl.: Structured Data
”
Entry“, SDE).
Bei der Verwendung von Textbausteinen wählt der Benutzer aus einer Liste vorgefertigter, längerer Textfragmente ein geeignetes aus. Da die Auswahl insbesondere für häufig verwendete Textbausteine sehr schnell geht,
kann so die Texteingabe stark beschleunigt werden. Außerdem wird das ermüdende Formulieren immer gleicher Textfragmente vermieden [Nou06]. Ausgefeilte Lösungen für Textbausteine erlauben die Modifikation der
Textinhalte an einigen Stellen ( Lückentext“). In den Textbausteinen können für einzelne Begriffe oder ganze
”
Abschnitte Kodes hinterlegt sein. Auf diese Weise kann eine standardisierte Dokumentation erzeugt werden, ohne dass der Benutzer mit Kodes und den zugrundeliegenden Terminologien oder Ordnungssystemen konfrontiert
wird.
Bei der strukturierten Eingabe wird dem Benutzer eine vorgegebene Struktur, z. B. ein Formular, präsentiert,
bei der er wiederum aus mehreren Möglichkeiten wählen muss. Im Vergleich zu den Textbausteinen erfolgt die
Eingabe aber feingranularer. Beispielsweise entscheidet sich der Benutzer zwischen verschiedenen Ausprägungen
eines Attributs ( Ankreuzen“ auf einem Formular) oder für den nächsten passenden Teilsatz in einem Fließ”
text. Die strukturierte Eingabe erfolgt dabei typischerweise nicht wahlfrei sondern ähnlich einer mündlichen
Befragung strikt sequentiell. Das schrittweise Abarbeiten erlaubt es, den Benutzer nur mit den Entscheidungen
zu konfrontieren, die im jeweiligen Kontext tatsächlich relevant sind. Dieses Konzept wird in den Sozialwissenschaften Filter“ oder Contingency Question“ genannt [114]. Auch mit strukturierter Eingabe kann eine
”
”
standardisierte Dokumentation erzeugt werden. Im Gegensatz zu Textbausteinen können nicht nur einzelne
Wörter oder Abschnitte mit Kodes hinterlegt werden, sondern Kodes können auch aus mehreren aufeinander-
Seite 15
2
GRUNDLAGEN
folgenden Eingabeschritten abgeleitet“ werden.
”
Neben starren Textbausteinen und flexibler strukturierter Eingabe sind viele Zwischenformen denkbar.
2.4.5 Strukturierte Befundberichte in der Pathologie
Die grundsätzliche Gliederung pathologischer Befundberichte ergibt sich aus dem Arbeitsablauf und ist zumindest deutschlandweit nahezu einheitlich:
1. Klinische Angaben. Im Institut für Pathologie am Universitätsklinikum Schleswig-Holstein, Campus
Lübeck, (UK-SH)) wird dieser Abschnitt Klinische Diagnose / Fragestellung“ genannt. Hier wird die Fra”
gestellung des Auftraggebers, typischerweise also des klinisch tätigen Arztes, wiederholt. Ist eine relevante
Vorerkrankung und eine eventuell zugehörige Therapie bekannt oder gab es bereits eine Voreinsendung,
so wird dies ebenfalls aufgeführt.
2. Eingesandtes Material.
3. Makroskopischer Befund. Listet die Einzelbefunde bei der Untersuchung am Zuschnittplatz.
4. Mikroskopischer Befund. Listet die Einzelbefunde der Untersuchung aller zum Fall gehörigen Präparate
unter dem Mikroskop.
5. Diagnose. Häufig wird synonym der Begriff Begutachtung“ oder Beurteilung“ verwendet. Wird die
”
”
Überschrift Begutachtung“ gewählt, so schließt dieser Abschnitt meist den Kommentar (siehe nächster
”
Punkt) ein.
6. Kommentar.
Zwischen 2. und 3. befindet sich oft noch eine Aufzählung, was sich in welchem Paraffinblock befindet (vgl. Abb.
4) – dieser Abschnitt ist besonders gut strukturierbar.
Der auftraggebende Arzt interessiert sich eigentlich nur für Diagnose und Kommentar. Aufgabe des ausführlichen
makroskopischen und mikroskopischen Befundes ist vor allem, im Streitfall nachvollziehen zu können, ob der Pathologe etwas übersehen oder nur“ falsch bewertet hat. Haftbar gemacht werden kann er nur für Einzelbefunde,
”
die übersehen wurden.
Befunde, die ausschließlich aus Textbausteinen bestehen, sind in der Pathologie illegitim, da ein solches Vorgehen
dem Prinzip einer patientenspezifischen ärztlichen Leistung widerspräche. Dennoch werden Textbausteine auch
von Pathologen häufig eingesetzt. Gängig scheint die Befundschreibung anhand weniger, längerer Textbausteine,
die an die jeweilige Beobachtung angepasst werden. Eine gewisse Unschärfe durch diese Textbausteine wird in
Kauf genommen, solange sie nicht die Diagnose beeinflusst.
Strukturierte Dateneingabe hat sich in der Pathologie bisher nicht durchgesetzt. In den speziellen PathologieInformationssystemen (z. B. NEXUS / PATHOLOGIE [74] oder dc-pathos/ipms [21]) findet sich höchstens die
Zuordnung von Freitext zu den oben genannten Überschriften eines Befundberichts. Als Austauschformat wird
Microsoft Word verwendet. Auch allgemeinere Softwareprodukte, die für andere Fachdisziplinen durchaus eine
strukturierte Eingabe ermöglichen, bieten für die Pathologie entweder überhaupt keine oder nur eine minimale
Lösung an (z. B. Clinic Windata [28] oder MediColor [65]). Dies mag daran liegen, dass in anderen medizinischen Fachdisziplinen wie der Gastroenterologie eine wichtige Motivation für den Einsatz von strukturierter
Dokumentation die Ableitung von Kodes ist, die für Abrechnungszwecke benötigt werden. Für niedergelassene
Pathologen entfällt jedoch diese Motivation, da sie nach der Anzahl der Materialien“ (z. B. Mamma + Biopsie
”
vorne/hinten/rechts/links/oben/unten = 7 Materialien) sowie der Anzahl der Sonderfärbungen bezahlt werden.
Beide Parameter fallen jeweils in eine EBM- bzw. GOÄ-Kategorie und werden dann zu einem Gesamtscore
verrechnet. Die beiden genannten Parameter können aber nicht zuverlässig aus den Befundtexten abgeleitet
werden.
Kapitel 4.4.2 erklärt, wie strukturierte und standardisierte Befundberichte in der Pathologie zukünftig aussehen
könnten.
Seite 16
2
GRUNDLAGEN
2.5 Der DICOM-Standard
Dieser Abschnitt führt in den DICOM-Standard ein. Aufgrund des Umfangs des DICOM-Standards muss die
Einführung stark lückenhaft und oberflächlich bleiben. Die Kenntnis des DICOM-Jargons“, der sich in einigen
”
Punkten von der in der Softwaretechnik verwendeten Terminologie unterscheidet, und der Grundprinzipien von
DICOM ist jedoch für das Verständnis der folgenden Kapitel von Bedeutung. Viele DICOM-Begriffe wurden
für einen besseren Lesefluss ins Deutsche übersetzt. Eine Liste von übersetzten und nicht-übersetzten DICOMBegriffen findet sich in Anhang B.
2.5.1 Allgemeines
DICOM ( Digital Imaging and Communications in Medicine“) ist ein objektorientierter Standard für die In”
teroperabilität von medizinischen Anwendungen. Er definiert Datenstrukturen für medizinische Bilddaten der
verschiedensten Fachdisziplinen sowie die dazugehörigen Metadaten, Dienste für den Austausch über Netzwerke
und Formate für die Speicherung auf Datenträgern.
Der Standard geht weit über ein herkömmliches Bildformat hinaus. Neben den üblichen 2D-Bildern können
unter anderem 3D-Bilder, Videos und 1D-Signalverläufe – wie beispielsweise ein EKG – im DICOM-Format
gespeichert werden, aber auch Arbeitslisten und ärztliche Befundberichte (s. u.). Diese digitalen Informationen
werden im DICOM-Jargon Informationsobjekte ( Information Objects“) genannt. Zusätzlich zu den Datenfor”
maten bietet DICOM für jedes Informationsobjekt zahlreiche Dienste ( Service Classes“) an, beispielsweise für
”
die Suche ( Query“) und den Versand ( Retrieve“ bzw. Storage“) von DICOM-Objekten über Netzwerke, das
”
”
”
Drucken ( Print Management“), die Langzeitarchivierung ( Storage Commitment“) oder auch den Austausch
”
”
auf Datenträgern ( Media Storage“). Weitere Dienste umfassen die Verschlüsselung und die elektronische Signa”
tur von Daten sowie die Workflow-Unterstützung. Die Einheit aus Informationsobjekt und darauf ausführbaren
Diensten wird Service-Object Pair“ (SOP) genannt. In Analogie zum Modell der Klasse mit Attributen und
”
Methoden in der objektorientierten Programmierung spricht man von verschiedenen SOP-Klassen.
Arbeitsorganisation und
medizinische Dokumentation
RIS
Administration und Abrechnung
Datenakquisition
KIS
Bildgebende Systeme
HL7
(DICOM)
HL7
DICOM
Archivierung und Patientenakte
Digitales Bildarchiv (PACS)
DICOM
DICOM
Bildverarbeitung und Befundung
Röntgenfilmbelichter
Befundungsarbeitsplatz
Abbildung 7: Arbeitsteilung der IT im Krankenhaus aus Sicht der Radiologie (nach [Eic08], Bilder aus [125])
Abbildung 7 macht deutlich, zwischen welchen Teilsystemen im Krankenhaus typischerweise DICOM verwendet
wird (dicke rote Linien). Sowohl Abteilungsinformationssysteme (hier: Radiologieinformationssystem, RIS) als
Seite 17
2
GRUNDLAGEN
auch einrichtungsweite Informationssysteme (KIS) unterstützen demnach heute überwiegend kein DICOM; hier
wird meist der andere wichtige Kommunikationsstandard in Krankenhäusern, HL7, zum maschinellen Datenaustausch verwendet.
2.5.1.1 DICOM Conformance Statements
DICOM ist so umfangreich, dass kein medizintechnisches Gerät alle Datenformate und Dienste des Standards
implementiert. Daher wird im DICOM-Standard (in PS 3.2) definiert, wie Hersteller in einem sogenannten
DICOM Conformance Statement“ selbst niederschreiben können, welche Datenformate und Dienste ihre me”
dizintechnischen Geräte unterstützen. Die Idee der Conformance Statements hat sich mittlerweile durchgesetzt,
die Hersteller bildgebender Geräte bzw. mit Bildern in Zusammenhang stehender Software stellen diese nahezu ausnahmslos auf ihren Webseiten oder auf Nachfrage bereit. Eine internationale Zertifizierungsstelle, die
sicherstellt, dass die in den Conformance Statements der Firmen gemachten Angaben korrekt sind, existiert
allerdings nicht; die Idee einer solchen Kontrollinstanz wird ständig wiederkehrend schon seit Ende 1993 unter
dem Stichwort DICOM Police“ diskutiert12 .
”
2.5.2 Geschichtliche Entwicklung
Der DICOM-Standard hat seine Ursprünge 1983 in einer gemeinsamen Anstrengung zweier US-amerikanischer
Berufsverbände: Dem American College of Radiology (ACR) und der National Electrical Manufacturers Association (NEMA). Motivation für einen neuen Standard waren die zahlreichen verschiedenen Dateiformate der
Modalitäten13 zu Beginn der 1980er Jahre. Die erste Version des Standards wurde 1985 unter dem Namen
ACR-NEMA-Standard“ veröffentlicht. Eine starke Einschränkung im Standard war die fehlende Netzwerk”
kommunikation. Eine deutlich erweiterte Version 2.0 des Standards folgte drei Jahre später und verbreitete sich
bereits recht weit, obwohl sie weiterhin keine gängigen Netzwerkstandards unterstützte.
DICOM als Nachfolger des ACR-NEMA-Standards wurde ab 1990 entwickelt und erstmals im Jahre 1993
vorgestellt. Der DICOM-Standard trägt keine Versionsnummer, die verschiedenen Versionen unterscheiden sich
durch ihr Suffix in Form einer Jahreszahl. Um die Herkunft von DICOM aus den ACR-NEMA-Standards
zu verdeutlichen, wird jedoch manchmal auch von DICOM 3.0“ gesprochen. Unter anderem ermöglichte der
”
DICOM-Standard die in ACR-NEMA 1 und 2 vermisste Netzwerkkommunikation über Standardprotokolle
wie OSI-Protokolle oder TCP/IP. Der DICOM-Standard wurde 1995 überarbeitet und wird seit 1999 zumeist
jährlich aktualisiert vom DICOM Standards Committee“ (im Folgenden: DICOM-Komitee) herausgegeben14 .
”
1995 wurde DICOM mit kleinen Änderungen unter dem Namen MEDICOM“ vom CEN/TC 251 auch in Europa
”
als Vornorm verabschiedet und im Jahr 2004 als Europäische Norm (EN) veröffentlicht [CEN04]. Ebenfalls im
Jahr 2004 wurde Teil 18 des DICOM-Standards ( Web Access to DICOM persistent Objects (WADO)“) nahezu
”
unverändert von der ISO/TC 215 als ISO 17432 standardisiert [ISO04]. 2006 wurde der DICOM-Standard
schließlich vollständig (inklusive Teil 18) als ISO 12052 veröffentlicht [ISO06]. Der Standardisierungsprozess
wird dabei weiterhin ausschließlich durch das DICOM-Komitee durchgeführt (vgl. Kap. 2.5.3), ISO 12052 ist
nur eine Referenz auf die jeweils aktuelle, vollständige DICOM-Version. [Oos05, Eic02, Rie06]
Aus dem Umfeld der diagnostischen Radiologie entstanden, verbreitet sich der DICOM-Standard durch die
Aufnahme weiterer Modalitäten in den letzten Jahren zunehmend auf andere klinische Bereiche wie zum Beispiel
die Kardiologie, Strahlentherapie, Chirurgie, Gastroenterologie, Geburtshilfe/Gynäkologie oder Pathologie.
Im Laufe der Jahre wurde der DICOM-Standard an aktuelle Technologien wie beispielsweise Digitales Röntgen,
Optische Kohärenztomographie (OCT), DVD-RAM, MOD, USB-Sticks, MPEG-2, JPEG 2000, PDF und HL7CDA angepasst. Gleichzeitig wurde großer Wert auf die Abwärtskompatibilität des zugrundeliegenden Binärformats gelegt, da die teuren bildgebenden Geräte in der Medizintechnik oft jahrzehntelang betrieben werden und
zudem gesetzliche Archivierungsfristen bis zu 30 Jahren zu berücksichtigen sind [Eic08]. Durch die Erweiterung
des Standards auf weitere Anwendungsbereiche und aktuelle Technologien hat der Umfang von DICOM im
Laufe der Jahre kontinuierlich zugenommen; Abbildung 8 verdeutlicht diese Tendenz.
12 Siehe
http://groups.google.de/group/comp.protocols.dicom/browse_thread/thread/bde08a238dd7ee50/d41e66bf5abfae94
der bildgebenden Medizin steht der Begriff Modalität“ für eine beliebige Art von Gerät, mit der man Bilder (zumeist vom
”
menschlichen Körper) anfertigen kann.
14 Diese Diplomarbeit basiert auf der im Januar 2008 veröffentlichten und zum Zeitpunkt der Erstellung der Arbeit gültigen Version
DICOM 2008 [DIC08a].
13 In
Seite 18
2
GRUNDLAGEN
aben des DICOM-Standards:
750 Seiten
3500
1050 Seiten
3000
1400 Seiten
2500
1500 Seiten
1650 Seiten
2000
1950 Seiten
1500
2100 Seiten
1000
3100 Seiten
500
3300 Seiten
0
3450 Seiten
1993 1996 1998 1999 2000 2001 2003 2004 2006 2007
erantwortlich:
des DICOM-Komitees
Abbildung 8: Entwicklung der Summe der Seitenzahlen des DICOM-Standards [Eic08]
Arbeit:
2.5.3 Standardisierungsprozess
d Correction
Proposals
Die Entwicklung des DICOM-Standards wird, wie oben erwähnt, vom DICOM-Komitee vorangetrieben. An
dieser internationalen Organisation sind, verwaltet von der NEMA Medical Imaging and Technology Alliance“,
”
sowohl die Hersteller der einzelnen Modalitäten, RIS- und PACS-Lösungen als auch die Anwender in Form
der jeweiligen Fachverbände vertreten. Des Weiteren können Standardisierungsgremien und Regierungsämter
stimmberechtigtes Mitglied im Komitee werden. Eine Liste der Mitglieder des DICOM-Komitees findet sich im
World Wide Web [25].
Kolloquium des Instituts für Med. Informatik,
Korrekturen gehen9in Form von Correction Proposals (CP)“, Erweiterungen
in Form
von Supplements (Supp)“
Uni Lübeck,
2008-01-17
”
”
in den Standard ein. Diese Dokumente enthalten jeweils nur die Unterschiede im Vergleich zur derzeit aktuellen
offiziellen DICOM-Version und sind daher für sich allein gesehen oft unverständlich. Der Hauptteil der Arbeit
für die Erweiterung und Korrektur des Standards wird in mehr als 20 sogenannten Working Groups“ erbracht,
”
die vom DICOM-Komitee eingesetzt werden. Einen guten Überblick über die verschiedenen Working Groups
und deren kurz- und langfristigen Ziele bietet [DIC08e].
Die im Laufe des Jahres gesammelten Correction Proposals und Supplements werden Working Group 06 ( Base
”
Standard“) zum Review vorgelegt. Im Falle eines Supplements folgt eine public comment“-Phase mit ab”
schließender schriftlicher Abstimmung (engl.: letter ballot“) über die Aufnahme in den Standard durch die
”
Mitglieder des DICOM-Komitees. Schließlich werden die Änderungen und die akzeptierten Ergänzungen in die
üblicherweise Anfang des Jahres erscheinende aktuelle Version des Standards eingearbeitet.
Die genauen Regularien ( Procedures“) des DICOM-Standardisierungsprozesses sind öffentlich einsehbar [27].
”
Einen guten Einblick in die aktuellen Entwicklungen im DICOM-Standard bieten die Sitzungsprotokolle der
Working Group 6 (WG-06, Base Standard“), die ebenfalls öffentlich einsehbar sind [26].
”
2.5.4 Aufbau des Standards
DICOM folgt einer ISO/IEC-Direktive zum Aufbau von internationalen Standards [ISO97]. In der Version für
das Jahr 2008 besteht der DICOM-Standard aus 16 Teildokumenten PS 3.1 bis PS 3.18 (die Teile PS 3.9
und PS 3.13 sind inzwischen obsolet und wurden aus dem Standard entfernt). Abbildung 9 verdeutlicht die
Beziehung der einzelnen Teile des DICOM-Standards zueinander, während Tabelle 1 noch einmal den Umfang
der jeweiligen Teile verdeutlicht.
Im weiteren Verlauf dieser Arbeit werden PS 3.3 und PS 3.16 ausführlich behandelt. Die anderen Teile spielen
für diese Arbeit eine untergeordnete Rolle und werden hier kurz vorgestellt:
Seite 19
GRUNDLAGEN
Annexes
Part 17: Explanatory Information
Web
Access
Codes &
Templates
Profiles
Part 15: Security and
System Management Profiles
Part 16: Content Mapping Resource
Display
Part 14: Grayscale Standard
Display Function
Media
Storage Interchange
Point to
Point
Print
Network and
Point to Point
Communication
Part 13: Print Management Point to Point
Communication Support
General
Aufbau des DICOM-Standards – Überblick
Part 2: Conformance
Part 6: Data Dictionary
Part 5: Data Structures and Encoding
Part 9:
Point to Point
Communication
Part 8:
Network
Communication
Part 7:
Message Exchange
Part 10:
Media Storage
and File Format
Part 12:
Media Formats and
Physical Media
for Media Exchange
Part 18: Web Access to DICOM
Persistent Objects (WADO)
Part 3: Information Object Definitions
Part 11: Media Storage Application Profiles
Part 4: Service Class Specifications
Part 1: Introduction and Overview
2
Kolloquium
des Instituts für Med. Informatik,
Abbildung 9: Aufbau des DICOM-Standards
[Eic08]
10
Teil
PS 3.1
PS 3.2
PS 3.3
PS 3.4
PS 3.5
PS 3.6
PS 3.7
PS 3.8
(PS 3.9)
PS 3.10
PS 3.11
PS 3.12
(PS 3.13)
PS 3.14
PS 3.15
PS 3.16
PS 3.17
PS 3.18
Titel
Introduction and Overview
Conformance
Information Object Definitions
Service Class Specifications
Data Structures and Encoding
Data Dictionary
Message Exchange
Network Communication Support for Message Exchange
obsolet
Media Storage and File Format for Media Interchange
Media Storage Application Profiles
Formats and Physical Media
obsolet
Grayscale Standard Display Function
Security and System Management Profiles
Content Mapping Resource
Explanatory Information
Web Access to DICOM Persistent Objects (WADO)
Summe:
Uni Lübeck, 2008-01-17
# Seiten
21
342
1097
288
108
106
124
56
–
34
76
55
–
55
80
831
297
22
3592
Tabelle 1: DICOM 2008 – Teile und jeweilige Seitenanzahl (wichtigste Teile für diese Arbeit fett gedruckt)
Seite 20
2
GRUNDLAGEN
PS 3.2 beschreibt, wie DICOM-Conformance-Statements aufgebaut sein und welche allgemeinen Anforderungen konkrete DICOM-Implementierungen erfüllen müssen (vgl. Kap. 2.5.1.1). Diese Fragestellungen
sind erst dann von Interesse, wenn eine fertige DICOM-Lösung vermarktet werden soll. Es ist nicht zu
erwarten, dass das Ergebnis der Diplomarbeit diesen Status erreicht.
PS 3.4 beschreibt die logische Ebene von Diensten ( Services“), die auf den in PS 3.3 beschriebenen
”
Informationsobjekten ausgeführt werden können. In dieser Arbeit geht es im Wesentlichen um das Erstellen
von DICOM-konformen Informationsobjekten. Das Thema DICOM-Dienste wird in Kapitel 2.5.9 und
4.3.4 nur kurz angesprochen. Prinzipiell wird davon ausgegangen, dass DICOM-Dienste (beispielsweise
digitale Signatur oder Langzeitarchivierung) – wenn nötig – über am Markt befindliche Standardwerkzeuge
implementiert werden können.
PS 3.5, 3.6, 3.10 und 3.11 behandeln die unteren Ebenen der Kodierung von DICOM-Objekten. In dieser
Arbeit wird davon ausgegangen, dass die Kodierungsebenen weitgehend sogenannten DICOM-Toolkits“
”
überlassen werden können, die für die verschiedensten Programmiersprachen zur Verfügung stehen (vgl.
Kap. 2.5.10).
PS 3.7, 3.8 und 3.18 beschäftigen sich mit den unteren Ebenen der Netzwerkkommunikation sowie mit
Kodierungsdetails auf der Anwendungsebene, Aspekten, die ebenfalls den DICOM-Toolkits überlassen
werden.
PS 3.12 beschreibt physikalische Datenträger, die in dieser Arbeit keine Rolle spielen.
PS 3.14 betrifft ausschließlich bildliche Medien.
PS 3.15 beschreibt Sicherheitserweiterungen von DICOM, die hier höchstens am Rande erwähnt werden.
2.5.5 Das DICOM-Modell der realen Welt
Das häufig zitierte Entity-Relationship-Diagramm in Abbildung 10 verdeutlicht, welche Objekte (Entitäten) der
realen Welt im DICOM-Standard berücksichtigt und zueinander in Beziehung gebracht werden. Man beachte
den hierarchischen Aufbau der Ebenen Patient“, Study“, Series“ sowie der Ebene mit den Elementen, die
”
”
”
eine Series“ beinhaltet. Jedes Objekt der unteren Ebenen gehört zu exakt einem Vater-Objekt“ der jeweils
”
”
15
höheren Ebene.
Die wichtigsten Objekte im DICOM-Modell der realen Welt seien hier kurz erläutert:
Ein Patient ist ein Mensch oder Tier, der bzw. das Dienstleistungen des Gesundheitswesens beansprucht
oder zukünftig beanspruchen soll. Alternativ kann ein Patient das Betrachtungsobjekt einer oder mehrerer
Untersuchungen zu anderen Zwecken sein. (PS 3.3, Kap. 7.3.1.1 [DIC08a]).
Eine Study (deutsch: Untersuchung) ist die Menge aller Bilder, Befundberichte, Patientenkurven etc., die
für die Bestimmung einer Diagnose erstellt wurden.
Eine Series (deutsch: Folge) ist eine logische Gruppe von Bildern, Befundberichten, Patientenkurven etc.
Insbesondere sollen alle Bestandteile einer Folge von der gleichen Modalität erzeugt worden sein. Weitere
Gruppierungsregeln finden sich in PS 3.3, Anhang A.1.2.3 [DIC08a].
In der untersten Objektebene sei insbesondere auf die folgenden Typen verwiesen (Details siehe PS 3.3, Anh.
A.1.2.6-A.1.2.16 [DIC08a]):
Image beschreibt die Pixeldaten und Farbpaletten eines digitalisierten Bildes. Ein Bild ist in DICOM
immer zweidimensional zu verstehen. Es besteht aber die Möglichkeit, mehrere zusammengehörige zweidimensional strukturierte Pixelmengen, sog. Frames“ (z. B. Schichtbilder einer tomografischen Aufnahme),
”
in einer einzigen Objektinstanz zusammenzuführen. Dies heißt im DICOM-Jargon Multi-Frame Image“.
”
Ein Waveform-Objekt (deutsch: Signalverlauf) beschreibt eindimensionale, in regelmäßigen zeitlichen Intervallen erhobene physikalische Messwerte auf einem oder mehreren Kanälen. Beispiele für Signalverläufe
sind die Daten eines EKGs/EEGs oder der Verlauf des intrathorakalen Druckes bei maschineller Beatmung.
SR Document steht für Structured Report Document“, ein strukturiertes Informationsobjekt (typischer”
weise ein ärztlicher Befundbericht) nach dem DICOM-SR-Standard (vgl. Kap. 2.6).
Eine Objektinstanz vom Typ Encapsulated Document kapselt Dokumente, die nicht in einem DICOMFormat vorliegen, gemeinsam mit zusätzlichen Informationen wie der Herkunft der Dokumente und des
15 DICOM
verwendet nicht die in der Objektorientierung üblichen Begriffe Klasse und Objekt. Stattdessen werden Klassen als
Objekt ( Object“) und Objekte als Objektinstanzen ( Object Instance“) bezeichnet. Der Begriff Klasse“ ist in DICOM für die
”
”
”
Kombination aus Datenstrukturen (Informationsobjekten) und darauf aufgeführten Operationen reserviert ( SOP-Klassen“). In
”
diesem Kapitel wird die DICOM-Terminologie verwendet.
Seite 21
2
GRUNDLAGEN
PS 3.3 - 2008
Page 54
Patient
1
1
makes
has
1-n
1-n
Visit
1
includes
1-n
Study
1-n
Comprised
of
1-n
Modality Performed
Procedure Steps
1
1
includes
contains
1-n
1-n
0-1
Frame of
Reference
1-n
Spatially
Defines
1
1-n
creates
Equipment
Series
1-n
Spatially
Defines
1
contains
1
0-n
0-n
Image
Fiducials
0-n
Registration
0-n
Radiotherapy
Objects
0-n
0-n
SR Document
MR Spectroscopy
0-n
Presentation
State
0-n
Encapsulated
Document
0-n
Waveform
0-n
Raw Data
0-n
Real World
Value Mapping
Figure
7-1a
Abbildung 10: DICOM Model of the
Real-World“
(PS 3.3, Abb. 7-1a [DIC08a])
”
DICOM
MODEL OF THE REAL-WORLD
- Standard -
Seite 22
2
GRUNDLAGEN
Dokumenttitels, so dass diese ebenfalls in DICOM-Archiven abgelegt und über DICOM-Dienste kommuniziert werden können. Unter anderem erlaubt der DICOM-Standard das Einkapseln von PDF- (Supp
104) und HL7-CDA-Dokumenten (Supp 114) [17].
Objektinstanzen vom Typ Presentation State (Supp 33, Supp 100 [17]) beschreiben, wie die Pixelwerte
eines Bildes dem Betrachter präsentiert werden sollen. Beispielsweise kann über einen Presentation State
der anzuzeigende Bildausschnitt, die Fensterung von Grauwerten und/oder der Kontrast angegeben werden. Des Weiteren erlauben Presentation States die Annotation von Bildern mit Text, Vektorgrafiken
(z. B. Punkte, Linien, Ellipsen) oder überlagerten Bitmaps. Supplement 120, das sich kurz vor der Verabschiedung befindet, erweitert die Annotationsmöglichkeiten um diverse standardisierte, zusammengesetzte
Vektorgrafiken wie Pfeile, Skalen und Fadenkreuze und weitere geometrische Figuren. Eine Einführung in
das Konzept der Presentation States bietet [ERK+00].
2.5.6 Logischer Aufbau von DICOM-Informationsobjekten
In diesem Abschnitt wird der logische Aufbau eines DICOM-Informationsobjekts Top-down, also von großen,
übersichtlichen Einheiten hin zu kleinen Details beschrieben.
2.5.6.1 Information Object Definitions (IODs)
Jedes Informationsobjekt wird in DICOM durch eine Information Object Definition“ (IOD) auf standardisierte
”
Weise definiert. In einer IOD wird festgelegt, aus welchen Informationseinheiten ( Information Entities“, IE)
”
des DICOM-Informationsmodells die betrachtete komplexe Datenstruktur aufgebaut ist. Besteht eine IOD aus
einer einzelnen IE, spricht der DICOM-Standard analog zur Datenbankterminologie von einer normalisierten
IOD ( Normalized IOD“), anderenfalls von einer zusammengesetzten IOD ( Composite IOD“). Jede IE besteht
”
”
ihrerseits aus einem oder mehreren Modulen ( Modules“). Für jedes Modul ist festgelegt, welche Attribute
”
( Attributes“) es enthalten darf.
”
Ein normalisiertes Informationsobjekt enthält also nur solche Daten, die inhärent zu dem Objekt der realen
Welt gehören, das es repräsentiert. Wird die Instanz eines solchen Informationsobjekts kommuniziert, so wird
der Kontext in Form von Zeigern auf andere Objektinstanzen übermittelt (PS 3.3., Kap. 6.1.2 [DIC08a]). Dies
ist mit dem call-by-reference“-Konzept in Programmiersprachen vergleichbar. Normalisierte Objektinstanzen
”
kommen verhältnismäßig selten vor und werden im Folgenden nicht weiter berücksichtigt.
Zusammengesetzte Informationsobjekte dürfen hingegen Informationen enthalten, die nicht inhärent im zugehörigen Objekt der realen Welt, sondern in anderen realen Ojekten, die mit dem betrachteten Informationsobjekt in Beziehung stehen, enthalten sind (PS 3.3., Kap. 6.1.1 [DIC08a]). Ein Beispiel hierfür ist das Informationsobjekt Computed Tomography Image“, das nicht nur Informationen über die Pixelwerte des Bildes in sich
”
trägt, sondern auch Informationen zum Patienten, von dem das Bild aufgenommen wurde, zur jeweiligen Untersuchung, zur aktuellen Bildfolge und zum CT-Gerät ( Equipment“), mit dem die Bildsequenz aufgenommen
”
wurde. Zugunsten der Unabhängigkeit der einzelnen Informationsobjekte (die Betrachtung des Informationsobjekt ist völlig isoliert von anderen Entitäten) wird also Redundanz (jedes Bild der beschriebenen CT-Bildfolge
enthält die gleichen Informationen aus den anderen Entitäten) und damit ein höherer Speicherbedarf und die
Gefahr von Inkonsistenzen in Kauf genommen. Bei der Kommunikation einer zusammengesetzten Objektinstanz
werden alle Kontextinformationen mit übertragen. Dies ist vergleichbar mit dem call-by-value“-Konzept bei
”
der Parameterübergabe in Programmiersprachen.
Alle zusammengesetzten IODs (Anhang A.2-A.54), IEs (Anhang A.1.2), Module und deren Attribute (Anhang
C) kann man in PS 3.3 Information Object Definitions“ nachschlagen [DIC08a]. Beispiele für Definitionen von
”
IODs, IEs und Modulen und weitere Erläuterungen finden sich weiter unten in Kapitel 2.6.1 dieser Arbeit.
2.5.6.2 Attribute
Attribute sind die kleinste logische Einheit eines DICOM-Objektes und daher von besonderer Bedeutung. Instanzen eines DICOM-Informationsobjekts bestehen letztlich aus einer hierarchisch flachen Menge von Attributen.
Die Strukturierung in Module und IEs dient lediglich der Spezifikation und ist Objektinstanzen nicht mehr
anzusehen.
Jedes Attribut wird über eine eindeutige 32-Bit-Kennung identifiziert, das sogenannte Attribut-Tag ( Attribute
”
Seite 23
2
GRUNDLAGEN
Tag“). Dieses Tag wird in DICOM stets achtstellig hexadezimal kodiert und in der Form eines geordneten Paares
(gggg,eeee) angegeben. Aus historischen Gründen wird die vordere Komponente des Paares Gruppennummer
( Group Number“) und die hintere Komponente Elementnummer ( Element Number“) genannt; in den alten
”
”
ACR-NEMA-Standards (Version 1 und 2) hatten die Gruppen strukturierende Funktion. In DICOM wurden
zwar die Begrifflichkeiten beibehalten, die Vergabe von Tags orientiert sich aber nicht mehr zwangsläufig an
Gruppen:
Although similar or related Data Elements often have the same Group Number; a Data Group does
”
not convey any semantic meaning beginning with DICOM Version 3.0.“
DICOM PS 3.5, Kap. 7.1 [DIC08a].
Neben dem Tag wird ein Attribut durch seinen Namen, seinen Datentyp und seine Multiplizität beschrieben. Die
27 zulässigen DICOM-Basisdatentypen ( Value Representations“, VR) werden in PS 3.5, Kapitel 6.2, aufgelistet
”
[DIC08a]. Wie viele Werte des entsprechenden Datentyps ein Attribut enthalten darf, schreibt seine Multiplizität
( Value Multiplicity“, VM) vor.
”
Der DICOM-Standard enthält in PS 3.6, dem sogenannten DICOM Data Dictionary“, eine Liste vordefinierter
”
Attribute für die Anwendung im medizinischen Umfeld. Für jedes dieser Attribute wird
das Attribut-Tag, der
PS 3.6-2008
Attribut-Name, der Datentyp und die Multiplizität der Attributwerte angegeben. Abbildung
Page 13 11 zeigt einen
kleinen Ausschnitt aus dieser Liste, die ca. 2.500 Einträge umfasst.
Tag
Name
VR
VM
(0010,0010)
Patient’s Name
PN
1
(0010,0020)
Patient ID
LO
1
(0010,0021)
Issuer of Patient ID
LO
1
(0010,0022)
Type of Patient ID
CS
1
(0010,0030)
Patient's Birth Date
DA
1
(0010,0032)
Patient's Birth Time
TM
1
(0010,0040)
Patient's Sex
CS
1
(0010,0050)
Patient's Insurance Plan Code Sequence
SQ
1
Abbildung
11: Ausschnitt
aus dem
(0010,0101)
Patient’s
Primary Language
CodeDICOM
Sequence Data
(0010,0102)
Dictionary
(PS 13.6 [DIC08a])
SQ
Patient’s Primary Language Code Modifier Sequence
SQ
1
Das Nachschlagen
von Attributen
im DICOM Data Dictionary ist eineLOhäufige Tätigkeit
für Programmierer,
(0010,1000)
Other Patient IDs
1-n
die sich mit den mittleren Kodierungsebenen von DICOM beschäftigen. Für häufiges Nachschlagen im DICOM
(0010,1001)
Other Patient Names
PN
1-n
Data Dictionary
bieten sich
statt der beschränkten Suchfunktionen von
PDF-Betrachtern
webbasierte NachOther Patient [68]
IDs Sequence
1
schlagewerke(0010,1002)
wie die DICOMpedia
oder Offline-Nachschlagewerke SQ
wie das kleine
Tool Java Dicom Buddy
[33] an.
(0010,1005)
Patient's Birth Name
PN
1
(0010,1010)
Patient's Age
AS
1
(0010,1020)
Size unter den Attributen nehmen Attribute
DS
1
Sequenzattribute
Eine Patient's
Sonderrolle
vom Datentyp
Sequence of Items“
”
(SQ) ein. Der
Wert eines
Sequenzattributs
ist eine Liste von Attributmengen
(0010,1030)
Patient's
Weight
DS
1( Items“), die wiederum Se”
quenzattribute
enthaltenPatient's
könnenAddress
[Eic02]. Auf diese Weise kann die prinzipiell
flache
Hierarchie eines DICOM(0010,1040)
LO
1
Informationsobjekts überwunden werden:
(0010,1050)
Insurance Plan Identification
LO
1-n
RET
Zusammengehörige
Attribute
können
in einer Attributmenge gruppiert
werden.
(0010,1060)
Patient's
Mother's
Birth Name
PN
1
Mit Hilfe von verschachtelten Sequenzattributen können baumartige Datenstrukturen realisiert werden.
(0010,1080)
Military Rank
LO
1
Diese Möglichkeit wird insbesondere bei DICOM-SR intensiv genutzt (vgl. Kap. 2.6).
(0010,1081)
Branch of Service
LO
1
(0010,1090)
Medical Record Locator
LO
1
Private Attribute Keine Regel ohne Ausnahme: Das weiter oben stehende Zitat aus dem DICOM-Standard,
(0010,2000)
Medical Alerts
LO
1-n
nach dem die Gruppennummer eines Attributs keine semantische Bedeutung hat, ist so nicht ganz korrekt. Al(0010,2110)
Allergies
LO
le im DICOM Data Dictionary definierten Standard-Attribute haben eine gerade1-n
Gruppennummer. Anwender
Country of Residenceum eigene, private Attribute LO
1
können die (0010,2150)
Liste der Standardattribute
mit ungerader
Gruppennummer erweitern16 . Private
Attribute
werden
im
DICOM-Standard
in
PS
3.5,
Kapitel
7.8,
näher
beschrieben
[DIC08a]. In
(0010,2152)
Region of Residence
LO
1
(0010,2154)
Patient’s
Telephone
Numbers
SH
1-nGroups“ bekannt. Dieser Begriff
Konzept
ist aus Version
1 und
2 der ACR-NEMA-Standards
unter dem Namen
Shadow
”
wird im DICOM-Standard
nicht
mehr
verwendet.
(0010,2160)
Ethnic Group
SH
1
16 Dieses
(0010,2180)
Occupation
SH
1
(0010,21A0)
Smoking Status
CS
1
(0010,21B0)
Additional Patient History
LT
1
- Standard -
Seite 24
2
GRUNDLAGEN
der Praxis werden private Attribute sehr häufig verwendet, man trifft mitunter auf DICOM-Dateien, die nahezu
ausschließlich private Attribute enthalten. Das Einsatzgebiet von DICOM kann durch solche benutzerspezifischen Einträge auch über den medizinischen Bereich hinaus erweitert werden.
Private Attribute haben jedoch auch gravierende Nachteile (vgl. z. B. Kapitel 5.4.2 in [Pia08]). Zum einen behindert der Einsatz von privaten Attributen die semantische Interoperabilität, da private Attribute eben gerade
nicht standardisiert sind. Zum anderen kann es passieren, dass verschiedene Hersteller das gleiche Attribut-Tag
aus dem privaten Bereich für völlig verschiedene Attribute einsetzen. In PS 3.5, Kapitel 7.8.1, wird eine Strategie
vorgestellt, wie solche Kollisionen vermieden werden sollen.
Private Attribute sollen aufgrund der angedeuteten Problematiken in dieser Arbeit nicht näher behandelt werden.
2.5.6.3 UIDs
An vielen Stellen im DICOM-Standard werden weltweit eindeutige Bezeichner ( Unique Identifier“, UID) ver”
wendet, beispielsweise für Konzepte wie SOP-Klassen und Transfersyntaxen. Als Schlüssel für konkrete Untersuchungen oder Bilder dienen ebenfalls UIDs. Jedes Programm, dass DICOM-Objekte erzeugen oder verändern
kann, muss daher auch UIDs erzeugen können.
Die in DICOM verwendeten UIDs sind dem ISO-Standard 8824 [ISO02] entsprechend aufgebaut, der UIDs
als Wege in einer Baumstruktur auffasst. UIDs bestehen demnach aus mehreren Zahlen, die jeweils mit einem
Punkt getrennt werden. Jede Zahl steht für einen zu wählenden Weg an einem Baumknoten. Die Blätter des
Baumes zeigen auf die Objekte. Der HL7-Standard (vgl. Kap. 2.6.6) benutzt das gleiche Format für eindeutige
Bezeichner, dort werden sie jedoch Object Identifier“ (OID) genannt.
”
Eine UID ist logisch in zwei Teile geteilt. Der erste Teil einer UID ist Schlüssel für die verwaltende Organisation
( org root“), der zweite Teil, das Suffix“, ist der Schlüssel für das eigentliche Objekt. Die verwaltende Orga”
”
nisation hat sich darum zu kümmern, nach welchem Prinzip die UIDs im Unterbaum vergeben werden. Alle
im DICOM-Standard definierten UIDs beginnen mit 1.2.840.1000817 . Die UID 1.2.840.10008.5.1.4.1.1.2
beispielsweise bezeichnet die SOP-Klasse CT Image Storage“. Der hierarchische Aufbau von UIDs wird von
”
DICOM nicht systematisch ausgenutzt, man kann also nicht von einer UID auf ihre Semantik schließen. Stattdessen findet sich ein Verzeichnis aller DICOM-UIDs inklusive Verweis auf weitere Informationen im Anhang A
von PS 3.618 . Weitere Informationen zum Aufbau und zur Registrierung von UIDs finden sich in PS 3.5, Kapitel
9 und Anhang C. [DIC08a]
2.5.6.4 Kodierte Merkmalsausprägungen in DICOM
Viele DICOM-Module erlauben den Einsatz von Kodes aus anderen Standards für die Beschreibung von Merkmalsausprägungen. Beispiele dafür sind die Angabe der Muttersprache des Patienten, Kodes für Krankenhäuser,
Einweisungsdiagnosen, angeforderte Prozeduren, anatomische Strukturen etc. Besonders häufig werden kodierte
Elemente im DICOM-SR-Bereich verwendet (vgl. Kap. 2.6).
Wie kodierte Elemente in DICOM dargestellt werden, wird in PS 3.3, Kapitel 8, beschrieben [DIC08a]. Im
einfachsten Fall wird ein Tripel aus einem Kodewert ( Code Value“, z. B. I21.0“), einem Bezeichner für das
”
”
verwendete Kodierungsschema ( Coding Scheme Designator“, z. B. I10“ für ICD-10) und einem Kurztext für
”
”
die Kodebedeutung ( Code Meaning“, z. B. Akuter transmuraler Myokardinfarkt der Vorderwand“) angege”
”
ben. Eine Liste von in DICOM verwendeten Kodierungsschema-Bezeichnern findet sich in PS 3.16, Kapitel 8
[DIC08a], es sind jedoch auch andere Bezeichner zulässig. Für interne oder für den lokalen Gebrauch erstellte
Kodierungsschemata sollen analog zum HL7-Standard Bezeichner verwendet werden, die mit der Zeichenfolge
99“ beginnen. Der Kurztext für die Kodebedeutung ist dann relevant, wenn auf dem System, welches das
”
Dokument anzeigen soll, das jeweilige Kodierungsschema nicht zur Verfügung steht.
Zusätzlich zum genannten Tripel kann die Version des verwendeten Kodierungsschemas ( Coding Scheme Versi”
on“) angegeben werden, falls die Angabe von Kodewert und Kodierungsschema-Bezeichner allein nicht eindeutig
ist. Die in DICOM standardisierten Bezeichner enthalten jedoch großenteils bereits Versionsinformationen.
Stammt der Konzeptname aus einem kontrollierten Vokabular, so kann diese Herkunft über erweiterte Angaben
17 Dieses
18 Für
Präfix soll nicht für selbst erzeugte ( private“) UIDs verwendet werden.
”
häufiges Nachschlagen von DICOM-UIDs bietet sich wiederum die DICOMpedia an [68].
Seite 25
2
GRUNDLAGEN
( Enhanced Encoding Mode Attributes“) verdeutlicht werden (vgl. Visualisierung in Abb. 32).
”
SNOMED als Kodierungsschema in DICOM DICOM erlaubt explizit den Einsatz verschiedener Versionen
von SNOMED als Kodierungsschema für kodierte Elemente. Ursprünglich benutzte der DICOM Standard eine
Untermenge der SNOMED International (Version 3), das SNOMED DICOM Microglossary (SDM, [Bid98b]). Als
Bezeichner für dieses Kodierungsschema wurde 99SDM“ verwendet19 . Später wurden die Bezeichner SNM3“
”
”
für Snomed International (Version 3) und SRT“ für SNOMED-RT eingeführt.
”
Die neueste Version von SNOMED, SNOMED Clinical Terms (SNOMED-CT), wird im DICOM 2007 Standard
nicht explizit erwähnt. Im DICOM Correction Item CP-730 wird jedoch klargestellt, dass eine Verwendung
von SNOMED-CT kein Problem ist [DIC07]. Für SNOMED-CT Kodes soll der Bezeichner SRT“ und die
”
von SNOMED-RT bekannte alphanumerische SnomedId (inklusive Bindestrich) statt der mit SNOMED-CT
eingeführten rein numerischen ConceptId verwendet werden20 . Da alle SNOMED-CT Konzepte sowohl einen
numerischen als auch einen alphanumerischen Kode besitzen, ist dies keine Einschränkung. Im DICOM 2008
Standard sind die Änderungsvorschläge des Correction Item CP-730 bereits eingearbeitet.
2.5.7 Binäre Kodierung von DICOM-Informationsobjekten
Für die Datenspeicherung oder Übermittlung von DICOM-Informationsobjekten werden diese binär kodiert.
Auf die binäre Kodierungsebene soll hier nur kurz eingegangen werden. Dieser Abschnitt soll im Wesentlichen
deutlich machen, dass das Binärformat von DICOM-Informationsobjekten viele Freiheitsgrade hat, was die
Programmierung aufwändig macht. Daher sollte nach Möglichkeit auf fertige Programmbibliotheken ( DICOM”
Toolkits“, s. Kap. 2.5.10) zurückgegriffen werden.
Abbildung 12 skizziert die binäre Kodierung von DICOM-Informationsobjekten. Ein binär kodiertes DICOMAttribut wird auch als Datenelement ( Data Element“) bezeichnet und enthält neben dem Attribut-Tag und
”
einem Feld für Attributwerte noch Informationen zur Länge dieses Wertfelds und optional den Datentyp des
PS 3.5-2008
Attributs. Die aufsteigend nach Tagnummer sortierte Liste aller Datenelemente eines Informationsobjekts
heißt
Page 35
Datensatz ( Data Set“).
”
Data Set
Data Elem.
order of transmission
Data Elem.
Data Elem.
Data Elem.
Data Element
Tag
Value
Length
VR
Value Field
optional field - dependent on
negotiated Transfer Syntax
Abbildung 12: Datenelement ( Data Element“) und Datensatz ( Data Set“) (aus PS 3.5, Abb. 7.1-1)
”
”
Jedem Attribut wird im Data Dictionary“ von PS 3.6 eindeutig ein Datentyp zugeordnet. Insofern kann der
”
Datentyp prinzipiell weggelassen werden ( Implicit VR“).
Wenn
das verarbeitende System keinen Zugriff auf das
Figure
7.1-1
”
DICOM DATA
SEToder
AND neu
DATA
ELEMENT STRUCTURES
DICOM-Dictionary hat oder im Datensatz
private
eingeführte
Attribute verwendet werden, so kann
die Angabe des Datentyps hingegen sinnvoll sein ( Explicit VR“). Mischformen mit expliziter und impliziter
”
7.1.1 DATA
ELEMENT
FIELDS
Angabe der Datentypen
sind
innerhalb
eines Datensatzes nicht zulässig.
19 DICOM
A Data Element is made up of fields. Three fields are common to all three Data Element structures; these
benutzt
Konvention
aus HL7
Version
2, nach
alleField.
Bezeichner
fürfield,
Kodierungsschemata,
die mitis99“
beginnen,
arehier
theeine
Data
Element Tag,
Value
Length,
and der
Value
A fourth
Value Representation,
” only
private Kodierungsschemata
beschreiben;
Bezeichner
für lokale
Kodierungsschemata
beginnen
mit L“.
present
in
the
two
Explicit
VR
Data
Element
structures.
The
Data
Element
structures
are
defined
in
”
20 In einigen Sonderfällen müssen oder können weiterhin die Bezeichner 99SDM“ und SNM3“ verwendet werden. Diese Sonderfälle
Sections 7.1.2. and 7.1.3. The definitions of the fields” are:
”
werden ebenfalls in [DIC07] bei den Änderungen zu PS 3.16, Abschnitt 8.1, erklärt.
Data Element Tag:
An ordered pair of 16-bit unsigned integers representing the Group Number
followed by Element Number.
Value Representation:
A two-byte character string containing the VR of the Data Element. The VR
Seite 26
for a given Data Element Tag shall be as defined by the Data Dictionary as
specified in PS 3.6. The two character VR shall be encoded using characters
from the DICOM default character set.
Value Length:
Either:
2
GRUNDLAGEN
Die Kodierung von Attributwerten ist sehr komplex:
Die Anzahl der Bytes ( Value Length“) für einen Attributwert muss immer grade sein. Welches Zeichen bei
”
ungerader Länge als Füllzeichen verwendet und ob das Füllzeichen vorne oder hinten angehängt werden
kann, ist in der Liste der Basistypen (Tabelle 6.2-1 in PS 3.5 [DIC08a]) nachzulesen.
Bei Zahlenwerten, die aus mehreren Bytes bestehen, unterstützt DICOM verschiedene Byte-Sortierungen
( Little Endian“, Big Endian“, vgl. Kap. 7.3 in PS 3.5).
”
”
Für die Kodierung von Zeichenketten unterstützt DICOM etwa ein Dutzend verschiedene Standards,
darunter ISO 8859 und Unicode mit UTF-8-Kodierung21 .
Bei mehrwertigen Attributen mit einem Datentyp variabler Länge wird der Backslash ( \“) als Trenn”
zeichen zwischen den einzelnen Werten verwendet. Hat das Attribut einen Datentyp feste Länge, so wird
kein Trennzeichen verwendet.
Bilddaten können komprimiert kodiert werden. Dabei werden wiederum verschiedene Verfahren wie eine
in DICOM definierte Lauflängenkodierung (RLE), JPEG (verlustfrei und verlustbehaftet) und JPEG 2000
unterstützt.
Sequenzattribute können entweder mit expliziter Längenangabe oder undefinierter Länge kodiert werden.
Wird die Länge einer Sequenz bzw. ihrer Items nicht angegeben, so zeigt stattdessen ein spezielles Attribut
( Sequence Delimitation Item“ bzw. Item Delimitation Item“) das Ende einer Sequenz bzw. eines Items
”
”
an.
Bei der Kommunikation eines Datensatzes zwischen zwei DICOM-Systemen muss ausgehandelt werden, welche
der vielfältigen oben genannten Kodierungsoptionen verwendet werden. Diese Spezifikation von Kodierungsregeln wird Transfersyntax ( Transfer Syntax“) genannt. Jede DICOM-Anwendung muss mindestens die DICOM
”
”
default Transfer Syntax“ ( Implicit VR Little Endian“, keine Bilddatenkompression) unterstützen.
”
Beim Speichern von DICOM-Datensätzen in eine Datei kann keine Transfersyntax mit dem Zielsystem ausgehandelt werden. In diesem Fall werden Informationen zur verwendeten Transfersyntax in einen zusätzlichen
sogenannten File Meta Information“-Header geschrieben, der seinerseits mit der Transfersyntax Explicit VR
”
”
Little Endian“ kodiert ist. Binär kodierte DICOM-Dateien lassen sich verhältnismäßig übersichtlich mit dem
kostenlosen Sante DICOM HEXViewer“ betrachten [97].
”
2.5.8 XML-Kodierung von DICOM-Informationsobjekten
Betrachtet man die komplizierten Kodierungsregeln für das DICOM-Binärformat, drängt sich aus heutiger Sicht
die Frage auf, ob man DICOM-Informationsobjekte mit ihren üblicherweise zahlreichen Metainformationen
nicht besser in einem XML-Format speichern sollte. Für XML spräche unter anderem die bessere Lesbarkeit
kodierter Information durch menschliche Benutzer, die weite Verbreitung auch in anderen Fachdisziplinen, die
Verfügbarkeit von Standardwerkzeugen für die Erzeugung und Verarbeitung und die direkte Unterstützung
in zahlreichen Programmiersprachen. Tatsächlich gibt es etliche Vorschläge, wie allgemeine DICOM-Strukturen
oder zumindest bestimmte Arten von DICOM-Informationsobjekten in XML kodiert werden könnten [BSB+01,
THL02, LH03, Bru05]. Ein offizielles, durch das DICOM-Komitee verabschiedetes XML-Format für DICOMInformationsobjekte gibt es jedoch nicht. Als Begründung dafür werden folgende Gründe genannt:
Für die großen Datenmengen medizinischer Bilder ist ein Binärformat besser geeignet als XML.
Das DICOM-Binärformat kann aus Gründen der Abwärtskompatibilität zunächst nicht abgeschafft werden
(Aufbewahrungsfrist für medizinische Daten ca. 30 Jahre).
Das DICOM-Komitee möchte nicht zwei offizielle Repräsentationen für DICOM-Informationsobjekte pflegen. Jedem Anwendungsprogrammierer ist freigestellt, intern ein eigenes XML-Format zu verwenden.
2.5.9 Netzwerkdienste mit DICOM
In diesem Abschnitt soll ein kurzer Überblick über die DICOM-Netzwerkkommunikation gegeben werden. Die
folgenden Ausführungen gelten für alle DICOM-Informationsobjekte, also auch für die in dieser Arbeit behandelten DICOM-SR-Dokumente.
21 Bei
Verwendung eines Zeichensatzes mit mehreren Kodeseiten, kann innerhalb einer Zeichenkette zwischen diesen umgeschaltet
werden. Auch die Erweiterung eines Zeichensatzes um eigene Zeichen ist möglich.
Seite 27
2
GRUNDLAGEN
Begriffsdefinitionen Dienste werden im DICOM-Jargon analog zur Begriffsverwendung in der Objektorientierung Service-Klassen ( Service Classes“) genannt, da sie die zulässigen Operationen (Methoden) auf festgelegten
”
Datenstrukturen (DICOM-Informationsobjekten) beschreiben.
Im DICOM-Jargon wird ein Dienstanbieter als Service Class Provider (SCP) bezeichnet. Ein Computerprogramm, das Dienste eines SCP in Anspruch nimmt, wird Service Class User (SCU) genannt. Diese Begriffe
entsprechen den sonst in der Informatik üblichen Begriffen Server“ und Client“. Eine Verbindung zwischen
”
”
SCU und SCP wird im DICOM-Standard Association“ genannt.
”
Die Rollen von SCU und SCP können bei jedem DICOM-Kommando anders verteilt sein, was bei der Erläuterung
von DICOM-Kommunikation oftmals zu Verwirrung führt. Im Folgenden sollen daher zwei weitere Begriffe verwendet werden:
Als DICOM-Server“ wird in dieser Arbeit eine Systemkomponente aus Software und möglicherweise
”
dedizierter Hardware verstanden, die klassische PACS-Funktionalität erfüllt, also Bilder DICOM-konform
archiviert und über ein Computernetzwerk zugreifbar macht.
Als DICOM-Anwendung“ wird ein Softwaresystem oder ein System aus Hard- und Software verstanden,
”
das Bilder auf dem DICOM-Server ablegt (z. B. Software der Modalität CT“) oder auf Bilder des PACS
”
zugreift (z. B. Befundungssoftware auf einem klinischen PC-Arbeitsplatz).
Verbindungsaufbau Eine DICOM-Association entspricht im Wesentlichen einer TCP-Netzwerkverbindung
zwischen SCU und SCP. Allerdings findet auf DICOM-Netzwerkebene zusätzlich eine ausführliche Verhandlung
statt, welche SOP-Klassen und zusätzlichen Optionen auf beiden Seiten unterstützt werden. Zu den Optionen
gehört beispielsweise die sog. Transfersyntax, die die Byte-Reihenfolge (Big Endian, Little Endian) und etwaige
Kompressionsalgorithmen (JPEG, MPEG,...) vorgibt.
DICOM Query/Retrieve Service Class Ein Standard-Anwendungsfall für DICOM-Netzwerkdienste ist die
Suche nach Bildern mit einem bestimmten Kriterium in einem Bildarchiv und deren anschließende Übertragung
vom DICOM-Server zu einer DICOM-Anwendung. Dieses Szenario wird durch die Service-Klasse Query/Re”
trieve“ realisiert (PS 3.4, Anhang C [DIC08a]).
Das Dienstprimitiv für die Suche heißt C-FIND (das C steht für Composite, Bilder sind Composite-Objekte).
Beim Aufruf von C-FIND übergibt der Client (SCU) einen Datensatz mit DICOM-Attributen an den Server
(SCP). In diesem Datensatz werden zwei Arten von Attributen ( Request Identifier“) unterschieden [64]:
”
Attribute mit Werten beschreiben einen Filter, der auf die DICOM-Objekte des Servers angewandt werden
soll. Es sollen also diejenigen DICOM-Objekte in die Suchantwort aufgenommen werden, deren Attribute mit den Filterattributen übereinstimmen (vgl. WHERE-Angabe im SQL-SELECT-Statement). Dabei
können die üblichen Platzhalter * und ? verwendet werden, es ist also keine exakte Übereinstimmung der
Attributwerte erforderlich. Für Zeit- und Datumsangaben kann man Zeiträume über Start- und Endzeit
bzw. -datum angeben. Eine genaue Beschreibung, wie bei C-FIND auf Übereinstimmung von Attributwerten geprüft wird, findet sich in Anhang C.2.2.2 von PS 3.4 [DIC08a].
Attribute ohne Wert (leere Attribute) beschreiben, welche Attribute zusätzlich vom C-FIND SCP für jedes
gefundene Objekt zurückgegeben werden sollen (vgl. Angabe der Spalten im SQL-SELECT-Statement).
Der DICOM-Standard definiert drei Vorgehensmodelle für die Suche in DICOM-Archiven ( Standard Que”
ry/Retrieve Information Models“, vgl. PS 3.4, Anhang C.3 [DIC08a]):
Patient Root
Study Root
Patient/Study Only (mit Version 2006 des DICOM-Standards als obsolet gekennzeichnet)
In allen drei Modellen wird der hierarchische Aufbau des DICOM-Informationsmodells (siehe Abb. 10 bzw. 14)
ausgenutzt, was an die Hierarchischen Datenbankmodelle aus den 1970er-Jahren erinnert. Das Abfragemodell
Patient Root“ startet bei der Suche auf der obersten Hierarchieebene und identifiziert dort über die Patient ID“
”
”
die gewünschte Objektinstanz. Anschließend kann die gesuchte Composite-Objektinstanz über die eindeutigen
Schlüssel der niedrigeren Ebenen ( Study Instance UID“, Series Instance UID“ und SOP Instance UID“) bzw.
”
”
”
bei Fehlen eines Schlüssels über andere Suchparameter der jeweiligen Hierarchieebene identifiziert werden. Das
Abfragemodell Study Root“ startet mit der Suche auf der Ebene Study“ und verhält sich ansonsten genauso.
”
”
Seite 28
2
GRUNDLAGEN
Das Modell Patient/Study Only“, das nicht mehr verwendet werden soll, berücksichtigte nur die obersten
”
beiden Ebenen, eine Suche nach Bildern ist mit diesem Modell also nicht möglich.
In der Radiologie, die der Motor für die DICOM-Entwicklung ist, herrscht üblicherweise ein untersuchungszentrierter Arbeitsablauf. Daher unterstützen die meisten PACS-Systeme und DICOM-Toolkits zumindest das
Study Root“-Abfragemodell. Patienteninformationen werden bei diesem Modell als Attribute der Untersuchung
”
und nicht als eigene Informationseinheit verstanden.22
Nachdem ein geeignetes Bild ausgewählt ist, soll dieses vom DICOM-Server abgerufen werden. Dafür bietet der
DICOM-Standard zwei Dienstprimitive an: C-MOVE und C-GET.
C-MOVE veranlasst den DICOM-Server, seinerseits als SCU eine C-STORE-Verbindung zu einer anderen DICOM-Anwendung ( Application Entity“, AE) aufzubauen. Dabei kann der Endpunkt dieser Verbindung die
”
gleiche Anwendung sein, die den C-MOVE-Befehl initiiert hat – dies ist sogar der Regelfall. Wie [64] darstellt,
hat der C-MOVE-Befehl entscheidende Nachteile:
Da im C-MOVE-Befehl als Argument für die empfangende AE lediglich deren Name ( Application Entity
”
Title“, AET), eine bis zu 16 Zeichen lange Folge von ASCII-Zeichen, angegeben wird, muss der DICOMServer vorab die zum Namen gehörige IP-Adresse und Portnummer kennen. Üblicherweise geschieht die
Zuordnung von AET zu IP-Adresse und Port statisch in einer Konfigurationsdatei des DICOM-Servers
(vgl. Abb. 40).
Außerdem muss sichergestellt sein, dass der DICOM-Server die DICOM-Anwendung über die angegebene
Netzwerkadresse erreichen kann. Dabei können zum Beispiel dynamische IP-Adressen, zwischengeschaltete
NAT-Router oder zu strenge Firewall-Einstellungen problematisch sein.
Ein Vorteil der von C-MOVE erzwungenen Vorgehensweise ist hingegen, dass der Administrator des DICOMServers über die Zuordnungsliste von AEs zu Netzwerkadressen bereits implizit eine Art Zugriffsschutz in der
Hand hat, mit dem nicht-authorisierte DICOM-Anwendungen ausgesperrt werden können.
C-GET wickelt im Gegensatz zu C-MOVE die Anfrage nach einem Bild und dessen Übertragung über die gleiche
Netzwerkverbindung ab.
Nahezu alle DICOM-Server unterstützen das C-MOVE Dienstprimitiv für die Übertragung von Bildern, da
dieser Dienst auch in anderen Zusammenhängen gebraucht wird. C-GET-Funktionalität wird nur in seltenen
Fällen angeboten.
2.5.10 DICOM-Toolkits
Die Erstellung von Software, die DICOM-konforme Daten lesen und/oder schreiben kann bzw. DICOM-konforme
Dienste anbietet und/oder nutzt, ist aufgrund der Komplexität des DICOM-Standards (vgl. Tab. 1) ein mühsames
Unterfangen. Natürlich kann man versuchen, diese Herausforderung anzunehmen:
If your brain power seriously outweighs your budget, you might be tempted to develop some DICOM
”
programming from scratch.“ [Pia08]
Eine von Grund auf neu entwickelte DICOM-Lösung wird jedoch in der Regel nur eine stark eingeschränkte
Funktionalität bieten können ( Bild A kann gelesen werden, Bild B aber leider nicht“) oder aber jahrelange
”
Entwicklungsarbeit erfordern. Zahlreiche Firmen und Forschungseinrichtungen haben dieses Problem erkannt
und bieten dem Anwendungsprogrammierer Bibliotheken zur DICOM-Entwicklung an, die DICOM Toolkits“
”
oder DICOM SDKs“ genannt werden (im Folgenden: Toolkits“). Toolkits bilden die in DICOM verwendeten
”
”
Datenstrukturen auf typischerweise stärker abstrahierte Datenstrukturen der jeweiligen Programmiersprache ab
und bieten Funktionsbibliotheken für häufig benötigte Problemstellungen.
Bestandteile von DICOM-Toolkits
Gängige Toolkits bieten unter anderem:
Funktionen zum Lesen und Schreiben von zum Beispiel
22 Anmerkung:
Der Arbeitsablauf in der Pathologie ist typischerweise probenzentriert. Informationen zu Proben werden in DICOM
aber bisher der Informationseinheit Patient“ zugeordnet. Für pathologische Anwendungen benötigte man also das Patient
”
”
Root“-Abfragemodell. Dieses Problem wird mit dem frisch verabschiedeten Supplement 122 beseitigt, das die Informationen zu
Proben der Informationseinheit Image“ zuordnet (vgl. Kap. 2.5.11).
”
Seite 29
2
GRUNDLAGEN
– Metainformationen im Header einer DICOM-Datei
– DICOM-Bilddateien verschiedener Modalitäten und Transfersyntaxen (vgl. Kap. 2.5.7)
* Unterstützung verschiedener Kodierungsschemata (Big Endian, Little Endian etc.)
* Unterstützung der in DICOM zugelassenen Kompressionsalgorithmen (RLE, JPEG etc.)
–
–
–
–
Presentation-States (vgl. Kap. 2.5.5)
DICOM-Signalverläufen (sog. waveforms“, selten)
”
DICOM-SR-Dokumenten (selten; vgl. Kap. 2.6)
ACR-NEMA-Dateien (Version 1 und 2), dem Vorgängerformat von DICOM
Funktionen für die Anzeige von Bildern, zum Beispiel
– Unterstützung verschiedener Farbpaletten
– Unterstützung von Fensterung bei der Darstellung von Bildern (z. B. Hounsfield-Werte)
– Fertige Komponenten für grafische Benutzeroberflächen von Bildbetrachtungsprogrammen
Funktionen für das Versenden und Empfangen von DICOM-Dateien und -Nachrichten über Computernetzwerke
Funktionen für die Suche von Objekten in DICOM-Archiven
Funktionen für die Erstellung DICOM-konformer Datenträger (sog. DICOM Storage Media“)
”
Funktionen für das Einlesen von Bilddaten über externe Geräte (z. B. Scanner)
Funktionen zum Signieren von DICOM-Dateien bzw. zum Prüfen der Signatur (selten)
Funktionen zur Manipulation von DICOM-Datenstrukturen auf niedriger Abstraktionsebene (z. B. Unterstützung bei der Erstellung und dem Auslesen von Sequenzattributen, vgl. Kap. 2.5.7)
Logging-Funktionen
Eine maschinenlesbare Version des sogenannten DICOM-Dictionary“ (vgl. DICOM PS 3.6 [DIC08a])
”
Eine maschinenlesbare Version der Kontextgruppen in DICOM PS 3.16 (selten; vgl. Kap. 2.6.3 und 4.1)
Kommandozeilenprogramme zum Testen
Der Funktionsumfang der Toolkits variiert erheblich. Zahlreiche Toolkits beschränken sich auf einen speziellen
Ausschnitt der DICOM-Welt, häufig auf die Bildanzeige und -bearbeitung oder die Netzwerkkommunikation.
Aussagen der Hersteller wie 100% DICOM complete and compliant“ sollten daher ebenso skeptisch hinterfragt
”
werden wie Behauptungen, dass ein Toolkit industry leading“ sei.
”
Lizensierungskosten Kommerzielle Toolkits bieten meist Entwicklerlizenzen für einige hundert Euro an, die
auf einem einzigen Arbeitsplatz verwendet werden dürfen. Für die Verbreitung von Software, die auf das jeweilige Toolkit aufsetzt, müssen entweder eine unbeschränkte Runtime-Lizenz für typischerweise einige tausend
Euro oder rechnerbezogene Runtime-Lizenzen für jeweils einige zig Euro erworben werden. Es gibt aber auch
zahlreiche kostenlose Toolkits der Open-Source-Gemeinde mit zum Teil beachtlichem Umfang und guter Kodequalität.
Programmiersprachen und Plattformen Native“ Toolkits gibt es vor allem für Nutzer der Programmier”
sprachen C/C++ und Java sowie der Microsoft .NET-Plattform. Die Auswahl an Toolkits für die Programmiersprache C/C++ ist tendenziell am größten, neue Projekte setzen jedoch zunehmend auf managed code“.
”
Viele Toolkits sind auf Plattformunabhängigkeit ausgelegt. Gängig ist auch die Verbreitung eines Toolkits als
COM-Objekt [71], was die Nutzung des Toolkits auf Windows-Betriebssysteme beschränkt aber die Auswahl
der Programmiersprache auf alle COM-fähigen Sprachen erweitert.
Eine übersichtliche Liste kommerzieller wie freier DICOM-Toolkits existierte zum Zeitpunkt der Erstellung dieser
Diplomarbeit nicht – bestehende Toolkit-Listen sind mit reinen DICOM-Viewern und -Konvertern durchmischt,
veraltet und/oder nicht nach Programmiersprache sortiert. Der Autor dieser Arbeit hat daher eine eigene Liste
mit ca. 40 Toolkits begonnen, die als Webseite im Internet verfügbar ist [99]23 . Auf der Webseite finden sich
auch Verweise auf weitere Verzeichnisse von Toolkits.
23 Eine
vollständige Aufnahme der Liste in den Anhang dieser Arbeit hätte das Quellenverzeichnis gesprengt; außerdem birgt die
Veröffentlichung als Webseite nach Auffassung des Autors einen größeren Nutzen für die DICOM-Community.
Seite 30
2
GRUNDLAGEN
2.5.11 Einsatz von DICOM in der Pathologie
Der DICOM-Standard ist zum Zeitpunkt der Erstellung dieser Diplomarbeit für den Einsatz in der Pathologie
nicht geeignet. Folgerichtig ist DICOM in dieser Fachdisziplin noch nahezu unbekannt und wird nicht im Routinebetrieb eingesetzt. Die Defizite von DICOM und die aktuellen Entwicklungen in den Standardisierungsgremien
werden im Folgenden genauer erläutert.
Die für die Pathologie notwendigen Korrekturen und Erweiterungen von DICOM werden seit Ende 2005 von
der für diesen Zweck gegründeten DICOM Working Group 26: Pathology“ (im Folgenden: WG-26“) vorange”
”
trieben.
Für den sinnvollen Einsatz von DICOM in der Pathologie sind laut WG-26 folgende Aufgaben zu bewältigen
([DIC08e], S. 35 f.):
Schaffung technischer Standards für die Bildgewinnung, -anzeige, -kommunikation und -speicherung in der
Pathologie (sowohl für den klinischen Bereich als auch für die Forschung)
Anpassung des DICOM Informationsmodells an den gewebeprobenzentrierten Arbeitsablauf in der Pathologie im Unterschied zum sonst üblichen, patienten- oder untersuchungszentrierten Arbeitsablauf
Entwicklung von Methoden zur Integration von Bildern und daraus abgeleiteten Informationen für die
Befundschreibung
Entwicklung spezieller technischer Methoden zur Lösung pathologiespezifischer Probleme, wie zum Beispiel
zur Kompression von Bildern mit einer Datenmenge von mehreren Gigabyte
Kurzfristig sollen folgende Probleme gelöst werden:
Definition neuer bzw. Erweiterung bestehender DICOM Information Object Definitions (IODs) für den
Einsatz in der Pathologie. Dazu zählen:
–
–
–
–
Makroskopische Bilder
Mikroskopische Bilder
Multispektralbilder
Bild-Annotationen (z. B. Umrisslinien, Messungen)
Zugriff auf Bildobjekte mit einem Datenumfang von mehreren Gigabyte unter verschiedenen Auflösungen.
Der erste Punkt wird vor allem in Supplement 122 behandelt24 . Für den zweiten Punkt gibt es derzeit noch
kein Supplement, aber rege Diskussionen. Beide Punkte werden im Folgenden diskutiert.
2.5.11.1 Supplement 122
Ein wichtiges Ergebnis der Arbeit von WG-26 ist Supplement 122 Specimen Identification and Revised Patho”
logy“ [17]. Supplement 122 führt unter anderem folgende Neuerungen ein:
Der Informationseinheit Image“ wurde ein Modul Specimen“ hinzugefügt. In diesem Modul können alle
”
”
Informationen zur Herkunft und zu den Bearbeitungsschritten der Probe gespeichert werden, die für die
Interpretation des Bildes notwendig sind. Das Modul löst das bisherige Specimen Identification Module“
”
auf Patientenebene ab25 . Es wurde mit dem HL7 v2.5 SPM-Segment und dem Entwurf zum HL7 v3
Specimen Domain Information Model“ harmonisiert.
”
Das vielzitierte DICOM-Modell der realen Welt (vgl. Abb. 10) wurde um einige Objekte erweitert (siehe
Abb. 13).
Drei neue IODs Specimen VL Microscopic“, Specimen VL Slide-Coordinates Microscopic“ und Speci”
”
”
men Video Microscopic“ wurden in den Standard aufgenommen.
Einige DICOM-interne Kodes (Kodierungsschema-Bezeichner DCM“, s. u.) für Proben wurden auf SNO”
MED-Kodes [52] abgebildet.
Ein kontrolliertes Vokabular ( Kontextgruppen“, vgl. Kap. 2.6.3) für den Umgang mit Proben wurde er”
stellt (Probentypen, Probengewinnung, Verarbeitungsschritte, Färbungen, Einbettungsmedien etc.). Dabei wurde größtenteils auf SNOMED [52] zurückgegriffen. Falls keine SNOMED-Kodes für ein Konzept
existieren, wurde auf ein privates Kodierungsschema (vorläufiger Bezeichner: 99supp122) zurückgegriffen.
24 Das
Thema Bild-Annotationen wird von WG-11 Display Function Standard“ in Supplement 120 bearbeitet [17].
”
interessanter Nebeneffekt: Dadurch entfallen die Angaben zum Specimen in DICOM-SR-Dokumenten (diese beinhalten keine
Image IE, s. u.).
25 Ein
Seite 31
2
GRUNDLAGEN
DICOM-SR-Templates (vgl. Kap. 2.6.4) für die Lokalisation von Proben und die Verarbeitung von Proben
(speziell: Färben und Einscannen) wurden definiert.
Patient
1
1
Is
source
of
Has
n
Study
n
1
Contains
n
Equipment
n
1
Series
Creates
Modality
1
Contains
n
Image
1
Is
acquired
on
1
Component
Base, Coverslip
1
n
Has
Container
Box, Block, Slide, etc.
n
1
Specimen
Contains
Physical object
n
n
1
Has
Preparation
Step
Collect, Sample,
Stain, Process
1
Is child of
Abbildung 13: Erweiterung des DICOM-Modells der realen Welt für die Pathologie, Erweiterungen hervorgehoben (aus Supp. 122 [17])
Supplement 122 wurde nach einer Sitzung der DICOM WG-06 Ende Juni 2008 endgültig verabschiedet [DIC08f]
und wird damit in die nächste DICOM-Version integriert.
2.5.11.2 Speicherung virtueller Präparate mit DICOM
Wenn es ein DICOM-Format für virtuelle Präparate gäbe, könnten Standard-PACS-Systeme für deren Speicherung, die langfristige Archivierung, die Suche und Managementfunktionen verwendet werden. Eine gemeinsame
Verwaltung mit Bildern anderer Modalitäten scheint sowohl organisatorisch als auch technisch und wirtschaftlich
erstrebenswert. Die DICOM-konforme Speicherung von Bildern aus der Pathologie ermöglicht zudem weitere
Anwendungen. Dazu zählen laut WG-26:
Strukturierte und standardisierte Befundung in der Pathologie (Fokus dieser Diplomarbeit)
Integration von Werkzeugen zur automatischen Bildanalyse in virtuellen Präparaten (ebenfalls wichtig in
dieser Arbeit)
Korrelation von radiologischen mit pathologischen Bildern
Umgang mit Tissue Micro Arrays (TMAs), bei denen ein Objektträger Merkmale von hunderten von
Patienten enthalten kann
Supplement 122 schafft wie oben beschrieben Grundvoraussetzungen für die Speicherung von pathologischen
Bild- und Metadaten sowie das Erstellen von pathologischen Befundberichten. Das wichtige Problem der riesigen Datenmengen von virtuellen Präparaten (vgl. Kap. 2.2.2) wird in Supplement 122 nicht behandelt, WG-26
beschäftigt sich jedoch unter dem Schlagwort Whole Slide Imaging“ (WSI) intensiv mit diesem Thema. Ei”
ne verständliche, umfangreiche Schilderung des Problemkontextes und der speziellen Unzulänglichkeiten des
DICOM-Standards sowie eines informellen Lösungsvorschlags findet sich in [Eic07].
Seite 32
2
GRUNDLAGEN
Die WG-26 rechnet demnach für die Gestaltung eines geeigneten DICOM-Formates mit einer Auflösung von
0,1µm/Pixel ( 100x-Vergrößerung“), einer Probengröße von 50mm x 25mm und zehn verschiedenen Fokussie”
rungsebenen ( z-Ebenen“). Derartige virtuelle Präparate hätten Ausmaße von 500.000 x 250.000 Pixeln (125
”
Gigapixel) und wären damit größer als das derzeit größte bekannte zusammengesetzte Digitalfoto (16 Gigapixel [39]). Bei drei Byte pro Pixel ergäbe sich für dieses Szenario ein unkomprimierter Speicherbedarf von 3,75
Terabyte. Um auf derartig große Bilder effizient zugreifen zu können, sieht WG-26 den bereits in Kapitel 2.2.2
diskutierten Pyramiden-Ansatz vor.
[Eic07] nennt einige Beschränkungen des DICOM-Standards, die bei der Speicherung virtueller Präparate hinderlich sein können:
Die Pixelabmessungen eines DICOM-Bildes werden in einer vorzeichenlosen 16-Bit-Integervariable gespeichert, was die maximale Dimension eines Bildes auf 65.535 x 65.535 Pixel begrenzt (größte darstellbare
Zahl: 216 − 1 = 65.535).
Die Größe eines DICOM-Objekts in Byte wird in einer vorzeichenbehafteten 32-Bit-Integervariable gespeichert. Die maximale komprimierte Datenmenge eines Bildes beträgt damit 231 − 1 = 2.147.483.647
Byte (≈ 2GB).
DICOM bietet zwar Möglichkeiten für die Adressierung einzelner Bilder einer Bildsequenz, wie sie beispielsweise in CT- oder MRT-Geräten erzeugt wird. Eine Möglichkeit zur Adressierung eine Bildausschnittes
innerhalb eines einzelnen Bildes existiert jedoch nicht26 . Die Auswahl von Bildausschnitten ist jedoch
entscheidend für schnelles Zoomen und Verschieben des Sichtfeldes“.
”
Das Dokument nennt gleichzeitig jedoch auch die Lösung der genannten Probleme: Jede Ebene der gedachten
Pyramide soll - wie ebenfalls bereits in Kapitel 2.2.2 (Abb. 5(b)) erläutert – in Kacheln aufgeteilt werden. Die
Größe dieser Kacheln muss so klein gewählt werden, dass die in der Aufzählung genannten Grenzen unterschritten werden. Alle Kacheln einer Ebene sollen dann in einer DICOM-Bildsequenz ( Series“) zusammengefasst
”
werden. Eine andere Lösung für die genannten Probleme wurde im Mai 2008 als CP 896 eingereicht: Hier soll
für Bilder, die in der Höhe oder Breite die genannten Dimensionen überschreiten, ein neu eingeführtes Attribut Large Rows“ bzw. Large Columns“ mit Datentyp UL (Unsigned Long, 32-Bit-Wert) verwendet werden
”
”
[DIC08c]. Diese Änderung beträfe zahlreiche Kapitel des DICOM-Standards. Welcher der beiden Ansätze sich
durchsetzen wird, ist zur Zeit unklar.
Das zitierte Positionspapier [Eic07] wurde auf den letzten Treffen der WG-26 weiter diskutiert. So soll zusätzlich
zu den in hoher Auflösung aufgenommenen Bilddaten ein Übersichtsbild des kompletten Objektträgers sowie ein
Bild der Etikette (mit ID/Barcode) in die virtuellen Präparate integriert werden. Außerdem wird diskutiert, ob
innerhalb der Bilder Bearbeitungsschritte wie die Reduzierung der Farbtiefe oder die Kompression gespeichert
werden sollen [DIC08b]. Wann aus dem Positionspapier ein Supplement wird, ist derzeit nicht absehbar.
2.5.12 Informationsquellen zum DICOM-Standard
Einführende Literatur Die Komplexität des DICOM-Standards (vgl. Tab. 1) macht das Lesen einführender
Literatur erforderlich. Der Herkunft des Standards aus der Industrie mag geschuldet sein, dass solche nur in
sehr begrenztem Maße der Öffentlichkeit zur Verfügung steht. Die ansonsten empfehlenswerte, umfangreiche
Linksammlung von David Clunie [16] listet nur eine Handvoll allgemeiner Publikationen zu DICOM, die häufig
auch noch schwierig erhältlich sind oder dem Anspruch eines Überblickswerks nicht gerecht werden. Hier eine
kurze Liste spezieller DICOM-Literatur:
Das mittlerweile in überarbeiteter dritter Auflage erhältliche Buch DICOM Basics“ von Herman Oos”
terwijk [Oos05] kann am ehesten als einführendes Werk gelten. Es ist allerdings (trotz ISBN) nicht im
regulären Buchhandel erhältlich. Die Beschreibung ist sehr anwendungsorientiert und bleibt größtenteils
oberflächlich, bietet aber gerade deswegen einen gewissen Überblick.
Das seit Juni 2008 erhältliche Buch DICOM – A Practical Introduction and Survival Guide“ [Pia08] ist
”
umfangreicher und bietet mehr technische Details als DICOM Basics“, stand dem Autor zum Zeitpunkt
”
der Erstellung dieser Arbeit jedoch nicht vollständig zur Verfügung27 .
Das nicht nur bei Clunie zitierte DICOM Cook Book“ von Philips Medical Systems ist inzwischen in
”
26 Eine
Ausnahme bilden JPEG-2000-Objekte, die in DICOM via JPIP angesprochen werden können, vgl. DICOM Supplement 61,
105 und 106 [17].
27 Der Zugriff auf dieses Werk ist eingeschränkt über die search inside“-Funktion von Amazon möglich [3].
”
Seite 33
2
GRUNDLAGEN
Teilen veraltet. Es beschränkt sich auf die technische Ebene von DICOM und setzt daher einiges an
Wissen voraus.
Die im Internet verfügbare Nontechnical Introduction to DICOM“ von Steven C. Horii [Hor97] ist eben”
falls teilweise deutlich überholt und zudem sehr knapp gehalten.
Im DICOM-Standard selbst [DIC08a], PS 3.1, findet sich eine kurze Einführung in den Standard. Diese nennt die Ziele des DICOM-Standards und beschreibt die einzelnen Kapitel, bleibt dabei aber sehr
oberflächlich.
Einen häufig aktualisierten, allgemeinen Überblick bietet das DICOM-Komitee als Strategic Document“
”
selbst auf ihren Webseiten an [DIC08e]. Die Beschreibung ist aber sehr kurz und behandelt vor allem
organisatorische, weniger inhaltliche Aspekte.
Überblicksartikel zum DICOM-Standard, die mindestens einen Aspekt von DICOM näher beleuchten, finden
sich typischerweise in den Grundlagenkapiteln wissenschaftlicher Abschlussarbeiten. So führt M. Eichelberg in
seiner Dissertation [Eic02] ausführlich in den Standard ein und beschreibt den Aufbau von DICOM-Dateien
sowie die DICOM-Dienste. J. Riesmeier lehnt sich in seiner Dissertation [Rie06] an diese Einführung an, die
Informationen sind jedoch aktueller und auf das Maß beschränkt, das für das Verständnis von DICOM-SR
erforderlich ist.
Weitere Informationsquellen Neben herkömmlicher Literatur wird der interessierte Leser alternative Informationsquellen benötigen. Sehr empfehlenswert ist die offizielle DICOM-Webseite [73], die neben dem Standard
selbst beispielsweise auch Informationen zum Standardisierungsprozess, eine Liste der Supplements und Correction Items [17] sowie Links zu DICOM-Software und anderen weitergehenden Informationen anbietet. Ebenfalls
interessant ist die auch von Mitgliedern des DICOM-Komitees gelesene Newsgroup comp.protocols.dicom,
auf der Fragen schnell beantwortet werden. Neben Fragen und Antworten werden über die Newsgroup auch
Ergänzungsvorschläge und Fehlerkorrekturen für den DICOM-Standard von den Anwendern eingereicht. Weitere wertvolle Informationsquellen sind die Dokumentationen, Quellkodes, Foren und Wikis der diversen Anbieter
freier DICOM-Toolkits (z. B. [82], [124], [61]).
2.6 DICOM Structured Reporting
DICOM Structured Reporting (DICOM-SR) ist eine Erweiterung des DICOM-Standards, die mit Supplement
23 im April 2000 offiziell verabschiedet wurde [17]. DICOM-SR definiert ein Datenmodell für die Speicherung
und Übertragung strukturierter und standardisierter Dokumente (vgl. Kap. 2.4). Die offensichtlichste Anwendungsmöglichkeit von DICOM-SR liegt im Bereich der Befundberichte für DICOM-Bilder und -Signalverläufe.
DICOM-SR bietet daher die Möglichkeit, andere DICOM-Objekte zu referenzieren. Seinem Namen zum Trotz
eignet sich DICOM-SR aber auch für nahezu beliebige andere strukturierte Informationen, sogar über die Anwendungsdomäne der Medizin hinaus.
Die Entwicklung von DICOM-SR verläuft rasant. Zahlreiche Supplements der vergangenen Jahre verbesserten
die Einsatzmöglichkeiten des Standards für spezielle medizinische Fachgebiete28 , weitere Supplements sind in
Arbeit29 . Für die Weiterentwicklung von DICOM-SR ist vor allem die DICOM Working Group 08 (Structured
”
Reporting)“ verantwortlich.
Kapitel 2.6.1 und 2.6.2 beschreiben den Aufbau von DICOM-SR-Dokumenten. Da der Aufbau dem von anderen
DICOM-Informationsobjekten wie Bildern oder Presentation States aus technischer Sicht sehr stark ähnelt,
kann DICOM-SR von einer bestehenden DICOM-Infrastruktur profitieren. Software, die Dienste wie die Archivierung, Recherche, Übertragung oder Verschlüsselung für andere DICOM-Objekte wie zum Beispiel Bilder
anbietet, kann diese Operationen in der Regel – gegebenenfalls nach geringfügigen Modifikationen – auch auf
DICOM-SR-Dokumenten ausführen. Die gemeinsame Verwaltung von DICOM-SR-Dokumenten und assoziierten
anderen DICOM-Objekten ist eine der großen Stärken von DICOM-SR im Vergleich zu anderen Dokumentationsstandards.
DICOM-SR erlaubt eine nahezu beliebige Granularität der Strukturierung und semantischen Annotation von
Information. Die Speicherung von Freitext ist ebenso möglich wie das Anlegen eines Dokuments, das ausschließlich aus kodierten Einzelbegriffen mit komplizierten Beziehungen zueinander besteht. Auch Mischformen aus
28 Z.
29 Z.
B. Supplement 26, 50, 65, 66, 71, 72, 76, 77, 78, 79, 94, 97, 127 und 130 [17].
B. Supplement 126, 128, 129 und 134 [17].
Seite 34
2
GRUNDLAGEN
Freitext und strukturierten, kodierten Anteilen sind problemlos möglich. Für die Kodierung von Elementen
eines Dokuments bringt DICOM-SR ein eigenes kontrolliertes Vokabular mit, das in Kapitel 2.6.3 vorgestellt
wird. DICOM-SR erlaubt sowohl präkoordinierte als auch postkoordinierte kodierte Elemente.
Die beschriebene Flexibilität von DICOM-SR ist oftmals verwirrend und vom Endnutzer gar nicht gewünscht.
Eine Lösung für dieses Problem bietet DICOM-SR in Form von sogenannten Templates“. Mit Templates
”
können Struktur und Inhalte von Teilen eines Dokuments oder vollständigen Dokumenten vorgegeben werden.
Dieses Prinzip wird in Kapitel 2.6.4 näher erläutert. Ein Beispiel für die Anwendung von Templates ist die
Erstellung von Befundberichten für die Computergestützte Detektion (CAD, vgl. Kap. 2.3), die in Kapitel 2.6.5
kurz besprochen wird.
Kapitel 2.6.6 nennt Standards im Umfeld der strukturierten und standardisierten Dokumentation, die mit
DICOM-SR in Beziehung stehen.
Weitere Informationsquellen zu DICOM-SR findet der interessierte Leser schließlich in Kapitel 2.6.7.
2.6.1 Allgemeiner Aufbau von DICOM-SR-Dokumenten
DICOM-SR-Dokumente sind über Composite IODs (vgl. 2.5.6) definiert und entsprechen damit vom Aufbau
her anderen DICOM-Informationsobjekten wie Bildern oder Signalverläufen. Der Aufbau von Composite IODs
kann über das Informationsmodell für Composite IODs (siehe Abb. 14) veranschaulicht werden, das aus dem
PS 3.3
DICOM-Modell
der- 2008
realen Welt (Abb. 10) abgeleitet ist.
Page 92
Patient
1
is
the subject
of
1,n
Study
1
contains
1,n
1-n
Spatially or
temporally
defines
Series
creates
1,n
0-1
1
Frame of Reference
0,n
Real World
Value Mapping
Equipment
0,n
Encapsulated
Document
0,n
Fiducials
contains
0,n
0,n
Raw
Data
Registration
0,n
1
0,n
Presentation
State
0,n
Spectroscopy
Image
0,n
SR Document
0,n
Waveform
Figure A.1-1
Abbildung 14: Entity-Relationship-Modell für DICOM
Composite IODs (aus PS 3.3, Abb. A.1-1 [DIC08a])
DICOM COMPOSITE INSTANCE IOD INFORMATION MODEL
Neben dem eigentlichen
Befundbericht
ein State
Structured
Report“IEalso
immer
Each Series shall
contain at leastbeinhaltet
one Presentation
IE, SR Document
or Image
IE. auch einen Dokumenten”
kopf ( Header“), in dem Daten zu folgenden Informationseinheiten abgelegt sein können:
”
A.1.2.1 PATIENT IE
TheZu
Patient
defines the characteristics
a patient
who is eine
the subject
of one or
more medical studies.
Patient.
denIEPatientendaten
zählenofzum
Beispiel
eindeutige
Patienten-ID,
der Name, das Geburtsdatum,
das
Geschlecht
etc.
War
nicht
der
Patient
selbst,
sondern
ein
pathologisches
Präparat des
Note:
A patient may be a human or an animal.
The Patient IE is modality independent.
A.1.2.2 STUDY IE
The Study IE defines the characteristics of a medical study performed on a patient. A study is a collection
of one or more series of medical images, presentation states, and/or SR documents that are logically
related for the purpose of diagnosing a patient. Each study is associated with exactly one patient.
A study may include composite instances that are created by a single modality, multiple modalities or by
Seite 35
2
GRUNDLAGEN

Patienten Gegenstand der Untersuchung, so wurden bisher auch die zum Präparat gehörigen Daten in
dieser Informationseinheit aufgeführt. Dies wird sich in der nächsten DICOM-Version durch Supplement
122 ändern (vgl. Kap. 2.5.11).
Study. Daten der Untersuchung sind zum Beispiel das Kalenderdatum des Untersuchungsbeginns, der
einweisende Arzt oder der für die Untersuchung verantwortliche Arzt, aber auch Patientenmerkmale wie
Alter, Körpergröße und Gewicht zu Beginn der Untersuchung.
Series. In den Daten zur Folge kann beispielsweise gespeichert werden, zu welchem Untersuchungsschritt
( Performed Procedure Step“) das Dokument gehört.
”
Anmerkung: Da strukturierte Dokumente als eigene Modalität“ gelten und alle Elemente einer Folge zur
”
gleichen Modalität gehören sollen, finden sich in einer Folge mit Dokumenten ausschließlich Dokumente.
Equipment. In dieser Informationseinheit können Informationen über die Soft- und Hardware gespeichert werden, mit der das Dokument erstellt wurde. Dazu zählen beispielsweise der Name des SoftwareHerstellers, die Versionsnummer oder auch der Einsatzort der Software.
Frame of Reference. Diese Informationseinheit kann Daten zum zeitlichen Zusammenhang von Dokumenten enthalten, falls eine Folge mehrere Dokumente enthält.
Für klinische Studien sind in den Informationseinheiten Patient, Study und Series weitere spezielle Datenfelder
vorgesehen.
2.6.1.1 Dokumentenklassen
Mit Supplement 23 wurden in PS 3.3, Anhang A.35, folgende generische Dokumentenklassen ( SR IODs“)
”
definiert [DIC08a]:
Basic Text. Diese Dokumentenklasse ist für konventionellen Fließtext mit wenigen kodierten Einträgen
gedacht.
Enhanced. Diese Dokumentenklasse ist eine Erweiterung der Basic Text“-Klasse. Enhanced“-Doku”
”
mente bieten zusätzlich Unterstützung für die Kodierung numerischer Angaben (z. B. Messwerte) sowie
räumlicher und zeitlicher Koordinaten. Mithilfe von Koordinaten lassen sich beispielsweise Regions of
”
Interest“ (ROI) in Bildern oder Signalverläufen definieren.
Comprehensive. Diese Dokumentenklasse ist wiederum eine Erweiterung der Enhanced“-Klasse. Ins”
besondere sind in Comprehensive“-Dokumenten By-reference-Relationen erlaubt (vgl. Kap. 2.6.2, S. 38).
”
Neben den drei generischen Dokumentenklassen enthält PS 3.3 mittlerweile fünf weitere Dokumentenklassen für spezielle Anwendungen, beispielsweise für die Ablage von Ergebnissen bei der automatischen Erkennung von Brustkrebs (vgl. Kap. 2.6.5), für Herzkatheteruntersuchungen, für die Angabe von Strahlendosen bei
Röntgenuntersuchungen etc. Weitere Dokumentenklassen sind in Vorbereitung (vgl. Evidence Document SR
”
IOD“ in Supp. 115, Colon CAD SR IOD“ in Supp. 126 und das noch nicht verfügbare Supp. 134 Implantation
”
”
Plan SR Document Storage SOP Class“ [17]). Interessant im Zusammenhang mit strukturierten Befundberichten sind neben den Dokumentenklassen außerdem beispielsweise die IODs für eingebettete PDF-Dokumente
(Anhang A.45) und für Informationen zur Bildsegmentierung (Anhang A.51).
Abbildung 15 zeigt beispielhaft die Module für die Basic Text“-Dokumentenklasse30 . Die Spalte Reference“
”
”
verweist auf die Kapitel in PS 3.3, in denen exakt definiert ist, welche Attribute zu einem Modul gehören. In
der Spalte Usage“ ist festgelegt, ob das jeweilige Modul verpflichtend ( M andatory“) oder optional ( U ser
”
”
”
Option“) zum DICOM-Objekt gehört. Ein C“ ( C onditional“) in dieser Spalte bedeutet, dass das betreffende
”
”
Modul unter bestimmten Umständen verpflichtend enthalten sein muss und ansonsten weggelassen werden soll.
Charakteristisch für DICOM-SR-Dokumente sind folgende Module31 :
SR Document Series. Dieses Modul ersetzt das in anderen Composite IODs übliche General Series
”
Module“ und ist im Vergleich zu diesem stark vereinfacht, da Folgen von Dokumenten im Vergleich zu
Folgen bei beispielsweise CT-Aufnahmen typischerweise einfacher strukturierte Abhängigkeiten haben
[Rie06].
30 Die
Modultabellen der anderen Dokumentenklassen sehen ähnlich aus.
Dokumentenklasse Key Object Selection“ verwendet spezielle Document Series“- und Document“-Module, die hier nicht
”
”
”
berücksichtigt werden sollen (vgl. PS 3.3, Anhang C.17.6 [DIC08a]).
31 Die
Seite 36
PS 3.3 - 2008
Page 188
2
GRUNDLAGEN
Table A.35.1-1
BASIC TEXT SR IOD MODULES
IE
Module
Reference
Patient
Patient
C.7.1.1
M
Specimen Identification
C.7.1.2
C - Required if the Observation Subject is a
Specimen
Study
Series
Usage
Clinical Trial Subject
C.7.1.3
U
General Study
C.7.2.1
M
Patient Study
C.7.2.2
U
Clinical Trial Study
C.7.2.3
U
SR Document Series
C.17.1
M
Clinical Trial Series
C.7.3.2
U
Equipment
General Equipment
C.7.5.1
M
Document
SR Document General
C.17.2
M
SR Document Content
C.17.3
M
SOP Common
C.12.1
M
Abbildung 15:
ModultabelleBasic
für die
Dokumentenklasse
Basic Text“ (aus PS 3.3, Tab. A.35.1-1 [DIC08a])
A.35.1.3.1
Text
SR IOD Content Constraints
”
A.35.1.3.1.1

Value Type
Value Type (0040,A040) in the Content Sequence (0040,A730) of the SR Document Content
SR Document
ModulEnumerated
ist ein spezieller
Dokumentenkopf,
demType
beispielsweise Datum
Module isGeneral.
constrainedDieses
to the following
Values (see
Table C.17.3-7 forin
Value
definitions):
und Uhrzeit
der Erstellung des Dokumenteninhalts abgelegt sind. Außerdem beinhaltet das Modul Sta-
tusinformationenTEXT
zur Vollständigkeit ( Completion Flag“) und zum Freigabestatus ( Verification Flag“)
”
”
des Dokuments (vgl.
CODEVisualisierung in Abb. 31(b)).
SR DocumentDATETIME
Content. Während alle anderen Module aus der Modultabelle in Abbildung 15 MetaDATE
informationen enthalten,
repräsentiert dieses Modul den eigentlichen Inhalt des Dokuments. Es wird im
TIME
folgenden Kapitel
ausführlich besprochen.
UIDREF
PNAME
Das Modul SOP Common“
ist trotz der Zuordnung zur Informationseinheit Document“ von allgemeiner Natur.
COMPOSITE
”
”
IMAGE verpflichtend und enthält vor allem einen eindeutigen Schlüssel zur Identifikation
Es ist für alle DICOM-IODs
WAVEFORM
der jeweiligen Objektinstanz.
CONTAINER
A.35.1.3.1.2
Relationship Constraints
2.6.2 Der DICOM-SR-Inhaltsbaum
Relationships between Content Items in the content of this IOD shall be conveyed in the by-value
mode. See Table C.17.3-8 for Relationship Type definitions.
Der Inhalt eines DICOM-SR-Dokuments ist prinzipiell baumartig aufgebaut. Die Knoten des Baumes werden
Relationships
by-reference
areJedes
forbidden.
Therefore, Referenced
Item Identifier
Inhaltselemente (Note:
Content
Items“)
genannt.
Inhaltselement
stehtContent
zu seinem
Vaterelement in Relation (vgl.
(0040,DB73) is not present in any of the Content Items within the SR Document Content
”
Abb. 16). Das Wurzelelement
stellt
den
Titel
des
Dokuments
dar
und
trägt
keine
Relation.
Die Anwesenheit des
Module.
Wurzelelements ist verpflichtend, leere Inhaltsbäume sind also nicht erlaubt. Hat ein Inhaltselement mehrere
Kindelemente, so ist deren Reihenfolge relevant.
2.6.2.1 Inhaltselemente
Jedes Inhaltselement besteht aus einem Konzeptnamen ( Concept Name“) und einem Konzeptwert ( Concept
”
”
Value“).
- Standard -
Konzeptnamen Der Name eines Inhaltselements wird stets kodiert angegeben (vgl. Kap. 2.5.6, S. 25). Der
Konzeptname drückt den Kontext des Konzeptwertes aus, zum Beispiel die Rolle einer Person ( Einweisender
”
Arzt“), die Bedeutung eines Messwertes ( Durchmesser“) oder die Bedeutung eines Kodes ( Entlassungsdia”
”
gnose“). In einigen Fällen ist der Konzeptname als Überschrift zu verstehen (s. u.).
Konzeptwerte Der Wert eines Inhaltselements muss von einem bestimmten komplexen Datentyp ( Value
”
Type“) sein. Ein Inhaltselement kann je nach Typ seines Konzeptwertes beispielsweise Freitext, eine numerische
Angabe oder ein Datum repräsentieren. Die Liste der 14 zulässigen Datentypen für Konzeptwerte findet sich in
Tabelle 2. Details der einzelnen Datentypen für Konzeptwerte diskutiert Kapitel 4.3.1. Im Folgenden wird oft
Seite 37
2
GRUNDLAGEN
Abbildung 16: Informationsmodell von DICOM-SR (PS 3.3, Abb. C.17.3-1 [DIC08a])
auch vom Typ eines Inhaltselements“ gesprochen, womit der Datentyp seines Konzeptwertes gemeint ist32 .
”
2.6.2.2 Relationen
Wie oben erwähnt, steht jedes Inhaltselement eines DICOM-SR-Inhaltsbaums implizit in Relation zu seinem
Vaterelement. Diese Art der Relation wird im Standard by-value relationship“ genannt. Jede Relation hat einen
”
der sieben Relationstypen ( Relationship Types“) aus Tabelle 3. Die Lesrichtung von By-value-Relationen geht
”
immer von der Wurzel zu den Blättern des Baumes. Ist beispielsweise ein Inhaltselement vom Typ TEXT“
”
Kind eines Inhaltselements vom Typ CONTAINER“ und herrscht zwischen diesen beiden Inhaltselementen eine
”
Relation CONTAINS“, so bedeutet dies, dass der CONTAINER den TEXT enthält und nicht umgekehrt. Der
”
Typ der By-value-Relation wird mit dem Kindknoten, also dem Ziel der Relation, abgespeichert. Attributierte
Relationen kennt der DICOM-Standard nicht. Der Zweck einer Relation kann daher nur über den Relationstyp
und den Konzeptnamen des Zielelements ausgedrückt werden.
By-reference-Relationen Neben Relationen, die sich durch die Anordnung der Inhaltselemente im Inhaltsbaum
implizit ergeben, gibt es im DICOM-SR-Standard auch freie Relationen zwischen Inhaltselementen, sogenannte
by-reference relationships“. Diese Relationen werden mit dem Inhaltselement, das die Quelle der Relation
”
darstellt, abgespeichert. Die Adressierung des Zielknotens der Relation erfolgt ähnlich wie bei UIDs (vgl. 2.5.6)
über durch Punkte getrennte Zahlentupel. Beispielsweise verweist 1“ auf den Wurzelknoten des Inhaltsbaumes,
”
1.2“ auf das zweite Kind der Wurzel, 1.2.1“ auf dessen erstes Kind und so weiter. Der Inhaltsbaum wird durch
”
”
By-reference-Relationen zu einem gerichteten Inhaltsgraph“. Im DICOM-Jargon wird dieser Begriff aber nicht
”
verwendet.
Derzeit erlauben nur drei Dokumentenklassen den Einsatz von By-reference-Relationen: Comprehensive“,
”
Mammography CAD“ und Chest CAD“.
”
”
2.6.2.3 Einschränkungen bei der Konstruktion von DICOM-SR-Inhaltsbäumen
Das Wurzelelement eines Inhaltsbaumes ist immer vom Typ CONTAINER“. Der sonstige Aufbau von DICOM”
SR-Dokumenten aus Inhaltselementen und Relationen unterliegt je nach Dokumentenklasse verschiedenen weiteren Einschränkungen ( Content Constraints“). Welches Inhaltselement einem anderen Inhaltselement über
”
welche Relation zugeordnet werden darf, hängt vom Typ der Inhaltselemente und vom Relationstyp ab. Für
jede Dokumentenklasse findet sich im DICOM-Standard eine Tabelle wie in Abbildung 17. Die Menge der im
Dokument erlaubten Inhaltselement-Typen ergibt sich implizit aus der rechten Spalte der Tabelle, wird aber
auch noch einmal explizit im Standard aufgeführt.
32 Der
Autor hält diese vereinfachte Formulierung für zulässig, da der Typ eines Konzeptwertes Inhaltselemente charakterisiert. Der
Konzeptname hingegen ist für alle Inhaltselemente immer gleich aufgebaut.
Seite 38
2
GRUNDLAGEN
Datentyp
Konzeptname
Konzeptwert
Beschreibung
CONTAINER
Titel eines Dokuments oder
Überschrift
eines
Dokumentenabschnitts. Der Konzeptname beschreibt den Titel des
Dokuments (wenn der CONTAINER Wurzelelement des
Inhaltsbaumes ist) oder die
Beobachtungskategorie.
Typ des Textes, z. B. Einzel”
befund“, oder Name/Bezeichner,
z. B. Läsionsnr.“
”
Der Inhalt des CONTAINERs.
Der Wert eines CONTAINERElements ist die Sammlung aller
Inhaltselemente, die es beinhaltet.
Typ des Datums, z. B. Geburts”
datum“
Typ der Zeit, z. B. Startzeit“
”
Kalenderdatum
Typ von Datum und Uhrzeit,
z. B. Einweisungdatum und ”
uhrzeit“
Rolle der Person, z. B., Patient“
”
Datum und Uhrzeit konkateniert
CONTAINER gruppieren Elemente und
definieren die Überschrift oder die Kategorie, zu der der Inhalt gehört.
Die Überschrift beschreibt den Inhalt
des CONTAINER-Elements und kann
mit der Abschnittsüberschrift eines gedruckten oder angezeigten Dokuments
übereinstimmen.
Freitext, erzählende Beschreibung unbegrenzter Länge. Kann auch verwendet
werden, um einen Bezeichner oder den
Wert einer ID anzugeben.
Datum des Ereignisses vom im Konzeptnamen festgelegten Typ.
Uhrzeit des Ereignisses vom im Konzeptnamen festgelegten Typ.
Datum und Uhrzeit des Ereignisses vom
im Konzeptnamen festgelegten Typ.
Typ der UID, z. B. Study In”
stance UID“
Typ des Kodes, z. B. Befunde“
”
Unique Identifier
TEXT
DATE
TIME
DATETIME
PNAME
UIDREF
CODE
Textuelle Beschreibung des Konzepts
Uhrzeit
Name der Person
Verschlüsselte Darstellung des
Konzepts
Numerischer Wert und zugehörige Maßeinheit
NUM
Typ des Zahlen- oder Messwerts,
z. B. DBD“
”
COMPOSITE
Zweck der Referenz
Verweis auf UIDs von Composi”
te SOP“-Instanzen
IMAGE
Zweck der Referenz
Verweis auf UIDs von Image
”
Composite SOP“-Instanzen
WAVEFORM
Zweck der Referenz
SCOORD
Zweck der Referenz
Verweis auf UIDs von Waveform
”
Composite SOP“-Instanzen
Liste räumlicher Koordinaten
TCOORD
Zweck der Referenz
Liste zeitlicher Koordinaten
Name der Person, deren Rolle über den
Konzeptnamen festgelegt wurde.
Unique Identifier (UID) der im Konzeptnamen festgelegten Entität.
Repräsentation von Nominal- und nichtnumerischen Ordinalwerten.
Numerische Angabe, vollständig klassifiziert durch eine verschlüsselte Angabe
des Typs und der Maßeinheit.
Ein Verweis auf eine Composite SOP“”
Instanz, die weder Bild noch Signalverlauf ist.
Verweis auf ein Bild. Kann außerdem
einen Presentation State“ zur Darstel”
lung des Bildes referenzieren.
Verweis auf einen Signalverlauf.
Räumliche Koordinaten einer geometrischen
ROI
im
DICOMBildkoordinatensystem. Das IMAGEInhaltselement,
auf
das
sich
die
räumlichen
Koordinaten
beziehen,
wird über die Relation SELECTED
”
FROM“ angegeben.
Zeitliche Koordinaten (d.h. zeit- oder
ereignisbasierte Koordinaten) einer ROI
im
DICOM-Signalverlaufskoordinatensystem. Das Inhaltselement vom Typ
WAVEFORM, IMAGE oder SCOORD,
auf das sich die zeitlichen Koordinaten
beziehen, wird über die SELECTED
”
FROM“-Relation angegeben.
Tabelle 2: Komplexe Datentypen für die Werte von Inhaltselementen (Übersetzung nach PS 3.3, Tab. C.17.3-7
[DIC08a])
Seite 39
2
GRUNDLAGEN
Relationstyp
Beschreibung
CONTAINS
beinhaltet
Definition und Beispiel
Das Quellelement beinhaltet das Zielelement.
Z. B.: CONTAINER Familienanamnese“ {CONTAINS: TEXT Mutter
”
”
hatte Brustkrebs”, CONTAINS: IMAGE 36}
HAS OBS CONTEXT
hat
Das Zielelement soll detailliertere Informationen des BeobachtungskontexBeobachtungskontext
tes enthalten, die für eine eindeutige Dokumentation des Quellelements
notwendig sind.
Z. B.: CONTAINER Befundbericht“ {HAS OBS CONTEXT: PNAME
”
Protokollant“ = SmithˆJohnˆˆDrˆ“}.
”
”
HAS CONCEPT MOD
hat
Wird benutzt, um den Konzeptnamen des Quellelements genauer zu beKonzept-Modifikator
zeichnen oder zu beschreiben, z. B. durch Post-Koordination.
Z. B. CODE Thorax-Röntgenaufnahme“ {HAS CONCEPT MOD: CODE
”
Projektion“ = p.a. und lateral“}
”
”
Z. B. CODE Brust“ HAS CONCEPT MOD: TEXT Französische
”
”
Übersetzung“ = Sein“
”
Z. B. CODE 2VCXRPALAT“ {HAS CONCEPT MOD: TEXT Weitere
”
”
Erklärung“ = Thorax-Röntgen, zwei Projektionen, posterior-anterior und
”
lateral“}
HAS PROPERTIES
hat Eigenschaften
Beschreibt die Eigenschaften des Quellelements.
Z. B. CODE Tumor“ {HAS PROPERTIES: CODE Anatomische Lage“,
”
”
HAS PROPERTIES: CODE Durchmesser“, HAS PROPERTIES: CODE
”
Berandung“,. . . }.
”
PSDatenacquisition
3.3 - 2008
HAS ACQ CONTEXT
hat Aufnahmekontext
Das Zielelement beschreibt die Umstände während der
des Quellelements.
Page 193
Z. B. IMAGE 36 {HAS ACQ CONTEXT: CODE Kontrastmittel“, HAS
”
ACQ CONTEXT: CODE Patientenpositionierung“,. . . }.
”
INFERRED
FROM
gefolgert aus
Das Quellelement beschreibt einen Messwert oder andere Belege, aus deA.35.2.3.1.2
Relationship
Constraints
nen das Zielelement gefolgert werden kann. Kennzeichnet Evidenz für
Messwertof
oder
Urteil.
Relationships between Content Items in einen
the content
thiseinIOD
shall be conveyed in the by-value
Z. B. CODE Malignität“ {INFERRED FROM: CODE Tumor“, INFER”
”
mode. See Table C.17.3-8 for Relationship
Type
definitions.
RED FROM: CODE Lymphadenopathie“,. . . }.
”
Z. B. NUM: BPD“ = 5mm“ {INFERRED FROM: SCOORD}.
”
”
Note: Relationships
by-reference
Therefore,
Referenced
Content
Item
Identifier
SELECTED
FROM
ausgewählt
aus are forbidden.
Das Quellelement
beschreibt
räumliche
oder
zeitliche
Koordinaten im Zielelement
(bzw.
in
mehreren
Zielelementen).
(0040,DB73) is not present in any of the Content Items within
the SR Document Content
Z. B. SCOORD POLYLINE 1,1 5,1 5,10 1,10 1,1“ {SELECTED FROM:
”
Module.
IMAGE 36}.
Z. B. TCOORD SEGMENT 60-200mS“ {SELECTED FROM: WAVE”
FORM}.
Table A.35.2-2 specifies the relationship constraints of this IOD.
Tabelle 3: Typen für Relationen (Übersetzung nach PS 3.3, Tab. C.17.3-8 [DIC08a])
Table A.35.2-2
RELATIONSHIP CONTENT CONSTRAINTS FOR ENHANCED SR IOD
Source Value Type
Relationship Type
(Enumerated Values)
Target Value Type
CONTAINER
CONTAINS
TEXT, CODE, NUM, DATETIME,
DATE, TIME, UIDREF, PNAME,
SCOORD, TCOORD, COMPOSITE,
IMAGE, WAVEFORM, CONTAINER
CONTAINER
HAS OBS CONTEXT
COMPOSITE
CONTAINER, IMAGE,
WAVEFORM,
COMPOSITE, NUM
HAS ACQ CONTEXT
DATE, TIME, UIDREF, PNAME
any type
HAS CONCEPT MOD
TEXT, CODE
TEXT, CODE, NUM
HAS PROPERTIES
IMAGE, WAVEFORM, COMPOSITE,
SCOORD, TCOORD
TEXT, CODE, NUM
INFERRED FROM
IMAGE, WAVEFORM, COMPOSITE,
SCOORD, TCOORD
SCOORD
SELECTED FROM
IMAGE
TCOORD
SELECTED FROM
SCOORD, IMAGE, WAVEFORM
Abbildung 17: Einschränkungen bei der Konstruktion von DICOM-SR-Dokumenten der Klasse Enhanced“ (PS
” to, is
Note:
1. Which SOP Classes the IMAGE, WAVEFORM or COMPOSITE Value Type may refer
3.3,documented
Tab. A.35.2-2
[DIC08a])
in the Conformance Statement for an application (see PS 3.2 and PS 3.4).
2. The HAS CONCEPT MOD relationship is used to modify the meaning of the Concept Name
of a Source Content Item, for example to provide a more descriptive explanation, a different
language translation, or to define a post-coordinated concept.
Seite 40
A.35.3 Comprehensive SR Information Object Definition
A.35.3.1 Comprehensive SR Information Object Description
The Comprehensive SR IOD is a superset of the Basic Text SR IOD and the Enhanced SR IOD,
2
GRUNDLAGEN
Die Tabelle mit Einschränkungen gilt sowohl für By-value- als auch für By-reference-Relationen, was im Standard
allerdings nicht explizit erwähnt wird33 . Vor allem für By-reference-Relationen finden sich bei einigen Dokumentenklassen weitere, freitextlich formulierte Einschränkungen. So verbietet beispielsweise die Dokumentenklasse
Comprehensive“ By-reference-Relationen zu Zielknoten, die sich auf dem Pfad zwischen der Wurzel und dem
”
Quellknoten befinden. Auf diese Weise sollen Zyklen im Graph vermieden werden34 . Alle Dokumentenklassen,
die By-reference-Relationen erlauben, schränken deren Verwendung außerdem auf bestimmte Relationstypen
ein.
2.6.2.4 Beispiel für einen DICOM-SR-Inhaltsbaum
Abbildung
18- zeigt
PS 3.3
2008 einen gültigen Inhaltsbaum der Dokumentenklasse Comprehensive“ für einen Röntgen”
Page 956Der Dokumententitel wird über Postkoordination genauer spezifiziert ( has concept mod...“ oben
Befundbericht.
”
rechts). Verschiedene Umstände der Erstellung des Befundberichts werden als observation context“ struktu”
C.17.4 SR(unten
Contentlinks).
Tree Example
(Informative)
riert angegeben
Der Befundbericht
ist mittels Zwischenüberschriften in Form von CONTAI”
NER“-Inhaltselementen
weiterthe
strukturiert.
Inhaltsbaum
gibtinterpretation.
es zwei By-reference-Relationen. Das Beispiel
Figure C.17.4-1 depicts
content of anIm
example
diagnostic
verdeutlicht, dass ein Inhaltselement auch mehrere By-reference-Relationen haben kann.
Document Root Node CONTAINER
"Chest X-ray" (Document Title)
Leaf Node CODE
"Views = PA and Lateral"
has concept mod
contains
contains
contains
Leaf Node IMAGE
"Baseline"
Content Node CODE
"finding = mass"
Heading Node
CONTAINER
"Conclusions"
contains
Heading Node
CONTAINER "Specific
Image Findings"
has properties
has properties
contains
contains
Leaf Node NUM
"diameter = 1.3 cm"
Leaf Node CODE
"margination = infiltrativ e"
Content Node CODE
"conclusion = probable
malignancy "
Content node SCOORD
"best illustration of
findings"
inferred from
inferred from
selected from
Leaf Node IMAGE
Has obs contex t
Content Node PNAME
"Recording Observer =
Smith^John^^Dr^"
Has obs contex t
Content Node UIDREF
"Study Instance UID of
Evidence Directly Examined
by RO = 1.2.3.4.5.6.7.100"
Has obs contex t
Content Node PNAME
"Patient-Data-Acquisition
Subject = Homer^Jane^^^"
* Relationship Modes
= By-value
= By-reference
Abbildung 18: Beispiel für einen DICOM-SR-Inhaltsbaum (PS 3.3, Kapitel C17.4 [DIC08a])
Notes:
1. For nodes of type CONTAINER, the contents of the Concept Name Code Sequence are
shown in quotes and italicized.
Diskussion auf comp.protocols.dicom,
2. For nodes of Value Type CODE, PNAME, NUM the contents are shown as “Concept Name
http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/d7056c4d0d11b040.
= Value”.
Code Sequence
34 Dass diese Formulierung
im DICOM-Standard
allerdings keine Zyklenfreiheit garantiert, wurde bereits in [Rie06] und auf
3. For the
nodes (vgl.
of Value
TypeinIMAGE
and
SCOORD, the contents of the Concept Name Code
comp.protocols.dicom
diskutiert
Thread
Fußnote
33).
Sequence indicating the purpose of reference are shown in quotes and italicized.
33 Vgl.
Seite 41
2
GRUNDLAGEN
2.6.2.5 Abbildung eines Inhaltsbaums auf DICOM-Attribute
Es wurde bereits geschildert, dass DICOM-SR-Dokumente dieselben Basis-Datenstrukturen wie andere DICOMObjekte verwenden, damit die Vorteile einer bereits bestehenden DICOM-Infrastruktur genutzt werden können.
Die Daten eines Inhaltsbaumes müssen also auf DICOM-Attribute abgebildet werden.
Der Konzeptname eines Inhaltselements besteht aus mehreren zusammengehörigen Attributen und wird daher
als Sequenzattribut Concept Name Code Sequence“ (0040,a043) abgelegt. Für den Datentyp des Konzeptwertes
”
wird das Attribut Value Type“ (0040,a040) verwendet, für den Typ der (By-value-)Relation zum Vaterelement
”
das Attribut Relationship Type“ (0040,a010). Je nach Typ des Inhaltselements kommen zahlreiche weitere
”
Attribute hinzu (vgl. Kap. 4.3.1).
Die Baumstruktur von DICOM-SR-Dokumenten wird über verschachtelte Sequenzattribute realisiert. Das Wurzelelement befindet sich auf der obersten, flachen“ Hierarchieebene inmitten der DICOM-Attribute aus anderen
”
Inhaltsmodulen. Alle Kinder des Wurzelelements befinden sich jeweils als Item innerhalb des Sequenzattributs
Content Sequence“ (0040,a730). Handelt es sich bei einem Kindelement um einen inneren Knoten des Inhalts”
baumes, so enthält das zugehörige Items wiederum ein Content Sequence“-Attribut und so weiter.
”
Eine Sonderstellung nehmen By-reference-Relationen ein. Wie oben beschrieben, kann ein Inhaltselement mehrere By-reference-Relationen haben. Diese werden aber nicht als eigenständiges Sequenzattribut kodiert, sondern
wie die Kinder des betreffenden Inhaltselements als Items in die Content Sequence“ eingefügt. By-reference”
Relationen bestehen im Wesentlichen aus dem oben genannten Attribut Relationship Type“ und der Adresse
”
des Zielknotens, die in Attribut Referenced Content Item Identifier“ (0040,db73) angegeben wird. Sie haben
”
insbesondere keinen Value Type“ und keine Kindelemente, also kein Content Sequence“-Attribut.
”
”
2.6.3 Kontextgruppen
Kapitel PS 3.16 des DICOM-Standards mit dem Namen DICOM Content Mapping Resource“ (DCMR), enthält
”
im Anhang B auf ca. 350 Seiten eine Liste mit mehr als 8.000 Begriffen, die in DICOM-SR-Dokumenten verwendet werden sollen [DIC08a]. Diese Begriffe sind thematisch in ca. 600 sogenannte Kontextgruppen ( Context
”
Groups“, CGs) aufgeteilt. Kontextgruppen sind im DICOM-Sprachgebrauch Mengen von Begriffen mit eindeutigem Schlüssel, die auf die Benutzung in einem bestimmten Kontext zugeschnitten sind. Jede Kontextgruppe
trägt eine eindeutige Nummer, die Kontext-ID ( Context ID“, CID). Beispiele für Kontextgruppen sind Late”
”
rality“ (CID 244), Imaging Procedures“ (CID 3428) oder Linear Measurements“ (CID 7470).
”
”
Die Konzepte sind verschiedenen internationalen Standards, z. B. ICD-10 oder SNOMED, entnommen. Wo keine
geeigneten Begriffe aus anerkannten Standards existieren, schließt der DICOM-Standard mit einem eigenen
Vokabular, der sogenannten DICOM Controlled Terminology“, die Lücken (vgl. PS 3.16, Anhang D [DIC08a]).
”
Die Verwendung der im DCMR aufgezählten Begriffe ist (im Gegensatz zur Verwendung beispielsweise der
vollständigen SNOMED) lizenzkostenfrei35 . Es hat daher Vorteile, sich auf die in den Kontextgruppen des
DCMR genannten Konzepte zu beschränken, zumal das DCMR den Anspruch erhebt, die im DICOM-Umfeld
gebräuchlichen Begriffe möglichst vollständig aufzulisten. Ein Teil der Begriffe im DCMR liegt in französischer
und japanischer Übersetzung vor. Eine deutsche Übersetzung fehlt bisher.
Eine Kontextgruppe kann beliebig viele andere Kontextgruppen inkludieren. Auf diese Weise wird Redundanz
im DCMR vermieden, was Inkonsistenzen reduziert und die Pflege vereinfacht.
Abbildung 19 zeigt beispielhaft zwei Kontextgruppen mit Inklusion. Der allgemeine Aufbau von Kontextgruppen
ist in PS 3.16, Abschnitt 7 [DIC08a] beschrieben und sei hier nur stichpunktartig zusammengefasst:
Neben der bereits genannten numerischen CID hat jede Kontextgruppe einen alphanumerischen Bezeichner, den Kontextgruppennamen.
Kontextgruppen haben einen Typ, sie sind entweder erweiterbar ( extensible“, z. B. Kontextgruppe 4
”
Anatomic Region“) oder nicht-erweiterbar ( non-extensible“, z. B. Kontextgruppe 230 Yes-No“ oder
”
”
”
3015 Coronary Arteries“). Erweiterbare Kontextgruppen dürfen vom Anwender um selbstdefinierte Be”
griffe erweitert werden.
Jede Kontextgruppe trägt als Versionsnummer ein Datum im Format JJJJMMTT.
35 Die
Lizenzfreiheit für Nutzer beruht auf einem Abkommen zwischen den Standardisierungsorganisationen von DICOM und
SNOMED, nach dem DICOM die Lizenzkosten sozusagen dadurch erbringt, dass an den entsprechenden Konzepten gearbeitet
und neue Konzepte für SNOMED beigesteuert werden [Clu00].
Seite 42
2
GRUNDLAGEN
Die in der jeweiligen Kontextgruppe enthaltenen Begriffe werden in einer Tabelle angegeben36 . Jede Zeile
in dieser Tabelle entspricht genau einem kodierten Konzept. Wie in Kapitel 2.5.6 (S. 25) beschrieben, wird
ein kodiertes Konzept in DICOM über seinen Kodewert, den Kodierungsschema-Bezeichner, gegebenenfalls
die Kodierungsschema-Version und die Kodebedeutung beschrieben.
Bei einigen Kontextgruppen ist in einer zusätzlichen Spalte angegeben, welchen Einträgen einer Referenzterminologie das jeweilige Konzept entspricht. Ein Beispiel dafür ist Kontextgruppe 3014 Coronary
”
Artery Segments“: Hier wird standardmäßig nach der Bypass Angioplasty Revascularization Investigation
(BARI, vgl. Tabelle 8-1 in PS 3.16 [DIC08a]) kodiert, es wird jedoch für die meisten Konzepte auch ein
PS 3.16 - 2008
SNOMED-Kode
angegeben.
Page 342
CID 3614
Valve Areas, non-Mitral
Context ID 3614
Valve Areas, non-Mitral
Type: Extensible
Version: 20030327
CID 3615
Coding
Scheme
Designator
Code Value
Code Meaning
SRT
F-0231F
Aortic Valve Area
SRT
F-02321
Pulmonic Valve Area
SRT
F-02322
Tricuspid Valve Area
DCM
122160
Derived Non-Valve Area
Valve Areas
Context ID 3615
Valve Areas
Type: Extensible
Version: 20030327
Coding
Scheme
Designator
Code Value
Code Meaning
Include CID 3614 Valve Areas, non-Mitral
SRT
F-02320
Mitral Valve Area
CID 3616 19: Beispiele
Hemodynamic
Period Measurements
Abbildung
für Kontextgruppen
(aus PS 3.16, Anhang B [DIC08a])
Context ID 3616
Hemodynamic Period Measurements
Type: Extensible
Version: 20030327
2.6.4 Templates
Coding Aufbau
Code
Value
Code Meaning
In Kapitel 2.6.2 wurde der allgemeine
eines
DICOM-SR-Dokumentenbaums
erklärt. Abbildung 17 zeigScheme
te, dass man InhaltselementeDesignator
vielfältig über Relationen miteinander kombinieren kann. Die hohe Anzahl an
Freiheitsgraden bei der Strukturierung ist zwar aus theoretischer Sicht zu begrüßen, weil dadurch ein großes
SRT
R-002D2
Aortic Systolic Ejection Period (SEPa)
Einsatzgebiet für DICOM-SR geschaffen wird. Für die praktische Anwendung hat die Vielfalt von DICOM-SR
SRT
R-0035C
Pulmonary Systolic Ejection Period (SEPp)
jedoch Nachteile. Menschliche Betrachter empfinden die umfangreichen Auswahlmöglichkeiten für InhaltseleSRT
R-0032C
Mitral
Diastolic Filling
mente und Relationen als unübersichtlich und verwirrend.
Außerdem
wirdPeriod
die (DFPm)
maschinelle Interoperabilität
SRT
R-003A9
Tricuspid auf
Diastolic
Period (DFPt)
erschwert, weil sich ein und derselbe
Sachverhalt
mit DICOM-SR
vieleFilling
verschiedene
Arten ausdrücken lässt.
SRT
R-002F5
Derived Period, Non-Valve
Um trotz des Festhaltens an einem generisch ausgerichteten Standard die Anwendungstauglichkeit von DICOMSR zu verbessern, wurden mit Supplement 53 die sogenannten Templates“ in den DICOM-Standard eingeführt
”
3617
Valve
[17]. Mithilfe vonCID
Templates
kann
dieFlows
Kombinierbarkeit von Inhaltselementen und die Anzahl ihrer Kinder
beschränkt werden. Außerdem ermöglichen sie die Definition zulässiger Wertemengen für Konzeptnamen und
Context ID 3617
Konzeptwerte der Inhaltselemente.
Valve Flows
Type: Analog
Extensible
Version:(vgl.
20030327
Abbildung 20 zeigt Beispiele für Templates.
zu Kontextgruppen
Kap. 2.6.3) werden Templates
36 Ausnahme:
Einige wenige Kontextgruppen enthalten statt einer konkreten Tabelle mit Begriffen nur einen Verweis auf andere
Standards. Darauf wird in Kapitel 4.1.2 näher eingegangen.
- Standard -
Seite 43
otherwise.
2
3 >>
IMAGE
RSELECTED
FROM
1
MC
XOR Row 4
4 >>
SELECTED IMAGE
FROM
1
MC
XOR Row 3
1
U
5 >
HAS
GRUNDLAGEN
PROPERTI
CODE
EV (G-C036, SRT,
“Measurement Method")
DCID (7473) General Area
Calculation Methods
ES
in Tabellenform angegeben und besitzen einen Namen sowie eine eindeutige ID ( Template ID“, TID). Auch
”
Content Item Descriptions
für Templates gibt es einen Inklusionsmechanismus, so dass Templates in anderen Templates wiederverwendet
Row 2 “Area Outline”
A Graphic Type of POINT implies that the object is a single pixel and the
werden können (vgl. Abb. 20(b), Zeile
2 und
Im
Extremfall
lassen sich
Templates
vollständig aus anderen
object’s
area4).
is the
area
of the pixel. Otherwise
the type
shall be a closed
(start Observation
and end point theContext“).
same) or a CIRCLE
or an Templates,
ELLIPSE.
Templates komponieren (siehe z. B.POLYLINE
TID 1001
Es gibt
die die Struktur
”
für den gesamten Inhaltsbaum vorgeben (sog. Root Templates“, z. B. TID 2000 Basic Diagnostic Imaging
”
”
Report“ oder TID 2010 Key Object Selection“), und Templates, die nur Teilbäume beschreiben.
”
PS 3.16 - 2008
TID 1402
NL
NL Rel with
4Parent>
1
>
Value Type
Relation with
Parent
VT
TID 1402
Concept Name
V
M
VOLUME MEASUREMENT
Type: Extensible
Concept Name
CONTAINS
NUM
5
Page 223
Volume Measurement Template
INCLUDE
VM Req
Type
DTID (300) Measurement
1
DCID(7472) “Volume
Measurements”
CONTAINS
INCLUDE
Req
Type
Condition
Value Set Constraint
2,3,4,5 shall be
present
$Length
Condition
$Derivation = DCID
(3627) Measurement
Value Set
TypeConstraint
1-n
MC
$Measurement = $Width
At least one of row
2,3,4,5 shall be
Value shall $Derivation
be > 0
= DCID
present
(3627) Measurement
1-n
MC
At least one of row
$Measurement =
GRAPHIC TYPE
= not
2,3,4,5 shall be
$Height
{MULTIPOINT}
present
$Derivation = DCID
(3627) Measurement
Type
M
UNITS = DCID(7462) “Units of
Type
Volume Measurement”
2 >
INFERRED SCOORD
FROM
3 >>
IMAGE
RSELECTED
FROM
4 >>
1
MC XOR Row 3
SELECTED IMAGE
FROM
TID 5025 OB-GYN Fetal Vascular Ultrasound Measurement Group
CODE
1
U fetal vascular measurements.DCID (7474) General Volume
HAS
EV (G-C036,
SRT,container of OB-GYN
This template
is an anatomy
specific
PROPERTI
“Measurement Method")
Calculation Methods
ES
5 >
EV (121057,DCM, “Perimeter
Outline”)
1-n
U
1
MC
Parameter Name
XOR Row 4
Parameter Usage
$AnatomyGroup
The concept
name of the vascular anatomy und
(a) Schachtelungstiefe,
By-Reference-Relation
XOR
Row 2 “Perimeter
The two dimensional TID
perimeter
5025 of the volume’s intersection with or projection
Outline”
into theVASCULAR
image. A Graphic
Type of POINT
implies thatGROUP
the volume’s
OB-GYN FETAL
ULTRASOUND
MEASUREMENT
intersection or projection
in a plane is a single pixel. A single pixel projection
Type: Extensible
perimeter cannot cause a volume calculation to become 0.
NL Rel with
Parent
1
2
>
3 >
4 >
HAS OBS
CONTEXT
VT
Concept Name
VM Req
Condition
Value Set Constraint
Otherwise the type shallType
be a closed POLYLINE (start and end point the
same) or a CIRCLE1 or an
CONTAINER $AnatomyGroup
M ELLIPSE.
INCLUDE
HAS
CODE
CONCEPT
MOD
CONTAINS INCLUDE
DTID (1008) Subject Context, 1
Fetus
MC
EV (G-C171, SRT “Laterality”) 1
MC
M
IF this template is
more than once
- Standardinvoked
to describe more than
1-n
one fetus
IFF anatomy has lateralityDCID (244) Laterality
$MeasType = DCID (12119) Vascular
Ultrasound Property
$Derivation = DCID (3627) Measurement
Type
(b) Inklusion, Verwendung und Übergabe von Parametern
Anatomy Group
Specifies the anatomical context of the observations in the group.
Abbildung 20: Beispiele für DICOM-SR-Templates (aus PS 3.16, Anhang A [DIC08a])
TID 5026 OB-GYN Pelvic Vascular Ultrasound Measurement Group
This template is an anatomy specific container of OB-GYN pelvic vascular measurements.
Jede Zeile einer Template-Tabelle
beschreibt entweder ein Inhaltselement oder verweist auf ein anderes Template.
Die Spalten einer Template-Tabelle
seien
im Folgenden kurz beschrieben:
Parameter
Name
Parameter Usage
$AnatomyGroup
The concept name of the vascular anatomy
Die Zeilen eines Templates sind mit 1“ beginnend fortlaufend nummeriert.
”
NL. Die Anzahl der >“-Zeichen in dieser Spalte beschreibt die Schachtelungstiefe ( Nesting Level“) des
TID 5026
”
”
jeweiligen Inhaltselements
bzw.PELVIC
Templates
relativ
zum Inhaltselement
Zeile 1 des Templates. Fehlt diese
OB-GYN
VASCULAR
ULTRASOUND
MEASUREMENTin
GROUP
Type:
Extensible
Angabe, so handelt es sich um ein Geschwisterelement des Inhaltselements in Zeile 1.
- Standard Rel with Parent. Gibt den Typ der Relation zum Quellelement an. Die aktuelle Zeile beschreibt immer
das Zielelement der jeweiligen Relation. Handelt es sich um eine By-reference-Relation, so wird dem
Relationstyp R-“ vorangestellt (s. Abb. 20(a), Zeile 3).
”
VT. Beschreibt den Typ des Konzeptwertes ( Value Type“), falls die aktuelle Zeile ein Inhaltselement
”
beschreibt. Bindet die aktuelle Zeile hingegen ein anderes Template ein, so findet sich in dieser Spalte die
INCLUDE“-Anweisung (s. Abb. 20(b), Zeile 2 und 4).
”
Concept Name. Gibt Einschränkungen für den Wertebereich des Konzeptnamens an, falls die aktuelle
Zeile ein Inhaltselement beschreibt. Wenn in der vorhergehenden Spalte INCLUDE“ steht, so wird in
”
dieser Spalte das Zieltemplate angegeben (s. Abb. 20(b), Zeile 2 und 4).
VM. Gibt an, ob das in der jeweiligen Zeile spezifizierte Inhaltselement oder Template auch mehrfach
Seite 44
2
GRUNDLAGEN
hintereinander im Inhaltsbaum auftreten darf37 . Die untere Schranke ist dabei immer mindestens 1, Optionalität wird durch die beiden folgenden Spalten ausgedrückt.
Req Type. Beschreibt die Optionalität des betreffenden Inhaltselements bzw. Templates. Ein Element
kann verpflichtend ( M andatory“) oder optional ( U ser Option“) im Inhaltsbaum enthalten sein. Die
”
”
zusäzliche Angabe des Buchstabens C“ ( C onditional“) bedeutet, dass das Inhaltselement unter den in
”
”
der folgenden Spalte genannten Bedingungen angegeben werden muss ( MC“) oder angegeben werden
”
kann ( UC“).
”
Condition. Enthält die Bedingung, falls in der vorhergehenden Spalte MC“ oder UC“ steht. Eine häufig
”
”
verwendete Abkürzung in dieser Spalte ist XOR...“. Das Element der jeweiligen Zeile darf in diesem Fall
”
nur dann im Inhaltsbaum enthalten sein, wenn keine der anderen, im Ausdruck genannten Zeilen enthalten ist (s. Abb. 20(a), Zeile 3 und 4). Außerdem gibt es zwei verschiedene Fallunterscheidungen: IF...“
”
bedeutet, dass das Inhaltselement bzw. das eingebundene Template bei erfüllter Bedingung enthalten sein
muss und bei nicht erfüllter Bedingung enthalten sein kann, während IFF...“ die Abwesenheit bei nicht
”
erfüllter Bedingung erzwingt (s. Abb. 20(b), Zeile 2 und 3)38 .
Value Set Constraint. In dieser Spalte kann der Wertebereich für den Konzeptwert eines Inhaltselements
eingeschränkt werden. Auch die Angabe von Standardwerten für den Fall, dass das in der jeweiligen Zeile
beschriebene Inhaltselement in einem Inhaltsbaum fehlt, ist möglich. Wird in der jeweiligen Zeile ein
Template eingebunden, so können in dieser Spalte Parameter für das einzubindende Template gesetzt
werden (s. Abb. 20(b), Zeile 4). Parameter sind durch ein führendes $“-Zeichen gekennzeichnet und
”
können im eingebundenen Template an verschiedenen Stellen verwendet werden (s. Abb. 20(b), Zeile 1).
Weitere Details zum Aufbau von Templates sind Kapitel 6 in PS 3.16 zu entnehmen [DIC08a].
Einschränkungstypen Es gibt drei verschiedene Arten von Einschränkungen für Konzeptnamen und Konzeptwerte: Kodierte Begriffe, Verweise auf Kontextgruppen und Parameter.
Kodierte Begriffe werden in Templates als Tripel der Form (Kodewert, Kodierungsschema-Bezeichner, Kodebe”
deutung“) angegeben. Zusätzlich werden häufig die Modifikatoren EV ( Enumerated Value“) und DT ( Defined
”
”
Term“) verwendet. EV bedeutet, dass nur der angegebene Begriff zulässig ist, während DT neben dem angegebenen Begriff auch andere Werte erlaubt (vgl. PS 3.5, Kap. 6.3 [DIC08a]). Wird der Operator MemberOf{...}
verwendet, so sind nur die Begriffe aus den in den geschweiften Klammern referenzierten Kontextgruppen
zulässig.
Bei Verweisen auf Kontextgruppen werden die Abkürzungen BCID ( Baseline Context Group Identifier“) und
”
DCID ( Defined Context Group Identifier“) verwendet. Baseline“ bedeutet hier einen Vorschlag, Defined“ eine
”
”
”
39
feste Vorgabe . Für die Inklusion von Templates gibt es analog die Abkürzungen BTID ( Baseline Template
”
Identifier“) und DTID ( Defined Template Identifier“).
”
Umsetzung von DICOM-SR-Templates in XML Ein großes Problem beim maschinellen Umgang mit Templates ist die fehlende formale Notation für die letzten beiden Tabellenspalten, die zum Teil sehr komplexe
Formulierungen enthalten. Die maschinengerechte Aufbereitung von Templates, beispielsweise in ein semantisch
annotiertes XML-Format, ist daher keine triviale Aufgabe. Philips Research veröffentlichte 2005 einen allgemeinen Vorschlag für die Umwandlung von Template-Tabellen in XML-Schema-Dateien [Zha05], klammerte den
komplizierten Bereich der Einschränkungen dabei jedoch weitgehend aus. Ein Lösungsansatz mag das bereits
2002 veröffentlichtes Paper der gleichen Forschungsgruppe sein, in dem die Schemasprache Schematron [113]
verwendet wird, um komplex formulierte Einschränkungen zu beschreiben [Lee02]. Dieser Grundgedanke wurde
allerdings im Jahr 2005 patentiert [Lee05], was weitere Forschungsarbeiten behindern könnte.
37 DICOM-SR
verwendet hier wie schon bei der Definition mehrwertiger Attribute (vgl. Kap. 2.5.6) den Begriff Value Multiplicity“.
”
Der Autor hält diese Doppelverwendung für ungeschickt, da hier nicht nur der Konzeptwert, sondern auch der Konzeptname
eines Inhaltselements gemeint ist. Außerdem kann die Angabe auch eingebundene Templates betreffen. Eigentlich müsste man
also von Content Item / Template Multiplicity“ oder schlicht (Line) Multiplicity“ sprechen.
”
”
38 Die Definition
von XOR“, IF“ und IFF“ in Kombination mit der Definition von MC“ und UC“ ist nicht unproblematisch,
”
”
”
”
”
vgl. Nachfrage auf comp.protocols.dicom:
http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/34b33685fbc4f367.
39 Man beachte die widersprüchliche Bedeutung des Modifikators Defined“. Während er in Defined Term“ für eine liberalere
”
”
Auswahl steht, steht er hier für die striktere Vorgabe.
Seite 45
2
GRUNDLAGEN
2.6.5 DICOM-SR und CAD
Speziell für die drei in Kapitel 2.3 näher beschriebenen Anwendungsgebiete der Computergestützten Detektion
(CAD) bietet DICOM-SR eigene Informationsobjekte an.
Supplement 50 Mammography Computer-Aided Detection SR SOP Class“, das bereits im Mai 2001 verabschie”
det wurde, beschreibt ausführlich, wie Mammografie-CAD-Ergebnisse als DICOM-SR-Dokument gespeichert
werden sollen. Wie wichtig diese Anwendung von DICOM-SR ist, zeigen die 24 Templates (TID 4000-4023)
und ca. 100 Kontextgruppen (CID 6000-6097, 6159-6162, 4005, 4013-4015 etc.) im DCMR, die diesem Thema
gewidmet sind.
Die Ablage von CAD-Ergebnissen beim Thorax-Röntgen beschreibt das im Januar 2003 verabschiedete Supplement 65 Chest Computer-Aided Detection SR SOP Class“. Auch für diese Dokumentenklasse finden sich im
”
DCMR neun Templates (TID 4100-4108) und zahlreiche Kontextgruppen (CID 6100-6138 u. a.).
Die Erstellung von Befundberichten für die computergestützte Erkennung von Polypen im Dickdarm wird als
Supplement 126 Colon Computer-Aided Detection SR SOP Class“ entwickelt [17]. Supplement 126 befindet
”
sich derzeit (Juli 2008) in der Public Comment“-Phase, mit einer Verabschiedung ist also in den nächsten
”
Monaten zu rechnen.
2.6.6 Verwandte Standards
HL7-CDA Hauptkonkurrent von DICOM-SR ist sicherlich die HL7 Clinical Document Architecture (CDA).
CDA ist wie DICOM-SR ein Standard für strukturierte und semantisch annotierte Dokumente. Die derzeit
aktuelle Fassung von CDA ist Release 2, die seit 2005 vom ANSI standardisiert ist. Im Gegensatz zu DICOM
sind HL7-Standards nicht frei erhältlich. Für den Zugriff auf die wichtigsten Dokumente ist eine Mitgliedschaft
erforderlich, die für Einzelpersonen 600 US$ jährlich kostet, alternativ kann man den CDA-Standard einzeln
für 50 US$ beim ANSI kaufen [4]. Einführende Artikel finden sich in den einschlägigen Fachzeitschriften (z. B.
[DAB+06]).
Wie bereits in Abbildung 7 gezeigt, ist HL7 der dominierende Kommunikationsstandard in Krankenhäusern außerhalb des bildverarbeitenden Sektors. Außerdem wird HL7 zunehmend zur einrichtungsübergreifenden Kommunikation sowohl zwischen verschiedenen Kliniken als auch zwischen Kliniken und niedergelassenen Ärzten
verwendet. Durch die Verbreitung von HL7 hat CDA gute Chancen, der zentrale Standard für strukturierte
Dokumente im medizinischen Bereich zu werden. Insbesondere soll auch die deutsche elektronische Gesundheitskarte (eGK) in späteren Ausbaustufen CDA unterstützen. Bisher sind für den deutschen Markt ein elektronischer
Arztbrief und ein elektronischer ärztlicher Reha-Entlassungsbericht als CDA-Dokumente standardisiert40 . Auch
andere Länder wie die Niederlande, Spanien, Japan und Mexiko prüfen derzeit die Nutzung von HL7-CDA.
HL7-CDA fußt auf dem Reference Information Model“ (RIM) von HL7 Version 3. Daher werden CDA”
Dokumente – ebenso wie die verschiedenen Nachrichtentypen in HL7 Version 3 – XML-kodiert. CDA-Dokumente
können in HL7-Nachrichten verschickt werden, sie können aber auch unabhängig von Nachrichten, beispielsweise als Bestandteil einer elektronischen Gesundheitsakte, existieren. Ein CDA-Dokument besteht aus einem
Header“ und einem Body“, der wiederum in Sections“ unterteilt sein kann. Jede Section enthält einen Ab”
”
”
schnitt für Freitext, dessen Inhalte optional kodiert angegeben werden können. Ein CDA-Dokument kann auch
Multimedia-Inhalte wie Bilder und Tonaufnahmen enthalten, DICOM-Objekte können über WADO referenziert
werden. Umgekehrt können CDA-Dokumente in DICOM gekapselt werden, so dass sie sich in PACS-Systemen
speichern lassen. Diese Möglichkeit wurde mit DICOM-Supplement 114 DICOM Encapsulation of CDA Docu”
ments“ im Jahr 2007 eingeführt [17]. HL7-CDA kennt ebenso wie DICOM-SR ein Template-Konzept.
Um die Zusammenarbeit zwischen DICOM und HL7 zu verbessern, gibt es auf beiden Seiten spezielle Arbeitsgruppen. Bei DICOM ist dies WG-20 ( Integration of Imaging and Information Systems“), bei HL7 die
”
Imaging Integration Special Interest Group (SIG)“. Beide Gruppen arbeiten an einer Harmonisierung der
”
Standards, um den Übergang zwischen beiden Welten zu vereinfachen. Das erste große Produkt dieser Zusammenarbeit ist das kurz vor der Verabschiedung stehenden DICOM-Supplement 135 SR Diagnostic Imaging
”
Report Transformation Guide“ [17]. Dieses Supplement erklärt die Abbildung von DICOM-SR Dokumenten,
40 Für
beide Dokumententypen gibt es Implementierungsleitfäden und zusätzliche Materialien auf den Webseiten der deutschen
HL7 Benutzergruppe [46].
Seite 46
2
GRUNDLAGEN
die dem Root-Template 2000 Basic Imaging Report“ entsprechen, in Dokumente der CDA-Dokumentenklasse
”
Diagnostic Imaging Report“ (DIR, [Hea07]), die zur Zeit von der HL7-Arbeitsgruppe Structured Documents“
”
”
entworfen wird [Hea08]. Eine Einführung in diese Thematik wurde vor kurzem im Rahmen eines Hauptseminars
am IMI Lübeck erarbeitet [Wag08].
Integrating the Healthcare Enterprise (IHE) Eine weitere wichtige Institution im Zusammenhang mit DICOMSR und HL7-CDA ist Integrating the Healthcare Enterprise“ (IHE) [50]. Diese Initiative, die ähnlich wie der
”
DICOM-Standard von verschiedenen Anwendergruppen und Herstellern medizintechnischer Geräte vorangetrieben wird, hat sich das Ziel gesetzt, die Interoperabilität verschiedener im Gesundheitswesen etablierter
Standards zu verbessern. Dazu definiert IHE in sogenannten Integrationsprofilen ( Integration Profiles“) typi”
sche klinische Anwendungsfälle einer medizinischen Fachdisziplin und nennt die beteiligten Akteure ( Actors“)
”
und Transaktionen ( Transactions“). Ein Akteur ist ein IT-System, das Daten erzeugt, bearbeitet oder verwal”
tet. Transaktionen sind Interaktionen zwischen den Akteuren zum Datenaustausch. Für jede Transaktion wird
festgelegt, welche Standards zum Einsatz kommen. Aufgrund ihrer Verbreitung wird dabei häufig auf DICOM
und HL7 zurückgegriffen. Interoperabilitätsdefizite zwischen verschiedenen Standards werden an die jeweiligen
Standardisierungsgremien zurückgemeldet.
Alle Integrationsprofile einer medizinischen Fachdisziplin mit ihren Akteuren und Transaktionen werden schließlich in einem Dokument veröffentlicht, das Technical Framework“ genannt wird. Auf großen Testveranstaltun”
gen, den Connectathons“ versucht die medizintechnische Industrie mit ihren Lösungen die Integrationsprofile
”
zu realisieren. Nach den Tests formulieren die Firmen in sogenannten Integration Statements“, welche Inte”
grationsprofile von ihren Produkten unterstützt werden [49]. Diese Praxis ähnelt den DICOM Conformance
”
Statements“ (vgl. Kap. 2.5.1.1).
Das Technical Framework“ für die Pathologie wurde Anfang 2008 als Vorabversion ( Trial Implementation“)
”
”
veröffentlicht und enthält insbesondere das neue Integrationsprofil Pathology Workflow“ (PWF) [IHE08]. Dieses
”
Integrationsprofil beinhaltet bereits Informationen zum Umgang mit Befundberichten in der Pathologie (vgl.
Abb. 21). Vollständiger und genauer soll der Arbeitsablauf für Befundberichte im Integrationsprofil Pathology
”
Report Workflow“ (PRWF) beschrieben werden, das sich derzeit in Entwicklung befindet und 2009 in das
Technical Framework aufgenommen werden soll.
2.6.7 Informationsquellen zu DICOM-SR
Das in Abschnitt 2.5.12 bemängelte Fehlen an einführender Literatur zu DICOM trifft auf DICOM-SR in
verstärktem Maße zu.
Eine naheliegende Informationsquelle zu DICOM-SR wäre der DICOM-Standard selbst. DICOM Structured
Reporting (DICOM-SR) wurde wie oben erwähnt mit Supplement 23 eingeführt und durch Supplement 53
erheblich erweitert [17]. DICOM Supplements sind für sich gesehen recht unverständlich, da sie ausschließlich
die Unterschiede zur vorherigen DICOM-Version beschreiben. Sie sind also als einführende Literatur ungeeignet.
Das Exzerpieren der für Structured Reporting relevanten Informationen aus dem vollständigen DICOM-Standard
ist aufgrund des Umfangs mühsam und erfordert häufiges Blättern im Text41 . Wer sich dennoch anhand des
Standards in DICOM-SR einarbeiten will, sollte zunächst PS 3.3 studieren: Dort sind im Anhang A.35 die grundlegenden Dokumentenklassen definiert. Details zu den DICOM-SR-spezifischen Modulen finden sich ebenfalls in
PS 3.3 in Anhang C.17 und C.18. Essentiell ist weiterhin das Studium von PS 3.16, der zentralen Sammelstelle
für Templates und Kontextgruppen. Möchte man selbst DICOM-SR-Software programmieren, so kommt man
schließlich nicht um ein gelegentliches Nachschlagen in PS 3.5 und PS 3.6 herum.
Einführende Literatur Wesentlich schneller lassen sich die DICOM-SR-Prinzipien durch spezielle Literatur
erlernen. Das einzige dem Autor bekannte Buch speziell zum Thema DICOM-SR ist DICOM Structured Re”
porting“ von David A. Clunie, das gleichzeitig mit der Verabschiedung des DICOM-SR Standards im Jahr
2000 erschien und inzwischen kostenlos heruntergeladen werden kann [Clu00]. Das Buch setzt allgemeine DICOM-Grundkenntnisse voraus, ist ansonsten aber sehr verständlich und praxisnah geschrieben. Das Buch ist
mittlerweile an vielen Stellen veraltet. Eine Neuauflage ist bisher nicht in Sicht.
41 Allein
PS 3.3 umfasst mehr als 1.000 Seiten, siehe Tabelle 1.
Seite 47
382
384
2
386
388
390
The diagnostic process in anatomical pathology (figure 1) differs from that in the clinical
laboratory since it relies on image interpretation. It also differs from that in radiology since it
is specimen-driven and when digital imaging is performed many types of imaging equipments
GRUNDLAGEN
(gross imaging, microscopic still imaging, whole slide imaging, multispectral imaging, etc)
may be involved for a single examination. Moreover, images of the same study may be
related to different specimen (parts and/or slides) from one or even different patients (e.g.
Tissue Micro Array). Finally, slides are always available to acquire more images, if needed.
In radiology, the diagnostic process is patient-driven, an examination (study) usually involves
a single image acquisition modality and all images of the study are related to one and only
one patient.
IHE PAT Technical framework, vol.1 (PAT TF-1): Integration profiles
___________________________________________________________________________
594
3
Pathology Workflow
(PWF) Darstellung (aus [IHE08], Abb. 1)
(a) Schematische
__________________________________________________________________________________________
10/41
Copyright © IHE-International
Publication 25/01/2008
3.1
Actors/Transactions
Rev.1.14 Trial Implementation
596
Evidence
Creator
Order Placer
Storage Commitment
(RAD-10)
Placer Order Mgmt (PAT-1)
Filler Order Mgmt (PAT-2)
Order Filler
Procedure Scheduled
And Updated (PAT-4)
Image
Manager
Storage Commitment
(RAD-10)
Order Results
Mgmt
(PAT-3)
Query Modality
Worklist (PAT-5)
Evidence
Document
Stored (RAD-43)
Image
Archive
Query Images
(RAD-14)
Retrieve Images
(RAD-16)
Image
Display
Modality Image
Stored (RAD-8)
Acquisition
Modality
Order
Result
Tracker
(b) Abstraktes Modell mit Akteuren und Transaktionen (aus [IHE08], Abb. 3.1)
Figure 3.1-Pathology Workflow (PWF)
Abbildung 21: Arbeitsablauf in der Pathologie aus Sicht von IHE
598
Table 3.1 – Pathology Workflow – Actors and Transactions
Actors
Order Placer
Order Filler
Transactions
Optionality
Documentary
reference
Patient Identity Feed (ITI-030)
R
ITI TF-2 : 3.30
Patient Encounter Management (ITI-031)
R
ITI TF-2 : 3.31
Placer Order management (PAT-1)
R
Pathology TF-2
Filler Order Management (PAT-2)
R
Pathology TF-22
Patient Identity Feed (ITI-030)
R
ITI TF-2 : 3.30
Patient Encounter Management (ITI-031)
R
ITI TF-2 : 3.31
Seite 48
2
GRUNDLAGEN
Eine deutschsprachige Einführung in DICOM und DICOM-SR findet sich in Kapitel 3 der Dissertation von
Jörg Riesmeier [Rie06]. Das Kapitel ist sowohl vom Umfang (ca. 65 Seiten) als auch vom Schreibstil her einsteigerfreundlich. Die Dissertation ist jedoch derzeit nicht im herkömmlichen Buchhandel erhältlich, sondern muss
über Bibliotheken besorgt werden.
Eine gelungene Kurzeinführung in DICOM-SR schließlich bietet das englischsprachige Paper DICOM Structu”
red Reporting“ von Mitarbeitern des Deutschen Krebsforschungszentrums (DKFZ) [HES+04a].
Beschreibung der Vorteile von DICOM-SR Schon 1998, also deutlich vor der offiziellen Freigabe von DICOMSR, beschäftigte sich W. Dean Bidgood Jr. mit den Vorteilen des Einsatzes von DICOM-SR für die Befundung
von Bildern und Signalverläufen [Bid98a]. Rita Noumeier führt in einem aktuelleren Paper aus dem Jahr 2006
stichwortartig zahlreiche Vorteile von DICOM-SR auf [Nou06].
Implementierungen Allgemeine Überlegungen zur Implementierung von DICOM-SR-Lösungen wurden schon
2001 von der US-Regierung veröffentlicht [CDK01]. Das Oldenburger OFFIS-Institut wurde im gleichen Jahr
konkreter und publizierte über die eigene, generische DICOM-SR-Implementierung DICOMscope“ [REK+01].
”
Von der University of California stammt eine Arbeit, die im Jahr 2002 erschien und die nachträgliche Erstellung von DICOM-SR-Dokumenten durch Text-Retrieval in Freitextbefunden der Neuroradiologie beschreibt
[MST+02]. Erste industrielle Ansätze veröffentlichte die Forschungsabteilung von Philips ebenfalls im Jahr
2002 in Form von Plänen zum Einsatz von DICOM-SR in Kombination mit XML bei Ultraschalluntersuchungen [SLM02]. Ein Jahr später erschien ein Paper von Agfa-Mitarbeitern, das einen ebenfalls XML-zentrierten
Ansatz für verschiedene Modalitäten beschrieb [JB03]. Einen interessanten Lösungsansatz auf Basis von Templates publizierte im gleichen Jahr das deutsch-brasilianische Forschungsprojekt Cyclops [BWM03]. Das DKFZ
veröffentlichte 2004 einen Ansatz, bei dem DICOM-SR-Dokumente zur Bearbeitung in HTML und schließlich
wieder zurück in DICOM-SR transformiert werden [HES+04b]. Den Einsatz von DICOM-SR für die Teleradiologie in Deutschland untersuchte im Jahr 2006 die Universität Freiburg im Rahmen des Projekts Südbaden“
”
[PPZ06]. Eine aktuelle Publikation von David A. Clunie stellt dar, wie die Ergebnisse klinischer Studien als
DICOM-SR-Dokumente abgelegt werden können, und vergleicht diese Möglichkeiten mit denen anderer Standards wie HL7-CDA und OWL [Clu07].
Internet Als Informationsquellen zu DICOM-SR im Internet sind im Wesentlichen dieselben wie zu DICOM
allgemein zu nennen (vgl. Kap. 2.5.12).
Seite 49
3
ALLGEMEINER LÖSUNGSANSATZ
3 Allgemeiner Lösungsansatz
Ziel dieser Arbeit ist das Bereitstellen von Werkzeugen zum Erzeugen pathologischer Befundberichte nach dem
DICOM-SR-Standard zu deren nachträglicher Bearbeitung (vgl. Kap. 1.3).
Anwendungsfälle Abbildung 22 zeigt einige Anwendungsfälle im Zusammenhang mit diesen Tätigkeiten. Der
Autor konzentriert sich im Folgenden auf die Anwendungsfälle mit menschlichen Benutzern, da für diese nicht
nur der DICOM-SR-Standard beherrscht, sondern auch eine Benutzerschnittstelle entworfen werden muss. Da
die meisten Pathologen keine DICOM-SR-Experten sind, muss diese Benutzerschnittstelle leicht verständlich
sein und vor Eingabefehlern schützen. Sobald die technische Infrastruktur für menschliche Benutzer steht, sollte
die Umsetzung der Anwendungsfälle mit maschinellen Benutzern keine Schwierigkeiten mehr bereiten.
Benutzer
Mensch
Erzeugen
Vorgang
Bearbeiten
Maschine
Anlegen neuer
Befundberichte
Ablage von Messwerten
oder Ergebnissen einer
automatischen Bildanalyse
Erzeugen eines „Gerüsts“
für einen menschlich
generierten Befundbericht
Korrektur menschlich
erzeugter Befundberichte
Erweiterung maschinell
oder menschlich erzeugter
Befundberichte
Suche nach
Befundberichten
Batch-Korrektur (z.B.
Umstellung auf andere
Kodierungsschemata)
Abbildung 22: Anwendungsfälle für das Erzeugen und Bearbeiten von DICOM-SR-Dokumenten
Abstraktionsebenen beim Umgang mit DICOM-SR Das interaktive Erzeugen und Bearbeiten von DICOMSR-Dokumenten kann auf verschiedenen Abstraktionsebenen stattfinden.
3 Fachrichtungsspezifische Eingabemaske mit
abschließender DICOM-SR-Generierung
Nähe zum Standard,
Manipulationsmöglichkeiten,
Breite des Einsatzgebiets
2 Template-geführter DICOM-SR Editor
Abstraktionsgrad,
Bedienbarkeit durch Ärzte,
Spezialisierung auf
Anwendungsgebiete
1 Generischer DICOM-SR Editor
Abbildung 23: Drei Abstraktionsebenen für die interaktive Erzeugung und Bearbeitung von DICOM-SRBefundberichten
Abbildung 23 zeigt drei denkbare Ebenen:
Auf der untersten Ebene findet sich der Ansatz mit der maximalen Anzahl an Freiheitsgraden. Software auf
dieser Ebene erlaubt den freien Aufbau von DICOM-SR-Dokumenten aus den zulässigen Inhaltselementund Relationstypen der jeweiligen Dokumentenklasse (vgl. Kap. 2.6.2.3). Damit ist solche Software für
jede Anwendungsdomäne von DICOM-SR einsetzbar. Der menschliche Benutzer muss mit dem Aufbau
Seite 50
3
von DICOM-SR-Dokumenten gut vertraut sein und die Bedeutung der Typen von Inhaltselementen und
Relationen kennen.
Die mittlere Ebene erlaubt keinen freien Aufbau von DICOM-SR-Dokumenten, sondern führt den Benutzer
durch ein DICOM-SR-Template (vgl. Kap. 2.6.4). Der Benutzer muss sich daher (je nach Template)
nur noch wenig Gedanken über den sinnvollen strukturierten Aufbau eines Befundberichts machen – die
Interaktion beschränkt sich auf die Auswahl einer geeigneten Option aus einer Liste. Dafür benötigt der
Benutzer immer noch Kenntnis über die Bedeutung der Inhaltselement- und Relationstypen von DICOMSR. Ein templategestützter DICOM-SR-Editor ist nicht mehr universell einsetzbar, sondern erlaubt nur
die Erstellung und Bearbeitung von Dokumenten, für die Templates vorliegen.
Software der obersten Abstraktionsebene schließlich verbirgt DICOM-SR vollständig vor dem Benutzer.
Die Eingabe erfolgt über ein an das jeweilige Anwendungsszenario genau angepasstes Formular und ist
daher für Ärzte besonders benutzerfreundlich. Bearbeiten lassen sich nur ganz bestimmte Klassen von
DICOM-SR-Dokumenten. Lösungen auf der obersten Ebene lassen sich tendenziell schlechter an andere
Fachgebiete anpassen. Ein direkter Zugriff auf den DICOM-SR-Inhaltsbaum ist nicht möglich.
Ideal wäre Software, die alle drei Ebenen abdeckt. Minimalanforderung ist die oberste Ebene, um Anwender
zufriedenzustellen, und die unterste für tiefgreifende Manipulationen am DICOM-SR-Inhaltsbaum und zum
Debugging.
Darstellung von DICOM-SR-Dokumenten Der DICOM-SR-Standard enthält keine Vorgaben zur Darstellung von DICOM-SR-Dokumenten. Bezüglich der Darstellung eines fertigen Befundberichts auf dem Bildschirm
oder im Ausdruck herrscht also ebenso völlige Implementierungsfreiheit wie bei der Benutzeroberfläche zum
Bearbeiten eines Dokuments. Auf den standardnahen unteren beiden Abstraktionsebenen scheint es einleuchtend, für die Bearbeitung eine Baumdarstellung zu wählen, da DICOM-SR-Dokumente auf einer baumförmigen
Datenstruktur basieren (vgl. Kap. 2.6.2). Für eine bessere Lesbarkeit durch den Menschen scheint für Software
der obersten Ebene oder zur Darstellung der Endergebnisse nach Bearbeitung durch Software für die unteren beiden Ebenen hingegen eine linearisierte Form des Inhaltsbaumes sinnvoll. Außerdem sollten die für den
menschlichen Betrachter weniger relevanten Informationen ausgeblendet werden. Beispielsweise können Kodes
durch ihre Klartextbedeutung ersetzt werden.
Der DICOM-SR-Standard hat zur Zeit eine geringe Verbreitung. Insofern sollte als ein Aspekt der Darstellung
von DICOM-SR-Dokumenten auch deren Export in verbreitetere Formate berücksichtigt werden.
3.1 Implementierungsplan
Zunächst soll unter dem Arbeitsnamen GENRE ( Generic Report E ditor“) ein möglichst generischer Editor
”
für die Bearbeitung von DICOM-SR-Dokumente auf der untersten Abstraktionsebene implementiert werden.
Im Zusammenhang mit Komponenten, die die Funktionalität von GENRE ergänzen oder eine andere Sicht auf
die von GENRE verwalteten Daten bieten, wird im Folgenden auch vom GENRE-System gesprochen.
Abbildung 24 zeigt einige Bausteine des geplanten GENRE-Systems, von denen die meisten im Rahmen dieser
Arbeit realisiert wurden:
1. Im Mittelpunkt des GENRE-Systems steht eine grafische Oberfläche zur Darstellung des DICOM-SRInhaltsbaums mit Funktionen zu dessen Manipulation. Diese Benutzerschnittstelle wird in Kapitel 4.3.2.2
beschrieben.
2. Die Baumansicht soll das Einfügen von Inhaltelementen gemäß der verwendeten Dokumentenklasse erlauben. Später soll auch das templategeführte Einfügen von Inhaltselementen, also die Arbeit auf der
mittleren der oben erwähnten Abstraktionsebenen, ermöglicht werden.
3. Für das Erstellen standardisierter Dokumentation (vgl. Kap. 2.4), soll Zugriff auf das kontrollierte Vokabular des DICOM-Standards, die sogenannten Kontextgruppen (vgl. Kap. 2.6.3) erlaubt werden. Die
Implementierungsarbeit hierzu wird in Kapitel 4.1 beschrieben.
4. Neben dem Inhaltsbaum soll auch der Dokumentenkopf von DICOM-SR-Dokumenten bearbeitet werden
können (siehe Kap. 4.3.2.1).
5. In einem späteren Schritt soll über die oberste der Abstraktionsebenen aus Abbildung 23, nämlich fachrichtungsspezifische, benutzerfreundliche Eingabemasken für die Verwendung durch Ärzte, nachgedacht
werden (vgl. Kap. 4.5).
Seite 51
3
Eingabe
Verarbeitung
Ausgabe
6. Editieren der
Konzeptnamen von
Inhaltselementen
2. Standardkonformes,
generisches
Erstellen von
Inhaltselementen
nach IOD /
Template
3. Eingabe über
Kontextgruppen des
DCMR
8. Ausgabe als
DICOM-Dump
1. Intuitive
Baumansicht,
Löschen und
Verschieben
von Knoten
9. Ausgabe als
XML/HTML
4. Eingabe der
Attribute im
Dokumentenkopf
5. Assistenten für
das Neuanlegen
von Befunden für
spezifische med.
Fachrichtungen
10. Ausgabe in
Office-Formate
7. Komfortables
Bearbeiten der Werte
von Inhaltselementen
Abbildung 24: Einige konzeptionelle Bausteine des GENRE-Systems
Seite 52
3
6. Konzeptnamen von Inhaltselementen sollen bearbeitet werden können (vgl. Kap. 4.3.2.3).
7. Besonders wichtig ist natürlich das Bearbeiten der Konzeptwerte von Inhaltselementen. Hierzu sollen
komfortable Eingabeelemente gestaltet werden (Kap. 4.3.3).
8.-10. Schließlich soll der Export von DICOM-SR-Dateien in andere Formate ermöglicht werden (vgl. Kap.
4.3.2.4).
3.2 Erwartete Implementierungshindernisse
Betrachtet man das Zusammenspiel von GENRE mit dem in Kapitel 1.2 genannten Forschungsprojekt, sind
einige Hindernisse zu erwarten, die im Rahmen dieser Diplomarbeit nicht gelöst werden können.
Abschnitt 2.2 beschreibt, dass die Digitale Pathologie derzeit noch nicht im Routineeinsatz verwendet wird.
Insbesondere sind
Slide-Scanner noch zu langsam und
die entstehenden Datenmengen mit derzeitiger Technik nicht beherrschbar – das betrifft kurzfristige und
langfristige Speicherung ebenso wie die automatische Bildanalyse bei voller Bildauflösung.
In Abschnitt 2.5.11 wurde außerdem dargestellt, dass DICOM viele Voraussetzungen für einen Routineeinsatz
in der Pathologie noch nicht erfüllt. Unter anderem müssen folgende Aspekte DICOM-standardisiert werden:
Unterstützung von virtuellen Präparaten ( Whole Slide Images“, WSI) und anderen in der Pathologie
”
verwendeten Bildern
Speicherung von Patientendaten für Tissue-Micro-Arrays (TMAs)
Effizienter Zugriff auf Bilder mit einem Datenumfang von mehreren Gigabyte
Für diese Diplomarbeit werden daher folgende Annahmen gemacht:

Die DICOM-konforme Ablage von virtuellen Präparaten und anderen pathologischen Bildern ist möglich
Die Erstellung von virtuelle Präparaten und der Zugriff darauf sind ausreichend effizient möglich
Es steht genügend Rechenleistung für die automatische Bildanalyse in virtuellen Präparaten zur Verfügung
TMAs werden nicht berücksichtigt
Seite 53
4
KONZEPTION, IMPLEMENTIERUNG UND ANWENDUNG
4 Konzeption, Implementierung und Anwendung
In diesem Abschnitt wird die Implementierung einzelner Bausteine des GENRE-Systems beschrieben. Die Arbeit
richtet sich nach dem Implementierungsplan aus dem vorhergehenden Kapitel.
Kapitel 4.1 beschreibt Vorarbeiten für die Verwendung der DICOM-Kontextgruppen in GENRE. Kapitel 4.2
beschäftigt sich mit Vorüberlegungen zur Implementierung von GENRE selbst. Das Kernstück des Implementierungsteils ist Kapitel 4.3, das die eigentliche Implementierungsarbeit von GENRE beschreibt.
Der Rest des Implementierungsteils widmet sich dem Einsatz von GENRE in der Pathologie. Dazu werden
in Kapitel 4.4 zunächst beispielhafte Untersuchungsfälle aus der Pathologie vorgestellt und darauf aufbauend
ein Assistent für die strukturierte Eingabe von Befundberichten konzipiert. Die technische Realisierung dieses
Eingabeassistenten beschreibt Kapitel 4.5. Eine erste Bewertung des GENRE-Systems durch Pathologen findet
sich schließlich in Kapitel 4.6.
4.1 Erstellung einer maschinenlesbaren Version der DICOM-Kontextgruppen
Wie in Kapitel 2.4 dargestellt wurde, gibt es zahlreiche Vorteile, wenn medizinische Dokumentation nicht nur
strukturiert, sondern auch kodiert abgelegt wird. Bei kodierter Dokumentation beschränkt man den verwendeten Wortschatz auf ein kontrolliertes Vokabular und verwendet statt der jeweiligen gewünschten Terme deren
eindeutige Schlüssel im Vokabular. Daher spricht man häufig auch von Verschlüsselung“, obwohl dieser Begriff
”
in den meisten Informatikdisziplinen mit dem Fachgebiet der Kryptografie assoziiert wird.
Es ist naheliegend, in DICOM-SR-Dokumenten die Vielzahl standardisierter Begriffe aus den Kontextgruppen
des DCMR zu verwenden (vgl. Kap. 2.6.3). Um Software herzustellen, die einfachen Zugriff auf die DICOMKontextgruppen ermöglicht, müssen diese in maschinenverständlicher, strukturierter Form vorliegen. Erstaunlicherweise sind die DICOM-Kontextgruppen in solcher Form bislang nicht frei erhältlich42 , was vermutlich der
bisher geringen Verbreitung von DICOM-SR geschuldet ist. Diese Lücke soll in der vorliegenden Diplomarbeit
geschlossen werden.
4.1.1 Konzeption
Der DICOM-Standard wird in Form von Microsoft-Word-Dokumenten gepflegt, die auf menschliche Leser zugeschnitten und nicht als Datenbasis für Software geeignet sind. Besserung verspricht die Umstellung des DICOM-Standards auf das DocBook-XML-Format, das die bisherigen Word-Dateien vollständig ablösen soll und
zumindest die Erstellung der gewünschten maschinenlesbaren Attribut-Wert-Listen erleichtern würde. An dieser
Umstellung wird schon seit ca. fünf Jahren gearbeitet [DIC05], ein konkretes Erscheinungsdatum der DICOMDocBook-Version ist jedoch immer noch nicht bekannt43 .
Die Kontextgruppen sind nicht die einzigen Attribut-Wert-Listen im DICOM-Standard, bei denen eine maschinenlesbare Version sinnvoll ist. Das in DICOM-Anwendungen häufig benötigte DICOM Data Dictionary aus PS
3.6, ebenfalls ein umfangreicher tabellarischer Datensatz, liegt praktisch jedem DICOM-Toolkit als inoffizielle,
maschinenlesbare Version bei44 . Diese Lösungen können als Anregung für das Problem der Kontextgruppen
dienen.
Die maschinenlesbare Version aller Kontextgruppen sollte automatisiert erzeugt werden, da das manuelle Erzeugen und Aktualisieren sehr arbeitsaufwändig und fehlerträchtig ist. Eine automatische Generierung kann
42 Ergebnis
einer Internetrecherche des Autors und einer Nachfrage auf comp.protocols.dicom am 16.1.2008,
http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/d21374087a70a996/b893c72e73702277.
43 Vgl. Aussage von D. Clunie in der Newsgroup comp.protocols.dicom am 19.1.2008: There is no commitment to a time line.
”
Hopefully sometime during 2008, but then last year I said hopefully sometime during 2007.“
(http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/d21374087a70a996/adb8a20bbd36a86b#
e5e4b60ab3f984ea)
und die Aussage auf einem DICOM WG-6-Treffen Ende Juni 2008:
[P]rogress ha[s] fallen far behind expectations. Only about 100 of 381 figures ha[ve] been completed. Recent discussions with
”
the contractor indicate that the project can be completed in September or October.“ [DIC08f]
44 Das GDCM [61] enthält beispielsweise eine XML-Datei mit den gewünschten Informationen, siehe
http://gdcm.svn.sourceforge.net/viewvc/gdcm/trunk/Source/DataDictionary/Part6.xml?view=markup
Seite 54
Page 284
CID 227
4
Sample Statistical Descriptors
Context ID 227
Sample Statistical Descriptors
Type: Extensible
Version: 20030327
hingegen, eine entsprechende
Softwarearchitektur
vorausgesetzt,
auch auf zukünftige Versionen des DICOMCoding Scheme
Code Value
Code Meaning
Standards angewandt
werden.
Designator
Als Quasi-Standard
für strukturierte121415
Klartext-Daten hat
sich seitRanking
Ende der
1990er Jahre XML etabliert. Dieses
DCM
Percentile
of measurement
Format soll auch hier
verwendet werden,
da eine solche Lösung
flexibel ist: Für die Transformation von
DCM
121416
Z-Score besonders
of measurement
XML in andere Formate wie CSV oder Tabellen für eine relationale Datenbank existieren Standardwerkzeuge.
Umgekehrt ist die Transformation von den flacheren Datenstrukturen einer CSV-Datei oder Datenbanktabelle
Equation or Table
in XML nicht oderCID
nur228
mit Aufwand möglich.
4.1.2 Implementierung
Context ID 228
Equation or Table
Type: Extensible
Version: 20030327
Zunächst wurde die Word-Version von PS 3.16 in eine DocBook-XML-Fassung überführt. Dazu wurde OpenOfCoding
Scheme Code
Value
Code Meaning importieren und in einem sehr einfachen
fice.org Writer 2.3.1
[87] verwendet,
das Microsoft-Word-Dokumente
Designator
DocBook-XML-Format speichern kann. Da OpenOffice.org in der verwendeten Version kleinere Fehler beim
DocBook-Export hat,
die im GDCM-Wiki
DCMwurden außerdem
121420
Equationbeschriebenen Patches durchgeführt [62].
DCMExtraktion der121421
Citation
Um eine einwandfreie
Kontextgruppen Equation
aus der DocBook-XML-Version
zu gewährleisten, wurde
PS 3.16 händisch auf
Inkonsistenzen121424
untersucht. DabeiTable
entdeckte
der Autor zahlreiche Fehler wie inkonsistente
DCM
of Values
Spaltenüberschriften,
und
Tippfehler.
Eine Reihe dieser Fehler wurden an die
DCMinkonsistente Formatierungen
121422
Table
of Values Citation
Newsgroup comp.protocols.dicom gemeldet45 .
DCM
121423
Method Citation
Eine geeignete XML-Sprache für die Beschreibung von Kontextgruppen drängte sich nahezu auf und wurde vom
Autor in XML-Schema spezifiziert46 . Das mit der Kontextgruppe in Abbildung 25 assoziierte XML-Fragment
CID 230 aus:
Yes-No
etwa sieht folgendermaßen
Context ID 230
Yes-No
Type: Non-extensible
Version: 20060613
Coding Scheme
Designator
Code Value
Code Meaning
SRT
R-0038D
Yes
SRT
R-00339
No
SRT
R-0038A
Undetermined
Abbildung
25: Kontextgruppe
230 Yes-No“ (PS 3.16, Anhang B [DIC08a]
CID 240
Present-Absent
”
Context ID 240
<ContextGroup extensible="false" id="230" name="Yes-No"
version="20060613">
Present-Absent
<Concept meaning="Yes" scheme="SRT"
value="R-0038D"/>
Type: Non-extensible
Version: 20050110
<Concept meaning="No" scheme="SRT" value="R-00339"/>
<Concept meaning="Undetermined"
scheme="SRT"
value="R-0038A"/>
Coding Scheme
Code
Value
Code
Meaning
</ContextGroup>Designator
SRT
G-A203
Present
Möchte man auch SRT
sprachliche Varianten
von Kontextgruppen
R-4089B
Absent realisieren, so könnte man <ContextGroup>- und
<Concept>-Tag zum Beispiel wie folgt erweitern:
- Standard -
<Concept meaning="Yes" scheme="SRT" value="R-0038D">
<Translation lang="de" meaning="Ja"/>
<Translation lang="fr" meaning="Oui"/>
...
</Concept>
45 Vgl.
Posting unter
http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/d21374087a70a996#f1d24ae852761469
46 Das XML-Schema kann auf der Begleithomepage zu dieser Arbeit heruntergeladen werden [98]. Jörg Riesmeier verwendet in
seiner Dissertation ein sehr ähnliches Schema (vgl. Anhang C.3.3 und E.2 in [Rie06]), verzichtet jedoch auf die Angabe von
Code Meaning und etwaigen äquivalenten Kodes einer Referenzterminologie.
Seite 55
4
Das Programm zur Extraktion der Kontextgruppen aus der oben genannten vorläufigen DocBook-XML-Version
des DCMR sowie zur automatischen Transformation in das oben beschriebene Format, wurde vom Studenten
Marco Wegner im Rahmen einer Praktikumsarbeit geschrieben. Statt der ursprünglich vorgesehenen Verwendung von XSL-T, einer Programmiersprache speziell zur Umwandlung von XML-Dokumenten in andere XMLDokumente, wurde bei der Programmierplattform auf Java zurückgegriffen. Dies hatte im Wesentlichen folgende
Gründe:
Bei der Extraktion der Daten für die Kontextgruppen ist oftmals die Verwendung regulärer Ausdrücke
sinnvoll, beispielsweise um mehrere nahezu gleiche Fälle, die durch kleine Inkonsistenzen im DICOMStandard entstehen, mit einem einzigen Befehl zu behandeln. Reguläre Ausdrücke sind in XSL-T allerdings
nur in der noch nicht weit verbreiteten Version 2.0 möglich (xsl:analyze-string), für die bisher nur
wenige Prozessoren existieren (z. B. SAXON-B bzw. SAXON-SA [55]).
Der Praktikant hatte gute Java-Kenntnisse, aber nur geringe Erfahrung mit XSL-T.
Nicht alle Kontextgruppen werden vollständig durch Tabellen im DCMR beschrieben. In einigen Kontextgruppen wird stattdessen auf andere Standards verwiesen. Die folgenden Kapitel 4.1.2.1 bis 4.1.2.5 gehen auf diese
Kontextgruppen näher ein. Anschließend wird ein grafischer Dialog zum einfachen Zugriff auf die Konzepte der
Kontextgruppen beschrieben. Kapitel 4.1.2.7 betrachtet technische Details bei der maschinellen Handhabung
der DCMR-Kontextgruppen.
4.1.2.1 Kontextgruppe 82 Units of Measurement“
”
Für die kodierte Angabe von Maßeinheiten verweist DICOM in Kontextgruppe 82 auf den Standard Unified
”
Code for Units of Measure“ (UCUM [96]). Der ebenso wie LOINC (vgl. Kap. 4.1.2.5) vom Regenstrief-Institut
bereitgestellte UCUM definiert eine Liste von Einheiten und Präfixen sowie Regeln zu deren Kombination und
Operationen wie Multiplikation und Division. Auf diese Weise können unendlich viele gültige Einheiten abgeleitet werden. UCUM erhebt den Anspruch, alle derzeit in Wissenschaft, Technik und Wirtschaft verwendeten
Maßeinheiten zu beinhalten.
Für die interaktive Eingabe von UCUM-Kodes bräuchte man eine elektronische Eingabehilfe, die dem Laien
die Konstruktion gültiger UCUM-Kodes aus Basiseinheiten und abgeleiteten Einheiten erlaubt. Eine solche
Eingabehilfe geht über das Thema dieser Diplomarbeit hinaus und wurde daher nicht realisiert.
Eine möglicherweise hilfreiche Minimallösung bestünde darin, zumindest die gängigsten im Gesundheitswesen
verwendeten Maßeinheiten als statische Tabelle in die XML-Datei aufzunehmen. Eine solche Liste wird von der
deutschen HL7-Benutzergruppe bereitgestellt [45]. Nach Rücksprache mit dem Betreuer dieser Arbeit wurde
aber auch auf die Aufnahme dieser Kodes verzichtet.
Neben dem allgemeinen Verweis auf UCUM in Kontextgruppe 82 tauchen im DCMR an etlichen Stellen fertig
komponierte UCUM-Kodes auf (vgl. Tab. 447 ). Diese wurden selbstverständlich in die XML-Datei integriert.
4.1.2.2 Kontextgruppe 5000 Languages“
”
Kontextgruppe 5000 beinhaltet alle Tags für Sprachen nach IETF RFC 3066 [IET01]. Laut RFC 3066 bestehen
Sprachtags aus einem primären Subtag“ und einer optionalen, beliebig langen Liste darauf folgender Subtags“.
”
”
Als Quelle für das primäre Subtag wird im Wesentlichen ISO 639 genannt (vgl. Tab. 5). Im DCMR ist festgelegt,
dass bevorzugt zweibuchstabige Sprachtags nach ISO 639 Teil 1 verwendet werden sollen. Falls eine genauere Unterscheidung notwendig ist, können die dreibuchstabigen Kürzel aus ISO 639 Teil 2 verwendet werden,
wobei hier laut DCMR die Variante ISO 639-2/T ( terminology“) bevorzugt wird. Neben ISO 639-2/T exis”
tiert noch eine Variante ISO 639-2/B ( bibliographic“), die sich allerdings nur in 22 Kodes von ISO 639-2/T
”
unterscheidet48 .
47 In
diesen Kontextgruppen fand der Autor zahlreiche kleine Inkonsistenzen zum UCUM-Standard. Vgl. Posting auf
comp.protocols.dicom am 13.7.2008:
http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/9559c50f211cff0d
48 Vgl. http://www.loc.gov/standards/iso639-2/faq.html#3
Seite 56
4
CID
83
3082
3500
3502
3503
3510
6046
7456
7460
7461
7462
Name
Units for Real World Value Mapping
Cardiology Units of Measurement
Pressure Units
Hemodynamic Resistance Units
Indexed Hemodynamic Resistance Units
Catheter Size Units
Units of Follow-up Interval
Units of Measure for Age
Units of Linear Measurement
Units of Area Measurement
Units of Volume Measurement
Tabelle 4: Kontextgruppen des DCMR, die UCUM-konforme Maßeinheiten enthalten
Das erste optionale Subtag besteht nach RFC 3066 typischerweise aus dem zweibuchstabigen Länderkürzel nach
ISO 3166 (s. u., CID 5001). Es sind aber auch 3- bis 8-buchstabige Kürzel möglich, die bei der Internet Assigned
Numbers Authority (IANA) registriert wurden.
Alle weiteren (optionalen) Subtags unterliegen keinen weiteren Beschränkungen.
Ein Beispiel für ein gültiges Language-Tag nach RFC 3066 wäre de-CH“ für das Schweizer Hochdeutsch (Schwy”
zerdütsch hingegen wird über den 3-buchstabigen ISO 639-2 Kode gsw“ verschlüsselt).
”
Die Entscheidung des DICOM-Komitees, keine Tabelle für Sprachen in das DCMR aufzunehmen, ist nachvollziehbar, da RFC 3066 theoretisch unendlich viele Sprachtags ermöglicht. Andererseits ist die Zahl der tatsächlich
verwendeten, lebenden Einzelsprachen weltweit beschränkt und beläuft sich auf wenige Tausend49 . Insofern
scheint es sinnvoll, in eine maschinenlesbare Version der DCMR-Kontextgruppen zumindest eine Liste der
häufigsten Sprachen zu integrieren. Für diese Diplomarbeit wurden die 185 zweibuchstabigen Kürzel aus ISO
639 Teil 1 und die 485 dreibuchstabigen Kürzel aus ISO 639 Teil 2 terminology“ in ein XML-Format umge”
wandelt und in die XML-Datei integriert. Das dafür verwendete Programm steht auf der Begleitwebseite dieser
Diplomarbeit als Open-Source-Software zur Verfügung [98].
ISO 639-2/B
aar
abk
ace
ach
..
.
ISO 639-2/T
–
–
–
–
..
.
ISO 639-1
aa
ab
–
–
..
.
Sprache
Afar
Abkhazian
Achinese
Acoli
..
.
fre
..
.
fra
..
.
fr
..
.
French
..
.
ger
..
.
deu
..
.
de
..
.
German
..
.
zul
zun
zxx
zza
–
–
–
–
zu
–
–
–
Zulu
Zuni
No linguistic content
Zaza
Tabelle 5: Zweibuchstabige und dreibuchstabige Sprachkodes nach ISO 639 [58]
4.1.2.3 Kontextgruppe 5001: Countries“
”
Für die Länderbezeichnungen verweist das DCMR auf die zweibuchstabigen Kodes aus ISO 3166-1. Die Listen für
49 Vgl.
http://www.wissenschaft-im-dialog.de/de/aus-der-forschung/wieso/detail/browse/2/article/←wie-viele-sprachen-gibt-es-auf-der-welt.html
Seite 57
4
diese Kodes sind als eines der wenigen kostenlosen Angebote der ISO ebenfalls im Internet abrufbar [53]. Tabelle
6 verdeutlicht das Format der Listen. Für diese Diplomarbeit wurden sämtliche 246 ISO 3166-1 Länderkodes
in die XML-Fassung der DCMR-Kontextgruppen übernommen. Das dafür verwendete Programm steht auf der
Begleitwebseite dieser Diplomarbeit als Open-Source-Software zur Verfügung [98].
Land
AFGHANISTAN
ÅLAND ISLANDS
ALBANIA
..
.
WESTERN SAHARA
YEMEN
ZAMBIA
ZIMBABWE
Kode
AF
AX
AL
..
.
EH
YE
ZM
ZW
Tabelle 6: Zweibuchstabige Länderkodes nach ISO 3166-1 [53]
4.1.2.4 Kontextgruppe 7007 Signature Purpose“
”
Um den Zweck einer elektronischen Signatur zu beschreiben, verweist das DCMR auf die signature purposes
”
codes“ des ASTM E 2084-00 Standards. Dieser Standard ist nicht frei im Netz erhältlich, sondern muss für
$42 gekauft werden50 . Daher konnte diese Kontextgruppe im Rahmen dieser Diplomarbeit nicht berücksichtigt
werden.
4.1.2.5 Kontextgruppe 7020 Document Titles“
”
Eine Sonderstellung nimmt die Kontextgruppe 7020 Document Titles“ ein. Das DCMR beinhaltet für diese
”
Kontextgruppe keine Aufschlüsselung der zulässigen Konzepte, sondern erlaubt alle Dokumentennamen aus dem
HIPAA-Anhang der Logical Observation Identifier Names and Codes“ (LOINC). Die LOINC-Datenbank kann
”
als ASCII- (TAB-separiert) oder Microsoft-Access-Datei kostenlos im Internet heruntergeladen werden [95].
Es wurde ein Programm geschrieben, das die relevanten 432 LOINC-Kodes aus der ASCII-Version 2.2 (vom
3.12.2007) der LOINC-Datenbank extrahiert und ebenfalls in ein XML-Format umwandelt, das in die bestehende
Liste integriert werden kann51 . Das Programm wurde so gestaltet, dass es möglichst auch bei zukünftigen
LOINC-Versionen (mit veränderten Indizes der Tabellenspalten) verwendet werden kann52 . Es steht auf der
Begleitwebseite dieser Diplomarbeit als Open-Source-Software zur Verfügung [98].
LOINC NUM
34873-0
33720-4
34851-6
47520-2
47521-0
11524-6
11529-5
11526-1
COMPONENT
Admission evaluation note
Blood bank consult
Consultation note
Cytology report
Cytology report
Study report
Study report
Study report
SYSTEM
{Setting}
ˆPatient
{Setting}
Sputum
Breast.FNA
Heart
ˆPatient
ˆPatient
METHOD TYP
Surgery
Urology
Cyto stain
Cyto stain
EKG
Surgical pathology
Pathology
Tabelle 7: Einige Datensätze mit Scale Doc“ aus der LOINC-Datenbank Version 2.22 (ausgewählte Spalten,
”
für eine Beschreibung der Spalten siehe LOINC Users’ Guide [95])
50 http://www.astm.org/Standards/E2084.htm
51 Die
Anwendung der Algorithmen auf die neue Version LOINC 2.24 , die am 10.7.2008 veröffentlicht wurde, konnte im Rahmen
dieser Diplomarbeit nicht mehr getestet werden.
52 Beispielsweise wurden in der Version 2.22 der LOINC-Datenbank einige Felder entfernt, die sich als unbrauchbar herausgestellt
hatten, vgl. LOINC Users’ Guide [95].
Seite 58
4
Generierung eines sinnvollen Werts für das Feld Code Meaning“ Ein Konzept im DCMR besteht im
”
Wesentlichen aus dem Kodewert, einem Bezeichner für das Kodierungsschema und einer menschlich lesbaren
Beschreibung der Bedeutung des Konzepts. Diese Beschreibung wird integriert, damit Menschen oder Softwaresysteme, die das DCMR nutzen, nicht darauf angewiesen sind, alle im DCMR verwendeten kontrollierten
Vokabularien und Terminologien zusätzlich zum DCMR vorliegen zu haben. Wie Tabelle 7 andeutet, lässt sich
eine sinnvolle Konzeptbeschreibung nicht ohne weiteres aus der LOINC Datenbank ablesen53 . Dies wird im
DCMR auch festgestellt:
Some coding schemes such as LOINC do not specify the equivalent of a Code Meaning.“
”
PS 3.16, Kap. 7.1 [DIC08a].
Trotzdem wurde allen bereits direkt in das DCMR aufgenommenen LOINC-Kodes vom DICOM-Komitee ein
Wert für das Feld Code Meaning“ zugewiesen. Es erschien daher angebracht, dies auch für die automatisch
”
importierten Dokumenttitel zu tun. Einen brauchbaren Ausgangspunkt bildet das Feld COMPONENT“ der
”
LOINC-Datenbank. 32 Einträge im Feld COMPONENT werden jedoch mehrfach verwendet: COMPONENT
enthält nur 135 verschiedene Einträge54 für die insgesamt 432 Konzepte, so dass allein aus diesem Feld keine
eindeutige Konzeptbeschreibung ableitbar ist.
Die Spalte METHOD TYP“ enthält bei Dokumententiteln die für die Erzeugung verantwortliche Fachdiszi”
plin. Gemeinsam mit dem Feld COMPONENT können so häufig sinnvoll lesbare, unterscheidbare Konzeptbeschreibungen erzeugt werden (z. B. EKG study report“, Pathology study report“). Allerdings sind auch
”
”
COMPONENT und METHOD TYP gemeinsam in 23 Fällen noch kein eindeutiger Bezeichner (vgl. Tabelle 7,
Cytology report“ und Cyto stain“).
”
”
Das Programm geht nun bei der Generierung eines Wertes für das DCMR-Feld Code Meaning“ wie folgt vor:
”
Ist die Beschreibung im Feld COMPONENT eindeutig, wird diese verwendet.
Ist die Kombination aus COMPONENT und METHOD TYP eindeutig, so wird METHOD TYP und
COMPONENT getrennt durch ein Leerzeichen verwendet.
Ist auch die Kombination aus COMPONENT und METHOD TYP nicht eindeutig, so wird zusätzlich in
Klammern der Wert des Feldes SYSTEM ergänzt.
Die Konzepte werden schließlich alphabetisch nach Code Meaning“ sortiert in eine XML-Datei geschrieben.
”
4.1.2.6 Grafische Oberfläche zur Auswahl kodierter Konzepte
Im Rahmen dieser Arbeit wurde eine benutzerfreundlicher Dialog entwickelt, mit dem man die Kontextgruppen
des DCMR durchsuchen kann (Abb. 26).
In der Tabelle auf der linken Seite werden die Kontextgruppen aufgelistet. Ist im Textfeld über der Tabelle
etwas eingetragen, so werden nur solche Kontextgruppen angezeigt, die in ihrer ID oder ihrem Namen die
entsprechende Zeichenkette enthalten. Wählt der Benutzer eine Kontextgruppe aus, so werden in der Tabelle
auf der rechten Seite alle Konzepte der ausgewählten Kontextgruppe angezeigt. Dabei werden alle direkt oder
indirekt per Include“ referenzierten Kontextgruppen mit berücksichtigt. Auch auf der rechten Seite können über
”
das Textfeld die Einträge der Tabelle gefiltert werden. Ist auf der linken Seite keine Kontextgruppe markiert, so
bewirken Einträge in das Filter-Feld eine Suche über alle Konzepte im DCMR. Ein Rechtsklick auf ein Konzept
in der rechten Tabelle öffnet dessen zugehörige Kontextgruppe. Beide Tabellen lassen sich nach beliebigen
Spalten auf- oder absteigend sortieren.
4.1.2.7 Technische Betrachtungen
Zwei technische Probleme beim Umgang mit Kontextgruppen sollen hier etwas detaillierter erläutert werden.
53 Das
LOINC committee arbeitet gemeinsam mit der HL7 document ontology taskforce an einem sinnvollen Bezeichnungsschema
für Dokumententypen. Ein Bezeichner für den Dokumententyp wird dabei aus Begriffen aus bis zu vier Achsen zusammengesetzt. Kapitel 7 im LOINC-Handbuch [95] erklärt die geplante Vorgehensweise und liefert eine erste Tabelle mit einem Mapping
auf LOINC-Kodes. Sowohl die Erklärung als auch die Tabelle befinden sich allem Anschein nach noch in einem frühen Entwicklungsstadium, weshalb für diese Arbeit noch nicht auf derartige Bezeichner zurückgegriffen werden konnte.
54 SQL-Abfrage im Access-Dialekt: SELECT COUNT(*) FROM (SELECT DISTINCT COMPONENT FROM LOINC WHERE SCALE TYP=’Doc’)
Seite 59
4
Abbildung 26: Grafische Oberfläche zur Auswahl kodierter Konzepte
Arbeitsspeicherverbrauch und Zugriffszeiten Zunächst wurde die Datenbasis für Kontextgruppen mittels
DOM-Parser eingelesen und als DOM-Baum im Speicher gehalten. Zugriffe auf den DOM-Baum wurden über
XPATH realisiert. Beim derzeitigen Umfang der DCMR-Kontextgruppen benötigte diese Variante jedoch ca.
8MB Arbeitsspeicher, außerdem ist der Zugriff auf einzelne Datenelemente per XPath verhältnismäßig langsam.
Ein Einlesen der XML-Datei in Java-Datenstrukturen verringert den Speicherbedarf für die Daten und erhöht
die Geschwindigkeit bei Datenzugriffen, weil so effiziente Datenstrukturen wie Hashmaps verwendet werden
können. Daher wurde ein SAX-Parser geschrieben, der die XML-Datei in von Hand geschriebene Klassen Con”
textGroup“, DCMRConcept“ und DCMRInclude“ einliest. Der Speicherbedarf konnte durch diese Maßnahme
”
”
um ca. 2/3 reduziert werden. Sollte die Datenbasis des DCMR künftig massiv anwachsen, so muss dieses Konzept sicherlich überdacht werden, da dann das vollständige Vorhalten der Kontextgruppen im Speicher nicht
mehr sinnvoll wäre.
Mehrfachinklusion und zirkuläre Referenzen Bei der Zusammenstellung aller Konzepte einer Kontextgruppe müssen die über INCLUDE“-Zeilen eingebundenen Kontextgruppen ebenfalls berücksichtigt werden. Aus
”
Maschinensicht ist hierbei insbesondere auf zirkuläre Referenzen zu achten, die zu einer unendlich langen Konzeptliste führen würden. Auch wenn keine zirkulären Referenzen vorliegen, sollten andere Kontextgruppen nur
einmal eingebunden werden. Im DCMR der DICOM-Version 2008 gibt es genau ein Beispiel für eine Kontextgruppe, die eine andere Kontextgruppe mehrfach einbindet, und zwar Kontextgruppe 4 Anatomic Region“:
”
Sie verweist sowohl auf Kontextgruppe 4030 CT and MR Anatomy Imaged“ als auch auf Kontextgruppe 4042
”
XA/XRF Anatomy Imaged“, die beide jeweils die Kontextgruppe 4031 Common Anatomic Regions“ einbin”
”
den. Eine Nachfrage in der Newsgroup comp.protocols.dicom ergab, dass David Clunie, der Chef-Editor des
DICOM Standards, dieses Problem bereits kennt und einen entsprechenden Hinweis in die nächste DICOMVersion integrieren will55 . Dieser Hinweis wurde mittlerweile als CP 897 von der DICOM-WG-6 angenommen
[DIC08d].
55 Siehe
Mail von D. Clunie auf comp.protocols.dicom vom 22.5.2008: [In case of] circular inclusion and multiple inclusion, [...]
”
the Context Group shall consist of the transitive closure of the set of all coded concepts within the included Context Groups.“
(http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/b531ca23651c36f3)
Seite 60
4
4.2 Konzeption von GENRE
Für die Konzeption von GENRE wurden zunächst die Konzepte anderer DICOM-SR-Software untersucht (Kap.
4.2.1). Dabei ging es insbesondere um die Frage, ob GENRE von Grund auf neu geschrieben werden muss,
oder auf Open-Source-Software aufsetzen kann. Leider musste festgestellt werden, dass keine geeignete Basis
für GENRE frei verfügbar ist. Daher wird in Kapitel 4.2.2 abgewogen, welche Programmiersprache sich am
besten für GENRE eignet. In Kapitel 4.2.3 wird schließlich ein zur Programmiersprache passendes, kostenloses
DICOM-Toolkit ausgesucht.
4.2.1 Related Work
In diesem Unterkapitel wird untersucht, ob bereits bestehende Software für das Erreichen der Ziele dieser
Diplomarbeit verwendet werden kann.
4.2.1.1 Cyclops Dicom Structured Report Editor
Der von Bortoluzzi, von Wangenheim und Maximini in [BWM03] beschriebene Ansatz scheint den ersten beiden Abstraktionsebenen aus Abbildung 23 sehr gut zu entsprechen. Im Rahmen des deutsch-brasilianischen
Gemeinschaftsprojektes Cyclops“ wurde ein generischer DICOM-SR-Editor entwickelt, mit dem DICOM-SR”
Dokumente erstellt und nachträglich bearbeitet werden können. Bei Bedarf erlaubt das Programm eine geführte
Befunderstellung anhand von DICOM-SR-Templates. Außerdem wurde ein Template-Editor entwickelt, der die
Erstellung der benötigten Templates erleichtern soll.
Abbildung 27: Cyclops Dicom Structured Report Editor [BWM03]
Der Cyclops Dicom Structured Report Editor“ berücksichtigt die durch die gewählte Dokumentenklasse vorge”
gebenen Beschränkungen hinsichtlich Konzeptwert- und Relationstypen. Er unterstützt By-reference-Relationen
und kann fertige Dokumente als DICOM-SR- oder XML-Datei ausgeben. Für die Visualisierung von XMLBefundberichten in Webbrowsern wurde ein entsprechendes XSL Stylesheet entwickelt. Auf die in Abbildung
23 erwähnte Abstraktionsebene 3 wurde bewusst verzichtet, da die Autoren der Ansicht sind, dass dadurch die
Stärke des DICOM-SR-Standards, nämlich dessen Flexibilität, verloren ginge.
Die Nutzung der Cyclops-Software hätte diese Diplomarbeit stark vorangebracht und es erlaubt, die gewonnene
Zeit für die Anpassung an den Routinebetrieb der Pathologie zu nutzen. Eine Kontaktaufnahme mit dem
Cyclops-Projekt scheiterte aber. Eine in englischer Sprache am 11.12.2007 verfasste Mail an die drei Autoren
Seite 61
4
von [BWM03] blieb unbeantwortet56 . Auch eine Kontaktaufnahme über eine E-Mail-Adresse auf der Seite des
Cyclops-Projekts [20] scheiterte. Ein auf eben dieser Webseite angebotener Download konnte nicht ausprobiert
werden, weil die Registrierung mit einer Fehlermeldung abbrach ( Não foi possı́vel estabelecer conexão.“).
”
Für diese Arbeit musste daher vollständig auf Software des Cyclops-Projektes verzichtet werden.
4.2.1.2 DICOMscope
DICOMscope [83] ist ein in Java und C++ implementiertes Werkzeug, das aus einer Zusammenarbeit von
OTech [88], dem Instituts für Mikrotherapie an der Universität Witten/Herdecke [36] und dem OFFIS-Institut
Oldenburg hervorgegangen ist. DICOMscope versteht sich primär als Machbarkeitsstudie für DICOM Presen”
tation States und kalibrierte Druckausgabe“. Die Unterstützung für DICOM-SR ist eher als Nebenprodukt zu
verstehen, mit dessn Hilfe digitale Signaturen mit DICOM demonstriert werden können.
DICOMscope wird als Open-Source-Software zur Verfügung gestellt und kann daher einfach erweitert werden.
Die neueste Open-Source-Version von DICOMscope, Version 3.5.1, datiert auf das Jahr 2001. Im Jahr 2003
wurde die aktuelle Version 3.6.0 veröffentlicht, zu der jedoch kein Quelltext erhältlich ist. Eine Nachfrage bei
Jörg Riesmeier, einem ehemaligen Mitarbeiter des OFFIS-Instituts, ergab, dass die Veröffentlichung einer neuen
Version zwar geplant, aber nicht absehbar sei.
DICOMscope [83] basiert auf dem DCMTK und spricht dieses über das Java Native Interface (JNI) an. Das
Programm kann DICOM-SR-Dokumente in HTML konvertieren und in einem integrierten Browser darstellen.
Außerdem bietet DICOMscope einen Editor für DICOM-SR, der ziemlich genau die Ebene 1 aus Abbildung
23 abdeckt. DICOM-SR-Dokumente werden vom Editor in einer Baumansicht dargestellt (vgl. Abb. 28). Der
Typ eines Inhaltselement ist dabei durch verschiedene Icons leicht zu erkennen, außerdem wird jeweils der Typ
der Relation zum Vaterknoten angegeben, solange es sich nicht um den trivialen CONTAINS-Typ handelt.
Es können gemäß den Beschränkungen der jeweiligen Dokumentenklasse neue Inhaltselemente in den Baum
hinzugefügt und bestehende verändert werden. Für die Konzeptnamen von Inhaltselementen sowie die Werte von CODE- und NUM-Elementen kann auf selbstdefinierte Kontextgruppen zurückgegriffen werden (vgl.
Auswahlliste in Abb. 28(b)). Einige Felder des DICOM-Dokumentenkopfes können bearbeitet werden.
DICOMscope bietet viele interessante Ansätze, es lassen sich aber auch schnell Schwächen des Programms
identifizieren57 :
Die Verknüpfung des C++-Toolkits DCMTK mit der Java-Oberfläche von DICOMscope ist nach Meinung
des Autors nicht ideal. Für jede Klasse des DCMTK und jede der Methoden dieser Klassen, die von Java
aus verwendet werden sollen, muss ein JNI-Wrapper existieren. Dieser kann zwar automatisch generiert
werden, was aber nach jeder Änderung an den Signaturen von Methoden im DCMTK erneut erfolgen
muss. Auf dem Entwicklerrechner des Autors kam es zudem nach einem Update der JVM zu Problemen
mit dem JNI-Interface, die den Programmstart verhinderten und bis zur Abgabe der Diplomarbeit nicht
gelöst werden konnten58 .
Templates werden von DICOMscope nicht unterstützt.
Kapitel 8 des Conformance Statements [OMO01] stellt klar, dass der Einsatz von kontrollierte Vokabularen zur Eingabe kodierter Information in DICOMscope zwar prinzipiell über eine einfach aufgebaute
Konfigurationsdatei möglich ist, das mitgelieferte Vokabular enthält jedoch nur eine Handvoll Kodes zu
Demonstrationszwecken. Die im DICOM-Standard definierten Kontextgruppen werden nicht mitgeliefert.
DICOMscope ist als Paket für Windows erhältlich. Andere Plattformen werden zwar prinzipiell unterstützt, DICOMscope muss dann allerdings selbst kompiliert werden. Der Kompilationsvorgang von
DICOMscope ist durch die Aufteilung in einen C++-Teil (DCMTK) und einen Java-Teil (grafische Benutzeroberfläche) sowie durch zahlreiche Abhängigkeiten von externen Programmbibliotheken sehr aufwändig.
Die Bearbeitungsansicht ist recht unübersichtlich, da weder Konzeptname noch Konzeptwert der Inhaltselemente unmittelbar angezeigt werden.
56 Zwei
der Autoren haben mittlerweile andere E-Mail-Adressen als die in [BWM03] genannten. Die neuen E-Mail-Adressen konnten
jedoch über Suchmaschinen im WWW gefunden werden.
57 Mitarbeiter des OFFIS-Instituts bezeichnen DICOMscope selbst als Machbarkeitsstudie, technischer Ansatz, nicht ‘alltagstaug”
lich’“ [REJ+01]
58 Vgl. Diskussion im DICOMscope-Forum unter
http://forum.dcmtk.org/viewtopic.php?t=1520
Seite 62
4
(a) Bearbeiten des Dokumentenkopfs
(b) Zugriff auf Kontextgruppen, Anzeige des Konzeptnamens
Abbildung 28: Benutzeroberfläche von DICOMscope
Zum Bearbeiten selektiert man ein Inhaltselement und muss für die eigentliche Dateneingabe in einen
anderen Bereich der Benutzeroberfläche wechseln.
Bei der Eingabe von Konzeptwerten, zum Beispiel für die Typen PNAME und DATE, ist man darauf
angewiesen, das Format des jeweils verwendeten Datentyps (VR) zu kennen, Eingabehilfen gibt es nicht.
Für die Anzeige von Kodewert und Kodierungsschema-Bezeichner des Konzeptnamens, muss eine gesonderte Schaltfläche angeklickt werden (vgl. Abb. 28(b)). Möchte man diese Information editieren, muss
die rechts daneben befindliche Schaltfläche verwendet werden. Der Dialog, der sich daraufhin öffnet, hat
grundsätzlich leere Textfelder. Die erweiterten Attribute für Angaben einer Kontextgruppe etc. werden
überhaupt nicht unterstützt.
DICOMscope bzw. das zugrundeliegende DCMTK ermöglicht den Export von DICOM-SR-Dokumenten
in das HTML-Format. Allerdings gehen beim Export nahezu alle Kodeinformationen der Konzeptnamen verloren. Außerdem lässt die HTML-Ausgabe zwar mittels CSS-Stylesheets optisch modifzieren, die
eigentliche Struktur der HTML-Tags ist jedoch im Quellkode von DCMTK fest vorgegeben.
4.2.1.3 Weitere Ansätze
In Kapitel 2.6.7 wurden einige weitere Implementierungen für DICOM-SR-Werkzeuge genannt. Der Autor ging
davon aus, dass die Lösungen aus der freien Wirtschaft (z. B. [JB03, SLM02]) für die Weiterentwicklung als
Open-Source-Software nicht zur Verfügung stehen. Sie werden daher in dieser Arbeit nicht weiter berücksichtigt.
4.2.1.4 Fazit
GENRE lehnt sich konzeptionell an DICOMscope an. Auf die oben genannten Defizite von DICOMscope soll
Seite 63
4
besonderes Augemerk gelegt werden. Ziele von GENRE sind folglich:
Standardkonformität. GENRE soll DICOM-SR möglichst vollständig unterstützen, also insbesondere
Manipulationsmöglichkeiten für nahezu alle Datenfelder von Inhaltselementen anbieten. Die von GENRE
erzeugten DICOM-SR-Dateien sollen DICOM-konform sein, um auch in anderen DICOM-SR-Tools verarbeitbar zu sein, mittels DICOM-Diensten übers Netz verschickt und in DICOM-Archiven gespeichert werden zu können. Gleichzeitig soll GENRE das Öffnen möglichst vieler DICOM-SR-Dokumente ermöglichen,
also eine gewisse Fehlertoleranz bieten und z. B. mit privaten Attribute und neu eingeführten Attributen
zukünftiger DICOM-Versionen umgehen können.
Benutzungsfreundlichkeit. Ein DICOM-SR-Dokument soll auch während des Bearbeitens im Ganzen
lesbar bleiben. Die Eingabe von Daten soll auch ohne Kenntnis der DICOM-Datentypen möglich sein.
Für die Akzeptanz des Programms kann es sinnvoll sein, die Benutzeroberfläche an die Gegebenheiten des
jeweiligen Einsatzlandes anzupassen ( Lokalisierung“). Um den Benutzer nicht mit den unüberschaubaren
”
Möglichkeiten des DICOM-SR-Standards zu überfordern, sollen weniger häufig verwendete Datenfelder
automatisch oder auf Wunsch des Benutzers verborgen werden.
Integration der DICOM-Kontextgruppen. Die in Kapitel 4.1 beschriebene Datenbasis aller in PS
3.16 (DCMR) definierten Kontextgruppen soll in GENRE zur Verfügung stehen, die Suche nach passenden
Konzepten möglichst einfach gestaltet sein.
Plattformunabhängigkeit. GENRE soll mit seinem generischen Ansatz möglichst vielfältige Benutzergruppen ansprechen. Die Zielgruppe soll nicht unnötig durch Abhängigkeiten GENREs von einer bestimmten Hardwareplattform oder einem bestimmten Betriebssystem verkleinert werden.
Verweise auf Bilder. Bei allem generischen Anspruch von GENRE, soll die umrahmende Aufgabenstellung, nämlich das in der Einleitung erwähnte Forschungsprojekt mit dem Ziel der Speicherung von
Ergebnissen einer automatischen Bildanalyse, nicht völlig außer Acht gelassen werden. Ergebnisse einer
automatischen Bildanalyse machen nur dann Sinn, wenn im Befundbericht komfortabel das analysierte
Bild referenziert werden kann.
Export in andere Datenformate. Es muss davon ausgegangen werden, dass DICOM-SR-Dateien an
den meisten Stellen im Krankenhaus und im niedergelassenen Bereich derzeit (noch) nicht verarbeitet
werden können. Dies steht einer Integration von DICOM-SR in bestehende Workflows prinzipiell entgegen. GENRE sollte daher den Export in gängigere Datenformate, wie beispielsweise Office-Formate,
ermöglichen.
4.2.2 Auswahl der Programmierplattform
Die Auswahl einer geeigneten Programmierplattform ist wesentlicher Eckpfeiler für das Erreichen der genannten
Ziele. Für diese Arbeit wurde die Programmierung in C/C++, in C# für die .NET-Plattform von Microsoft und
in Java erwogen. Außerdem bestand die Überlegung, GENRE als Browseranwendung nach dem derzeit stark
im Kommen begriffenen AJAX-Konzept zu entwickeln.
Weitere Informationen und Links zu den genannten DICOM-Toolkits finden sich auf der Begleithomepage zu
dieser Diplomarbeit [99].
4.2.2.1 C/C++
Für die Programmiersprache C++ spricht vor allem das in C++ geschriebene DICOM-Toolkit DCMTK [82],
das von allen untersuchten, frei erhältlichen Toolkits die umfangreichsten DICOM-SR-Unterstützung anbietet.
DCMTK wird trotz lange zurückliegendem letzten offiziellen Release hervorragend gepflegt, allein zwischen
März und Mai 2008 gab es ein halbes Dutzend neue Versionen (sog. snapshots“). Der Support für DCMTK”
Anwender über das öffentliche Anwenderforum ist hervorragend, Fragen werden zügig und kompetent beantwortet. Zwei wesentliche Entwickler des DCMTK, Marco Eichelberg und Jörg Riesmeier, waren im Wintersemester
2007/2008 im Rahmen des Institutskolloquiums am IMI zu Gast und insofern persönlich bekannt. Persönlich
an sie gerichtete Anfragen wurden ebenfalls schnell und fundiert beantwortet.
Ein weiteres Argument für C++ mag die Tatsache sein, dass ein Großteil der kommerziellen, medizinischen
Informationssysteme in dieser Programmiersprache implementiert ist. Sollte GENRE einmal kommerziell verwertbaren Status erreichen, könnte es als C++-Programm relativ leicht in bestehende große Systeme integriert
Seite 64
4
werden.
Als wesentlichen Nachteil von C++ sieht der Autor die verhältnismäßig langen Entwicklungszyklen bei Verwendung dieser Programmiersprache. Eine Programmiersprache mit managed code“ führt schneller zu brauchbaren
”
Ergebnissen und ist sicherlich akzeptabel, da ein Softwareprojekt im Rahmen einer Diplomarbeit eher prototypischen als kommerziellen Charakter hat. Weiterhin benötigt man für Plattformunabhängigkeit von C++Programmen vor allem auch eine plattformunabhängige Klassenbibliothek für grafische Benutzeroberflächen.
Solche Bibliotheken sind zwar auch frei erhältlich (z. B. Qt [115], GTK+ [37] und wxWidgets [103], erfordern
jedoch einiges an Einarbeitung. Um das Neukompilieren von C++-Programmen für andere Betriebssysteme
und Hardware-Plattformen kommt man so und so nicht herum.
4.2.2.2 .NET/C#
Auch die .NET-Plattform kann als Vorteil verbuchen, dass sie von wichtigen kommerziellen MedizininformatikProdukten genutzt wird. Insbesondere sei hier das Produkt NEXUS / PATHOLOGIE [74] (vormals Paschmann
”
PAS.NET“) genannnt, die aktuelle Version des in Deutschland marktführenden Pathologie-Informationssystems,
dessen Vorgängerversion auch am UK-SH zum Einsatz kommt.
Des Weitern sprechen die umfangreiche Klassenbibliothek (z. B. XML- und Internationalisierungsfunktionen)
und der relativ schnelle Entwicklungszyklus (Garbage-Collector, starke Typsicherheit etc.) für C#.
Keines der freien DICOM-Toolkits für die .NET-Plattform erwähnt explizit die Unterstützung für DICOMSR59 . Überhaupt wirkt keines der bisher erhältlichen freien Toolkits wirklich ausgereift. Daher schied die .NETPlattform für diese Diplomarbeit aus.
Bei guter Entwicklung der C#-DICOM-Toolkits könnte .NET jedoch zukünftig eine sehr interessante Basis
für DICOM-Anwendungen sein. Bisher bestehende Probleme bei der Plattformunabhängigkeit im GUI-Bereich
sind voraussichtlich Ende des Jahres 2008 zumindest teilweise gelöst: Bisher existiert mit Mono eine plattformübergreifende Laufzeitumgebung für .NET-Anwendungen. Die von Microsoft favorisierte Windows Forms
API für grafische Benutzeroberflächen wurde bisher jedoch nicht vollständig von Mono unterstützt. Seit Mai
2008 ist Windows Forms für Mono nun komplett [91] und wird mit der kommenden Version Mono 2.0 voraussichtlich im September 2008 veröffentlicht [78]. Alternative GUI-Bibliotheken für Mono [77] wären auch eine
Alternative, haben aber unter Windows eine geringe Verbreitung.
4.2.2.3 Java
Java ist im Bereich der Geschäftssoftware sehr verbreitet, im Bereich der Medizinischen Informatik wird es
zumindest bei Server-Software inzwischen ebenfalls häufig eingesetzt. Medizinische Client-Software in Java ist
hingegen eher ungebräuchlich, hier ist ein Nachteil gegenüber C++ und .NET festzuhalten.
Vorteile von Java sieht der Autor vor allem in der wie auch bei .NET mächtigen Klassenbibliothek mit XMLund Internationalisierungsfunktionen sowie dem relativ schnellen Entwicklungszyklus von Anwendungen. Mit
dem PixelMed-Toolkit [18] existiert eine gut gepflegte Klassenbibliothek für den Umgang mit DICOM, die
DICOM-SR zumindest in Ansätzen unterstützt.
4.2.2.4 Browseranwendungen und AJAX
Zahlreiche Gründe sprechen zunächst für browsergesteuerte Client-Server-Lösungen im Vergleich zu eigenständigen Programmen. Zusätzliche Clients können bei diesen Systemen leicht hinzugefügt werden, da ein Webbrowser üblicherweise bereits vorhanden ist und somit keine Software installiert werden muss. Webbrowser existieren
für alle gängigen Betriebssysteme, was eine maximale Plattformunabhängigkeit bei den Clients gewährt. Der
Rollout von Software-Updates ist einfach, da nur der Server aktualisiert werden muss. Diese technischen Vorteile
59 Auch
bei den kommerziellen Toolkits unterstützt offenbar nur DICOM.net von Reliable Medical Imaging [99] DICOM-SR und
diese Unterstützung ist nach der öffentlich zugänglichen Dokumentation zu urteilen mehr als lückenhaft.
Seite 65
4
haben dazu geführt, dass Browseranwendungen in der medizinischen Informatik bereits auf breiter Front eingesetzt werden, beispielsweise für Arzneimittelinformationssysteme, für die computergestützte Auftragssteuerung
oder für komplette Stationsarbeitsplätze.
Als größte Probleme von Browseranwendungen sieht der Autor die tendenziell schlechtere Bedienbarkeit durch
die bisher relativ eingeschränkte Auswahl an Bedienelementen in HTML (z. B. keine standardisierte Baumansicht, keine Schieberegler etc.) und die erheblich langsameren Reaktionszeiten der grafischen Benutzeroberfläche
im Vergleich zu echten“, lokalen Programmen.
”
AJAX Als Lösung für das letztgenannte Problem wird derzeit die AJAX-Technik (Asynchronous J avaScript
and X ML) stark diskutiert. Bei dieser Technik muss für die Präsentation der Ergebnisse von Benutzereingaben
keine vollständig neue Webseite geladen und gerendert werden. Stattdessen kann eine bestehende Webseite durch
clientseitig ausgeführte Skriptsprachen manipuliert werden. Unter den im Browser ablaufenden Skriptsprachen
hat sich JavaScript als Quasi-Standard etabliert60 . HTML- oder XML-Dateien können von Skriptsprachen über
das Document Object Model (DOM [120]) ausgelesen und manipuliert werden. Werden für die Änderung der
Webseite Informationen vom Server benötigt, so werden diese über ein XMLHttpRequest-Objekt [119] angefordert61 . Die Kommunikation zwischen Server und Client läuft dabei fast immer asynchron ab, der Client-Prozess
läuft also nach Absenden der Anfrage weiter, ohne auf das Ergebnis zu warten62 . Eine über diese Eckpfeiler
hinausgehende Beschreibung von AJAX würde den Rahmen dieser Diplomarbeit sprengen; der interessierte
Leser sei auf weiterführende Literatur wie zum Beispiel das kostenlos einzusehende [Wen07] verwiesen.
Da nur die wirklich benötigten Daten übertragen werden und der Browser typischerweise nur sehr kleine Teile
der Webseite neu rendern muss, lassen sich AJAX-Anwendungen tatsächlich flüssiger bedienen als klassische
Webanwendungen. AJAX-Anwendungen sind tendenziell komplex zu programmieren. Auf Client-Seite müssen
verschiedene Programmier- und Auszeichnungssprachen wie Javascript, HTML und CSS kombiniert werden,
auf Server-Seite kommen weitere Technologien wie PHP, Java Servlets o.Ä. hinzu. Da JavaScript in Browsern
sehr unterschiedlich implementiert ist, ist die Plattformunabhängigkeit von AJAX zwar theoretisch aber nicht
unbedingt in der Praxis gegeben. Beispielsweise ist es mit handgeschriebenem JavaScript-Kode sehr schwierig,
ein korrektes Verhalten der Vor“- und Zurück“-Schaltflächen in AJAX-Anwendungen zu implementieren.
”
”
Für die Programmierung von AJAX existieren zahlreiche freie Programmierbibliotheken63 , die unter anderem
die Unabhängigkeit vom Browsertyp verbessern sollen. Gängig ist beispielsweise die Kombination von Prototype [93], einer Bibliothek, die den Zugriff von JavaScript auf DOM vereinfacht, mit script.aculo.us [32], einer
Bibliothek für grafische Effekte. Großen Einfluss bei der Entwicklung von AJAX-Anwendungen haben auch
die Branchenriesen Yahoo! und Google. Yahoo! bietet mit YUI [123] eine eigene freie AJAX-Bibliothek mit
Netzwerkfunktionen und fertigen Bausteinen für grafische Bedienelemente an. Außerdem bemüht sich Yahoo!
in einem anderen Projekt, Entwurfsmuster für Webanwendungen zu etablieren [122].
Das Google Web Toolkit (GWT) Google hat sich mit dem Google Web Toolkit (GWT) [35] einen Ansatz zur AJAX-Programmierung ausgedacht, der eine gesonderte Betrachtung verdient. Das GWT wurde der
Öffentlichkeit erstmals im Frühjahr 2006 vorgestellt. Der Quellkode steht unter der liberalen Apache-2.0-Lizenz.
Mittlerweile hat sich eine beachtliche Nutzergemeinde um das GWT herum entwickelt, es gibt beispielsweise
zahlreiche, auch deutschsprachige Bücher speziell zu diesem Produkt.
GWT setzt auf der Programmiersprache Java auf. Die Serverseite einer Browseranwendung wird als Java-Servlet
implementiert, mit Tomcat liefert das GWT einen vorkonfigurierten Servlet-Container zum Testen gleich mit.
Kernstück des GWT ist ein Compiler, der Java-Programme für die Clientseite einer Browseranwendung in Javascript übersetzt64 . Mit Hilfe des GWT können Client und Server also in der gleichen Programmiersprache,
60 Als
herstellerübergreifender Standard ist hier eigentlich ECMAScript [29] zu nennen. Der Markenname ECMAScript konnte sich
jedoch nie durchsetzen, stattdessen wird meist von JavaScript, dem bekanntesten ECMAScript-Dialekt gesprochen.
61 Seinem Namen zum Trotz kann über dieses Objekt nicht nur XML sondern zum Beispiel auch Klartext übertragen werden.
62 Asynchrone Kommunikation wird vor allem deswegen benötigt, weil praktisch alle Javascript-Engines Skripte single-threaded
ablaufen lassen. Synchrone Kommunikation würde daher immer wieder zu einem kurzzeitigen Einfrieren“ der grafischen Ober”
fläche führen, was die Bedienbarkeit erheblich erschwerte.
63 Einen Überblick über etliche AJAX-Bibliotheken bietet zum Beispiel [67].
64 Der GWT-Compiler unterstützt nicht den vollen Sprachumfang von Java (vgl. Kap. Fundamentals“ in der umfangreichen GWT”
Dokumentation). Insbesondere muss der Java-Kode kompatibel zu J2SE 1.4.2 sein. Die in Entwicklung befindliche Version 1.5
des GWT soll erstmals auch Sprachkonstrukte von Java 1.5 wie Generics und Enumerationen unterstützen.
Seite 66
4
Java, entwickelt werden, ohne dass auf den Clients ein JRE installiert sein muss. Dieser Ansatz bietet insbesondere für Java-erfahrene Programmierer diverse Vorteile. Die heutigen Entwicklungsumgebungen für Java (z. B.
Eclipse, NetBeans) sind sehr ausgereift (Koderefaktorisierung, Kodevervollständigung, Kodegenerierung etc.)
und können weiter verwendet werden. GWT ist dabei nicht auf eine spezielle IDE angewiesen. Auf Entwurfsmuster für Objektorientiertes Design kann zurückgegriffen werden, ebenso auf Java-Spezialitäten wie JUnit-Tests,
JavaDoc oder Kodewiederverwendung mittels JARs.
Der GWT-Ansatz vereinfacht auch das Debuggen: JavaScript-Debugger sind rar und noch recht neu. GWT
ermöglicht das Ausführen der Client-Anwendung in einem sogenannten Hosted Mode“ als Java-Bytekode vor
”
der Übersetzung in Javascript. Es können also beliebige Java-Debugger verwendet werden. Das gemeinsame
Debugging von Client und Server erleichtert die Entwicklerarbeit. Da Java im Gegensatz zu JavaScript eine
statisch getypte Programmiersprache ist, fällt eine ganze Klasse an Fehlern ohnehin schon zur Übersetzungszeit
und nicht erst zur Laufzeit auf.
Nicht nur der Entwicklungsprozess, sondern auch das fertige Programm profitiert vom GWT-Compiler. Der
vom GWT generierte JavaScript-Kode ist auf Browserunabhängigkeit optimiert, eine ansonsten sehr schwierige
Aufgabe (s. o.). GWT liefert bereits zahlreiche vordefinierte GUI-Komponenten wie Menüzeile, Baumansicht,
Registerkarten, Vorschlagbox und Splitpanels mit, die in Standard-HTML vermisst werden. Benutzeroberflächen
werden vom Programmierer aus diesen Komponenten analog zu herkömmlichen Swing-Komponenten zusammengestellt.
Werden sowohl Client als auch Server mit dem GWT entwickelt (Normalfall), so kann für die Client-ServerKommunikation das proprietäre Protokoll GWT-RPC verwendet werden. Dieses Protokoll ist insbesondere für
große Binärdateien wesentlich effizienter als etwa XML. Für die Kompatibilität zu Clients und Servern von
anderen Webanwendungen65 unterstützt das GWT außerdem das Datenformat JavaScript Object Notation
(JSON)66 für die Parameterübergabe bei RPCs.
ZK Das ZK-Framework [92] der Firma Potix hat einen ähnlichen Ansatz wie das GWT und soll daher an
dieser Stelle kurz erwähnt werden. ZK wurde wenige Wochen vor dem GWT veröffentlicht und ist unter zwei
verschiedenen Lizenzen erhältlich (GPL und kommerziell). Auch ZK stellt Java in den Mittelpunkt, die Verwendung von JavaScript bei der Entwicklung von Webanwendungen soll möglichst vollständig vermieden werden.
ZK liefert wie das GWT bereits eine große Zahl an Komponenten für grafische Benutzeroberflächen mit.
Im Gegensatz zum GWT setzt ZK darauf, dass die Anwendungslogik (z. B. Zustandsverwaltung) weitgehend
serverseitig abläuft, der Browser auf den Clients dient fast ausschließlich als Präsentationsschicht. Ein weiterer
Unterschied findet sich beim Erzeugen grafischer Oberflächen: ZK setzt hier auf eine eigene XML-basierte
Auszeichnungssprache, ZUML, die es auch Nicht-Programmierern erlauben soll, bei der Oberflächengestaltung
mitzuwirken.
Um GWT und ZK miteinander vergleichen zu können, wäre eine ausführliche Einarbeitung in beide Frameworks
notwendig, die im Rahmen dieser Arbeit nicht geleistet werden kann. Ein erster Anhaltspunkt mag der Artikel
[59] sein, der allerdings von einem ZK-Entwickler geschrieben und daher sicher nicht als neutral anzusehen ist.
Objektiv kann man feststellen, dass für ZK deutlich weniger Literatur existiert67 .
4.2.2.5 Fazit
Jede der untersuchten Programmierplattformen hat ihre Vorteile. Für C/C++ steht mit dem DCMTK das insbesondere im Bereich DICOM-SR leistungsfähigste Open-Source-Toolkit mit guter Dokumentation und reger
Entwickler-Community zur Verfügung. Die Nutzung von Microsofts .NET-Plattform scheint besonders interessant hinsichtlich einer möglichen Integration in NEXUS / PATHOLOGIE. Browseranwendungen mit AJAXUnterstützung sind derzeit in Mode und möglicherweise besonders zukunftsträchtig. Aufgrund der inhärenten
Client-/Server-Architektur skalieren Browserlösungen gut auf Arbeitsgruppen oder ganze Kliniken, zumal auf
den Clients keine Installation und Wartung anfällt.
65 Die
Kombination bestehender Webanwendungen zu einer neuen Webanwendung wird Mashup“ genannt.
”
wurde als RFC 4627 standardisiert [IET06]. Eine in zahlreiche Sprachen übersetzte, gut verständliche Einführung in JSON
findet sich auf der offiziellen Homepage [19].
67 Im Juli 2008 listen die Kataloge von http://www.libri.de/ und http://www.amazon.de nur zwei englischsprachige Bücher zum
Thema ZK.
66 JSON
Seite 67
4
Letztlich schied die .NET-Plattform aus, da die hierfür verfügbaren Open-Source-DICOM-Toolkits insbesondere
im Bereich DICOM-SR keine Unterstützung anbieten. Die Nähe zu bestehender Software für den pathologischen
Routinebetrieb verliert ohnehin etwas von ihrem Reiz, da DICOM in der Pathologie noch in den Kinderschuhen
steckt. Von C/C++ wurde Abstand genommen, weil die Entwicklungszeit als zu hoch angenommen wurde und
Plattformunabhängigkeit nur mit großem Aufwand erreicht werden kann.
Die Implementierung als Browseranwendung schien sehr reizvoll, insbesondere mit Unterstützung der vorgestellten AJAX-Frameworks GWT oder ZK. Letztlich wurde dieser Gedanke aber aus folgenden Gründen verworfen:
Die Entwicklung von Browseranwendungen ist auch bei Einsatz mächtiger AJAX-Frameworks komplexer
als bei Einzelplatzanwendungen in einer einzigen Programmiersprache.
Die Freiheit bei der Gestaltung grafischer Oberflächen ist letztlich geringer. GWT, ZK und andere AJAXFrameworks liefern zwar eine große Zahl vorkoknfigurierter GUI-Komponenten mit, die Erweiterung um
eigene, besonders benutzerfreundliche Eingabeelemente erschien jedoch wesentlich aufwändiger als bei den
anderen untersuchten Plattformen.
GENRE soll durch seinen neuartigen Ansatz Demonstrationscharakter haben. Demonstrationen von ClientServer-Anwendungen sind aber relativ aufwändig, weil stets zwei Programme installiert werden müssen
(plus etwaige Applikationsserver etc.). Eine einfache Weitergabe z. B. auf USB-Stick ist so nicht möglich.
Aus den genannten Gründen soll GENRE in Java implementiert werden.
4.2.3 Auswahl eines geeigneten DICOM-Toolkits
Für die Implementierung von GENRE wurde ein kostenloses Toolkit gesucht, dass die folgenden Kriterien erfüllt:
Funktionen für die Arbeit mit DICOM-SR-Dokumenten
Gute Pflege mit regelmäßigen Veröffentlichungen neuer Versionen
Netzwerkfunktionalität für die Einbettung von DICOM-SR-Dokumenten in eine bestehende DICOMInfrastruktur
Aus der vom Autor erstellen Marktübersicht für DICOM-Toolkits [99] wurden drei Toolkits ausgewählt, die
diese Kriterien erfüllen: Das C++-Toolkit DCMTK“sowie die Java-Toolkits dcm4che2“ und PixelMed Java
”
”
”
DICOM Toolkit“.
4.2.3.1 DCMTK
Das Toolkit DCMTK [82], das mittlerweile vom OFFIS-Institut in Oldenburg angeboten und weiterentwickelt
wird hat eine lange Geschichte: Es entstand als europäische Referenzimplementierung ( Central Test Node“)
”
des DICOM-Standards bereits kurz nach dessen Verabschiedung. In den folgenden Jahren wurde die Software,
unter anderem durch Referenzimplementierungen geplanter DICOM-Erweiterungen im Auftrag des DICOMKomitee, stark erweitert. Insbesondere kann man mithilfe des DCMTK DICOM-SR-Dokumente erzeugen, lesen,
modifizieren, schreiben und in andere Formate exportieren. [Rie06]
DCMTK ist hat nach Einschätzung des Autors einen besonders großen Funktionsumfang, eine gute Dokumentation und eine aktive Nutzergemeinde, die bei Problemen mit DCMTK im offiziellen Forum schnell weiterhilft.
Der Einsatz des DCMTK für eigene Projekte wäre insofern naheliegend.
Die Nutzung von C++-Bibliotheken aus Java heraus ist nicht problemlos möglich. Im offiziellen DCMTKForum wird häufig nach Verwendungsmöglichkeiten in Java-Programmen gefragt. Einer vollständigen Portierung
nach Java stehen die Entwickler eher ablehnend gegenüber68 . Eine andere Lösung wären Wrapper-Klassen,
mit deren Hilfe über das Java Native Interface (JNI) auf die originalen DCMTK-Bibliotheken zurückgegriffen
werden kann. Das in Kapitel 4.2.1.2 vorgestellte Programm DICOMscope verwendet diesen Ansatz, bietet
jedoch keinen vollständigen Zugriff auf die DCMTK-Klassen. Außerdem beziehen sich die Wrapper-Klassen der
OpenSource-Version von DICOMscope auf eine veraltete DCMTK-Version.Die Erzeugung eines vollständigen
68 Marco
Eichelberg am 18.4.2008: Since there are good open source DICOM toolkits for Java (for example dcm4che), I am not sure
”
if a DCMTK port to Java is worthwhile the effort, in particular since DCMTK uses many features of the C/C++ environment
that would be difficult to directly port to Java“,
http://forum.dcmtk.org/viewtopic.php?t=1606.
Seite 68
4
Java-Wrappers für DCMTK wird von den Entwicklern im Prinzip befürwortet69 , eigene Versuche der Entwickler
mit automatischen Wrapper-Generatoren scheiterten jedoch an der Komplexität des DCMTK-Quellkodes70 .
Der Zugriff auf das DCMTK über JNI-Wrapper hätte ohnehin Nachteile. Einerseits geht damit die Plattformunabhängig von Java verloren, sowohl DCMTK als auch die Wrapper-Klassen müssten für die jeweilige
Zielplattform kompiliert werden. Andererseits wäre die JNI-Schnittstelle ein Flaschenhals bei der Übergabe
großer Datenmengen (wie z. B. virtuellen Präparaten) von DCMTK an GENRE und zurück.
Aus diesen Gründen wurde für GENRE nicht auf das DCMTK zurückgegriffen.
4.2.3.2 dcm4che2 DICOM Toolkit
Offensichtlich weit verbreitet und beliebt ist das Java-Toolkit dcm4che2 [124]. Treibende Kraft dieses Projekts
ist Gunter Zeilinger aus Wien, der mittlerweile bei Agfa Healthcare arbeitet. An dem Open-Source-Projekt sind
jedoch noch ca. 50 weitere Entwickler beteiligt. Neue Versionen des Toolkits erscheinen mehrmals im Jahr.
Das in dcm4che2 enthaltene Kommandozeilenprogramm txt2dcmsr und Klassen wie SRDocumentContent und
SRDocumentContentModule deuten zunächst darauf hin, dass dcm4che2 Unterstützung bei der Bearbeitung von
DICOM-SR-Dokumenten bietet. Ein Studium des Quellkodes von txt2dcmsr zeigte jedoch, dass DICOM-SRDokumente hier auf einem sehr niedrigen Abstraktionsniveau erstellt werden. Die genannten Java-Klassen sind
völlig undokumentiert. Überhaupt existiert fast keine Dokumentation für dcm4che2, weswegen auch auf dieses
Toolkit verzichtet wurde.
4.2.3.3 PixelMed Java DICOM Toolkit
Der Editor des DICOM-Standards, David Clunie, bietet auf seiner Homepage ein in Java geschriebenes DICOMToolkit zur freien Verfügung unter eigener Open-Source-Lizenz an. Auch eine kommerzielle Nutzung ist kostenlos
erlaubt.
Das PixelMed-Toolkit enthält komfortable Methoden zum Einlesen von DICOM-Attributlisten aus Dateien und
eine Klasse StructuredReport, mit der aus solchen Attributlisten der DICOM-SR-Inhaltsbaum extrahiert und
in seine Inhaltselemente zerlegt werden kann. Inhaltselemente werden in Datenstrukturen gepspeichert, die in
der Klasse ContentItemFactory definiert sind (siehe auch Kap. 4.3.1). Neben den Datenstrukturen gibt es auch
eine einfache GUI-Klasse StructuredReportBrowser, mit deren Hilfe Inhaltsbäume angezeigt werden können
(siehe Abb. 29).
Abbildung 29: GUI-Klasse StructuredReportBrowser aus dem PixelMed-Toolkit
69 Siehe
70 Siehe
Forenbeitrag am 30.11.2006, http://forum.dcmtk.org/viewtopic.php?t=488.
Forenbeitrag am 16.11.2007, http://forum.dcmtk.org/viewtopic.php?t=1397.
Seite 69
4
Die Benutzung des Toolkits ist ausschließlich im Quellkode dokumentiert, dort aber teilweise sehr ausführlich
und mit Anwendungsbeispielen. Für weitere Hilfe existiert eine Mailingliste bei Yahoo! Groups71 , auf der David
Clunie persönlich und in der Regel innerhalb von 24 Stunden auf Anfragen reagiert.
Insgesamt schien der Funktionsumfang des PixelMed-Toolkits für die Implementierung von GENRE ausreichend
und die gebotene Dokumentation zufriedenstellend, so dass die Wahl letztlich auf dieses Toolkit fiel.
Hinweise zur Benutzung des PixelMed-Toolkits Für den Einsatz des PixelMed-Toolkits in eigenen Programmen reicht das Herunterladen des Archivs pixelmed.jar und dessen Registrierung im Java-CLASSPATH.
Möchte man das PixelMed-Toolkit selbst kompilieren, beispielsweise um Fehler im Quellkode zu korrigieren, so
sind zusätzlich folgende Bibliotheken erforderlich:
vecmath.jar. Dieses Bibliothek ist eigentlich Teil von Java 3D, ist jedoch auch einzeln im Quelltext auf
der Homepage von Java 3D [104] erhältlich (vecmath-1 5 2-src.zip). Eine bereits kompilierte Version
findet sich im ZIP-Archiv von Java 3D; dieses Archiv beinhaltet ein weiteres Archiv j3d-jre.zip, in dem
man unter lib/ext die gewünschte vecmath.jar findet.
hsqldb.jar. Diese Datei findet sich im ZIP-Archiv von HSQLDB [48] unter dem Pfad hsqldb/lib.
jmdns.jar. Diese Datei befindet sich im Ordner jmdns-1.0/lib des ZIP-Archivs von JmDNS (Java multicast DNS [47]).
4.3 Implementierung von GENRE
Dieses Kapitel beschreibt das Vorgehen bei der Entwicklung von GENRE. Im Unterkapitel 4.3.1 werden zunächst
die Datenstrukturen betrachtet, die das PixelMed-Toolkit für Inhaltselemente anbietet. Es wird beschrieben,
wie diese Datenstrukturen für den Einsatz in GENRE erweitert werden mussten. Kapitel 4.3.2 beschäftigt sich
ausführlich mit der grafischen Oberfläche von GENRE.
4.3.1 Datenhaltung von DICOM-SR-Dokumenten
Ein DICOM-SR-Dokument besteht aus einer Liste von DICOM-Attributen, die logisch in einen Dokumentenkopf
und einen Inhaltsbaum unterteilt werden kann (vgl. Kap. 2.6.1 und 2.6.2). Die Knoten im Inhaltsbaum heißen
Inhaltselemente und sind über Relationen miteinander verknüpft. Jedes Inhaltselement kann aus einem Konzeptnamen, der als Triplet-Kode angegeben wird, und einem Konzeptwert bestehen. Je nach Typ des Konzeptwertes
kann sich der Aufbau von Inhaltselementen stark unterscheiden. Generell besteht jedes Inhaltselement wieder
aus einer Liste von DICOM-Attributen, die in einem Sequenzattribut zusammengefasst sind.
Am Anfang der Überlegungen zu geeigneten Java-Datenstrukturen stand die Erkenntnis, dass das Bearbeiten
bereits bestehender DICOM-SR-Dokumente und das Erstellen vollständig neuer Dokumente durch GENRE
unterschieden werden muss. Im ersten Fall muss man nämlich damit rechnen, dass die Datei DICOM-Attribute
enthält, die GENRE unbekannt sind (z. B. private Attribute, vgl. Kap. 2.5.6.2). Außerdem kann eine bestehende
Datei Attribute mit ungültigen Attributwerten enthalten.
Wollte man die Attributlisten von Inhaltselementen für die Bearbeitung mit GENRE in eine abstraktere Datenstruktur bringen und nach erfolgreicher Bearbeitung wieder in eine Attributliste zurückwandeln, so gingen
die unbekannten Attribute verloren und es wäre unklar, was mit ungültigen Attributwerten geschehen soll. Der
Autor entschied sich daher dazu, für jedes Inhaltselement dessen ursprüngliche Attributliste beizubehalten und
Änderungen am Inhaltselement direkt auf der Attributliste durchzuführen. Die Datenstrukturen für Inhaltselemente in GENRE sollen also nur Wrapper-Klassen mit komfortablen Zugriffsmethoden auf die typspezifischen
Attribute von Inhaltselementen sein.
Abbildung 30 stellt schematisch den Aufbau von Inhaltselementen verschiedenen Typs dar. Optionale Angaben
sind gestrichelt umrahmt. Betrachtet man die verschiedenen Inhaltselemente genauer, so fallen Gemeinsamkeiten
auf:
71 http://tech.groups.yahoo.com/group/pixelmed_dicom/
Seite 70
4
Abbildung 30: Komplexe Datentypen von Inhaltselementen (gruppierte Zusammenstellung nach [Clu00])
Seite 71
4
Die Konzeptwerte von Inhaltselementen der Typen TEXT, PNAME, DATE, TIME, DATETIME, und
UIDREF haben zwar eine verschiedene Semantik und werden durch verschiedene DICOM-Attribute ausgedrückt, in allen Fällen handelt es sich jedoch prinzipiell um einen einzelnen String. Diese Typen können
also von einer gemeinsamen Oberklasse abgeleitet werden.
Der Konzeptwert von CODE-Inhaltselementen besteht im Wesentlichen aus einem Tripel mit Kodewert,
Kodierungsschema-Bezeichner und Kodebedeutung. Die Attribute hierfür werden im sogenannten Code
”
Sequence Macro“ in PS 3.3 definiert (vgl. Tab. 8.8-1 [DIC08a]). Dieses Makro wird auch für die Angabe
von Konzeptnamen verwendet.
Der Konzeptwert von NUM-Inhaltselementen besteht aus der eigentlichen Zahlenangabe und einem Kodetripel für die Maßeinheit. Dieses Kodetripel wird wieder wie im Code Sequence Macro“ definiert an”
gegeben. Allerdings ist die Angabe eines Konzeptwertes beim Typ NUM optional. Ein fehlender Wert
bedeutet, dass der Wert nicht erhoben wurde oder unbekannt ist. Insofern müssen NUM-Elemente gesondert behandelt werden.
Inhaltselemente der Typen IMAGE und WAVEFORM verweisen wie solche vom Typ COMPOSITE auf
ein DICOM Composite Object“, spezifizieren dies aber genauer. Beim Typ IMAGE kann zusätzlich eine
”
Referenced Frame Number“ mitgegeben werden, falls das Zielbild aus mehreren Frames besteht, außerdem
”
ein Softcopy Presentation State“-Objekt, das Informationen zur Anzeige des Zielbildes beinhalten kann
”
(z. B. Fensterung bei CT-Aufnahmen, Annotationen; vgl. Kap. 2.5.5). Beim Typ WAVEFORM kann über
das Attribut Referenced Waveform Channels“ angegeben werden, welcher Kanal bzw. welche Kanäle einer
”
mehrkanaligen Aufzeichnung (z. B. Ableitung V3 im EKG) mit dem Verweis gemeint sind. Die beiden
Typen IMAGE und WAVEFORM stellen also echte Erweiterungen des COMPOSITE-Typs dar, was über
Vererbung modelliert werden kan.
SCOORD-Inhaltselemente haben als Wert einen als String kodierten Graphic Type“ (POINT, MUL”
TIPOINT, POLYLINE, CIRCLE oder ELLIPSE). Das zugehörige Attribut Graphic Data“ beinhaltet
”
Paare von Gleitkommazahlen, die jeweils einen Punkt beschreiben.
Die zulässigen Werte für den Range Type“ eines TCOORD-Elements unterscheiden sich von den Graphic
”
”
Types“ eines SCOORD-Elements. Außerdem sind die Koordinatenangaben ( Reference(s)“) natürlich
”
eindimensional. Obwohl SCOORD und TCOORD semantisch ähnliche Bedeutung haben, liegt also eine
recht unterschiedliche Datenstruktur vor.
Im PixelMed-Toolkit gibt es bereits eine Klassenhierarchie für Inhaltselemente, die diese Gemeinsamkeiten
ausnutzt: Alle Klassen für Inhaltselemente erben von der abstrakten Oberklasse ContentItem die gemeinsamen Felder (z. B. für Konzeptname und Relationstyp) und Get-Methoden für diese Felder. Die Klassen für
Inhaltselemente vom Typ TEXT, PNAME, DATE, TIME, DATETIME, und UIDREF erben von einer zwischengelagerten abstrakten Oberklasse StringContentItem. Die Klassen für IMAGE und WAVEFORM erben
von COMPOSITE.
Fast alle Klassen für Inhaltselemente des PixelMed-Toolkits waren versteckte innere Klassen von ContentItemFactory, was eine weitere Spezialisierung durch Vererbung verhinderte. Auch sah das PixelMed-Tookit in der
Version vom 20.1.2008 keine Datentypen für WAVEFORM und TCOORD vor. Auf Anregung des Autors hin
änderte David Clunie die Sichtbarkeit der inneren Klassen am 18.2.2008, fügte Klassen für WAVEFORM und
TCOORD hinzu und veröffentlichte die Änderungen noch am gleichen Tag als neue Version des Toolkits.
Offenbar sind die Klassen für Inhaltselemente im PixelMed-Toolkit nur zur Anzeige von bereits bestehenden
DICOM-SR-Dateien gedacht. Für diese Arbeit mussten die Klassen daher erheblich erweitert werden:
Im PixelMed-Toolkit basieren Inhaltselemente grundsätzlich auf einer bestehenden Attributliste. Beim
Neuanlegen von Inhaltselementen muss eine solche Attributliste aber erst erzeugt werden. Jeder Klasse
wurden daher typspezifische Konstruktoren hinzugefügt, die das komfortable Erzeugen neuer Attributlisten ermöglichen.
Für jede Get-Methode wurde eine entsprechende Set-Methode implementiert.
Jedes Inhaltselement wurde um eine Methode erweitert, die eine HTML-Repräsentation des Elements
generiert (vgl. Kap. 4.3.2.4).
Die Klasse CodedSequenceItem des PixelMed-Toolkits enthält nur Methoden zum Lesen des Tripels aus
Kodewert, Kodierungsschema-Bezeichner und Kodebedeutung von kodierten Elementen. Sie wurde um
alle Get- und Set-Methoden für den Enhanced Encoding Mode“ erweitert, mit dem über zahlreiche
”
Attribute beschrieben werden kann, aus welcher Kontextgruppe ein kodiertes Element stammt.
Ein CONTAINER-Inhaltselement hat eine Eigenschaft Continuity of Content“, die beschreibt, ob der
”
Seite 72
4
Inhalt als zusammenhängender Text oder, wie bei einer Aufzählung, als getrennte Elemente aufgefasst
werden soll. Diese Eigenschaft wurde im PixelMed-Toolkit nicht berücksichtigt und daher ergänzt.
Die Klassen für DATE- und TIME-Inhaltselemente wurden um statische Methoden erweitert, die Uhrzeitund Datumsangaben vom DICOM-Format in eine lokalisierte Darstellung bringen.
Der Klasse für PNAME-Inhaltselemente wurde ebenfalls eine statische Methode hinzugefügt, die Personennamen vom DICOM-Format in eine besser lesbare Darstellung überführt.
Schließlich wurde für alle 14 Datenklassen jeweils eine GUI-Klasse angelegt, mit der die Daten visualisiert
und bearbeitet werden können.
4.3.2 Grafische Darstellung von DICOM-SR-Dokumenten
Während man mit DICOM über sogenannte Presentation States“ (siehe Kap. 2.5.5) exakt festlegen kann, wie
”
Bilddaten auf einem Monitor angezeigt werden sollen, ist die Darstellung von strukturierten Dokumenten nicht
standardisiert. Der Standard enthält in PS 3.4, Anhang O.2.2, lediglich eine Formulierung, dass der Inhalt von
DICOM-SR-Dokumenten in seiner vollen Bedeutung“ und unzweideutig“ dargestellt werden soll. Was dies
”
”
konkret bedeutet, wird nicht weiter ausgeführt. Diese Problematik wird unter anderem in [Rie06] und [CDK01]
diskutiert.
Ein DICOM-SR-Dokument kann also in verschiedenen Systemen vollkommen unterschiedlich dargestellt werden.
Da die visuelle Repräsentation eines Dokuments – zumindest für Menschen – durchaus Inhalt transportieren
kann, stellt dieser Mangel ein ernsthaftes Problem dar. Teilweise lässt sich dieses Problem lösen, indem man
gemeinsam mit dem DICOM-SR-Dokument eine DICOM-Datei bereitstellt, in die ein fertig formatiertes Ausgabedokument eingebettet ist. Dafür bietet sich das PDF-Format an, dessen Einbettung in DICOM-Dateien
seit 2004 standardisiert ist72 .
Die Entscheidungen bezüglich der Darstellung von DICOM-SR-Dokumenten in GENRE sollen in den folgenden
Kapiteln besprochen werden. DICOM-SR-Dokumente lassen sich nach Kapitel 2.6.1 grob in die Metainformationen des Dokumentenkopfes und den eigentlichen Befundbericht unterteilen. In Kapitel 4.3.2.1 wird ein einfacher
Ansatz beschrieben, wie Informationen des Dokumentenkopfes bearbeitet werden können.
Der Inhalt des Befundberichts besteht wie in Kapitel 2.6.2 beschrieben aus verschachtelten Sequenzen, was in
einer baumartigen Datenstruktur resultiert. Es ist daher naheliegend, den Inhalt des Befundberichts grafisch
ebenfalls als Baum darzustellen und dem technisch versierten Benutzer damit unmittelbaren Zugriff auf die
endgültige Struktur des Dokuments zu geben. Jeder Knoten des Baumes entspricht in dieser Darstellung einem
Inhaltselement des DICOM-SR-Dokuments. Die Implementierungsprobleme bei dieser Darstellungsart werden
in Kapitel 4.3.2.2 erläutert.
Für ärztliches Personal ist die Baumdarstellung eher verwirrend. Menschen sind es zum Beispiel durch den Umgang mit Büchern gewohnt, baumartig strukturierte Informationen in linearisierter (pre-order-) Form präsentiert
zu bekommen. Das Programm sollte es also ermöglichen, aus dem DICOM-SR-Baum eine linearisierte Fassung
in einem gängigen Dateiformat zu erzeugen. Kapitel 4.3.2.4 beschreibt diese Linearisierung.
4.3.2.1 Darstellung des Dokumentenkopfes von DICOM-SR-Dokumenten
Die den verschiedenen Information Entities (z. B. Patient, Study, Series) zugeordneten Metainformationen
des Dokumentenkopfes besitzen keine innere Ordnung sondern liegen wie in Kapitel 2.5.7 beschrieben in einer aufsteigend nach Attribut-Tag sortierten Liste vor. Da es sich fast ausschließlich um Attribut-Wert- bzw.
Attribut-Multiwert-Paare handelt, können sie tabellarisch angezeigt werden. Abbildung 31 zeigt den in GENRE integrierten Dialog zur Bearbeitung von DICOM-SR-Metainformationen. Die zu einer Informationseinheit
gehörenden Attribute werden jeweils auf einer eigenen Registerkarte dargestellt und lassen sich über Textfelder
bearbeiten. Dabei zeigt der Dialog nur die Attribute an, die im DICOM-Standard als verpflichtend markiert
sind. Wollte man alle denkbaren Attribute anzeigen, so sollte man überlegen, wie man den Dialog automatisch
aus einer Konfigurationsdatei generieren kann. Aufgrund der vielfältigen Optionalitäten und Bedingungen von
Attributen sprengt dieser Ansatz das Thema der Diplomarbeit und wurde nicht weiter verfolgt. Auch wurde
beim Dialog aus Zeitgründen auf Eingabehilfen für Personennamen, Datumsangaben etc. verzichtet.
72 Vgl.
Supp. 104 DICOM Encapsulation of PDF Documents“, ftp://medical.nema.org/medical/dicom/final/sup104_ft.pdf.
”
Seite 73
4
(a) Attribute der Study IE
(b) Attribute des SR Document General Module
Abbildung 31: Formulare zur Bearbeitung von wichtigen DICOM-Headerinformationen
4.3.2.2 Darstellung des Inhaltsbaumes von DICOM-SR-Dokumenten
Baumdarstellung mit JTree Die mit Java mitgelieferte Bibliothek zur Erstellung plattformunabhängiger grafischer Oberflächen, Swing, liefert mit der Klasse JTree bereits eine sehr mächtige Komponente für Bäume mit.
Standardmäßig wird ein Knoten des Baumes über ein Icon und einen einzeiligen, beschreibenden Text (JLabel)
repräsentiert.
Es ist naheliegend, über das Icon den jeweiligen Datentyp eines Knotens darzustellen. Für die 14 komplexen
Datentypen von Inhaltselementen wurden geeignete Icons aus einer freien Icon-Sammlung [126] ausgewählt bzw.
aus mehreren kombinierten Icons dieser Sammlung erstellt.
Die Darstellungsform des beschreibenden Textes als einzeiliges JLabel erscheint im Falle von DICOM-SR
ungünstig: Ein Knoten (=Inhaltselement) in einem DICOM-SR-Dokument ist für sich wiederum eine komplexe
Datenstruktur, die sich in vielen Fällen nicht geeignet auf ein Icon und eine einzelne Textzeile reduzieren lässt.
Beispielsweise sollte im Baum der vollständige Text einer TEXT-Inhaltskomponente erscheinen, damit dem
menschlichen Betrachter ein möglicher inhaltlicher Zusammenhang zum folgenden Geschwisterknoten deutlich
wird. Für IMAGE-Inhaltskomponenten bietet sich, soweit vorhanden, ein Thumbnail des Bildes eher an als die
textuelle Darstellung von UIDs, die auf das Bild verweisen.
Angepasstes Erscheinungsbild für Knoten Glücklicherweise sieht JTree ein angepasstes Erscheinungsbild für
Knoten vor, das über ein JLabel hinausgeht. Dieses Erscheinungsbild wird im Swing-Jargon TreeCellRenderer
genannt. Einem JTree kann über die Methode setCellRenderer(TreeCellRenderer x) ein neues Knotenerscheinungsbild zugewiesen werden.
Das Erstellen eines maßgeschneiderten TreeCellRenderers ist einfach: Man erstellt eine Klasse, die das Interface
TreeCellRenderer implementiert, und überschreibt in dieser Klasse die Methode
public Component getTreeCellRendererComponent(...).
Man beachte den Rückgabetyp Component: Ein Knoten kann also aus einem beliebigen grafischen Element
bestehen, insbesondere auch aus einem Container, der wiederum beliebig geschachtelte grafische Elemente und
Container enthalten kann. Das Erstellen eines eigenen TreeCellRenderers über Vererbung von der Klasse
DefaultTreeCellRenderer, wie es als einfacher Weg im Java-Swing-Tutorial [106] beschrieben wird, ist nicht
zu empfehlen, da DefaultTreeCellRenderer von JLabel Eigenschaften und Methoden erbt, die für komplexere
TreeCellRenderer nicht benötigt werden.
Darstellungsfehler bei bestimmten Look&Feels“ Für tiefgreifende Veränderungen an JTrees ist es wichtig
”
zu verstehen, dass die Methoden für die Standardoptik und das Standardverhalten von Swing-Komponenten
maßgeblich durch das eingestellte sogenannte Look&Feel bestimmt werden. Jeder Swing-Komponente wird
dazu eine sogenannte ComponentUI zugeordnet, die die grafische Darstellung der Komponente und das EventHandling übernimmt. Für Bäume existiert die abstrakte Oberklasse TreeUI und ihre konkrete Implementierung
Seite 74
4
BasicTreeUI, die für verschiedene Look&Feels weiter spezialisiert wird.
Das Look&Feel-Konzept soll dafür sorgen, dass Java-Anwendungen den nativen Anwendungen auf dem jeweiligen Betriebssytem hinsichtlich Aussehen und Handhabung ähneln. Look&Feel-abhängig sind bei JTree zum
Beispiel die verwendeten Standard-Icons und Schriftarten, die Darstellung von Verbindungslinien des Baumes
oder das Verhalten bei Doppelklick auf einen Knoten.
Unter vielen Betriebssystemen sind Bäume mit mehrzeiligen Knoten unüblich. Ist ein entsprechendes Look&Feel
eingestellt, kommt es bei GENRE zu Darstellungsfehlern, die das Programm nahezu unbenutzbar machen. Dieser
Effekt wurde festgestellt bei:
com.sun.java.swing.plaf.windows.WindowsLookAndFeel (steht nur unter Windows zur Verfügung)
com.sun.java.swing.plaf.motif.MotifLookAndFeel
Eine korrekte Darstellung gelang hingegen mit:
javax.swing.plaf.metal.MetalLookAndFeel (Java-Standard-Look&Feel)
com.sun.java.swing.plaf.gtk.GTKLookAndFeel (für neuere Versionen von Linux und Solaris, steht unter Windows nicht zur Verfügung)
Die Darstellung mittels apple.laf.AquaLookAndFeel konnte nicht getestet werden, da dieses Look&Feel nur
auf Apple-Rechnern Bestandteil der JVM ist und kein Apple-Rechner zur Verfügung stand.
Die fehlerhafte Darstellung der grafischen Oberfläche von GENRE unter einigen Look&Feels ist zwar bedauerlich, der Autor entschied sich aber, dies zugunsten der besseren Übersichtlichkeit von mehrzeiligen Knoten in
Kauf zu nehmen. Schließlich steht das korrekt funktionierende Metal-Look&Feel unter jedem Betriebssystem
zur Verfügung. Insofern wird die Plattformunabhängigkeit durch die Darstellungsfehler nicht beeinträchtigt.
Editierbare Knoten Wie oben dargestellt, sollte es GENRE ermöglichen, Inhaltskomponenten direkt an ihrer
Position im Baum zu editieren. Der Autor sieht in dieser Vorgehensweise folgende Vorteile:
Der Blick des Benutzers kann beim Umschalten in den Bearbeiten-Modus an gleicher Stelle auf dem
Bildschirm verharren
Der zu bearbeitende Knoten steht weiter in seinem durch Geschwister- und Vaterknoten gegebenen Kontext.
Im Gegensatz zu editierbaren Tabellenzellen, die die meisten Computeranwender aus Tabellenkalkulationsprogrammen kennen, sind editierbare Knoten in Bäumen eher ungewöhnlich. Deren vermutlich häufigster Anwendungsfall ist das Umbenennen von Verzeichnissen in Dateimanagern.
Der geringen Popularität editierbarer Baumknoten mag geschuldet sein, dass tiefgehende Informationen zu
diesem Thema sowohl in der offiziellen Java-Dokumentation als auch in Anwenderforen schwer zu finden sind.
Eine recht ausführliche Behandlung von JTrees bieten [Zuk05] und [Top01] (Kapitel 10, The Tree Control“).
”
Das ansonsten sehr brauchbare Swing-Tutorial von Sun [106] behandelt editierbare Zellen nur im Zusammenhang
mit JTables. Alle drei Quellen befassen sich nur mit einfachen, einzeiligen Anwendungsfällen (String-Eingabe,
Checkbox oder Combobox).
Im Java-Jargon heißt ein editierbarer Baumknoten TreeCellEditor. Mit der Methode setCellEditor(TreeCellEditor cellEditor) kann einem JTree ein selbstgeschriebener TreeCellEditor zugewiesen werden. Standardmäßig ist bereits ein DefaultTreeCellEditor zugewiesen, der ein einfaches, einzeiliges Textfeld zur Eingabe
bereitstellt. Für das oben genannte Umbenennen von Verzeichnissen reicht dies aus, für GENRE mussten jedoch
erweiterte Editoren programmiert werden.
Ein selbstgeschriebener TreeCellEditor muss das gleichnamige Interface implementieren, das eine Spezialisierung des Interfaces CellEditor ist. Desweiteren bietet es sich an, von der abstrakten Klasse AbstractCellEditor
zu erben, da diese bereits ein (sehr einfach gehaltenes) Listener-Management bereitstellt. Das Erstellen eines
eigenen TreeCellEditors über Vererbung von DefaultTreeCellEditor erweist sich als unpraktisch, da dieser
bereits auf das Zusammenspiel mit einem DefaultTreeCellRenderer, also letztlich einem einfachen JLabel,
optimiert ist.
Im Folgenden sollen einige Methoden der Interfaces CellEditor und TreeCellEditor kurz vorgestellt und
dabei Grundprinzipien editierbarer Baumknoten erläutert werden:
Seite 75
4
isCellEditable: Das Editieren von Knoten wird durch ein Tastenkürzel oder die Maus gestartet. Die
Tastenkombination zum Bearbeiten eines Knotens wird über die Methode initComponentDefaults(...)
im Look&Feel des Baumes festgelegt, typischerweise wird die Taste F2 verwendet. Das Verhalten bei
Verwendung der Maus kann der Programmierer über die Methode isCellEditable selbst festlegen: Liefert
sie true zurück, so wird das Editieren gestartet. Bei jedem Mausklick auf einen Knoten des Baumes wird
isCellEditable von der BasicTreeUI aufgerufen und erhält als Parameter das zugehörige MouseEvent.
Man kann also beispielsweise ein Editieren mit Dreifach-Mausklick starten lassen oder mit zwei Mausklicks,
die länger als eine gewisse Zeitspanne auseinanderliegen. Tasten-Events werden nicht an isCellEditable
weitergereicht, so dass eine einfache Änderung der Tastensteuerung nicht möglich ist.
getTreeCellEditorComponent: Wenn isCellEditable true zurückliefert, wird in der Methode BasicTreeUI.startEditing(...) als nächstes die Methode getTreeCellEditorComponent aufgerufen. Diese hat
als Rückgabetyp Component, also eine beliebige Swing-Komponente. Das Aussehen des TreeCellEditors
muss daher in dieser Methode festgelegt werden. Nach dem Aufruf von getTreeCellEditorComponent
wird die GUI des Baumes aktualisiert, also die Editor-Swing-Komponente angezeigt und der Baum so
arrangiert, dass der editierbare Knoten genug Platz hat.
cancelCellEditing: Diese Methode wird von BasicTreeUI.completeEditing aufgerufen, wenn sich die
dem Knoten zugrundeliegenden Daten ändern oder wenn der Benutzer durch eine Maus- oder Tastaturaktivität das Editieren eines Knotens abbricht, beispielsweise durch Drücken der ESC-Taste oder durch
Selektieren eines anderen Baumknotens.
stopCellEditing: Ähnelt cancelCellEditing, wird aber aufgerufen, wenn der Benutzer die Eingabe regulär abschließt, zum Beispiel durch Drücken der Eingabetaste. Um festzulegen, dass das Selektieren eines
anderen Baumknotens nicht cancelCellEditing sondern stopCellEditing aufruft, also das Editieren
des Knotens regulär beendet, verwendet man die Methode JTree.setInvokesStopCellEditing(...).
getCellEditorValue: Diese Methode muss nach der Bearbeitung eines Knotens das Datenobjekt zurückliefern, das dem Knoten zukünftig zugrunde liegen soll. Wurde das Bearbeiten regulär beendet,
veranlasst BasicTreeUI die Aktualisierung der Daten im Datenmodell des Baumes über die Methode
TreeModel.valueForPathChanged(...).
Es soll nicht verschwiegen werden, dass editierbare Baumknoten auch ihre Nachteile haben. Beispielsweise
ist unklar, was passieren soll, wenn der Benutzer eine ungültige Eingabe vornimmt und dann einen anderen
Baumknoten selektieren möchte. Soll die Eingabe verworfen werden oder der alte Baumknoten im Fokus und
editierbar bleiben? In GENRE wird das Standardverhalten von Swing verwendet und die Eingabe verworfen.
Bei der Verwendung editierbarer Baumknoten kann nur ein Knoten zur Zeit bearbeitet werden, während bei
der Verwendung nicht-modaler Dialoge auch mehrere Knoten gleichzeitig bearbeiten könnte. Zudem barg der
Quellkode für editierbare Zellen im JDK in der Vergangenheit zahlreiche Fehler. Der Artikel [30] behandelt
verschiedene Problematiken editierbarer Tabellenzellen anhand einfacher Beispiele. Diese Probleme sind teilweise
auf editierbare Baumknoten übertragbar.
Editierbare Knoten, die ihre Größe ändern können, z. B. Textfelder variabler Größe oder Formulare, bei denen
erweiterte Elemente auf Knopfdruck eingeblendet werden (im Microsoft Windows Jargon progressive disclos”
ure“), verursachen weitere Darstellungsprobleme im JTree. Die Größe des Knotens muss angepasst werden,
damit alle Elemente des Knotens sichtbar sind und nicht von benachbarten Baumknoten verdeckt werden. Dies
kann man erzwingen, indem man die bevorzugte Größe des Knotens über die Methode revalidate() neu
berechnet und anschließend über setSize(...) neu zuweist.
Ein weiteres Problem bleibt bestehen: Ein vergrößerter Knoten überdeckt nun selbst den unteren Nachbarknoten im Baum, ein verkleinerter Knoten sorgt für eine unschöne Lücke. Es ist also ein kompletter Neuaufbau
des JTrees vonnöten. Da die Größeninformationen der einzelnen Knoten in BasicTreeUI aus Performancegründen gecached werden, hilft ein Aufruf der sonst gängigen Swing-Funktionen validate() oder revalidate()
auf dem JTree nicht. In BasicTreeUI werden stattdessen die Funktionen treeState.invalidateSizes() und
updateSize() verwendet. Diese sind jedoch nicht von außen zugänglich. Beim Design von BasicTreeUI wurde
offenbar angenommen, dass sich Knoten-Editor-Komponenten nach dem Aufruf nicht mehr in der Größe ändern.
Um eine Aktualisierung des JTree-Layouts zu erzwingen, muss man also eigentlich eine Spezialisierung von
BasicTreeUI schreiben, was insbesondere aufgrund des komplexen Zusammenspiels mit bereits spezialisierten
TreeUI-Klassen des jeweiligen Look&Feels aufwändig und fehlerträchtig ist. Nach einigem Suchen konnte jedoch
ein Workaround gefunden werden: BasicTreeUI bietet die öffentlichen Methoden setLeftChildIndent(...)
Seite 76
4
und setRightChildIndent(...) an, die als Seiteneffekt einen kompletten Neuaufbau der TreeUI erzwingen.
Der folgende Quelltext ist also ein unschöner Trick, ist aber sehr kompakt und funktioniert:
BasicTreeUI ui = (BasicTreeUI) srTree.getUI();
ui.setLeftChildIndent(ui.getLeftChildIndent());
4.3.2.3 Darstellung von kodierten Elementen in DICOM-SR-Dokumenten
Bei der Konzeption von GENRE wurde darauf geachtet, dass der Benutzer möglichst viele Details von DICOMSR-Dokumenten manipulieren kann. Dazu gehören auch die Attribute des Enhanced Encoding Mode“ von
”
Kodesequenzattributen, die nach Kenntnis des Autors mit keinem anderen frei verfügbaren Werkzeug bearbeitet werden können. Abbildung 32 zeigt die in GENRE implementierten Dialoge zur Angabe kodierter Elemente.
In beiden Dialogen werden die Felder für den Enhanced Encoding Mode“ nur dann angezeigt, wenn sie Text
”
enthalten oder der Benutzer das jeweilige Kontrollkästchen aktiviert. Auch das Feld Private Scheme Crea”
tor UID“ wird gemäß Konvention nur dann angezeigt, wenn der Kodierungsschema-Bezeichner wie im rechts
abgebildeten Dialog mit 99“ beginnt.
”
(a) Konzeptname als kodiertes Element
(b) Inhaltselement vom Typ CODE“
”
Abbildung 32: Darstellung kodierter Elemente von DICOM-SR-Dokumenten in GENRE
4.3.2.4 Rendering eines DICOM-SR-Dokuments in andere Ausgabeformate
Aus Abbildung 7 geht hervor, dass DICOM (und damit auch DICOM-SR) typischerweise nur in bildverarbeitenden Fachabteilungen eines Krankenhauses anzutreffen ist. Es kann also nicht davon ausgegangen werden, dass
Seite 77
4
alle potentiellen Empfänger von mit GENRE erstellten Dokumenten, wie beispielsweise das Medizincontrolling
im Krankenhaus oder niedergelassene Hausärzte, über Anzeigemöglichkeiten für DICOM-SR verfügen. Daher
wurde in GENRE prototypisch ein Export in das verbreitete HTML-Format integriert (vgl. Abb. 33).
Die HTML-Ausgabe berücksichtigt die Attribute des Dokumentenkopfs, die mit GENRE bearbeitet werden
können (vgl. Kap. 4.3.2.1), und natürlich den Inhaltsbaum von Dokumenten. Kodierungstripel sind auch im
exportierten HTML-Dokument noch als Tooltip enthalten.
Neben dem HTML-Format sollten weitere Formate berücksichtigt werden. PS 3.18 des DICOM-Standards,
Web Access to DICOM Persistent Objects (WADO)“, widmet sich dem Zugriff auf DICOM-Objekte von
”
nicht-DICOM-Systemen und kann daher als Maßstab herangezogen werden. Für den Export von DICOMSR-Dokumenten sieht PS 3.18 in Kapitel 7.3.2 die Formate DICOM (Originalformat), Nur-Text und HTML
verpflichtend vor. Zusätzlich empfielt PS 3.18 Exportmöglichkeiten nach XML, PDF, RTF und HL7-CDA.
Export nach Microsoft Word Im Rahmen dieser Diplomarbeit ist vor allem ein Export in das MicrosoftWord-Format von Interesse, da dieses bisher in der Pathologie am UK-SH verwendet wird. Um Word-Dateien
zu erstellen, gibt es im Wesentlichen drei Ansätze:
1. Direktes Erzeugen des Word-Binärformats (.doc)
2. Direktes Erzeugen von Office Open XML“ (OOXML), einem XML-basierten Format, das Microsoft mit
”
Office 2007 eingeführt hat (.docx)
3. Indirektes Erzeugen von Word-Dateien mittels Fernsteuerung von Word
Die Spezifikation des Word-Binärformats wurde im Februar 2008 von Microsoft offiziell frei zugänglich gemacht
[69]. Es existieren jedoch bisher keine Toolkits für die einfache Erstellung von Dokumenten in diesem Format.
Das Konvertieren von DICOM-SR ins OOXML-Format wurde von einem Praktikanten am IMI evaluiert. Leider
ist das OOXML-Format ähnlich komplex wie die Office-Binärformate. Mitte Juni veröffentlichte Microsoft ein
Toolkit für OOXML, das die Erstellung solcher Dokumente vereinfachen könnte [42]. Es konnte aus Zeitgründen
in dieser Diplomarbeit nicht mehr berücksichtigt werden und ist außerdem nicht für Java, sondern nur für .NETProgrammiersprachen geeignet.
Die Fernsteuerung von Word ist über dessen COM-Schnittstelle möglich. Wie man von Java aus auf die COMSchnittstelle von Windowsprogrammen zugreift, hat der Autor dieser Arbeit in seiner Studienarbeit beschrieben [Sch06]. Generell hat dieser Ansatz den Nachteil, dass ein Windows-Rechner mit einer Word-Lizenz zur
Verfügung stehen müsste, während GENRE ansonsten auf Plattformunabhängigkeit ausgelegt ist. Daher wurde
er ebenfalls nicht weiter verfolgt.
Weitere Formate Dateien im OpenDocument-Text-(ODT)-Format, wie sie von OpenOffice.org Writer verwendet werden, können zum Beispiel mit dem kostenloses Java-Toolkit jOpenDocument manipuliert werden
[54]. Für die Erzeugung von PDF bietet sich der XML-Export in den Extensible Stylesheet Language – For”
matting Objects“-Dialekt (XSL-FO) an. Solche Dateien können mit entsprechenden Formatierern, sogenannten
XSL-FO-Prozessoren“, in PDF umgewandelt werden. Ein XSL-FO-Prozessor, der in Java geschrieben ist und
”
aus anderen Java Programmen heraus verwendet werden kann, ist beispielsweise Apache FOP [5].
4.3.3 Benutzungsfreundlichkeit
Die Bedeutung der Benutzungsfreundlichkeit von Software für medizinisches Personal kann gar nicht überschätzt
werden. Bortoluzzi et al. drücken es so aus:
It is extremely important for health care software to be user-friendly and fast-to-learn, otherwise,
”
it might be abandoned or under-used by the staff.“ [BWM03]
Insofern wurde auch in dieser Diplomarbeit besonderer Wert auf eine einfache Benutzbarkeit der Software gelegt.
In den folgenden Kapiteln werden einige Ideen zur Benutzungsfreundlichkeit disktutiert, die vollständig oder
teilweise in GENRE implementiert wurden.
Seite 78
4
Abbildung 33: HTML-Export von DICOM-SR-Dokumenten mit GENRE
Seite 79
4
4.3.3.1 Internationalisierung und Lokalisierung
In Kapitel 4.2.1 wurde beschrieben, dass es trotz zunehmender Verbreitung von DICOM-SR bisher keine zufriedenstellende Software auf dem Markt gibt, die Ähnliches wie GENRE leistet. Aus diesem Grund wurde GENRE
von vornherein so konzipiert, dass es nach Abgabe der Diplomarbeit als kostenloses Open-Source-Werkzeug einer weltweiten Benutzergemeinde zur Verfügung gestellt werden kann. Dazu gehört auch eine Anpassung an
regionale Umstände.
Unter Internationalisierung (engl.: internationalisation oder kurz i18n 73 ) versteht man die Schaffung der technischen Voraussetzungen für die Anpassung der Benutzeroberfläche eines Programms an Sprach- und Kulturkreisspezifische Gegebenheiten. Die eigentliche Anpassung wird üblicherweise als Lokalisierung (engl.: localisation oder kurz L10n 74 ) bezeichnet. Zur Lokalisierung zählt vor allem die Übersetzung von Texten in die
Landessprache, aber auch die Einhaltung von Schreibkonventionen bei Datumsangaben, Uhrzeiten, Gleitkommazahlen etc. Auch wenn es sich bei der Übersetzung von Programmen in die jeweilige Landessprache des
Anwenders um eine technisch recht einfache Aufgabe handelt, so ist die Verbesserung der Benutzerakzeptanz
durch diese Maßnahme nach Erfahrung des Autors groß. Selbst technisch versierte Anwender greifen oft lieber
zu einer landessprachlichen Variante ihrer Software, sofern diese bereitsteht.
Internationalisierung von Zeichenketten Grundprinzip für die Internationalisierung von Zeichenketten ist
deren Ausgliederung aus dem Quelltext. Stattdessen werden alle zu übersetzenden Zeichenketten mit einem
eindeutigen Schlüssel versehen und in externen Text-Dateien gespeichert (z. B. in einem XML-Format). Zur
Laufzeit des Programms werden die benötigten Zeichenketten dynamisch aus diesen Textdateien eingelesen.
Diese Vorgehensweise hat mehrere Vorteile: Zum einen kann die Übersetzung des Programms in andere Landessprachen ohne Programmierkenntnisse erfolgen und als Werkzeug reicht ein einfacher Text-Editor. Zum anderen
muss bei Anpassungen von Programmausgaben das Programm nicht neu übersetzt werden. Dies beschleunigt
nicht nur den Software-Entwicklungsprozess, sondern ermöglicht zudem die Anpassung von Ausgaben durch den
(technisch versierten) Anwender selbst ( Personalisierung“, customization“). Gerade im stationären Gesund”
”
heitswesen mit den in jedem Krankenhaus anderen terminologischen Konventionen erwartet der Autor einen
Bedarf an Personalisierbarkeit.
Die Java-Klassenbibliothek bringt bereits zahlreiche Methoden für die Internationalisierung und Lokalisierung
von Programmen mit75 . Eine gute Einführung in diese Methoden bietet das offizielle Tutorial von Sun im
entsprechenden Abschnitt [107]. Eine große Hilfe stellt auch der in Eclipse integrierte Assistent zum Ausgliedern
von Zeichenketten aus dem Quelltext dar (vgl. Abb. 34). Dieser beschleunigt die Arbeit enorm und verringert
die Fehllerrate im Vergleich zu manuellem Vorgehen.
Für eine schnelle und erfolgreiche Internationalisierung von Zeichenketten sind softwarearchitektonische Maßnahmen sinnvoll. Vor allem sollten Klassen für die grafische Darstellung der Benutzeroberfläche sauber von
Klassen getrennt werden, die Aufgaben des Kontrollflusses oder der Datenhaltung übernehmen (z. B. mithilfe
des Model-View-Controller-Patterns aus der Smalltalk-Welt [116]). Für GENRE wurde eine Internationalisierung von vornherein eingeplant. Die Ausgliederung von Zeichenketten betraf daher nur wenige Pakete und darin
jeweils eine überschaubare Anzahl Klassen.
Eine weitere wichtige Maßnahme ist es, die Dimensionierung und Platzierung von GUI-Elementen von deren
textueller Beschriftung abhängig zu machen. Hierfür bietet Java das Konzept der Layout Manager, das in [106]
ausführlich beschrieben und in GENRE durchgängig eingesetzt wird.
Abbildung 35 zeigt abschließend die GENRE-Benutzeroberfläche mit deutschen Menüs, Schaltflächen, Beschriftungen etc. Die Anpassung an weitere Sprachen ist technisch trivial.
Lokalisierung von Datumsangaben
kalisierung:
Bei Datumsangaben gibt es mindestens folgende Unterschiede in der Lo-
Reihenfolge von Tag, Monat und Jahr
73 Die
Zahl 18 bezieht sich auf die Anzahl der ausgelassenen Buchstaben zwischen i“ und n“.
”
”
hier steht die Zahl 10 für zehn ausgelassene Buchstaben. Das große L“ wird verwendet, weil ein kleines l“ und ein großes
”
”
I“ leicht verwechselt werden können.
”
75 Das
Microsoft .NET-Framework bietet entsprechende Klassen im Namespace System.Globalization
74 Auch
Seite 80
4
Abbildung 34: Assistent in Eclipse zum Ausgliedern von Zeichenketten in Textdateien
Abbildung 35: GENRE-Benutzeroberfläche auf deutsch
Seite 81
4

Trennzeichen zwischen den einzelnen Elementen (z. B. .“, /“, -“)
” ”
”
Wochentags- und Monatsbezeichnungen (ausgeschrieben und abgekürzt)
Wochentag, mit dem die Woche beginnt (typischerweise Sonntag oder Montag)
Gängige Kurzschreibweise des Datums (z. B. mit abgekürztem Monatsnamen oder Monat als Zahl)
Ein Versuch des Autors, das Datum lokalisiert darzustellen und eine landesübliche Eingabe zu erlauben, wurde
aus Komplexitätsgründen abgebrochen. Stattdessen wurde das GUI-Element JXDatePicker aus der SwingXBibliothek verwendet, das mittlerweile alle genannten Lokalisierungseigenheiten beherrscht. Für die Ausgabe
einer Kurzdarstellung in der Titelzeile des Datums-Editors wurden Java-eigene Funktionen verwendet. Um
die Eingabe häufig benötigter Datumsangaben zu beschleunigen, stellt die Benutzeroberfläche von GENRE
zusätzliche Knöpfe bereit.
(a) Locale en US
(b) Locale fr FR
Abbildung 36: Eingabe eines Datums bei verschieden eingestellter Default Locale
Lokalisierung von Zeitangaben Bei der Formatierung von Zeitangaben sind mindestens folgende Unterschiede
in der Lokalisierung zu berücksichtigen:

Trennzeichen zwischen Stunden, Minuten und Sekunden (z. B. :“)
”
Trennzeichen zwischen Sekunden und Sekundenbruchteilen (z. B. .“, ,“)
” ”
Verwendung von 12- oder 24-Stunden-Darstellung
Gängige Symbole für Vor- und Nachmittag bei 12-Stunden-Darstellung (z. B. AM“, a.m.“, A.M.“)
”
”
”
Langnamen und Abkürzungen für Zeitzonen
Zeitangaben können in Java ebenso wie Datumsangaben mit der Klasse SimpleDateFormat lokalisiert werden. Dabei werden aber nur die letzten beiden der oben genannten Punkte berücksichtigt. Außerdem ist die
kleinste formatierbare Zeiteinheit eine Millisekunde, während DICOM die Angabe von Mikrosekunden erlaubt.
Insofern wäre die Lokalisierung von Zeitangaben mit einigem händischem Aufwand verbunden und wurde aus
Zeitgründen in der Diplomarbeit nicht berücksichtigt.
Lokalisierung von dezimalen Festkomma- und Gleitkommazahlen
als Zeichenkette betrachtet aus den folgenden Bestandteilen:
Eine dezimale Gleitkommazahl besteht
Vorzeichen
Ganzzahliger Anteil (Ziffern, evtl. führende Nullen), evtl. mit Gruppierungszeichen für Tausender (in
Deutschland: .“)
”
Dezimaltrennzeichen (in Deutschland: Dezimalkomma)
Nachkommastellen (Ziffern, evtl. Folgenullen)
Seite 82
4
Exponententrennzeichen (z. B. E“, e“ oder x10ˆ“)
”
”
”
Vorzeichen des Exponenten
Exponent (Ziffern, evtl. führende Nullen)
DICOM lehnt sich für die interne Repräsentation von Gleitkommazahlen (DICOM-Jargon: Value Representa”
tion Decimal String“) an die Definition aus dem FORTRAN 77 Standard an (ANSI X3.9-1978, Kap. 4.4 Real
”
Type“ [ANS78])76 :
Als Exponententrennzeichen wird E“ verwendet
”
Die Angabe eines Exponenten ist optional (bei fehlendem Exponenten handelt es sich um eine Festkommazahl bzw. ganze Zahl)
Sowohl das Vorzeichen der gesamten Zahl als auch das Vorzeichen eines etwaigen Exponenten sind im Fall
positives Vorzeichen“ optional
”
Die Angabe von Nachkommastellen ist optional, ebenso die Angabe des ganzzahligen Anteils (in diesem
Fall wird ein ganzzahliger Anteil von 0“ angenommen), allerdings dürfen nicht beide Elemente ausgelassen
”
werden
Bei vorhandenem ganzzahligen Anteil und fehlenden Nachkommastellen ist die Angabe des Dezimaltrennzeichens optional
Tausender-Gruppierungszeichen und Leerzeichen zwischen den einzelnen Elementen sind nicht erlaubt
Ein benutzerfreundliches Programm sollte eine lokalisierte Darstellung von dezimalen Zahlen bieten und deren
Eingabe in landesüblicher Schreibweise erlauben. Vor allem sollten die landesüblichen Dezimaltrennzeichen
und Exponententrennzeichen verwendet werden. Tausender-Gruppierungszeichen können die Übersichtlichkeit
bei der Darstellung erhöhen, bei der Eingabe von Daten sind sie jedoch eher hinderlich. Java unterscheidet
sogar noch verschiedene Minuszeichen und Symbole für die Null, dies wurde in GENRE jedoch zunächst nicht
berücksichtigt.
(a) Locale de de
(b) Locale en US
(c) Locale fr FR
Abbildung 37: Landesübliche Eingabe und Anzeige von Zahlenwerten
Für die Formatierung von Fest- und Gleitkommazahlen bietet Java die Klasse DecimalFormat im Paket java.text
an. Obwohl diese Klasse sehr funktionsreich und sicherlich leistungsfähig ist, wurde beschlossen, für diese Arbeit
auf ihre Anwendung zu verzichten. Hintergrund sind die oben genannten vielfältigen Optionalitäten der Komponenten sowie führender und folgender Nullen. Der Autor glaubt, dass ein benutzerfreundliches Programm
explizit angegebene positive Vorzeichen ebenso wie überflüssige Nullen und die Position des Dezimaltrennzeichens erhalten sollte, da in verschiedenen Kontexten möglicherweise verschiedene Schreibweisen üblich und
damit übersichtlich sind. Beispielsweise ist es denkbar, dass in einem strukturierten Befundbericht einerseits
Messwerte eines Gerätes abgelegt sind, das mit normalisierten Gleitkommazahl arbeitet, andererseits aber auch
Messwerte eines anderen Gerätes, das technische Notation (also ausschließlich durch drei teilbare Exponenten)
verwendet. Diese Variabilität ist mit festen Zahlenformaten nicht realisierbar.
Abbildung 37 zeigt die Eingabemaske von GENRE für Zahlenwerte. In der Titelzeile wird das Ergebnis der
Eingabe angezeigt. Man beachte, dass überflüssige Leerzeichen ignoriert werden und zur Übersichtlichkeit
Tausender-Trennzeichen hinzugefügt werden.
76 Zur
Diskussion über diese Herkunft siehe auch Thread Decimal Strings and ANSI X3.9“ auf comp.protocols.dicom vom
”
27./28.5.2008,
http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/8fecff6156cbb544/5b1a7bece6f650af
Seite 83
4
4.3.3.2 Ausblenden von GUI-Elementen
Um die Benutzeroberfläche von GENRE übersichtlicher zu machen, wurde die Möglichkeit geschaffen, nicht
benötigte Elemente durch Mausklick auf Knöpfe ausblenden zu können. In Abbildung 38 sind diese Knöpfe rot
markiert.
Abbildung 38: Knöpfe zum Verbergen von Teilen der GENRE-Benutzeroberfläche
Im linken Teil der GENRE-Benutzeroberfläche finden sich Angaben zum Konzeptnamen des markierten Inhaltselements. Die zum Teil umfänglichen Informationen, wenn ein Konzeptname einer Kontextgruppe entnommen
wurde, sind für nicht-technische Benutzer üblicherweise irrelevant und möglicherweise verwirrend. Daher wurden
diese Informationen in eine sogenannte JXTaskPane verpackt, die sich bei Bedarf auf ihre Überschrift reduzieren
lässt (Abb. 38, 1.). Die GUI-Klasse JXTaskPane wurde der freien Java-Swing-Bibliothek SwingX 0.9.1 entnommen [111].
Im rechten Teil der GENRE-Benutzeroberfläche befindet sich ein Bereich zum Anlegen neuer Knoten. Soll ein
bestehendes DICOM-SR-Dokument nur betrachtet oder nur innerhalb der bestehenden Knoten bearbeitet werden, ist dieser Bereich überflüssig und kann weggeklappt werden, um Platz zu schaffen (Abb. 38, 2.). Hierzu
wurde die in Swing integrierte GUI-Klasse JSplitPane verwendet. Auch der gesamte Informationsbereich zum
Konzeptnamen des aktuell ausgewählten Inhaltselements kann vollständig weggeklappt werden (Abb. 38, 3.).
Dies schafft zugleich Platz auf Monitoren mit geringer Auflösung. Damit sich der interessierte Benutzer trotzdem über den Konzeptnamen informieren kann, wurden die wichtigsten Informationen hierzu auch in Tooltips
integriert.
4.3.4 Einbinden von Bildern aus einem DICOM-Bildarchiv
Ein DICOM-SR-Inhaltselement vom Typ IMAGE“ verweist auf ein Bild über dessen SOP-Class- und SOP”
Instance-UID. Optional kann über ein weiteres Pärchen aus SOP-Class- und SOP-Instance-UID ein zugehöriger
Presentation State und für Multi-Frame-Bilder der gewünschte Frame angegeben werden.
Die Auswahl von Bildern durch die Eingabe von SOP-Class- und SOP-Instance-UID ist nicht benutzerfreundlich
und außerdem fehlerträchtig, da UIDs bis zu 64 Zeichen lang sind und Fehler bei der Eingabe von Zahlen einem
Menschen weniger auffallen als Fehler bei der Eingabe von sinnvollen Wörtern. Es ist naheliegend, die Eingabe
von UIDs durch die Auswahl aus einer Liste verfügbarer Bilder zu ersetzen.
Beim realen Einsatz von DICOM-SR kann davon ausgegangen werden, dass ein DICOM-Server existiert, auf dem
die Bilder des jeweiligen Fachgebiets abgelegt sind und abgefragt werden können. GENRE soll es erlauben, eine
Seite 84
4
Liste von Bildern, die bestimmten Suchkriterien genügen, von einem DICOM-Server abzurufen. Aus dieser Liste
kann der Benutzer das gewünschte Bild auswählen. Die SOP-Class und SOP-Instance-UID des ausgewählten
Bildes werden automatisch in das Inhaltselement vom Wertetyp IMAGE“ übernommen.
”
Dieser Abschnitt setzt im Folgenden das in Kapitel 2.5.9 beschriebene Grundwissen über die Benutzung von
DICOM zur Bild-Kommunikation über Computernetzwerke voraus.
4.3.4.1 Wahl eines geeigneten DICOM-Servers
Um die Integration von GENRE in ein professionelles DICOM-Umfeld zu simulieren, wurde ein DICOM-Server
gesucht, der die benötigten Dienste anbietet. Da im Institut für Medizinische Informatik keine Testinstallation
eines professionellen DICOM-Servers läuft, sollte ein kostenloser DICOM-Server lokal auf dem Entwicklungsrechner des Autors installiert werden.
K-PACS V1.5 Zunächst wurde K-PACS77 betrachtet, ein nur in einer Windows-Version erhältliches Programm, das durch eine moderne Benutzeroberfläche und umfangreiche Funktionen bei der Bildanzeige auffiel. Es
musste aber festgestellt werden, dass K-PACS zwar verschiedene DICOM-Netzwerkdienste anbietet (so können
z. B. Bilder auf einem externen DICOM-Server abgelegt werden und es kann in externen Archiven nach Bildern gesucht werden), die für die Aufgabenstellung notwendigen Rollen als C-QUERY-SCP und C-MOVE-SCP
jedoch nicht erfüllen kann.
ConQuest DICOM server 1.4.13 Der ConQuest DICOM server78 (im Folgenden ConQuest“) besitzt eine
”
etwas angestaubte Oberfläche mit einfachem integriertem Bildbetrachter und konzentriert sich vor allem auf
die Server-Funktionalität. ConQuest bringt eine eingebaute dBaseIII-Datenbank mit, arbeitet jedoch auch mit
vielen externen SQL-Datenbanken wie Microsoft SQL-Server oder MySQL zusammen. Eine Linux-Version ist
ebenfalls erhältlich, beinhaltet jedoch keine grafische Oberfläche für die Administration und ist weniger flexibel
bei der Auswahl der externen Datenbank. Nur die Linux-Version ist quelloffen. Ein DICOM-ConformanceStatement liegt bei. Die Dokumentation beschreibt die Installation unter Windows ausführlich und diskutiert,
welche Datenbank für welches Anwendungsszenario passt. Dabei wird deutlich, dass ConQuest auch für die
Verwaltung von vielen Millionen Bildern geeignet ist. Die Aktivität in den Anwenderforen belegt die weite
Verbreitung von ConQuest. Mit einem Speicherverbrauch von wenigen MegaByte eignet sich ConQuest auch
für ältere Rechnersysteme und für Situationen, in denen keine dedizierte Serverhardware zur Verfügung steht.
PacsOne Server Basic Edition version 1.0.0.14 PacsOne79 ist ein DICOM-Server, der Bildarchivierung in
MySQL-Datenbanken ermöglicht und auf Wunsch eine PHP-gestützte Web-Benutzeroberfläche mitbringt, für
deren Betrieb zusätzlich ein Apache-Webserver notwendig ist. Das Conformance-Statement listet eine beeindruckende Zahl an unterstützter SOP-Klassen, sowohl als SCU als auch als SCP. In einer Basic Edition für
Windows ist die Software kostenlos. Allerdings wird diese Version offenbar seit 2005 nicht mehr gepflegt und
setzt unter anderem eine mittlerweile stark veraltete MySQL Version 4.0.x voraus, deren Support im Herbst
2006 auslief und die beim Hersteller nicht mehr erhältlich ist80 .
dcm4chee-2.x DICOM Clinical Data Manager dcm4chee81 ist eine Java-Enterprise-Anwendung, die den
JBoss Application Server voraussetzt und eine Vielzahl an Datenbanken unterstützt. Ein DICOM-ConformanceStatement ist erhältlich und bestätigt die Eignung als C-FIND- und C-MOVE-SCP. Im Gegensatz zu den oben
genannten Lösungen gibt sich dcm4chee nicht nur kostenlos, sondern auch sehr offen, der Quellkode ist in verschiedenen liberalen OpenSource-Lizenzen (u. a. LGPL) erhältlich und selbst das verwendete Datenbankschema
ist ausführlich dokumentiert82 .
77 http://www.k-pacs.de/
78 http://www.xs4all.nl/
~ingenium/dicom.html
79 http://www.pacsone.net/
80 http://downloads.mysql.com/archives.php?p=mysql-4.0
81 http://www.dcm4che.org/confluence/display/ee2/Home
82 http://www.dcm4che.org/confluence/display/ee2/Database+Schema+Diagram
Seite 85
4
Fazit Von den untersuchten kostenlosen DICOM-Server-Lösungen erfüllten alle bis auf K-PACS die erforderliche Funktionalität. Ein Einsatz von PacsOne in der kostenlosen Basic Edition“ kommt allerdings selbst für
”
Testzwecke kaum infrage. Selbst wenn man die benötigte MySQL-Version noch auf Seiten von Drittanbietern
findet, ist mit Problemen im Zusammenspiel mit modernerer Software zu rechnen.
dcm4chee wirkt technisch geeignet, gut gepflegt und besticht durch seine Offenheit und Plattformunabhängigkeit.
Allerdings ist die Installation recht aufwändig: JBoss (Downloadgröße ca. 100MB) und eine externe Datenbank
müssen zunächst eingerichtet werden. Da sich ConQuest bezüglich der Systemanforderungen genügsamer gab
und außerdem bei Verwendung der für kleine Bildarchive völlig ausreichenden, mitgelieferten Datenbank keine
zusätzlichen Downloads und Installationen erforderlich machte, wurde schließlich ConQuest als Testumgebung
gewählt.
4.3.4.2 Implementierung
Abbildung 39 stellt vereinfacht die Kommunikation bei der Suche nach Bildern auf einem DICOM-Server
und deren anschließende Übertragung zu GENRE dar. Die fett gedruckten Nachrichten stehen für DICOMKommunikation.
: Benutzer
<<actor>>
: ImageChooserView
<<UI>>
: ConquestServer
: StudyRootQueryInformationModel
Bestätige Suche
<<create>>
performHierarchicalQuery(...)
Anzeige Suchergebnis
C-FIND
OK (FIND)
QueryTreeModel
Auswahl Bild
h : ReceivedOjectHandler
<<create>>
: StorageSOPClassSCPDispatcher
<<create>> (h)
: MoveSOPClassSCU
performHierarchicalMove(...)
<<create>>
C-MOVE
C-STORE
: StorageSOPClassSCP
<<create>> (h)
OK (STORE)
sendReceivedObjectIndication(fileName,...)
showImage(...)
OK (MOVE)
Abbildung 39: Ablauf der Kommunikation mit dem DICOM-Server bei der Auswahl von Bildern
Der Dialog zur Eingabe der Suchkriterien heißt bei GENRE ImageChooserView. Der Benutzer gibt seine Filterkriterien ein und startet mit einem Klick auf die entsprechende Schaltfläche die Suchanfrage an den DICOM-Server. Die Wahl zwischen dem Patient Root“ und Study Root Query/Retrieve Information Model“
”
”
Seite 86
4
(vgl. Kap. 2.5.9) für die Suchanfrage fiel leicht, da das PixelMed DICOM Toolkit nur letzteres unterstützt83
(Klasse StudyRootQueryInformationModel in Paket com.pixelmed.query). Der C-FIND-Befehl wird durch
den Aufruf der Funktion performHierarchicalQuery mit den Suchkriterien als Parameter ausgelöst. Das Suchergebnis wird schließlich in einer Baumstruktur zurückgeliefert und kann zum Beispiel als Tabelle dargestellt
werden. Dabei muss dem Benutzer natürlich so viel Information geboten werden, dass er das gewünschte Bild
identifizieren kann.
Der Benutzer wählt nun das gewünschte Bild aus der Tabelle aus und betätigt eine weitere Schaltfläche, woraufhin das Bild vom DICOM-Server übertragen wird. Die eigentliche Bildübertragung kann wie in Kapitel 2.5.9
geschildert mittels C-MOVE- oder C-GET-Befehl erfolgen. ConQuest unterstützt jedoch keine Anfragen mittels
C-GET (vgl. Conformance Statement). Für die Bildübertragung mittels C-MOVE müssen ConQuest einmalig
IP-Adresse und Port der empfangenden DICOM-Anwendung bekannt gemacht werden. Diese Zuordnung von
Application Entity Titles“ (AET) zu IP-Adressen und Ports lässt sich in der grafischen Benutzeroberfläche
”
von ConQuest bequem erledigen (vgl. Abb. 40, hinzugefügte Zeile mit Pfeil markiert).
Abbildung 40: Zuordnung von Application Entity Titles (AET) zu IP-Adressen und Ports in ConQuest
Da die Übertragung des Bildes asynchron abläuft, muss vor dem Absenden von C-MOVE zunächst eine
Rückruffunktion definiert werden, die nach erfolgreicher Bildübertragung aufgerufen wird. Dafür leitet man
im PixelMed-Toolkit von der abstrakten Oberklasse ReceivedObjectHandler ab. Mit diesem Handler als Parameter wird ein StorageSOPClassSCPDispatcher-Thread erzeugt, der auf einem vorgegebenen Port lauscht
und bei jedem Eintreffen von C-STORE-Kommandos ein Objekt der Klasse StorageSOPClassSCP instantiiert,
das den eigentlichen Empfang übernimmt.
Nach den genannten Vorbereitungen kann der C-MOVE-Befehl schließlich über die Methode performHierarchicalMove im bereits vorhandenen StudyRootQueryInformationModel-Objekt angestoßen werden. Dadurch
wird eine Instanz der Klasse MoveSOPClassSCU erzeugt, die die eigentliche DICOM-Kommunikation übernimmt.
In Kapitel 2.5.9 wurde bereits erläutert, dass ein C-MOVE-Befehl den DICOM-Server dazu veranlasst, ein oder
mehrere Bilder per C-STORE zu versenden. In diesem Fall wird ein einziges Bild angefordert. Der ConquestServer initiiert eine C-STORE-Nachricht an den TCP-Endpunkt, der in der Konfigurationsdatei angegeben
wurde (s. o.). Das Bild wird empfangen, gespeichert und die Rückruffunktion aufgerufen, die an den Konstruktur
des StorageSOPClassSCPDispatcher übergeben wurde. Der C-STORE-Befehl ist damit abgeschlossen, und da
nur eine Datei übertragen wurde, kann auch der C-MOVE-Befehl beendet werden.
Alle genannten Netzwerkklassen finden sich im Paket com.pixelmed.network und sind per JavaDoc gut do83 Das
PixelMed-Toolkit unterstützt jedoch die Erweiterung auf weitere Query-Informationsmodelle durch die abstrakte Oberklasse
QueryInformationModel.
Seite 87
4
kumentiert. Für Testzwecke enhalten die Klassen eine main-Methode, sie können also auch direkt von der
Kommandozeile gestartet werden.
Nur der erste Teil des geschilderten Szenarios, die Definition eines Suchfilters und die Anforderung entsprechender Bilder per C-FIND, wurde in GENRE tatsächlich implementiert. Die Bildübertragung mittels C-MOVE/CSTORE konnte aus Zeitgründen nicht fertiggestellt werden.
4.3.5 Anforderungen an das Java Runtime Environment (JRE)
GENRE benötigt zur Ausführung ein Java Runtime Environment in der Version 6.x. Im Folgenden wird kurz
erläutert, an welchen Stellen Funktionen von Java 6 benötigt werden und wie diese Funktionen unter älteren
Java-Versionen imitiert werden könnten. Anschließend wird evaluiert, für welche Betriebssysteme und HardwarePlattformen Java 6 zur Verfügung steht.
GENRE kann von folgenden mit Java 6 neu eingeführten Funktionen besonders profitieren:
Starten von Standardanwendungen. GENRE bietet die Möglichkeit, eine DICOM-SR-Datei zur Weitergabe an Systeme, auf denen GENRE nicht zur Verfügung steht, in eine einfache HTML-Darstellung
umzuwandeln (vgl. Kap. 4.3.2.4). Für die Anzeige dieser HTML-Datei, kann über einen entsprechenden
Eintrag im GENRE-Menü der Standard-Webbrowser des jeweiligen Betriebssystems aufgerufen werden.
Java 6 bietet eine einfache Möglichkeit, den Standard-Webbrowser, das Standard-E-Mail-Programm oder
die einer Datei zugeordnete Standardanwendung des jeweiligen Host-Betriebssystems zu starten: Die sogenannte Desktop API“ [80], die über die Klasse Desktop im Paket java.awt angesprochen werden kann.
”
Für frühere Java-Versionen existieren externe Klassen, die diese Aufgabe einigermaßen zufriedenstellend
übernehmen können [13, 90].
Sortieren und Filtern von Tabellen. Für die Auswahl eines Konzepts aus dem DCMR (Klasse
ConceptChooserView, vgl. Abb. 26 in Kap. 4.1.2.6) bietet GENRE eine komfortable Benutzeroberfläche,
die das Filtern und Sortieren von Einträgen in Tabellen ermöglicht. Seit Java 6 kann man diese Funktionalität komfortabel über die Klasse TableRowSorter im Paket javax.swing.table realisieren. In
früheren Java-Versionen musste für diese Funktionalität auf zusätzliche Klassen wie beispielsweise [72]
zurückgegriffen werden.
Einbettung von Skriptsprachen. In Kapitel 4.5.3 wird dargestellt, inwiefern GENRE von durch den
Benutzer erstellten Erweiterungen in einer Skriptsprache wie JavaScript profitieren kann. Java 6 bringt
eine API zur Integration von Skriptsprachen in Java mit und legt die notwendige Engine für JavaScript
gleich bei [79, 110]. Für ältere Java-Versionen kann die JavaScript-Engine Rhino“ separat heruntergeladen
”
und integriert werden [9].
Bessere Integration in Windows Vista. Ältere Java-Versionen haben verschiedene optische und funktionelle Probleme, wenn sie unter Windows Vista laufen. Auch wenn Sun zahlreiche Lösungen für diese
Probleme auch in die Updates für ältere JREs integriert hat, ist doch Java 6 die einzige offizielle JavaVersion für Windows Vista [38].
Java 6 ist Ende 2006 erschienen [44] und wird vom Hersteller Sun für die Betriebssysteme Windows (32 und
64 bit für x86-Architektur), Linux (32 und 64 bit für x86-Architektur) und Solaris (32 und 64 bit für x86Architektur und SPARC-Architektur) angeboten. Für alle anderen Kombinationen aus Betriebssystem und
Hardwarearchitektur ist die Verfügbarkeit von Java 6 problematischer. Beispiele:
FreeBSD. Aus den Webseiten des offiziellen FreeBSD-Ports für das Java SDK von Sun [31] geht hervor,
dass die aktuellste offizielle Version Java 5 ist, an Java 6 aber bereits gearbeitet wird. In zahlreichen
Foreneinträgen im Internet ist aber nachzulesen, dass Java 6 erfolgreich unter FreeBSD installiert worden
ist.
Mac OS X. Die offizielle Veröffentlichung der Java-Plattform für Mac OS X übernimmt traditionell die
Firma Apple. Die aktuelle Version Mac OS X 10.5 (Leopard) beinhaltet sowohl das Runtime Environment
als auch das Development Toolkit in der Version 5. Mit großer Verzögerung veröffentlichte Apple im April
2008 ein Softwareupdate, das Java 6 beinhaltet [43]. Dieses benötigt zwingend Mac OS X in der Version
10.5 und einen 64bit Intel-Prozessor (Core 2 Duo, Xeon). Besitzer älterer Apple-Rechner mit PowerPC G4
oder G5 bzw. Core/Core Duo Prozessor (z. B. Mac minis, erste Intel-iMacs, erste MacBooks/MacBook
Pros) müssen bis auf Weiteres auf Java 6 verzichten.
Seite 88
4
Zahlreiche Betriebssysteme (z. B. OpenBSD, Fedora) haben Suns JRE und JDK aufgrund von Lizenzfragen
bislang nicht als Binärversion integriert. Nachdem Sun im Juni 2008 unter dem Namen OpenJDK ein vollständig
unter GPL stehendes Java 6 (JRE und JDK) veröffentlicht hat, ist aber zu erwarten, dass sich dieses in der
Open-Source-Welt schnell verbreitet. Derzeit stellt Sun OpenJDK-Binärpakete für Ubuntu 8.04, Fedora 9 sowie
für Red Hat Enterprise Linux 5 und dessen Derivate zur Verfügung [108].
Fazit. Es wird deutlich, dass GENRE nicht zwingend auf Java 6 angewiesen ist, da die in älteren Java-Versionen
fehlenden Funktionalitäten durch Bibliotheken von Drittherstellern nachgerüstet werden könnten. Das Erstellen
einer GENRE-Version für Java 5 oder früher wäre jedoch recht aufwändig und insbesondere schwer zu pflegen, da
neue Versionen der benötigten Bibliotheken möglicherweise ungewünschte Seiteneffekte zeigen können. GENRE
setzt daher trotz anfänglicher Bedenken auf Java 6. Wesentliches Opfer dieser Entscheidung sind die aus JavaSicht vernachlässigten Nutzer älterer Apple-Rechner mit Mac OS X.
4.4 Konzeption eines Eingabeassistenten für strukturierte pathologische Befundberichte
Bisher wurde GENRE als ein generischer DICOM-SR-Editor diskutiert, der den Standard möglichst vollständig
ausschöpft und tiefe Eingriffe in DICOM-SR-Bäume erlaubt. Obwohl bei der Konzeption und Implementierung
viel Arbeit in die Benutzungsfreundlichkeit des Editors investiert wurde (vgl. Kap. 4.3.3), setzt das direkte Bearbeiten des DICOM-SR-Inhaltsbaumes ein Verständnis zahlreicher DICOM-SR-spezifischer Konzepte voraus84 :
Unterschiede der verschiedenen Dokumentenklassen (Basic/Enhanced/Comprehensive, Key Object Selection,. . . )
Bedeutung der verschiedenen Typen für Inhaltselemente (CONTAINER, IMAGE, NUM,. . . )
Bedeutung von Relationen verschiedener Typen (CONTAINS, HAS ACQUISITION CONTEXT, HAS
CONCEPT MODIFIER,. . . )85
Unterscheidung von By-value- und By-reference-Relationen
Begriffskodierung in Triplet-Schreibweise (Kodewert, Kodierungsschema, Kodebedeutung“)
”
Sinn und Aufbau von Kontextgruppen
Und weitere, siehe Kapitel 2.6
Während GENRE ein bislang einzigartiges Werkzeug für Techniker ist (Erstellung von Testdaten, Erlernen der
DICOM-SR-Grundlagen,...), muss daher angezweifelt werden, dass das System in dieser Fassung von Ärzten,
Pflegepersonal und Schreibkräften akzeptiert wird. Das Erstellen von SR-Inhaltsbäumen im klinischen Routinebetrieb sollte auf einer höheren Abstraktionsebene erfolgen (siehe auch allgemeiner Lösungsansatz in Kap.
3).
In Kapitel 4.4.1 dieser Arbeit soll versucht werden, sich dem Einsatz im Routinebetrieb über einige Anwendungsfälle in der Pathologie zu nähern. Kapitel 4.4.2 diskutiert, wie die Befundberichte einer Fallklasse für die Speicherung im DICOM-SR-Format strukturiert werden können. Kapitel 4.5 schließlich beschreibt
die Implementierung eines für ärztliche Anwender gedachten, flexibel konfigurierbaren Eingabeassistenten als
Brückenschlag zur Routineanwendung.
4.4.1 Beispielhafte Untersuchungsfälle aus der Pathologie
Um die Eignung des GENRE-Systems im pathologischen Alltag zu beurteilen, wurden zunächst im Gespräch mit
Pathologen geeignete Fallklassen diskutiert, für die eine strukturierte Befundberichtsschreibung sinnvollerweise
eingesetzt werden könnte.
Die Idee für die erste Fallklasse, die Untersuchung von Magen-/Darmbiopsaten, stammt von Dr. Andreas Turzynski, einem niedergelassenen Arzt der Gemeinschaftspraxis für Pathologie am Pferdemarkt in Lübeck. Die
84 Vgl.
Bortoluzzi et al.: As opposed to free text, it is far more difficult to build a hierarchical tree structure or graph with content
”
items, each of which having a value type, a chosen relationship with its parent, a concept name chosen from a lexicon, and so
forth.“ [BWM03]
85 Die Bedeutung der Relationstypen ist selbst unter DICOM-Experten umstritten, da sie im DICOM-Standard unpräzise und
widersprüchlich formuliert ist.
Seite 89
4
Untersuchung von Magen-/Darmbiopsaten ist die häufigste Untersuchung im niedergelassenen Bereich. Verbesserungen bei der Dokumentation dieser Fallklasse hätten somit ein besonderes, auch wirtschaftliches Gewicht. Kapitel 4.4.1.1 nennt einige Stichworte zur Untersuchung von Magen-/Darmbiopsaten, die während eines
längeren Gespräches mit Dr. Turzynski protokolliert wurden.
Die Idee für die zweite Fallklasse, die Untersuchung von Beckenkamm-Trepanaten bei Verdacht auf Plasmozytom, hatte Oberarzt Dr. Christoph Thorns vom Institut für Pathologie am UK-SH, Standort Lübeck. Laut Dr.
Thorns sind die Befundberichte zu dieser Fragestellung relativ gleichförmig und eignen sich damit möglicherweise
besonders gut für eine strukturierte Dokumentation. Kapitel 4.4.1.2, das ebenfalls aus den Aufzeichnungen eines
längeren Gespräch entstanden ist, beschreibt diese Fallklasse näher. Im darauf folgenden Kapitel 4.4.2 dient sie
als Beispiel.
Neben dem genannten Verdacht auf Plasmozytom wies Herr Dr. Thorns noch auf weitere Fallklassen hin:
Für zahlreiche Untersuchungsfälle, beispielsweise für die Biopsiediagnostik bei Verdacht auf Magenkarzinom, existieren Leitlinien des Berufsverbandes Deutscher Pathologen (BDP) und der Deutschen Gesellschaft für Pathologie (DGP)86 . Diese Leitlinien sind ein guter Ausgangspunkt für die Planung von Inhalten
und Struktur standardisierter Befundberichte.
Als Gegenbeispiel für die genannten, gut strukturiert zu erfassenden Fallklassen führte Dr. Thorns die
Angioimmunoblastische Lymphadenopathie (AILD) an. Dies sei ein besonders komplizierter Befund, der
mit großer Wahrscheinlichkeit nur schlecht strukturiert abzubilden sei.
Leider konnte für keine der genannten Fallklassen der Routinebetrieb des GENRE-Systems getestet werden.
Dies hatte vor allem zeitliche Gründe. Eine spätere wissenschaftliche Arbeit, bevorzugt aus der medizinischen
Fakultät, soll diese Lücke schließen.
4.4.1.1 Magen-/Darmbiopsien
Nach Einschätzung von Dr. Turzynski ist die Untersuchung von Magen-/Darmbiopsaten recht einheitlich und
damit eine strukturierte Befundung realisierbar. Gleichzeitig ist die Untersuchung von Magen-/Darmbiopsaten
eine der mengenmäßig wichtigsten – etwa die Hälfte der täglich untersuchten Präparate sind aus diesem Bereich.
Aus den folgenden Fragen, die bei der Befundung eines Magenbiopsats beantwortet werden müssen, ließe sich
eine Struktur für den Befundbericht ableiten:
1. Welches Gewebe liegt vor?
2. Wie tief ist das Biopsat gemacht worden?
3. Wo ist die Lokalisation (Antrum, Korpus, Fundus, Cardia,...)?
4. Welche Art von Drüsenkörper liegt vor (muzinös, korpusspezifisch, gemischt)?
5. Sind die Drüsenkörper voll entwickelt oder nicht?
6. Wie lang sind die Foveolen?
7. Für das Graduieren: Wie groß ist die Dichte des lymphoplasmazellulären Infiltrats (Chronizität der Gastritis)?
8. Wie hoch ist die Aktivität der Gastritis (Dichte des granulozytären Infiltrats, Übergreifen auf das Epithel)?
4.4.1.2 Untersuchung von Beckenkamm-Trepanaten bei Verdacht auf Plasmozytom
Medizinischer Hintergrund Das Plasmozytom (synonym: multiples Myelom) ist eine bösartige Tumorerkrankung aus der Gruppe der Non-Hodgkin-Lymphome, die durch eine Plasmazellvermehrung ( Plasmozytose“)
”
86 Die
Leitlinien der meisten medizinischen Fachdisziplinen werden von der Arbeitsgemeinschaft der Wissenschaftlichen Medizinischen Fachgesellschaften (AMWF [7]) zusammengetragen. Ausgerechnet für die Pathologie gibt es dort jedoch keine gültige
Leitlinie.
Seite 90
4
an zumeist zahlreichen Herden im Knochenmark charakterisiert ist87 . Die Plasmozytose geht dabei von einem
einzigen, entarteten Zellklon aus ( monoklonal“). Ein weiteres Kennzeichen des Plasmozytoms ist die Produk”
tion von krankhaften Immunglobulinen ohne Antikörperfunktion. In späteren Stadien des Plasmozytoms kann
es zu Knochendefekten, Hyperkalziämie und Niereninsuffizienz kommen. Ein Ausschwemmung der krankhaften
Plasmazellen in das Blut ist möglich (Plasmazellenleukämie). Die Ursache für das Plasmozytom ist weitgehend
ungeklärt. Besonders häufig tritt es bei Männern jenseits des 50. Lebensjahres auf. Die Prognose für betroffene
Patienten ist schlecht. [Psc98, 23, SM06]
Die Vorgehensweise zur Diagnostik des Plasmozytoms ist nicht in klinischen Leitlinien standardisiert, es gibt
jedoch klar definierte diagnostische Kriterien, die eine Vorgehensweise vorzeichnen [DHM+06].
Ausgangssituation Das Institut für Pathologie am UK-SH erhält (typischerweise vom niedergelassenen Hämatoonkologen oder einer entsprechenden stationären Einrichtung) ein sogenanntes Trepanat“ (synonym: Stanze),
”
eine Knochenmarkbiopsie, die mit einem chirurgischen Instrument unter Lokalanästhesie aus dem Beckenkamm
des Patienten herausgestanzt wird. Das Präparat wird entsprechend den in Kapitel 2.1 beschriebenen Schritten
vorbereitet und vom Pathologen unter dem Mikroskop untersucht (vgl. Abb. 41).
Abbildung 41: Plasmozytomzellen mit charakteristischen, exzentrisch gelegenen Zellkernen. [HF97]
Untersuchung Die Untersuchung eines Beckenkamm-Trepanats ist ein vergleichsweise klar strukturierter Prozess, der aus den folgenden Schritten besteht:
1. Bewertung des Materials. Zunächst muss die Frage beantwortet werden, ob Quantität und Qualität
des Materials für einen Befund ausreichend sind. Beispielsweise wird überprüft, ob das Trepanat lang
genug, nicht zu stark zerbröckelt und nicht zu stark komprimiert ist.
2. Knochenbälkchen. Im nächsten Schritt werden die Knochenbälkchen (synonym: Trabekelknochen) quantitativ (z. B. viele, mittel, wenige) und qualitativ (z. B. breit, schmal) bewertet.
3. Markräume und Fettzellen. Es wird der Zellgehalt der Markräume angegeben (Vergrößerungsstufe:
z. B. 40x).
4. Vorläuferzellen der Blutbildung (synonym: haematopoetische Progenitorzellen). Vorläuferzellen
werden nach Quantität und topografischer Verteilung begutachtet. Dabei werden die drei wesentlichen
Komponenten (Granulopoese, Erythropoese und Megakaryopoese) gesondert betrachtet.
5. Pathologische Veränderungen. Zu den pathologischen Veränderungen zählen beispielsweise ungewöhnliche Verhältnisse in der Anzahl der Zelltypen oder veränderte Zellen. Im Fall des Plasmozytoms ist die Zahl
der Plasmazellen stark erhöht; üblicherweise sollte sie unter 5% liegen. Für diesen Untersuchungsschritt
sind mitunter starke Vergrößerungen (z. B. 400x) vonnöten.
87 Eine
gut verständliche, ausführliche Beschreibung des Plasmozytoms findet sich beispielsweise in [ERS91].
Seite 91
4
In Schritt 3 und 4 werden also gesunde Zellen, in Schritt 5 pathologische Veränderungen beschrieben. Sind die
pathologischen Veränderungen besonders augenfällig, wird Schritt 5 häufig vorverlegt.
Häufig ist der Befund nach Abarbeitung der genannten Schritte bereits fertig. Ansonsten folgen dem Verdacht
entsprechende Spezialuntersuchungen. Zwei Spezialfärbungen, die im Institut für Pathologie am UK-SH eigentlich immer durchgeführt werden, sind:
Gomori-Färbung (Versilberung). Mit dieser Färbung werden Gitterfasern (synonym: Retikulin) sichtbar gemacht (pathologisch: viele Fasern).
Berliner-Blau-Färbung. Diese Färbung markiert Eisen in Siderophagen (Speichereisen; pathologisch:
zu viel oder zu wenig Eisen).
Bei Verdacht auf Plasmozytom kommen unter anderem folgende Spezialfärbungen zum Einsatz:
CD38-Färbung. Markiert Plasmazellen.
κ- und λ-Färbung. Macht Leichtketten der Immunglobuline (κ- und λ-Typ) sichtbar. Pathologisch ist
eine deutlich vermehrte Produktion nur eines Leichtkettentyps.
Gelegentlich CD20, CD56 u. a. Weisen häufig auf bösartige Plasmazellen mit Expression atypischer
Oberflächenmarker hin.
Neben der Knochenstanze werden bei Verdacht auf Plasmozytom auch Knochenmarksausstriche untersucht.
Da dies aber typischerweise auch vom niedergelassenen Arzt erledigt werden kann (und die Befundkomplexität
erheblich erhöht), sollen Ausstriche in dieser Arbeit unberücksichtigt bleiben.
Endergebnis des Befunds ist entweder eine mit ICD-O [24] kodierte Diagnose oder – wenn noch keine klare
Diagnose gestellt werden konnte – ein Vorschlag für weitere Untersuchungen.
4.4.2 Abbildung der strukturierten Eingaben auf DICOM-SR
Die Struktur der bisher am UK-SH Standort Lübeck in der Pathologie verwendeten Befundberichte wurde in
Abschnitt 2.4.5 vorgestellt. Zunächst soll überlegt werden, wie der Textkörper eines solchen Berichts auf DICOMSR-Strukturen abgebildet werden kann. Anschließend wird detaillierter auf einzelne Elemente der resultierenden
Struktur eingegangen.
4.4.2.1 Grad der Strukturierung
Anhand eines realen, anonymisierten Befundberichts aus dem Institut für Pathologie (Abb. 42) soll exemplarisch
dargestellt werden, wie die Inhalte strukturiert werden könnten. Dabei wird zunächst auf den Briefkopf mit
Angaben zum Einweisenden Arzt, dem Patienten und den untersuchenden Ärzten verzichtet.
DICOM-SR ist sehr flexibel, was den Grad der Strukturierung der Dokument-Instanzen angeht. Das einfachste
denkbare DICOM-SR-Dokument besteht aus zwei Content Items: Einem Wurzelknoten mit Wertetyp Contai”
ner“, dessen Wert die Überschrift des Dokuments darstellt, sowie einem einzigen über die Relation CONTAINS“
”
angebundenen Inhaltsknoten, der den Textkörper repräsentiert (vgl. Abb. 43).
Der nächste denkbare Stukturierungsschritt ist die Unterteilung des Textes des Befundberichts in die durch die
Überschriften gegebenen Abschnitte. Jeder Abschnitt ist wiederum ein Content Item vom Typ Text“ (vgl. Abb.
”
44). Jedes Text-Content-Item hat verpflichtend einen Konzeptnamen, der seinen Zweck erläutern soll. Dieser
Konzeptname kann als Absatzüberschrift aufgefasst werden. Dies ist jedoch nicht vorgeschrieben, so dass man
sich nicht darauf verlassen kann, ob bzw. wie Betrachterprogramme für DICOM-SR-Dateien den Konzeptnamen
anzeigen.
Seite 92
4
Abbildung 42: Textkörper eines Befundberichts aus dem Institut für Pathologie
Seite 93
4
Abbildung 43: Triviale Strukturierung eines Befundberichts in DICOM-SR mit GENRE
Abbildung 44: Strukturierung eines Befundberichts in einzelne Abschnitte
Seite 94
4
Möchte man garantieren, dass Überschriften auch als solche aufgefasst werden, muss man eine zusätzliche
Ebene aus Container“-Content-Items einziehen (vgl. Abb. 45). Diese Struktur wird von David Clunie in sei”
nem DICOM-SR-Buch [Clu00] als übliches Muster“ erwähnt (Kapitel 4, Contains Relationship Type“). Im
”
”
DICOM-SR-Standard ist festgelegt, dass der Konzeptname eines Containers maschinell als Überschrift inter88
pretiert werden muss .
Abbildung 45: Container Content Items als Abschnittsüberschriften
Es erscheint sinnvoll, Aufzählungen (vgl. Abschnitt Material“) und vom Arzt durch Absätze unterteilte Text”
Elemente weiter zu unterteilen. Messwerte sollten als Inhaltselement vom Typ Num“ ausgedrückt werden.
”
Elemente, die auf ein kontrolliertes Vokabular, eine Terminologie oder eine Klassifikation verweisen, sollten den
Typ Code“ tragen. Abbildung 46 zeigt die so erzielte Strukturierung.
”
Die Strukturierung und Kodierung von Befundberichten lässt sich bis zur Wortebene oder gar Teilwortebene
weiter treiben. Für die Kodierung einzelner Begriffe bietet sich beispielsweise die SNOMED-Terminologie an
(vgl. [Klo08] und Anhang A, Tab. 10). In dieser Arbeit wird dieser Ansatz aus Zeitgründen jedoch nicht weiter
verfolgt.
Mit fortschreitender Strukturierung des Befundberichts nimmt typischerweise der menschliche Aufwand für
die Erstellung zu. Eine Unterstützung der strukturierten Eingabe durch den Rechner wird erforderlich. Wie
diese Unterstützung aussehen könnte, wurde in Kapitel 2.4.4 vorgestellt. In Kapitel 4.5 wird die prototypische
Implementierung solcher Konzepte beschrieben.
88 Es
sind allerdings auch Container ohne Konzeptnamen erlaubt, die einen semantischen Zusammenhang ohne sinnvolle Überschrift
ausdrücken.
Seite 95
4
Abbildung 46: Messwerte und kodierte Elemente zur weiteren Strukturierung
4.4.2.2 Einzelne Elemente des DICOM-SR-Berichts näher betrachtet
Die DICOM-SR Befundberichte sollen den bisher im Institut für Pathologie am UK-SH gebräuchlichen Befundberichten ähneln und gleichzeitig möglichst gut internationalen Standards genügen.
Überschrift des Befundberichts Im DCMR gibt es bereits Kontextgruppen für Überschriften von Befundberichten. Dies sind im Einzelnen:
Kontextgruppe 3400: Procedure Log Titles (nur ein Eintrag Cath Lab Procedure Log“, daher hier un”
brauchbar)
Kontextgruppe 7000: Diagnostic Imaging Report Document Titles (Ausschnitt aus Kontextgruppe 7020)
Kontextgruppe 7010: Key Object Selection Document Title (speziell für den DICOM-Standard entworfen)
Kontextgruppe 7020: Document Titles
Wie in Kapitel 4.1.2.5 beschrieben, verweist die Kontextgruppe 7020 auf alle in den LOINC enthaltenen Dokumentenüberschriften. Zwei Konzepte scheinen dabei besonders geeignet:
LOINC 11526-1 Pathology study report und
LOINC 11529-5 Surgical pathology study report.
Letzteres wird im Implementierungsleitfaden zur Arztbriefschreibung mit HL7-CDA [VHi06] mit der deutschen
Übersetzung Pathologischer Bericht“ empfohlen und soll daher im Folgenden als Dokumententitel verwendet
”
werden. Es sei darauf hingewiesen, dass der Standard HL7 V2.5 ebenfalls einen Dokumententyp Surgical
”
Pathology“ (SP) vorschlägt, vgl. User-defined Table 0270 – Document Type“ in [ISO08].
”
Seite 96
4
Zwischenüberschriften (vgl. Abb. 44) Wie in Kapitel 2.4.5 beschrieben, verwendet das Institut für Pathologie am UK-SH Standort Lübeck die Zwischenüberschriften Klinische Diagnose/Fragestellung“, Eingesandtes
”
”
Material“, Makroskopischer Befund“, Mikroskopischer Befund“, Begutachtung“ und Kommentar“ zur Glie”
”
”
”
derung eines Befundberichts.
Die Auswahl an Zwischenüberschriften im DCMR ist unbefriedigend. Kontextgruppe 6052 Breast Imaging
”
Report section title“ beinhaltet elf Konzepte, von denen einige allgemeiner verwendet werden können. Sie alle
stammen jedoch aus dem Kodierungsschema DCM, wurden also speziell für den DICOM-Standard erfunden“
”
und sind in keinem allgemeineren Standard zu finden. Am geeignetesten für pathologische Befundschreibung
wirken die Konzepte:
DCM 121070 Findings oder DCM 121072 Impressions für die Abschnitte Makroskopischer Befund“ bzw.
”
Mikroskopischer Befund“
”
DCM 121076 Conclusions, DCM 121074 Recommendations oder DCM 111413 Overall Assessment für
den Abschnitt Begutachtung“
”
DCM 121078 Addendum für den Abschnitt Kommentar“
”
In SNOMED finden sich einige Begriffe, die für die Kodierung der genannten Überschriften einigermaßen geeignet
scheinen (vgl. Anhang A, Tabelle 9).
Der Implementierungsleitfaden zur Arztbriefschreibung mit HL7-CDA [VHi06] listet in Kapitel 6.3 Zwischenüberschriften für die allgemeinen Kategorien einer medizinischen Dokumentation“. Diese sind auf den klinischen
”
Bereich zugeschnitten und für die Pathologie nahezu unbrauchbar.
Für die HL7-basierte Kommunikation relevanter Indikatoren zwischen klinischen Instituten und Krebsregistern
wurde ein besonderer Satz LOINC-Kodes entwickelt, dem die Klasse TUMRRGT“ (tumor registry) zugewie”
sen wurde (vgl. Kap. 5 im LOINC-Handbuch [95], dort mit Tippfehler89 ). Diese Überschriften scheinen gut
zugeschnitten auf die Lübecker Verhältnisse. Eine eigene Klasse PATH“ (pathology) existiert zwar ebenfalls
”
im LOINC, diese enthält jedoch keine geeigneten Kodes für Zwischenüberschriften.
Verschlüsselung von Abschnitten und Begriffen innerhalb von Freitext Alle betrachteten Quellen bieten
Kodes zur Kodierung von Abschnitten oder einzelnen Begriffen innerhalb von Freitext an.
Beispielsweise empfiehlt die oben genannte CDA-Leitlinie die Kodes LOINC 29548-5 Diagnose (Text) bzw.
29308-4 Diagnose (Codiert) zur Auszeichnung von Diagnosen.
In der LOINC-Datenbank finden sich zudem in der Klasse PATH“ bzw. deren Unterklassen PATH.PROTO”
”
COLS.BRST“ (breast), ...GENER“ (general), ...PROST“ (prostate) und ...SKIN“ zahlreiche Kodes für nomi”
”
”
nale (z. B. 10760-7 Iron.microscopic observation;Gomori stain“) oder ordinale (z. B. 49469-0 CD33 Ag;Immune
”
”
stain“) Untersuchungsergebnisse, aber auch Kodes für Maßangaben (z. B. 9804-6 Weight“, 33723-8 Specimen
”
”
length“ oder 14228-1 Estrogen receptor/100 cells“).
”
Im DICOM-Standard finden sich neben den oben genannten Zwischenüberschriften weitere Gliederungselemente
( Finding“, Conclusion“ etc.), mit denen einzelne Abschnitte unter der jeweiligen Überschrift kodiert werden
”
”
können (vgl. CID 3419 Findings Titles“ und 7002 Diagnostic Imaging Report Elements“ bzw. spezieller CID
”
”
6053 Breast Imaging Report Elements“). Daneben bietet das DCMR einen reichhaltigen Fundus an Konzepten
”
für die Verschlüsselung von einzelnen Begriffen. Es stehen zahlreiche allgemeine Kontextgruppen (z. B. CID 4
Anatomic Region“, 244 Laterality“, 271 Observation Subject Class“) sowie fachrichtungsspezifische Kontext”
”
”
gruppen zur Verfügung. Schwerpunkte gibt es im Bereich von EKG-Untersuchungen, Echokardiografie, Herzkatheteruntersuchungen, kardiovaskulären Untersuchungen (Supp 97), Mammografie-CAD, Thoraxröntgen-CAD
und Ophtalmologie (Supp 91, 110, 130).
Neben den genannten Möglichkeiten bietet sich für die Verschlüsselung einzelner Begriffe am ehesten SNOMED
an. Anhang A listet einige Kodes speziell für den Anwendungsfall Untersuchung von Beckenkammtrepanaten
”
bei Verdacht auf Plasmozytom“ auf.
89 Auf
Nachfrage sicherte eine Mitarbeiterin des Regenstrief Institute am 29.5.2008 zu, dass dieser Fehler in der nächsten Ausgabe
des LOINC-Handbuchs korrigiert wird.
Seite 97
4
Kode
22636-5
COMPONENT
Path report.relevant Hx
22633-2
Path report.site of origin
22634-0
Path report.gross observation
22635-7
Path report.microscopic observation
33746-9
22640-7
Pathologic findings
Path report.staging evidence
22637-3
Path report.final diagnosis
22638-1
Path report.comments
22034-3
Pathology report.total
22639-9
Path report.supplemental reports
COMMENT
Relevant clinical information, generally stating the patient’s past history of cancer, pre-operative diagnosis, and/or
the reason the specimen was collected...
Describes the site (s) and laterality of the specimen (s). If
there is more than one specimen included on the pathology
report, each is generally assigned an identifying letter or
numeral...
A physical desc. of gross appear. of specimen (source, size,
color, unusual features, location of visible lesion, margins,
markings placed by surgeon) & labeling scheme used by
pathologist for assigning portions of specimen to blocks or
cassettes...
Findings and description of the presence or absence of disease in each section of the specimen(s). Generally include
the types of tissues, cells, or mitotic activity observed...
–
Information to aid in assigning a stage to each cancer. Commonly includes a discussion of tumor size and spread, lymph
node involvement, metastasis, and pathologic AJCC stage...
Summarizes the microscopic findings for each specimen examined. Confirms or denies gross findings of malignancy,
given the histologic type of the cancer and in some instances the grade...
Additional comments from the pathologist regarding situations such as possible source of the metastases, comparison
to previous specimens, need for additional surgery or specimens, and usefulness of additional stain/examinations, if
applicable...
Text area for manual documentation of information from
cytology and histopathology reports...
Info attached to report, generally after original issued.
Includes subsequent testing/stains, comparision with previous specimens, 2nd opinions from other pathologists or
labs, or a change in diagnosis resulting from re-examining
or re-sampling specimen.
Tabelle 8: Überschriften aus der LOINC-Datenbank für Meldungen an Krebsregister (Auswahl)
Seite 98
4
4.5 Implementierung eines Eingabeassistenten für strukturierte
Pathologie-Befundberichte
Aufbauend auf den Grundlagen zur strukturierten und standardisierten Dokumentation (Kapitel 2.4) sowie den
Betrachtungen zu konkreten Anwendungsfällen der Pathologie im vorhergehenden Kapitel wurde ein Eingabeassistent für strukturierte Pathologie-Befundberichte implementiert. Der Assistent orientiert sich stark am
kommerziellen Programm Clinic WinData der Firma E&L [28], welches das Erstellen strukturierter Befundberichte für verschiedene medizinische Disziplinen anbietet und auch im UK-SH eingesetzt wird. Clinic Windata
bietet kein Programmmodul für die Pathologie an und ermöglicht auch keine Speicherung des strukturierten
Befundberichts in Standardformaten wie HL7-CDA90 oder DICOM-SR.
4.5.1 Strukturierte Formulare
Abbildung 47(a) zeigt beispielhaft ein Formular aus Clinic WinData für Befundberichte in der Gastroskopie.
Alle grau hinterlegten Eingabefelder zeigen bei Aktivierung per Doppelklick einen für den jeweiligen Kontext
geeigneten Eingabeassistenten an. Beispielsweise ermöglicht der Eingabeassistent des Feldes zugew. von“ die
”
Auswahl eines einweisenden Arztes aus einer Adressdatenbank und der Assistent des Feldes Gerät“ eine Aus”
wahl an Gastroskopen.
Besonders interessant sind Eingabefelder mit rosa hinterlegtem Label. An dieser Stelle kommt in klassischen
Befundberichten Freitext zum Einsatz. Werden stattdessen die von Clinic Windata angebotenen Eingabeassistenten verwendet, so wird direkt bei der Eingabe Information für die rot umrahmten Felder abgeleitet. Im
Idealfall erfolgt das Ausfüllen der rot umrahmten Felder daher vollkommen automatisch, was die Erstellung des
Befundberichts beschleunigt.
Für diese Arbeit wurde ein einfaches Befundungsformular für pathologische Untersuchungen prototypisch in Java
implementiert (vgl. Abb. 47(b)). Über die Auswahlliste ganz oben im Dialog kann der passende Untersuchungstyp ausgewählt werden. Jeder Hauptüberschrift eines Pathologie-Befundberichts ist ein Textfeld zugeordnet.
Wie beim Vorbild Clinic WinData öffnet ein Doppelklick auf die Freitextfelder einen geeigneten Assistenten für
die strukturierte Eingabe. Auf Felder für Patientendaten, einweisenden Arzt, Gutachter etc. wurde aus Zeitgründen verzichtet. Bei Betätigung der linken Schaltfläche wird ein entsprechender DICOM-SR-Inhaltsbaum
erzeugt und in GENRE geöffnet. Dort kann der Baum manipuliert und schließlich gespeichert werden.
4.5.2 Grammatikgeführte strukturierte Eingabe in Clinic WinData
Für die strukturierte Eingabe natürlicher Sprache verwendet E&L Clinic WinData einen Ansatz, bei dem eine
(in der Regel kontextsensitive) Grammatik abgearbeitet wird91 . Die Grammatiken sind als Klartext abgelegt
und haben ein leicht verständliches Format. Dadurch können sie vom Benutzer schnell an die eigenen Bedürfnisse
angepasst werden. Ein Ausschnitt aus einer Grammatik sieht beispielsweise so aus:
Polyp(en) ::{Polypanzahl}
...
{Polypanzahl}
einzeln
::{Etagen} zeigt sich ein {Form_Polyp}{Oberfläche} Polyp mit einer Größe von ...#
multipel ::{Etagen} zeigen sich {Anzahl_Polyp} Polypen mit einer Größe von {Zahl_mm} ...#
...
Syntax Das genannte Fragment der Grammatik stellt drei Produktionsregeln dar. Produktionsregeln sind zu
Blöcken mit einer gemeinsamen Prämisse zusammengefasst, die den betreffenden Zeilen vorangestellt wird (hier
z. B. {Polypanzahl}). Die Erweiterung der Prämisse (im Folgenden: Kontext“) und die Konklusion werden
”
”
90 In
einer früheren Abschlussarbeit am IMI Lübeck wurde das Konzept von Clinic Windata jedoch bereits erfolgreich für die
Erzeugung von HL7-CDA-Dokumenten verwendet [Bec06].
91 Der Ansatz, Dokumente durch das Abarbeiten einer Grammatik zu erzeugen, ist in der Medizininformatik nicht neu. Friedrich
Wingert beschrieb beispielsweise schon 1979 eine derartige automatische Arztbriefschreibung“ [Win79].
”
Seite 99
4
(a) E&L Clinic WinData. Die rot markierten Felder des Befundungsformulars werden
durch sog. Makros“ automatisch gefüllt, können aber auch manuell verändert werden.
”
(b) GENRE. Prototyp eines Befundungsformulars für pathologische
Untersuchungen
Abbildung 47: Befundungsformulare: Original und Nachbau
Seite 100
4
durch einen doppelten Doppelpunkt ( ::“) getrennt. Zeichenketten in geschweiften Klammern sind Nichttermi”
nalsymbole. Gleiches gilt für den nicht in geschweiften Klammern stehenden Kontext. In eckigen Klammern
eingeschlossene Zeichenketten sind Verweise auf sogenannte Makros“ (s. u.). Ein Startsymbol gibt es nicht,
”
stattdessen beginnen Grammatiken bei E&L immer mit einer Gruppe von Produktionsregeln ohne gemeinsa”
me“ Prämisse am Dateianfang.
Die Konklusion beginnt mit dem ersten Zeichen nach dem doppelten Doppelpunkt und endet mit der Zeilenschaltung, etwaige Leerzeichen werden nicht ignoriert. Sind Kontext und Konklusion zeichengleich, so können
der doppelte Doppelpunkt und die Konklusion weggelassen werden. Zeilenumbrüche werden durch das Doppelkreuz ( #“) dargestellt. Zeilen, die nur ein Minuszeichen -“ enthalten, werden als Trennstrich zwischen
”
”
Gruppen von Produktionsregeln interpretiert.
Makros Unter Makros versteht Clinic WinData kurze, ausführbare Skripte, die Text oder Kodes zu den in
Abbildung 47(a) rot umrahmten Textfeldern hinzufügen. Diese Skripte werden in Visual Basic geschrieben.
Clinic WinData bringt einen eigenen Visual Basic Editor und Interpreter mit, so dass Makros ebenso wie die
Grammatiken vom Benutzer an die eigenen Bedürfnisse angepasst werden können.
Ablauf der Eingabe Abbildung 48(a) verdeutlicht den Ablauf der Eingabe. Im oberen Bereich des Dialogs
wird das aktuell produzierte Wort der Grammatik angezeigt.
Das erste Nichtterminal wird hervorgehoben und als gemeinsame Prämisse aufgefasst. Enthält die Grammatik
keine Produktionsregel für das Nichtterminal, so erhält der Benutzer die Möglichkeit, die Grammatik entsprechend zu bearbeiten. Anderenfalls wird dem Benutzer im mittleren Bereich des Dialogs eine Liste mit
allen Kontexten zum markierten Nichtterminal angezeigt. Nach Anklicken des gewünschten Kontextes wird die
Prämisse durch die Konklusion ersetzt. Enthält die Konklusion Makros, so werden diese ausgeführt und die
Symbole für die Makro-Aufrufe aus der Konklusion entfernt. Klickt der Benutzer auf Eingabe überspringen”,
”
so wird das markierte Nichtterminal durch das leere Wort ersetzt und bei direkt auf das Nichtterminal folgendem Satzzeichen gegebenenfalls ein Leerzeichenausgleich vorgenommen. Befinden sich im aktuellen Wort nur
noch Terminalsymbole, so wird das entstandene Wort in das untere Textfeld hinzugefügt und das Abarbeiten
der Grammatik beginnt von vorne. Mit Klicken auf OK“ wird der Text aus dem unteren Textfeld in das
”
Befundungsformular übernommen.
Eine Sonderstellung nimmt das Nichtterminal {...}“ ein. Trifft die Grammatik-Engine von Clinic WinData auf
”
dieses Symbol, so wird der Benutzer zu einer freien Eingabe aufgefordert.
4.5.3 Eigene Implementierung einer grammatikgeführten, strukturierten Eingabe
Es wurde ein Eingabedialog in Java implementiert, der dem Dialog von Clinic WinData sowohl optisch als auch
von der Funktion her ähnelt (Abb. 48(b)). Da die verwendeten Grammatiken syntaxkompatibel zu denen von
Clinic WinData sind, steht bereits ein großer Fundus vorgefertigter Grammatiken zur Verfügung. Grammatiken
können vom Programm aus in einem einfachen Editor bearbeitet werden. Das Überspringen von Eingabeschritten wurde ebenso implementiert wie das Rückgängigmachen der letzten Eingabe. Unbekannte Nichtterminale
und Makros werden ignoriert. Auf die etwas verwirrende Aufteilung des Dialogs in zwei Textfelder wurde verzichtet.
Implementierung von Makros Wie oben aufgeführt, wurde auf die Implementierung von Makros verzichtet.
Die Idee, neben der reinen Texterzeugung aus der Grammatik weitergehende Funktionen anzustoßen, die auch
noch einfach von Benutzern angepasst werden können, ist jedoch eine wesentliche Stärke des E&L-Ansatzes.
Ein paar konzeptionelle Gedanken seien daher im Folgenden geschildert.
Ein Einsatz der kommerziellen Visual-Basic-Engine Sax Basic Engine“, die in Clinic WinData verwendet wird,
”
kommt für GENRE nicht infrage. Erstens widerspräche dies dem Gedanken freier Software, zweitens scheint
der Hersteller diese Engine nicht mehr zu vertreiben und drittens ist fraglich, ob das Zusammenspiel von Visual
Basic und Java funktioniert.
Eine Lösung sieht der Autor in der mit Java 6 eingeführten API zur Integration von Skriptsprachen [79, 110].
Seite 101
4
(a) E&L Clinic WinData
(b) für Diplomarbeit nachgebaut
Abbildung 48: Dialoge zur grammatikgestützten, strukturierten Eingabe
Über die API lassen sich Java-Objekte als Parameter an Skriptmethoden übergeben oder auch von Skriptsprachen aus neu erzeugen. Die notwendige Engine für die Skriptsprache JavaScript legt Sun gleich bei. Eine
Sammlung weiterer Implementierungen von Skriptsprachen, die über die neu geschaffene Scripting-API angesprochen werden können, bietet das Projekt scripting“ [109].
”
Wenn man man für das Skripting auf JavaScript setzt, kann man auf weitere Bibliotheken verzichten. Für
das Editieren von Javascript innerhalb der Eclipse-Entwicklungsumgebung bietet sich das Plugin JSEclipse
an. Die Installation dieses Plugins wird unter [2] beschrieben. Ansonsten könnte für Java-Programmierer die
Skriptsprache BeanShell [75] eine interessant Wahl sein, da BeanShell die Standardsyntax von Java vollständig
unterstützt.
Prinzipiell zu erwartende Probleme Das skriptgesteuerte Erzeugen von DICOM-SR-Dokumenten ist komplizierter als der Ansatz von E&L. Bei Clinic WinData werden Kodes zu einer hierarchisch flachen Liste hinzugefügt. Die Reihenfolge der Kodes in der Liste spielt prinzipiell keine Rolle, neue Kodes können immer am Ende
der Liste angehängt werden.
Das Hinzufügen zu einem DICOM-SR-Baum ist ungleich schwieriger. Hier muss stets der korrekte Vaterknoten
bekannt sein, der sich während der Eingabe vielfach ändern kann. Weil die Reihenfolge der Inhaltselemente
in DICOM-SR semantisch relevant ist, muss man außerdem eine Variable mitführen, als wievieltes Kind des
Vaterknotens ein neuer Knoten eingefügt werden soll.
Schließlich muss der Benutzer mit den 14 derzeit verwendeten Datentypen sowie den sieben Relationstypen für
DICOM-SR-Inhaltselemente vertraut sein, wenn er in die Erzeugung des DICOM-SR-Baumes eingreifen will.
Insgesamt wird die Bearbeitung von Makros daher einen größeren Einarbeitungsaufwand und bessere Programmierkenntnisse erfordern als im Fall von Clinic WinData.
4.5.4 Integration in GENRE
Wie bereits in Kapitel 4.5.1 und 4.5.3 erwähnt, wurden für das Befundformular und den grammatikgeführten
Eingabeassistenten wie schon beim GENRE-Kernsystem Java verwendet. Das erleichterte die Integration in das
Seite 102
4
bestehende System.
Um auch im Bereich der anwenderfreundlichen Formulare und Eingabeassistenten die große Flexibilität von
GENRE zu erhalten, wurde bei der Programmierung stark auf Erweiterbarkeit geachtet. Ein Formular besteht
aus genau einer Java-Klasse, die von der abstrakten Oberklasse wizards.AbstractWizard erbt. Die Namen
dieser Klassen werden in der Konfigurationsdatei GENRE.ini angegeben. Beim Start von GENRE wird versucht,
die angegebenen Klassen mit Class.forName(...) dynamisch zu instantiieren. Falls dieser Versuch erfolgreich
ist, registrieren sich die Formular-Klassen mit ihrem lokalisierten Namen beim Dialog zum Erzeugen neuer
Befundberichte (vgl. Abb. 49). Dieser Plugin-Mechanismus entspricht der Vorgehensweise bei der Verwendung
von JDBC-Treibern und sollte Java-Programmierern daher vertraut sein.
Abbildung 49: Anlegen eines neuen Befundberichts mit Liste der verfügbaren Eingabeassistenten
Um ebenso wie das GENRE-Kernsystem einen internationalen Benutzerkreis anzusprechen, wurde auch das
prototypisch erstellte Formular für pathologische Befundberichte komplett internationalisiert und lokalisiert.
Im Falle des grammatikgeführten Eingabeassistenten muss natürlich nicht nur die grafische Benutzeroberfläche
sondern vor allem die zugrunde liegende Grammatik in mehrere Sprachen übersetzt werden.
4.6 Anwendung des GENRE-Systems in der Pathologie
In einem Gespräch mit Medieningenieur Harald Hatje und den Oberärzten Dr. Christoph Thorns und Dr.
Heinz-Wolfram Bernd vom Institut für Pathologie am UK-SH Standort Lübeck wurde am 29.7.2008 versucht,
die Einsetzbarkeit des in dieser Arbeit geschilderten Workflows in der Routine zu bewerten.
Virtuelle Mikroskopie Der Einsatz virtueller Mikroskopie (vgl. Kap. 2.2) wird am Institut für Pathologie bereits erprobt. Für die Lehre existiert beispielsweise ein frei im Internet verfügbarer Präparatekasten Histologie“
”
[51] mit ca. 50 virtuellen Präparaten, der mit dem am Institut verfügbaren Olympus dotSlide-System [85] hergestellt wurde. Andere Systeme wie der NanoZoomer von Hamamatsu [40] und das DMD108 von Leica mit
Live-Sichtfeld-Digitalisierung [57] wurden ebenfalls getestet.
Die Ärzte bemängeln hinsichtlich der virtuellen Mikroskopie vor allem zwei Dinge: Die Bildqualität müsse
mit der eines herkömmlichen Lichtmikroskops gleichziehen. Es mache keinen Sinn, wenn Untersuchungen zur
Kontrolle an einem herkömmlichen Mikroskop wiederholt werden müssen. Außerdem sei die Geschwindigkeit
der heutigen Lösungen sowohl bei der Digitalisierung als auch bei der Handhabung der digitalen Präparate noch
zu gering.
CAD Eine Unterstützung der diagnostischen Tätigkeit durch den Computer (CAD, vgl. Kap. 2.3) können sich
die Pathologen prinzipiell gut vorstellen. Allerdings müssten dazu zunächst die oben beschriebenen Probleme
mit der virtuellen Mikroskopie zufriedenstellend gelöst werden.
Seite 103
4
Auch in der Pathologie spielen Zweitgutachten eine wichtige Rolle. So werden alle pathologischen Befunde, die
nicht von Fachärzten angefertigt wurden, noch einmal von einem Facharzt befundet. Bei diesen Fällen ist der
Ersatz der Zweitbegutachtung durch ein CAD-System vermutlich nicht sinnvoll. Von Fachärzten erstellte Befunde werden meist nur bei unklaren oder besonders komplizierten Fällen doppelt begutachtet. Diese Begutachtung
erfolgt meist institutsintern. Bestimmte Fälle wie beispielsweise die Colitis Ulcerosa mit Dysplasie werden aber
standardmäßig doppelt begutachtet. Steht kein Kollege mit langjähriger Expertise für solche Spezialfälle zur
Verfügung, so werden externe Gutachten eingeholt. Für diesen Einsatzfall wäre Telepathologie sinnvoll (schnelle
Bearbeitung, keine Portokosten, keine Beschädigung oder Verlust auf dem Postweg). Eventuell käme auch ein
Einsatz von CAD infrage.
Strukturierte Eingabe Bei dem in dieser Diplomarbeit vorgestellten Ansatz zur strukturierten Eingabe (vgl.
Kap. 4.5) übernimmt der Arzt während der Untersuchung gleichzeitig die Niederschrift des Befundberichts. Da
am Institut für Pathologie ein Schreibbüro zur Verfügung steht, empfinden die Pathologen diese Vorgehensweise
vor allem als unangenehmen Zusatzaufwand.
Es werden jedoch auch Vorteile des Ansatzes gesehen. Die bei strukturierter Eingabe garantierte grammatikalische und orthografische Korrektheit käme den Ärzten entgegen. Außerdem vereinfachte sich das Korrekturlesen,
wenn häufig benutzte Textfragmente einheitlich formuliert würden. Falls an einem Tag nur wenige Befundberichte zu bearbeiten sind, sei das eigene Verfassen manchmal sogar wünschenswert (Korrektheit, keine zeitliche
Abhängigkeit von Anderen). Schließlich eignete sich strukturierte Eingabe gut für die Ausbildung, da werdende Fachärzte bei diesem Ansatz gleich an einen sinnvollen Untersuchungsablauf gewöhnt würden und keine
Untersuchungsschritte vergessen könnten.
Ein wesentlicher Vorteil strukturierter Eingabe ist das Ableiten von Kodes und Zusammenfassungen während
der Eingabe. Auch in der Pathologie ist das Heraussuchen korrekter Kodes eine lästige Aufgabe, so dass häufig
nur grob kodiert wird (ICD-Kodes mit Endung .9“, also nicht näher bezeichnet“). Die strukturierte Eingabe
”
”
könnte hier zu einer besseren Kodierungsqualität führen. Da die Diagnosen für die Pathologie selbst aber
nicht abrechnungsrelevant sind, sei dieser Vorteil nur gering. Hinsichtlich der automatischen Ableitung von
Zusammenfassungen (Abschnitt Beurteilung“ oder Diagnose“, vgl. Kap. 2.4.5) sind die Pathologen skeptisch.
”
”
Der Kliniker sei nur an möglichst wenigen, aber dafür wesentlichen Informationen interessiert. Das automatische
Ableiten aus makroskopischem und mikroskopischem Befund sei schwierig, da je nach Diagnose verschiedene
Erkenntnisse relevant seien. Außerdem helfe eine sinnvolle Reihenfolge, die möglicherweise nicht automatisch
herzustellen ist, dem Kliniker bei der Interpretation der Beurteilung.
Die besseren Recherchemöglichkeiten in strukturierten und standardisierten Befundberichten werden durchaus
als Vorteil gesehen. Allerdings stellt sich dieser Vorteil im Wesentlichen in der Forschung dar. Derzeit werden
kompliziertere Rechercheaufträge von Doktoranden durchgeführt. Fachärzte profitierten daher von besseren
Recherchemöglichkeiten nur indirekt.
Zusammenfassend wurde festgestellt, dass die strukturierte Eingabe des Befundberichts durch Pathologen etliche Vorteile hat. Als einziger, aber besonders gewichtiger Nachteil wurde die höhere Arbeitsbelastung für die
Ärzte genannt. Je nach Anzahl der pro Tag zu verfassenden Befundberichte sowie der Verfügbarkeit und den
Kosten eines Schreibbüros ist durchaus damit zu rechnen, dass strukturierte Eingabe zukünftig in der Pathologie
eingesetzt wird.
Zur Minimierung des zusätzlichen Arbeitsaufwandes machten die Pathologen folgende Vorschläge:
Für Standardbefunde sollten längere Textbausteine prominent in der Liste der Eingabemöglichkeiten platziert werden, da nicht jeder Fall das vollständige Abarbeiten aller Punkte erfordert.
Spracherkennung wäre für die Eingabe hilfreich. Die Auswahl zwischen den Eingabemöglichkeiten könnte
zum Beispiel über Zahlenkodes erfolgen.
Solange die virtuelle Mikroskopie noch nicht zur Verfügung steht, wäre möglicherweise eine Einblendung
des Eingabedialogs in das Sichtfeld des Lichtmikroskops sinnvoll, damit sich der Pathologe nicht abwechselnd verschiedenen Medien zuwenden muss92 .
92 Entsprechende
Technik wird seit einiger Zeit unter dem Namen image injection“ im Bereich der Operationsmikroskope erforscht
”
und bereits erfolgreich eingesetzt [EKM+00, GCP+07].
Seite 104
5
ERGEBNISSE UND AUSBLICK
5 Ergebnisse und Ausblick
5.1 Ergebnisse
5.1.1 Ergebnisse der theoretischen Arbeit
Strukturierte Befundberichte Bei der Erarbeitung des Grundlagenteils wurde zunächst festgestellt, dass die
bisherigen Befundberichte in den untersuchten Pathologieeinrichtungen in höchstens schwach strukturierter
Form abgespeichert werden (Kap. 2.4.5). Im Wesentlichen wird mit Freitext gearbeitet, explizite Merkmalsauszeichnung und kodierte Merkmalsausprägungen werden fast nirgends verwendet. Allein die abschließende
Diagnose einer Untersuchung wird zum Teil mit ICD- bzw. ICD-O-Kodes verschlüsselt. Von einer strukturierten und standardisierte Dokumentation sind die untersuchten Einrichtungen, vor allem aufgrund fehlender
kommerzieller Softwarelösungen für diesen Bereich, weit entfernt.
Virtuelle Mikroskopie und DICOM Bei der Recherche für den theoretischen Teil zeigte sich außerdem, dass
der DICOM-Standard bisher praktisch keine Rolle in der Pathologie spielt. Die Begründung dafür ist denkbar
einfach: Bisher wird in der Pathologie kaum mit digitalen Bildern gearbeitet. Da die Forschung und Entwicklung der virtuellen Mikroskopie“ aber in großen Schritten voranschreitet, wurde diesem Themengebiet in der
”
Diplomarbeit ein eigenes Unterkapitel gewidmet (Kap. 2.2). Insbesondere wurde festgestellt, dass es zur Zeit
eine unüberschaubare Vielfalt an Bildformaten für virtuelle Präparate gibt (Kap. 2.2.2). Eine Einigung auf
DICOM als Standardbildformat auch für virtuelle Präparate ist daher naheliegend und aus Anwendersicht
wünschenswert. Allerdings müssen bis dahin noch zahlreiche Änderungsarbeiten am DICOM-Standard abgeschlossen werden (siehe Kap. 2.5.11).
DICOM-Informationsquellen Der Mangel an einführender Literatur zum DICOM-Standard ist offensichtlich.
Neben den kurzen selbstverfassten Einführungen in DICOM (Kap. 2.5) und DICOM-SR (Kap. 2.6) integrierte
der Autor daher Verweise auf Informationsquellen zu DICOM im Allgemeinen (Kap. 2.5.12) und DICOM-SR
im Speziellen (Kap. 2.6.7) in den Grundlagenteil.
5.1.2 Vorarbeiten für die Implementierung
Marktübersicht für DICOM-Toolkits Aufgrund der Komplexität von DICOM ist es ratsam, bei der Implementierung von DICOM-konformer Software auf vorgefertigte Programmbibliotheken, sogenannte DICOM-Toolkits,
zurückzugreifen (vgl. Kap. 2.5.10). Eine Marktübersicht kommerzieller und freier DICOM-Toolkits, die bei der
Auswahl des für den jeweiligen Anwendungszweck geeigneten Toolkits helfen könnte, war zum Zeitpunkt der Erstellung dieser Arbeit nicht zu finden. Der Autor kombinierte daher die verschiedene fragmentarischen Ansätze
Anderer und ergänzte sie um die Ergebnisse eigener Recherchen zu einer möglichst vollständigen Liste [99].
Maschinelle Interpretation des DICOM-Standards Der DICOM-Standard selbst liegt nicht als strukturiertes
und standardisiertes Dokument, sondern nur als Word-Datei vor, was die Erstellung DICOM-konformer Software erschwert. Die Hersteller der DICOM-Toolkits haben dieses Problem erkannt und liefern ihre Produkte
zumindest mit einer maschinenlesbaren Form des häufig benötigten Data Dictionary“ (PS 3.6 [DIC08a]) aus.
”
Für die Erstellung von DICOM-SR-Software ist jedoch vor allem der Zugriff auf Kontextgruppen und Templates, die in PS 3.16 DCMR beschrieben werden, entscheidend. Gemeinsam mit einem Praktikanten wurden die
Kontextgruppen in eine maschinenlesbare XML-Form gebracht (Kap. 4.1). Diese Datei wurde um zahlreiche
Begriffe aus anderen Standards erweitert, die im DCMR lediglich referenziert und nicht konkret aufgeführt werden (Kap. 4.1.2.1 bis 4.1.2.5), und für Entwickler freier DICOM-Toolkits im Internet kostenlos zur Verfügung
gestellt [98]93 .
DICOM definiert in PS 3.3 der aktuellen Version 2008 acht Dokumentenklassen für DICOM-SR-Dokumente
(vgl. Kap. 2.6.1.1). Die wesentlichen Unterschiede zwischen den einzelnen Dokumentenklassen beschreibt die
93 Mathieu
Malaterre, der Hauptentwickler des C++-DICOM-Toolkits Grass roots DiCoM“ (GDCM, [61]), hat bereits Interesse
”
bekundet.
Seite 105
5
zugehörige Tabelle für Einschränkungen bei der Konstruktion von Dokumenten (vgl. Abb. 17). Für alle acht
Dokumentenklassen wurden diese Tabellen von Hand in ein XML-Format gebracht. Außerdem wurde in der
XML-Datei vermerkt, ob für die jeweilige Dokumentenklasse DICOM-SR-Templates vorgeschrieben sind ( De”
fined Template“) oder vorgeschlagen werden ( Baseline Template“).
”
5.1.3 Implementierung
GENRE Da derzeit keine zufriedenstellende Standardsoftware zur Erstellung, Visualisierung und Bearbeitung von DICOM-SR-Dokumenten existiert (vgl. Kap. 4.2.1), wurde im Rahmen dieser Diplomarbeit GENRE
( Generic Report E ditor“) implementiert (Kap. 4.3). GENRE ist durch seinen generischen Ansatz flexibel
”
einsetzbar und durch die Verwendung von Java nahezu plattformunabhängig (vgl. Kap. 4.3.5).
Bei der Entwicklung von GENRE wurde auf das kostenlose und quelloffene DICOM-Toolkit PixelMed Ja”
va DICOM Toolkit“ zurückgegriffen. Dieses Toolkit enthält grundlegende Datenstrukturen für DICOM-SRInhaltselemente, die im Rahmen dieser Arbeit erheblich erweitert wurden (vgl. Kap. 4.3.1). Die Änderungen am
Quellkode werden an den Autor des PixelMed-Toolkits weitergegeben, so dass zukünftig auch andere Entwickler
von den neuen Funktionen profitieren können.
Besonderer Wert wurde bei GENRE auf die Benutzungsfreundlichkeit gelegt. So lässt sich der Inhalt von
DICOM-SR-Dokumenten schon in der Bearbeitungsansicht von GENRE aus dem DICOM-SR-Inhaltsbaum
ablesen, und Inhaltselemente lassen sich an Ort und Stelle ändern (siehe Kap. 4.3.2.2). Überall, wo kodierte
Merkmale eingesetzt werden, kann in GENRE komfortabel auf die DICOM-SR-Kontextgruppen zurückgegriffen
werden (vgl. Kap. 4.1.2.6). Die GENRE-Benutzeroberfläche ist auf Mehrsprachigkeit ausgelegt. Eine deutsche
und eine englische Version wurden im Rahmen dieser Diplomarbeit erstellt, weitere Übersetzungen können von
Anwendern einfach realisiert werden. Außerdem ermöglicht GENRE die landestypische Eingabe von Gleitkommazahlen und Datumsangaben (Kap. 4.3.3.1). Das komfortable Einbinden von Bildern aus DICOM-Archiven
wurde vorbereitet, aber nicht fertiggestellt (Kap. 4.3.4). Teilbäume können aus dem Inhaltsbaum gelöscht oder
an eine andere Stelle verschoben werden. Für die Weitergabe von DICOM-SR-Dokumenten an Einrichtungen,
die nicht über entsprechende Anzeigesoftware verfügen, bietet GENRE einen HTML-Export an (Kap. 4.3.2.4).
Neben der Manipulation des Inhaltsbaumes ermöglicht GENRE auch die Bearbeitung der wichtigsten Angaben im Dokumentenkopf von DICOM-SR-Dokumenten (Kap. 4.3.2.1). Eine Dokumentenansicht auf DICOMAttribut-Ebene in GENRE erleichtert das Debugging von Software, die DICOM-SR-Dokumente erstellt.
Eingabeassistent für GENRE Trotz aller Bemühungen, GENRE benutzungsfreundlich zu gestalten, sind direkte Manipulationen an DICOM-SR-Inhaltsbäumen für den ärztlichen Alltag zu aufwändig. Daher wurde ein
Eingabeassistent implementiert, der das in der Praxis bewährte Konzept einer kommerziellen Softwarelösung
zur strukturierten Eingabe imitiert (Kap. 4.5). Bei diesem Konzept wird der Benutzer durch eine Grammatik
geführt, die er bei Bedarf selbst verändern und ergänzen kann. Dadurch kann der Eingabeassistent an verschiedenste Anforderungen angepasst werden.
In dieser Arbeit sollte die strukturierte Befundberichtschreibung für die Pathologie erforscht werden. Daher wurden in Absprache mit Pathologen zwei Beispielsfälle identifiziert, bei denen die strukturierte Eingabe besonders
sinnvoll scheint (Kap. 4.4.1). Für die Dokumentation dieser Fälle wurde ein einfaches, allgemeines Eingabeformular entworfen und mit der Entwicklung der notwendigen Eingabe-Grammatiken begonnen. Dieser Aspekt
soll in einer Promotionsarbeit an der Medizinischen Fakultät der Universität zu Lübeck weiter ausgearbeitet
werden.
5.2 Ausblick
5.2.1 DICOM-Entwicklung
Virtuelle Mikroskopie Entscheidend für die Verbreitung von DICOM in der Pathologie ist nach Einschätzung
des Autors die Einsatzmöglichkeit des Standards zur Speicherung und Kommunikation von virtuellen Präparaten
(vgl. Kap. 2.2). Diese Aufgabe wird derzeit von der DICOM-Arbeitsgruppe 26 bearbeitet, befindet sich aber
Seite 106
5
noch in einem frühen Stadium (vgl. Kap. 2.5.11). Mit einer Aufnahme in den Standard ist in den nächsten
Monaten nicht zu rechnen.
Erheblich weiter im Standardisierungsprozess ist Supplement 120 Extended Presentation States“ von der DI”
COM-Arbeitsgruppe 11. Diese Erweiterung ermöglicht eine bessere Annotation von Bildern durch vorgefertigte
Vektorobjekte (vgl. auch Kap. 2.5.5) und dürfte im Zusammenhang mit virtuellen Präparaten interessant sein.
DICOM-SR Größere Veränderungen im Bereich DICOM-SR wird Supplement 115 Evidence Document SOP
”
Classes“ mit sich bringen, das sich zur Zeit in Bearbeitung befindet. Mit Supplement 115 werden eine neue Dokumentenklasse, einige Templates und insbesondere zwei neue Datentypen für Inhaltselemente, TABLE“ und
”
CONTOUR“, in den DICOM-Standard eingeführt [17]. Ein TABLE“-Element enhält pro Zeile bzw. Spalte
”
”
jeweils mehrere Werte gleichen Typs mit einem gemeinsamen Konzeptnamen. Mit Elementen vom Typ CON”
TOUR“ können Koordinaten in einem Koordinatensystem der realen Welt angegeben werden ( SCOORD“ und
”
TCOORD“ verwenden hingegen DICOM-Koordinaten). Beide Datentypen sind recht komplex. Supplement
”
115 hat zur Zeit den Status Work“, eine Verabschiedung wird also noch etwas auf sich warten lassen.
”
Weitere Supplements (Supp. 126 Colon Computer-Aided Detection SR SOP Class“ und Supp. 134 Implan”
”
tation Plan SR Document Storage SOP Class“), die in den nächsten Monaten in den Standard aufgenommen
werden könnten, fügen PS 3.3 weitere neue Dokumentenklassen hinzu. Mit den Supplements 78 Fetal and
”
Pediatric Echocardiography SR“, 128 Cardiac Stress Testing Structured Reports“ und 129 Electrophysiology
”
”
Structured Reports and Procedure Log Templates“, die sich ebenfalls in Arbeit befinden, werden zwar zahlreiche Templates und Kontextgruppen hinzugefügt bzw. verändert, in die Grundlagen von DICOM-SR wird dort
jedoch nicht eingegriffen.
Mit Supplement 135 SR Diagnostic Imaging Report Transformation Guide“ wird DICOM in der nächsten Zeit
”
um eine Vorschrift ergänzt, wie DICOM-SR-Dokumente, die auf Template 2000 basieren, in ein HL7-CDAFormat umzuwandeln sind (vgl. Kap. 2.6.6).
Bei der Anpassung von DICOM-SR an Belange der Pathologie sind noch zahlreiche Fragen zu klären, unter
anderem: Sollten Befundberichte der Pathologie eine eigene Dokumentenklasse bekommen? Werden eigene Templates benötigt oder reichen die allgemeineren Templates wie TID 2000 Diagnostic Imaging Report“? Welche
”
Dokumententitel sollte zu Kontextgruppe 7020 bzw. 7000 hinzugefügt werden? Welche Aufnahmemodalitäten
zu Kontextgruppe 29?
Der Autor möchte der Deutschen Gesellschaft für Pathologie (DGP) und dem Berufsverband Deutscher Pathologen (BDP) nahelegen, sich in der DICOM-Arbeitsgruppe 26 Pathology“ zu beteiligen. Die Deutsche
”
Röntgengesellschaft ist beispielsweise schon lange Mitglied des DICOM-Komitees und arbeitet zur Zeit sogar
an einem eigenen Supplement speziell für deutsche Belange ( National Radiology Report“ [Hac07]).
”
5.2.2 GENRE-System
Im Umfeld von GENRE gibt es zahlreiche Anknüpfungspunkte für weitere Arbeiten. Die aus Sicht des Autors
interessantesten sind in den folgenden Abschnitten geschildert.
5.2.2.1 Kontextgruppen
Wie mehrsprachige Kontextgruppen in XML umgesetzt werden könnten, wurde in Kapitel 4.1.2 vorgeschlagen.
PS 3.16 enthält bereits die Übersetzungen zahlreicher Begriffe ins Französische und Japanische (PS 3.16, Anhang E und F [DIC08a]), deutsche Übersetzungen finden sich bisher jedoch nicht. Eine Liste aller Kodes mit
Kodierungsschema-Bezeichner DCM“ als Ausgangspunkt für Übersetzungsarbeiten findet sich auf der Begleit”
webseite zu dieser Diplomarbeit [98]. Die Übersetzung der Snomed-Begriffe ins Deutsche könnte automatisiert
ablaufen: Seit 2004 existiert eine deutsche Snomed-Version, die derzeit überarbeitet wird [Höl06], und eine Software mit Programmierschnittstelle zum Nachschlagen von Snomed-Kodes ist kostenlos im Internet erhältlich
[14].
Zwei Kontextgruppen konnten nicht in die maschinenlesbare Version des DCMR integriert werden: Kontextgruppe 82 Units of Measurement“ (vgl. Kap. 4.1.2.1) und Kontextgruppe 7007 Signature Purpose“ (vgl. Kap.
”
”
4.1.2.4). Für die UCUM-Kodes aus Kontextgruppe 82 sollte eine Eingabehilfe programmiert werden, damit
Seite 107
5
auch unkundige Benutzer gültige UCUM-Kodes generieren können. Für die Kodes aus Kontextgruppe 7007
sollte überprüft werden, ob der Standard ASTM E 2084-00 im Zusammenhang mit DICOM nicht doch kostenlos verwendet werden darf (normalerweise integriert DICOM keine Kodes, die die Zahlung von Lizenzgebühren
erfordern). Außerdem sollte die in Kapitel 4.1.2.5 beschriebene, automatische Extraktion von Dokumententiteln
für Kontextgruppe 7020 auf den aktuellen LOINC angewendet werden (vgl. auch Fußnote 51 auf Seite 58).
In Kapitel 4.1.2.7 wurde festgestellt, dass es bei wachsendem Umfang der DCMR-Kontextgruppen (z. B. durch
Mehrsprachigkeit) nicht mehr sinnvoll ist, diese vollständig im Arbeitsspeicher zu halten. Stattdessen sollte eine
Datenbank verwendet werden. Das GENRE-Konzept verfolgt das Ziel, möglichst wenig von externen Programmbibliotheken abhängig zu sein. Von daher böte sich die in Java 6 integrierte Java DB [105], eine Variante von
Apache Derby, als Datenbank an. Eine andere, besonders kompakte und schnelle Java-Datenbank ist HSQLDB94
[48].
5.2.2.2 Funktionalität von GENRE
In Implementierungsteil dieser Arbeit finden sich zahlreiche Ideen, die aus Zeitgründen nicht realisiert werden
konnten:
Grafische Eingabemasken für Konzeptwerte aller Typen. GENRE enthält Datenstrukturen und
Methoden zu deren Manipulation für alle 14 in DICOM-SR definierten Konzeptwert-Typen (vgl. Kap.
4.3.1). DICOM-SR-Dokumente, die Inhaltselemente mit Konzeptwerten dieser Typen enthalten, können
geladen und gespeichert werden. Es existieren jedoch bisher nur Eingabedialoge für Konzeptwerte der
Typen CONTAINER, TEXT, CODE, DATE, NUM, PNAME, UIDREF und IMAGE. Die Probleme bei
lokalisierten Eingabeassistenten für Zeitangaben (Typ TIME bzw. DATETIME) wurden in Kapitel 4.3.3.1
bereits kurz angesprochen. Kapitel 4.3.4 besprach den Entwurf und den Anfang der Implementierung eines
Eingabeassistenten für Konzeptwerte vom Typ IMAGE.
Wertüberprüfung bei der Eingabe. Die Änderung von DICOM-Attributwerten erfolgt in GENRE
über Textfelder. Die meisten dieser Felder werden nicht auf DICOM-konformen Inhalt überprüft (Ausnahmen bilden Textfelder für die Eingabe von UIDs in UIDREF- und IMAGE-Elementen sowie die Eingabe
von Gleitkommazahlen in NUM-Elementen). Es ist also möglich, mit GENRE nicht-DICOM-konforme Dateien zu erstellen. Java erlaubt die Inhaltsprüfung von Textfelder über die Klassen JFormattedTextField
bzw. InputVerifier. Es sollten für alle 27 Basisdatentypen (vgl. Kap. 2.5.6.2), die DICOM definiert, jeweils geprüfte Textfelder implementiert werden. Dabei sollten auch mehrwertige Attribute berücksichtigt
werden.
Berücksichtigung von DICOM-Templates. In Kapitel 3 ( Allgemeiner Lösungsansatz“) wurden die
”
Vorteile einer templategeführten Eingabe kurz angesprochen. GENRE kennt bereits für jede Dokumentenklasse die vorgeschriebenen oder empfohlenen Root-Templates (s. o.). Der Dialog zum Anlegen neuer
Dokumente zeigt diese auch an, beim Bearbeiten von Inhaltsbäumen werden sie jedoch nicht berücksichtigt.
Als Vorarbeit für die Unterstützung von Templates in GENRE wurden im Rahmen einer Praktikumsarbeit am IMI die Templatetabellen aus PS 3.16, Anhang A, in ein strukturiertes XML-Format gebracht.
In einem nächsten Schritt müssten die Inhalte der einzelnen Tabelleneinträge semantisch analysiert und
entsprechend annotiert werden. Die technischen und rechtlichen Problematiken dabei wurden in Kapitel
2.6.4 erwähnt.
Anlegen, Editieren und automatisches Korrigieren von By-reference-Relationen. In Kapitel
2.6.2.2 wird das Konzept von By-reference-Relationen erläutert. GENRE erlaubt das Öffnen von DICOMSR-Dokumenten mit By-reference-Relationen und zeigt sie im Inhaltsbaum korrekt an. Es können derzeit
aber noch keine neuen By-reference-Relationen angelegt werden. Auch die Änderung des Zielelements
solcher Relationen ist bisher nicht möglich. Schließlich sollte eine Funktion implementiert werden, die die
Zieladresse von By-reference-Relationen automatisch korrigiert, sobald sich die Position des Zielelements
im Inhaltsbaum durch das Löschen von Teilbäumen bzw. das Einfügen oder Verschieben von Inhaltselementen ändert.
Bessere grafische Darstellung von Relationen. Dem Autor ist bisher keine Lösung für das Problem bekannt, wie man Relationen verschiedener Typen sinnvoll grafisch darstellt. GENRE zeigt den
Typ einer By-value-Relation bisher nur im Tooltip des Zielelements an. Mit Ärzten und Kommunikationsdesignern sollte diskutiert werden, ob – und wenn ja wie – Relationstypen dargestellt werden sollen.
94 Diese
Datenbank bietet mit sogenannten Text Tables“ die interessante Möglichkeit, von Menschenhand gut zu pflegende CSV”
Dateien als Datenquelle zu verwenden, vgl. http://www.hsqldb.org/doc/guide/ch06.html
Seite 108
5

By-reference-Relationen werden in GENRE derzeit als Kinder des Quellelements der Relation angezeigt,
weil sie auf Kodierungsebene als solche abgelegt werden. Diese Art der Anzeige ist wenig intuitiv. Besser wäre möglicherweise die Repräsentation von By-reference-Relationen mittels Pfeilen zum Zielelement.
Dafür benötigte man allerdings ausgefeilte Platzierungsalgorithmen.
Export von DICOM-SR in Word, PDF etc. Erstrebenswert wäre neben dem bereits realisierten
Export nach HTML zusätzlich ein Export in das derzeit an der Uni Lübeck in der Pathologie verwendete
Microsoft-Word-Format sowie in das gängige PDF-Format. Dieser Punkt wird in Kapitel 4.3.2.4 diskutiert.
Editor für DICOM-Attribute im Dokumentenkopf. GENRE enthält einen Dialog, mit dem die
Pflicht-Attribute im Dokumentenkopf von DICOM-SR-Dateien bearbeitet werden können. Es wäre interessant, die Auswahl der bearbeitbaren Attribute zu vergrößern und für die einzelnen Felder Eingabehilfen
bereitzustellen. Kapitel 4.3.2.1 enthält nähere Erläuterungen hierzu.
UCUM Eingabehilfe. Im vorigen Abschnitt wurde eine UCUM-Eingabehilfe diskutiert. Diese sollte in
die Eingabemaske für Inhaltselemente vom Typ NUM“ integriert werden. Die Eingabemaske ist vom
”
Layout her bereits darauf vorbereitet.
Berücksichtigung spezieller Eigenheiten von Dokumentenklassen. Derzeit berücksichtigt GENRE
für alle Dokumentenklassen die Einschränkungen bezüglich By-value-Referenzen (vgl. Kap. 2.6.2.3). Dokumente der Klasse Key Object Selection“ beispielsweise haben jedoch zusätzlich zu diesen Einschränkungen
”
auch einen anderen Modulaufbau. Procedure Log“-Dokumente hingegen erfordern für jedes Zielelement
”
einer Relation vom Typ CONTAINS“ die Angabe eines Beobachtungszeitpunkts ( Observation DateTi”
”
me“, vgl. PS 3.3 Anhang A.35.7.3.1.2). Die Inhaltselemente der ersten Ebene sollen nach dieser Angabe
geordnet werden. Beide Anforderungen werden von GENRE bisher nicht unterstützt. Die Dokumentenklassen Mammography CAD“ und Chest CAD“ erzwingen für Befundberichte, die in Teilen auf früheren
”
”
Berichten beruhen, einen Observation Context“ nach TID 1001. Diese Bedingung ist maschinell nur
”
schwierig zu überprüfen. Der klinische Anwender sollte in zukünftigen Versionen von GENRE aber auf
den Observation Context“ hingewiesen und mit einem benutzungsfreundlichen Formular bei der Eingabe
”
dieser Daten unterstützt werden.
Berücksichtigung von UIDs für Kontextgruppen. Mit CP 845 wurde am 23.6.2008 für jede Kontextgruppe ein eindeutiger Bezeichner in Form einer UID hinzugefügt. Dies wird in GENRE noch nicht
berücksichtigt. UIDs müssten in jedes Code Sequence Attribute“ (z. B. in Konzeptnamen, die Concept
”
”
Code Sequence“ von CODE-Inhaltselementen oder die Measurement Units Code Sequence“ von NUM”
Inhaltselementen) integriert werden, das Enhanced Encoding“ verwendet. PS 3.6 enthält nun zusätzlich
”
das neue Attribut Context UID“ (0008,0117) und eine lange Liste, die allen Kontextgruppen aus PS 3.16,
”
Anhang B, eine UID zuordnet.
TABLE- und CONTOUR-Inhaltselemente. Sobald das weiter oben im Ausblick beschriebene Supplement 115 verabschiedet ist, sollte natürlich die Unterstützung für Inhaltselemente der neuen Typen
TABLE und CONTOUR in GENRE integriert werden. Die Architektur von GENRE ist auf Erweiterbarkeit ausgelegt, dennoch ist die Implementierung der neuen Typen aufgrund ihrer Komplexität sicherlich
aufwändig.
5.2.2.3 Eingabeassistent und klinische Anwendung
Von einem Einsatz in der klinischen Routine ist das GENRE-System derzeit noch nicht geeignet. Setzt man
weiter auf die in Kapitel 4.5 beschriebene Implementierung eines grammatikgeführten Eingabeassistenten, so
sollte auf jeden Fall zunächst die Unterstützung für benutzerdefinierte Makros ergänzt werden, mit deren Hilfe
erst stärker strukturierte Dokumente und automatische Kodeableitung realisiert werden können. Ein Ansatz
hierzu wurde in Kapitel 4.5.3 beschrieben, das Kapitel nennt allerdings auch Probleme, mit denen von vornherein
bei der Implementierung von Makros für DICOM-SR-Inhaltsbäume zu rechnen ist.
Die Verwendung von automatischer Spracherkennung in Kombination mit dem beschriebenen Eingabeassistenten ist aus mehreren Gründen reizvoll. Einerseits wird sie von Pathologen gefordert, damit sie ihre Hände für
Untersuchungen frei haben (vgl. Kap. 4.6). Andererseits ist bei der strukturierten Eingabe mit sehr guten Erkennungsraten zu rechnen, da in jedem Eingabeschritt nur aus einer Liste mit wenigen Punkten ausgewählt wird.
Das verwendete Vokabularium ist mithin sehr klein und das Erkennen kontinuierlicher Sprache nicht erforderlich. Auch andere Veröffentlichungen schlagen automatische Spracherkennung für die strukturierte Eingabe vor
(z. B. [Ber03, Nou06]). Da GENRE vollständig in Java geschrieben ist, wäre es sinnvoll, die Spracherkennung
Seite 109
5
ebenfalls mit Java zu realisieren. Sun hat bereits im Oktober 1998 die sogenannte Java Speech API (JSAPI),
eine allgemeine Schnittstelle für die Erkennung und Synthese natürlicher Sprache in Java, veröffentlicht. JSAPI
soll das Einbinden von Fremdprodukten verschiedener Hersteller erlauben. Allerdings sind praktisch alle Implementierungen für JSAPI mittlerweile nicht mehr verfügbar oder zumindest veraltet. Es existieren jedoch einige
freie Java Projekte zur Spracherkennung, die zwar nicht auf die JSAPI aufsetzen aber dafür offenbar noch aktiv
sind. Dazu zählen beispielsweise simon [102], MARF [63] und Sphinx-4 [11].
Auf jeden Fall müssen im Vorfeld eines möglichen klinischen Routineeinsatzes geeignete Grammatiken für den
Eingabeassistenten formuliert werden, deren Ausdrucksstärke deutlich über die im Rahmen dieser Arbeit zu
Demonstrationszwecken entwickelten Grammatiken hinausgeht. Diese Aufgabe kann und sollte von Medizinern
in enger Kooperation mit Fachärzten für Pathologie bearbeitet werden. Anschließend sollte evaluiert werden, ob
die Befunderstellung beschleunigt werden konnte und inwiefern die Aussagekraft der erzeugten Befundberichte
von herkömmlichen, diktierten Befundberichten abweicht.
5.3 Fazit
DICOM-SR wird bislang hauptsächlich von den Herstellern medizintechnischer Geräte für die Speicherung von
automatisch generierten Daten ihrer bildgebenden Geräte verwendet. Die Verwendung von DICOM-SR durch
menschliche Benutzer ist nur selten vorgesehen. Solange kein äußerer Zwang“ für Standards gegeben ist, wer”
den Kliniker weniger aufwändige Softwarelösungen wie die überwiegend proprietären Softwarelösungen von E&L
oder MEDNOVO favorisieren. Am ehesten könnte dieser Zwang entstehen, wenn sich im Zusammenhang mit der
elektronischen Gesundheitskarte die hierfür vorgesehene HL7 Clinical Document Architecture als Standardformat für medizinische Dokumente etabliert. In der Folge könnte auch die Verbreitung von DICOM-SR zunehmen,
da die Abbildung von DICOM-SR auf HL7-CDA für spezielle Dokumente bereits gelöst ist.
Durch seinen generischen Ansatz kann DICOM-SR eine prinzipielle Tauglichkeit für den Einsatz in der Pathologie bescheinigt werden. Die in Kapitel 2.4 genannten Vorteile einer strukturierten und standardisierten medizinischen Dokumentation lassen sich mithilfe von DICOM-SR ausnutzen. Supplement 122 (vgl. Kap. 2.5.11),
das in der nächsten DICOM-Version enthalten sein wird, verbessert noch einmal stark die Möglichkeiten zur
standardisierten Merkmalskodierung in DICOM-SR-Befundberichten für die Pathologie. Seinen größten Vorteil,
nämlich die Verwendung einer ohnehin vorhandenen DICOM-Infrastruktur, kann DICOM-SR aber erst dann
ausspielen, wenn sich DICOM auch in der Pathologie durchgesetzt hat – womit langfristig durchaus zu rechnen
ist. Insofern ist das Potential von DICOM-SR in der Pathologie stark abhängig von der zukünftigen Entwicklung
der virtuellen Mikroskopie und der Anpassung des DICOM-Standards für die Speicherung und Kommunikation
virtueller Präparate.
Allgemein leidet DICOM-SR bisher noch unter einem Mangel an Standardwerkzeugen. Die Unterstützung von
DICOM-SR in kostenlosen DICOM-Toolkits ist, mit Ausnahme des DCMTK [82], entweder überhaupt nicht
gegeben oder allenfalls als rudimentär zu bezeichnen. Auch viele kommerzielle Toolkits unterstützen den Umgang mit DICOM-SR-Dokumenten überhaupt nicht. Auf der Anwendungsebene ist das Software-Angebot bisher
ebenso spärlich wie auf der Entwicklerebene, zumal die meisten bestehenden Lösungen in verschlossenen Schubladen der Medizintechnik-Hersteller lagern (vgl. Kap. 2.6.7).
Diese Diplomarbeit leistet sowohl auf Toolkit- als auch auf Anwendungsebene einen Beitrag zur besseren Unterstützung von DICOM-SR. Zumindest für die Erstellung von DICOM-SR-Testdokumenten ist GENRE gut
geeignet. Die lange Liste an Verbesserungsmöglichkeiten im Ausblick zeigt aber, dass das Thema DICOM-SR
in einer Diplomarbeit nicht abschließend behandelt werden kann. Insbesondere wurde deutlich, dass ein Programm mit dem Anspruch, möglichst vollständige Unterstützung aller Möglichkeiten von DICOM-SR zu bieten,
kontinuierlicher Pflege bedarf: Allein im Zeitraum der Bearbeitung dieser Diplomarbeit flossen mehrere Sup”
plements“ und Correction Proposals“ in den DICOM-Standard ein, die die Möglichkeiten von DICOM-SR
”
erweiterten.
Seite 110
A
AUSWAHL AN SNOMED-KODES
A Auswahl an SNOMED-Kodes
Bezeichnung
Makroskopischer Befund
Mikroskopischer Befund
Klinische Diagnose /
Fragestellung
Eingesandtes Material
Begutachtung
SNOMED-Beschreibung
Macroscopic specimen observation (finding)
Microscopic specimen observation (finding)
Clinical diagnosis
Suspected diagnosis (contextual qualifier) (qualifier value)
Body material (substance)
Diagnostic assessment (procedure)
ConceptId
250429001
SnomedId
F-016A9
395538009
M-091AF
39154008
76053005
G-1010
G-2001
413674002
165197003
T-D04C8
P0-006ED
Tabelle 9: SNOMED-Kodes für Überschriften in pathologischen Befundberichten (Auswahl)
Bezeichnung
Plasmozytom
Monoklonale Gammopathie unbestimmter Signifikanz
Beckenkamm-Trepanat
Präparatlänge
Trabekelknochen
Zelltyp
Plasmazelle
Haematopoetische Progenitorzelle
Erythropoese
Thrombopoese
Erythroblast
Megakaryoblast
Megakaryozyt
Gitterfasern (Retikulin)
Gomori-Färbung
Versilberung
κ/λ-Verhältnis
Berliner-Blau-Färbung
Anzahl CD38-Zellen
SNOMED-Beschreibung
Multiple myeloma
Monoclonal gammopathy of undetermined significance
Iliac crest trephine
Length of core in specimen obtained by
needle biopsy
Trabecular substance of bone
Type of cell (attribute)
Plasma cell
Hematopoietic precursor cell
ConceptId
109989006
35601003
SnomedId
DC-F4643
M-97651
234330008
399598003
P0-0591F
R-0050C
20870005
246238003
113335003
127911004
T-11030
G-D79C
T-C1750
T-C100B
Erythropoiesis (function)
Platelet production
Erythroblast (cell)
Megakaryoblast
Megakaryocyte
Reticulin fibrosis
Gomori stain method
Reticulin stain
Kappa/lambda light chain ratio
Soluble berlin blue stain ?
CD38 count
69611006
179202003
84227004
27852005
23592000
75616009
117236003
117327000
413025002
64991008
413787004
F-D0100
R-40EA8
T-C1110
T-C1510
T-C1540
M-78010
P3-0017B
P3-0019C
P3-001C6
C-22975
P3-60246
Tabelle 10: SNOMED-Kodes für die Untersuchung eines Beckenkamm-Trepanats (Auswahl)
Seite 111
B ÜBERSETZUNGEN VON DICOM-BEGRIFFEN
B Übersetzungen von DICOM-Begriffen
Aus Gründen der besseren Lesbarkeit wurden für diese Diplomarbeit zahlreiche Begriffe des DICOM-Standards
ins Deutsche übersetzt. Bei der Suche nach geeigneten deutschen Begriffen wurde vor allem darauf geachtet,
dass der ursprüngliche, englische Begriff in der Übersetzung noch erkennbar ist; die sprachliche Eleganz wurde
nur nachrangig berücksichtigt. Tabelle 11 zeigt eine Übersicht häufig verwendeter Übersetzungen und enthält
außerdem Begriffe, die absichtlich in ihrer englischen Form belassen wurden.
Originalbegriff
Attribute
Code Meaning
Code Value
Coding Scheme Designator
Coding Scheme Version
Concept Name
Concept Value
Content Item
Context Group
Correction Proposal
Data Element
Data Set
Document Content Tree
Image
Information Entity (IE)
Information Object Definition (IOD)
Item (von Sequenzattributen)
Module
Relationship
Relationship Type
Sequence Attribute
Series
SOP Class
Structured Reporting Information Object Definition (SR IOD)
Study
Supplement
Template
Transfer Syntax
Value Range (VR)
Value Type
Waveform
Deutsche Übersetzung
Attribut
Kodebedeutung
Kodewert
Kodierungsschema-Bezeichner
Kodierungsschema-Version
(Konzept-)Name
(Konzept-)Wert
Inhaltselement
Kontextgruppe
–
Datenelement
Datensatz
Inhaltsbaum
Bild
Informationseinheit
–
–
Modul
Relation
Relationstyp
Sequenzattribut
Folge
SOP-Klasse
Dokumentenklasse
Untersuchung
–
–
Transfersyntax
(Basis-)Datentyp
(komplexer) Datentyp
Signalverlauf
Tabelle 11: Übersetzungstabelle für Begriffe aus dem DICOM-Standard
Seite 112
ACR American College of Radiology. 18, 24, 30
AE Application Entity. 29
AET Application Entity Title. 29, 87
AILD Angioimmunoblastische Lymphadenopathie. 90
AJAX Asynchronous JavaScript and XML. 64, 66–68, 124, 127
AMWF Arbeitsgemeinschaft der Wissenschaftlichen Medizinischen Fachgesellschaften. 90, 124
ANSI American National Standards Institute. 46, 83, 118, 124
API Application Programming Interface. 65, 88, 101, 102, 110, 128
ASCII American Standard Code for Information Interchange. 29, 58
ASTM American Society for Testing and Materials. 58, 108
BARI Bypass Angiography Revascularization Investigation. 43
BCID Baseline Context Group Identifier. 45
BDP Berufsverband Deutscher Pathologen e.V. 90, 107
BMU Bundesministerium für Umwelt, Naturschutz und Reaktorsicherheit. 12, 118
BPD Biparietaler Durchmesser (Querdurchmesser des kindlichen Kopfes im Mutterleib). 40
BTID Baseline Template Identifier. 45
CAD Computer-Aided Detection (deutsch: Computerunterstützte Detektion)
und/oder Computer-Aided Diagnosis (deutsch: Computerunterstützte Diagnose). 6, 11–13, 35, 36, 38, 46,
97, 103, 104, 109, 122–124, 128
CARS Computer Assisted Radiology and Surgery (Kongress). 118, 122, 123
CCD Charge-coupled Device. 8
CDA Clinical Document Architecture. 14, 15, 18, 23, 46, 47, 49, 78, 96, 97, 99, 107, 110, 118, 120, 124
CEN Comité Européen de Normalisation. 18, 119
CG Context Group. 42
CID Context (Group) Identifier. 42, 46, 57, 97
COM Component Object Model. 30, 78
CP Correction Proposal. 19, 26, 33, 60, 109, 119
CSS Cascading Style Sheets. 63, 66
CSV Comma-separated values. 55, 108
CT Computertomografie. 12, 23, 25, 28, 33, 36, 60, 72, 130
DBD Diastolischer Blutdruck. 39
DCID Defined Context Group Identifier. 45
DCMR DICOM Content Mapping Resource (PS 3.16). 42, 46, 54, 56–60, 64, 88, 96, 97, 105, 107, 108
DCT Discrete Cosine Transformation (Standard-Kompression bei JPEG-Bildern). 9
DGP Deutsch Gesellschaft für Pathologie e.V. 90, 107
Seite 113
DICOM Digital Imaging and Communications in Medicine. III, 5, 6, 10, 17–19, 21, 23–38, 41–43, 46, 47, 49,
51, 53–57, 59–65, 68–70, 72, 73, 77, 78, 82–87, 89, 96, 97, 105–110, 112, 118–125, 127–129
DICOM-SR DICOM Structured Reporting. III, 4–6, 12, 14, 15, 21, 24, 25, 27, 30–32, 34–38, 42, 43, 45–47,
49–51, 53, 54, 61–65, 67–70, 72–74, 77, 78, 80, 84, 88, 89, 92, 95, 96, 99, 102, 105–110, 122, 123, 130
DIMDI Deutsches Institut für Medizinische Dokumentation und Information. 125
DIN Deutsches Institut für Normung. 119
DIR HL7 CDA Diagnostic Imaging Report. 47
DKFZ Deutsche Krebsforschungszentrum. 49
DNS Domain Name System. 70
DOM Document Object Model. 60, 66, 128, 130
DRG Diagnosis Related Groups. 13
DSS Decision Support System. 5, 15
DT Defined Term. 45
DTID Defined Template Identifier. 45
DVD-RAM DVD-Random Access Memory. 18
EBM Einheitlicher Bewertungsmaßstab. 16
ECMA European Computer Manufacturers Association. 66, 125
EEG Elektroenzephalografie. 21
eGK elektronische Gesundheitskarte. 46
EKG Elektrokardiogramm. 17, 21, 72, 97
EN Europäische Norm. 18, 119
EV Enumerated Value. 45
FDA U.S. Food and Drug Administration. 12
FOP Formatting Objects Processor. 78, 124
GB Gigabyte. 33
GDCM Grass roots DiCoM. 54, 55, 105, 127
GENRE Generic Report Editor. III, 51, 53, 54, 61, 63, 64, 68–70, 73, 75–78, 80, 82–86, 88–90, 99, 101–103,
106–110
GOÄ Gebührenordnung für Ärzte. 16
GPL GNU General Public License. 67, 89
GUI Graphical User Interface (deutsch: grafische Benutzeroberfläche). 65, 67–69, 73, 76, 80, 82, 84, 129
GWT Google Web Toolkit. 66–68, 127
HER2 Human Epidermal Growth Factor Receptor 2. 13
HIPAA Health Insurance Portability and Accountability Act. 58
HL7 Health Level 7. 14, 15, 18, 23, 25, 26, 31, 46, 47, 49, 56, 59, 78, 96, 97, 99, 107, 110, 118–121, 123, 124,
126, 128
HTML Hypertext Markup Language. III, 49, 62, 63, 66, 67, 72, 78, 88, 106, 109
Seite 114
HTTP Hypertext Transfer Protocol. 121
IANA Internet Assigned Numbers Authority. 57
ICD International Statistical Classification of Diseases and Related Health Problems. 14, 25, 42, 92, 104, 105,
125
IDE Integrated development environment. 67
IE Information Entity. 23, 31, 112
IEEE Institute of Electrical and Electronics Engineers. 118, 120, 122
IETF Internet Engineering Task Force. 56
IHE Integrating the Healthcare Enterprise. 47, 120, 121, 126
IHTSDO International Health Terminology Standards Development Organisation. 126
IMI Institut für Medizinische Informatik an der Universität zu Lübeck. III, 47, 64, 78, 99, 108
IOD Information Object Definition. 23, 31, 35–37, 112
IP Internet Protocol. 18, 29, 87
ISO International Organization for Standardization. 18, 19, 25, 27, 56–58, 121, 126
J2SE Java 2 Platform, Standard Edition. 66
JAR Java Archive. 67
JDBC Java Database Connectivity. 103
JDK Java Development Kit. 76, 89, 129
JmDNS Java multicast DNS. 70, 126
JNI Java Native Interface. 62, 68, 69
JPEG Joint Photographic Experts Group. 9, 10, 18, 27, 28, 30, 33, 121
JPIP JPEG 2000 Interactive Protocol. 10, 33
JRE Java Runtime Environment. 67, 88, 89
JSAPI Java Speech API. 110
JSON JavaScript Object Notation. 67, 121, 125
JVM Java Virtual Machine. 62, 75
KIS Krankenhausinformationssystem. 18, 120, 123
LGPL GNU Lesser General Public License. 85
LOINC Logical Observation Identifiers Names and Codes. 14, 56, 58, 59, 96, 97, 108, 128
LZW Lempel-Ziv-Welch (Kompressionsalgorithmus für Pixelbilder). 10
MB Megabyte. 60, 86
MOD Magneto-Optical Disc. 18
MPEG Moving Picture Experts Group. 18, 28
MRT Magnetresonanztomographie. 33, 130
MVC Model-View-Controller. 129
NAT Network Address Translation. 29
Seite 115
NEMA National Electrical Manufacturers Association (Berufsverband d. elektrotechnischen Industrie d. USA).
5, 18, 19, 24, 30, 119, 127
NIH National Institute of Health. 129
NL Nesting Level. 44
NLM U.S. National Library of Medicine. 129
OCT Optical Coherence Tomography. 18
ODT OpenDocument Text. 78
OFFIS Oldenburger Forschungs- und Entwicklungsinstitut für Informatik-Werkzeuge und -Systeme. 49, 62, 68,
122, 128
OID Object Identifier. 25
OOXML Office Open XML. 78
OSI Open Systems Interconnection. 18
OWL Web Ontology Language. 49
PACS Picture Archiving and Communication System. 4, 10, 19, 28, 29, 32, 46, 85, 86, 120, 123, 127, 128
PDF Portable Document Format. 18, 24, 36, 73, 78, 109
PHP PHP: Hypertext Preprocessor. 66, 85
PRWF Pathology Report Workflow. 47
PWF Pathology Workflow (IHE Integrationsprofil). 47
RFC Request for Comments. 56, 57, 67
RIM Reference Information Model. 46
RIS Radiologieinformationssystem. 17, 19, 120, 123, 130
RLE Run Length Encoding. 27, 30
ROI Region of Interest. 36, 39
RPC Remote Procedure Call. 67
RTF Rich Text Format. 78
SAX Simple API for XML. 60
SCP Service Class Provider. 28, 85, 87
SCU Service Class User. 28, 29, 85, 87
SDE Structured Data Entry. 15
SDK Software Development Kit. 29, 88
SDM SNOMED DICOM Microglossary. 26
SIG Special Interest Group (HL7-Arbeitsgruppe). 46
SNOMED Systematized Nomenclature of Human and Veterinary Medicine. 26, 31, 42, 43, 95, 97, 118–120,
126
SOP Service-Object Pair. 17, 21, 25, 28, 36, 37, 46, 84, 85, 87, 107
SPARC Scalable Processor Architecture. 88
SQ Sequence of Items. 24
Seite 116
SQL Structured Query Language. 28, 59, 85, 86
SR Structured Reporting. 21, 36, 37, 46, 69, 89, 107, 112, 122–124, 129
TC Technical Committee. 18, 119, 121
TCP Transmission Control Protocol. 18, 28, 87
TID Template Identifier. 44, 46, 107, 109
TIFF Tagged Image File Format. 10, 118
TMA Tissue Microarray. 11, 32, 53
UCUM Unified Code for Units of Measure. 56, 107–109, 126, 128
UID Unique Identifier. 25, 28, 38, 74, 77, 84, 85, 108, 109, 127
UK-SH Universitätsklinikum Schleswig-Holstein (hier immer: Standort Lübeck). III, 16, 65, 78, 90–92, 96, 97,
99, 103, 126
USB Universal Serial Bus. 18, 68
UTF Unicode Transformation Format. 27
VM Value Multiplicity. 24, 44
VR Value Range. 24, 26, 27, 63
VT Value Type. 44
W3C World Wide Web Consortium. 129, 130
WADO Web Access to DICOM persistent Objects. 18, 46, 78
WG Working Group. 19, 31–33, 46, 54, 60, 120, 125
WSI Whole Slide Image. 32, 53
WWW World Wide Web. 62
XML Extensible Markup Language. 13, 27, 45, 46, 49, 54–61, 65–67, 78, 80, 105–108, 118, 119, 122, 124, 126,
129
XSL Extensible Stylesheet Language. 61
XSL-FO Extensible Stylesheet Language – Formatting Objects. 78
XSL-T Extensible Stylesheet Language Transformations. 56
ZUML ZK User Interface Markup Language. 67
Seite 117
Literatur
Literaturverzeichnis
Das Quellenverzeichnis ist dreigeteilt:
Im ersten Teil werden Quellen gelistet, die keinen zeitlichen Änderungen unterworfen sind. Die Liste ist
alphabetisch nach dem Verweiskürzel sortiert.
Der zweite Teil listet Quellen, bei denen im Laufe der Zeit mit Veränderungen gerechnet werden muss,
vornehmlich Online-Lernmaterialien und Firmenwebseiten. Diese Liste ist alphabetisch nach Autor bzw.
Firmenname sortiert. Namen, die mit The“ beginnen, werden anhand des folgenden Wortes einsortiert.
”
Im dritten Teil werden reine Bildquellen angegeben.
Alle in dieser Diplomarbeit genannten Webseiten wurden zuletzt am 12.8.2008 besucht.
Literatur
[Ado92] Adobe Systems Incorporated (1992). TIFF Revision 6.0. Mountain View, California: Adobe Developers Association.
http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf
[ANS78] American National Standards Institute (ANSI, 1978). ANSI X3.9-1978 – Programming Language Fortran.
http://www.fortran.com/F77_std/rjcnf-0.html
[Ast03] Astley SM (2003). Computer-aided detection for screening mammography. In: Lemke HU et al. (Hrsg.).
Computer Assisted Radiology and Surgery (CARS) 2003. Proc. of the 17th International Congress and
Exhibition. Amsterdam: Elsevier, 927-932.
[Bec06] Becker S (2006). Reimplementierung eines kommerziellen klinischen Befundsystems auf der Basis des
HL7-CDA-Standards. Universität zu Lübeck: Bachelorarbeit am Institut für Medizinische Informatik.
[Ber03] von Berg J (2003). A grammar-based speech user interface generator for structured reporting. In: Lemke
HU et al. (Hrsg.). Computer Assisted Radiology and Surgery (CARS) 2003. Proc. of the 17th International
Congress and Exhibition. Amsterdam: Elsevier, 887-892.
[Bid98a] Bidgood WD Jr (1998). Clinical importance of the DICOM structured reporting standard. Int J Card
Imaging. 1998 Oct;14(5):307-315.
[Bid98b] Bidgood WD Jr (1998). The SNOMED DICOM Microglossary: Controlled terminology resource for
data interchange in biomedical imaging. Methods Inf Med. 37(4-5):404-414.
[BMU07] Bundesministerium für Umwelt, Naturschutz und Reaktorsicherheit (BMU) (2007). Umweltradioaktivität und Strahlenbelastung – Jahresbericht 2006. Bonn: BMU.
http://www.bfs.de/de/bfs/druck/uus/jb06_Gesamtbericht.pdf
[BPR+06] Begelman G, Pechuk M, Rivlin E et al. (2006). System for Computer-Aided Multiresolution Microscopic Pathology Diagnostics. In: IEEE International Conference on Computer Vision Systems (ICVS) 2006.
New York: IEEE, 16.
[BSB+01] Baujard O, Staub JC, Blot D et al. (2001). DICOM and XML: Union makes Strength. In: Lemke
HU et al. (Hrsg.). Computer Assisted Radiology and Surgery (CARS) 2001. Proc. of the 15th International
Congress and Exhibition. Berlin: Elsevier, 820-823.
[Bun06] Bundesärztekammer (2006). (Muster-) Berufsordnung für die deutschen Ärztinnen und Ärzte (Stand
2006).
http://www.bundesaerztekammer.de/downloads/MBOStand20061124.pdf
[BWM03] Bortoluzzi MK, von Wangenheim A, Maximini K (2003). A clinical report management system based
upon the DICOM structured report standard. In: Proc. of the 16th IEEE Symposium on Computer-Based
Medical Systems (CBMS ’03). New York: IEEE, 183-188.
[Bru05] Bruder L (2005). Konvertierung von DICOM-Dateien in eine XML-Transfersyntax. Hochschule Heilbronn: Diplomarbeit am Institut für Verteilte Systeme und Telemedizin.
Seite 118
Literatur
[CDK01] Csipo D, Dayhoff RE, Kuzmak PM (2001). Integrating Digital Imaging and Communications in Medicine (DICOM)-Structured Reporting Into the Hospital Environment. J Digit Imaging. 2001 Jun;14(2 Suppl
1):12-16.
[CEN04] Comité Européen de Normalisation (CEN)/TC 251 (2004). Health informatics – Digital imaging –
Communication, workflow and data management. Europäische Norm EN 12052.
Erhältlich für ca. 45 EUR beim Deutschen Institut für Normung (DIN) unter
http://www.named.din.de/cmd?artid=78015390&level=tpl-art-detailansicht
[CKR93] Cotran RS, Kumar V, Robbins SL (1993). Grundlagen der Allgemeinen Pathologie. Stuttgart-JenaNew York: Gustav Fischer (ISBN 3-437-00677-0).
[Clu00] Clunie D A (2000). DICOM Structured Reporting. Bangor, Pennsylvania: PixelMed Publishing (ISBN
0-9701369-0-0).
Buch vergriffen! Herunterladbar unter http://www.pixelmed.com/srbook.html
[Clu07] Clunie D A (2007). DICOM Structured Reporting and Cancer Clinical Trials Results. Cancer Informatics. 2007;4:33-56.
[DAB+06] Dolin R, Alschuler L, Boyer S et al. (2006). HL7 Clinical Document Architecture, Release 2. J Am
Med Inform Assoc. 2006;13:30-39.
[DHM+06] Durie BG, Harousseau JL, Miguel JS et al. (2006). International uniform response criteria for
multiple myeloma. Leukemia. 2006 Sep;20(9):1467-73.
http://myeloma.org/pdfs/InternationalUniformResponseCriteria.pdf
[DIC05] DICOM Standards Committee (2005). DICOM in XML – Where we’re headed. Budapest: NEMA.
http://medical.nema.org/Dicom/minutes/Committee/2005/2005-09-29/DICOM%20in%20XML.ppt
[DIC07] DICOM Standards Committee (2007). Digital Imaging and Communications in Medicine (DICOM).
CP-730 – Clarify SNOMED coding scheme designators. Final Text. Rosslyn, Virginia: NEMA Standards
Publications.
ftp://medical.nema.org/medical/dicom/final/cp730_ft.pdf
[DIC08a] DICOM Standards Committee (2008). Digital Imaging and Communications in Medicine (DICOM)
PS 3 - 2008. Standard. Rosslyn, Virginia: NEMA Standards Publications.
ftp://medical.nema.org/medical/dicom/2008/
[DIC08b] DICOM Working Group Twenty-Six (Pathology). MINUTES. March 1, 2008. Denver, Colorado:
NEMA.
http://medical.nema.org/DICOM/minutes/WG-26/2008/2008-03-01/WG-26_2008-03-01_Min.doc
[DIC08c] DICOM Standards Committee (2008). Digital Imaging and Communications in Medicine (DICOM).
CP-896 – Eliminate 16 bit row and column image size restrictions. Draft. Rosslyn, Virginia: NEMA Standards Publications.
ftp://medical.nema.org/medical/dicom/CP/cp896_01.pdf
[DIC08d] DICOM Standards Committee (2008). Digital Imaging and Communications in Medicine (DICOM).
CP-897 – Context group included twice. Draft. Rosslyn, Virginia: NEMA Standards Publications.
ftp://medical.nema.org/medical/dicom/CP/cp897_01.pdf
[DIC08e] DICOM Standards Committee (2008). Strategic Document. Version 8.0. Rosslyn, Virginia: NEMA
Standards Publications.
http://medical.nema.org/dicom/geninfo/Strategy.pdf
[DIC08f] DICOM Working Group Six (Base Standard). MINUTES. June 23-26, 2008. Cardiff: NEMA.
http://medical.nema.org/Dicom/minutes/WG-06/2008/2008-06-23/←WG-06 2008-06-23 Min-Rev1.doc
[DMB+82] Deugnier Y, Margules S, Brissot P et al. (1982). Comparative study between biochemical and histological methods and image analysis in liver iron overload. J Clin Pathol. 1982 Jan;35(1):45-51.
http://www.pubmedcentral.nih.gov/picrender.fcgi?artid=497446&blobtype=pdf
[Doi07] Doi K (2007). Computer-Aided Diagnosis in Medical Imaging: Historical Review, Current Status and
Seite 119
Literatur
Future Potential. Comput Med Imaging Graph. 2007;31(4-5):198-211.
[Eic02] Eichelberg M (2002). Ein Verfahren zur Bewertung der Interoperabilität medizinischer Bildkommunikationssysteme. Carl von Ossietzky Universität Oldenburg: Dissertation am Fachbereich Informatik. Aschenberg & Isensee (ISBN 3-89598-852-9).
[Eic07] Eichhorn O (2007). DICOM WG 26: Proposal for Storing Whole-slide Images for Pathology using DICOM. Aperio Technologies.
http://medical.nema.org/Dicom/minutes/WG-06/2007/2007-01-22/←Storing Whole-Slide Images for Pathology.doc
[Eic08] Eichelberg M (2008). Medizinische Bildkommunikation im DICOM- und IHE-Umfeld. Universität zu
Lübeck: Vortrag am 17.1.2008.
[EKM+00] Edwards PJ, King AP, Maurer CR et al. (2000). Design and evaluation of a system for microscopeassisted guided interventions (MAGI). IEEE Trans Med Imaging. 2000 Nov;19(11):1082-93.
[ERK+00] Eichelberg M, Riesmeier J, Kleber K et al. (2000). DICOM Presentation States - ein neuer Dienst für
die digitale Bildverteilung und Softcopy-Befundung. In: Horsch A, Lehmann T (Hrsg). Proc. des Workshops
Bildverarbeitung für die Medizin 2000, Algorithmen, Systeme, Anwendungen. München: Springer (ISBN
3-540-67123-4), 223-227.
[ERS91] Eckstein R, Riess H, Siegert W (1991). Hämatologie – ein Leitfaden für Studierende und Ärzte.
Stuttgart-Berlin-Köln: Kohlhammer (ISBN 3-17-010368-7).
[GCP+07] Giraldez JG, Caversaccio M, Pappas I et al. (2007). Design and clinical evaluation of an imageguided surgical microscope with an integrated tracking system. International Journal of Computer Assisted
Radiology and Surgery. 2007 Feb;1(5):253-264.
[Hac07] Hackländer T. Standardisierte radiologische Befundstruktur und deren Umsetzung in DICOM Structured
Reporting. Vortrag auf der 9. RIS-KIS-PACS-Workshop der AGIT (Arbeitsgemeinschaft IT der Deutschen
Röntgengesellschaft) am 6.7.2007.
http://www.drg.de/data/DOWNLOADS/DICOM_2007/F0930%20Hacklaender%20Radiologie-Report.pdf
[Hea07] Health Level Seven, Inc. Implementation Guide for CDA Release 2 - Diagnostic Imaging Report. Committee Draft for 1st Informative Ballot. Version 0.4.22 vom 16.9.2007. Ann Arbor, Michigan: HL7
http://www.hl7.org/Library/Committees/imagemgt/←DiagnosticImagingReportForCdaRelease2Level1to3V04%2E22%2Edoc
[Hea08] Health Level Seven, Inc. Diagnostic Imaging Report – Universal Realm – Based on HL7 CDA Release
2.0. Draft Standard. Ann Arbor, Michigan: HL7
http://www.hl7.org/Library/Committees/structure/←CDA%20IG%20Diagnostic%20Imaging%20Report%2020080306%20draft%2Edoc
[HES+04a] Hussein R, Engelmann U, Schroeter A et al. (2004). DICOM Structured Reporting – Part 1. Overview and Characteristics. Radiographics. 2004;24:891-896.
[HES+04b] Hussein R, Engelmann U, Schroeter A et al. (2004). DICOM Structured Reporting – Part 2. Problems and Challenges in Implementation for PACS Workstations. Radiographics. 2004;24:897-909.
[HF97] Heckner F, Freund M (1997). Praktikum der mikroskopischen Hämatologie, 9. Auflage. München-WienBaltimore: Urban&Schwarzenberg (ISBN 3-541-01009-6).
[HIJ+08] Hall BH, Ianosi-Irimie M, Javidian P et al. (2008). Computer-assisted assessment of the Human Epidermal Growth Factor Receptor 2 immunohistochemical assay in imaged histologic sections using a membrane isolation algorithm and quantitative analysis of positive controls. BMC Medical Imaging. 2008;8:11.
[Höl06] Hölzer S (2006). Relevanz und Anwendung von SNOMED CT im deutschsprachigen Raum. In: Deutsche
Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie e.V. (gmds). 51. Jahrestagung der
Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie. Leipzig, 10.-14.09.2006.
Düsseldorf, Köln: German Medical Science.
Seite 120
Literatur
[Hor97] Horii SC (1997). A Nontechnical Introduction to DICOM. Philadelphia: Department of Radiology,
University of Pennsylvania Medical Center.
http://www.rsna.org/technology/dicom/intro/index.cfm
[HS92] Hees H, Sinowatz F (1992). Histologie – Kurzlehrbuch der Zytologie und mikroskopischen Anatomie, 2.
Auflage. Köln: Deutscher Ärzte-Verlag (ISBN 3-7691-0257-6).
[IHE08] IHE-International (2008). IHE Pathology Technical Framework (PAT TF). Revision 1.15 – Trial Implementation.
http://www.gmsih.fr/fre/ihe/documents_de_reference/cadre_technique_pathologie
[ISO00] International Organization for Standardization (ISO)/IEC JTC1/SC29 WG1 (2000). ISO/IEC 154441:2000. JPEG 2000 Part I Final Committee Draft Version 1.0.
http://www.jpeg.org/public/fcd15444-1.pdf
Anmerkung: Der offizielle JPEG 2000 Standard ist nicht kostenlos erhältlich, sondern muss als ISO/IEC
15444-1:2004 für etwa 150 EUR bei der ISO gekauft werden:
http://www.iso.org/iso/iso catalogue/catalogue tc/←catalogue detail.htm?csnumber=37674
Die in dieser Arbeit getroffenen Aussagen über JPEG 2000 sind aber so grundsätzlich, dass der Final Draft
als Quelle ausreichen sollte.
[ISO02] International Organization for Standardization (ISO)/IEC JTC1/SC6 (2002). ISO/IEC 8824-2:2002.
Information technology – Abstract Syntax Notation One (ASN.1): Information object specification.
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=35685
(ca. 75 EUR)
[ISO04] International Organization for Standardization (ISO)/TC 215/SC2 (2004). ISO 17432:2004. Health
informatics – Messages and communication – Web access to DICOM persistent objects.
(ca. 60 EUR)
Final Draft unter http://www.kith.no/upload/1770/ISO-DIS-17432.pdf
[ISO06] International Organization for Standardization (ISO)/TC 215 (2006). ISO 12052:2006. Health
informatics – Digital imaging and communication in medicine (DICOM) including workflow and data
management.
(ca. 45 EUR)
[ISO08] International Organization for Standardization (ISO)/TC 215 (2008). ISO/HL7 DIS 27931:2008. Health
informatics – HL7 Messaging Standard Version 2.5 – An application protocol for electronic data exchange in
healthcare environments. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.
htm?csnumber=44428 (ca. 40 EUR)
[ISO97] International Organization for Standardization (ISO)/IEC (1997). ISO/IEC Directives - Part 3: Rules
for the structure and drafting of International Standards.
http://isotc.iso.org/livelink/livelink?func=ll&objId=4230520
[IET01] The Internet Society (2001). Request for Comments: 3066. Tags for the Identification of Languages.
http://www.ietf.org/rfc/rfc3066.txt
[IET06] The Internet Society (2006). Request for Comments: 4627. The application/json Media Type for JavaScript Object Notation (JSON).
http://tools.ietf.org/rfc/rfc4627.txt
[IET99] The Internet Society (1999). Request for Comments: 2616. Hypertext Transfer Protocol – HTTP/1.1.
http://www.ietf.org/rfc/rfc2616.txt
[ITU93] International Telecommunication Union. Recommendation T.81. Information Technology – Digital Compression and Coding of Continuous-Tone Still Images – Requirements and Guidelines (JPEGStandard).
http://www.w3.org/Graphics/JPEG/itu-t81.pdf
[JB03] Jensen T, Baumgartner B (2003). A flexible, multimodality structured reporting system based on medical
Seite 121
Literatur
and networking standards. In: Computer Assisted Radiology and Surgery (CARS) 2003. Proc. of the 17th
International Congress and Exhibition. Amsterdam: Elsevier, 893-899.
[KHZ+05] Kalinski T, Hofmann H, Zwönitzer R et al. (2006). Virtuelle Mikroskopie und digitale Pathologie.
Der Pathologe. 2006;27(3):222-227.
[Klo08] Klocke S (2008). Digitale strukturierte Befunde in der Pathologie – Anwendung zur digitalen Befundung in der Pathologie unter Einbezug von Kodierung und digitaler Aufnahme. Universität zu Lübeck:
Diplomarbeit am Institut für Medizinische Informatik.
[Kod96] Eastman Kodak Company (1996). FlashPix Format Specification Version 1.0.
http://graphcomp.com/info/specs/livepicture/fpx.pdf
[KOV+03] Karssemeijer N, Otten JD, Verbeek AL et al. (2003). Computer-aided Detection versus Independent
Double Reading of Masses on Mammograms. Radiology. 2003 Apr;227(1):192-200.
http://radiology.rsnajnls.org/cgi/reprint/227/1/192.pdf
[KSS+07] Kong J, Sertel O, Shimada H et al. (2007). Computer-Aided Grading of Neuroblastic Differentiation: Multi-Resolution and Multi-Classifier Approach. IEEE International Conference on Image Processing
(ICIP). 2007;5:525-528.
[Lan00] Langlotz CP (2000). Structured Reporting in Radiology. Society for Health Service Research in Radiology, Winter 2000 Newsletter.
http://www.structuredreporting.com/langlotz-article.htm
[Lee02] Lee KP (2002). Expressing DICOM SR constraints in XML. In: Lemke HU et al. (2002). Computer
Assisted Radiology and Surgery (CARS) 2002. Proc. of the 16th International Congress and Exhibition.
Berlin-Heidelberg: Springer, 491-496.
[Lee05] Lee KP (2005). Specifying DICOM semantic constraints in XML. US Patent 6950985.
http://www.patentstorm.us/patents/6950985.html
[LH03] Lee KP, Hu J (2003). XML Schema Representation of DICOM Structured Reporting. J Am Med Inform
Assoc. 2003 Apr;10(2):213-223.
[MBP+07] Malich A, Beier A, Bank P et al. (2007). Inwieweit verbessert der Einsatz eines CAD-Systems
das Prüfungsergebnis bei der Beurteilung einer kassenärztlichen Mammographiefallsammlung? Fortschr
Röntgenstr. 2007;179:53-57.
http://www.thieme-connect.com/ejournals/pdf/roefo/doi/10.1055/s-2006-927199.pdf
[MST+02] Morioka CA, Sinha U, Taira R et al. (2002). Structured Reporting in Neuroradiology. Annals of the
New York Academy of Sciences. 2002 Dec;980:259-266.
[Nou06] Noumeir R (2006). Benefits of the DICOM Structured Report. J Digit Imaging. 2006 Dec;19(4):295-306.
[OLC+05] Ortega L, Ladero JM, Carreras MP et al. (2005). A computer-assisted morphometric quantitative
analysis of iron overload in liver biopsies. A comparison with histological and biochemical methods. Pathol
Res Pract. 2005;201(10):673-677.
[OMO01] OTech Inc., Institute for Microtherapy, Kuratorium OFFIS e.V. (2001). DICOM Conformance Statement – DICOMscope 3.5.
ftp://dicom.offis.de/pub/dicom/offis/software/dscope/dscope351/docs/dscs35.pdf
[Oos05] Oosterwijk H (2005). DICOM Basics. 3rd Edition. Aubrey, Texas: OTech, Inc (ISBN 0-9718867-4-1).
Bezug in Deutschland exklusiv über http://shop.hl7.de/
[Phi97] Philips Medical Systems Nederland B.V. (1997). DICOM Cook Book for Implementations in Modalities –
Chapters 1 and 2.
ftp://ftp.philips.com/pub/pms-3003/DICOM_Information/CookBook.pdf
[Pia08] Pianykh OS (2008). Digital Imaging and Communications in Medicine (DICOM): A Practical Introduction and Survival Guide. Berlin: Springer (ISBN 354074570X).
[PIH07] Pöppl S, Ingenerf J, Hatje H (2007). DICOM-SR-based Representation and Interpretation of Histopathological Findings Obtained Automatically from Microscope Image Processing. In: Fischer B, Nawrath
Seite 122
Literatur
R. Projektantrag CICAD – Center for Imaging and Computer Aided Diagnosis. Universität zu Lübeck,
”
Fachhochschule Westküste, 71-72.
[PPZ06] Pelikan E, Philipps M, Zimmermann S (2006). Teleradiologie-Projekt Südbaden“: DICOM-SR
”
Implementierung und elektronische Signatur für Fragestellung und Therapieempfehlung in Anlehnung an
die nationale Telematikinfrastruktur. Vortrag auf der Telemed 2006.
http://www.telemed-berlin.de/telemed2006/Beitraege/S06%20-%20PELIKAN,%20ERNST%20-%
20Teleradiologie-Projekt.pdf
[Psc98] Pschyrembel W (Begr.), Zink Ch, Hildebrandt H (Hrsg.) (1998). Pschyrembel Klinisches Wörterbuch,
258. Auflage. Berlin: de Gruyter (ISBN 3-11-014824-2).
[REJ+01] Riesmeier J, Eichelberg M, Jendrysiak U et al. (2001). DICOM Structured Reporting auf dem Weg in
die Praxis: Erste Erfahrungen. In: Achter interdisziplinärer Workshop KIS/RIS/PACS, Rauischholzhausen,
2001.
http://www.uniklinikum-giessen.de/kis-ris-pacs/archiv/2001/do1130.pdf
[REK+01] Riesmeier J, Eichelberg M, Kleber K et al. (2001). DICOM Structured Reporting – a Prototype
Implementation. In: Lemke HU et al. (Hrsg.). Computer Assisted Radiology and Surgery (CARS) 2001.
Proc. of the 15th International Congress and Exhibition. Berlin: Elsevier (ISBN 0-444-50866-X), 795-800.
[RGM+06] Rojo MG, Garcı́a GB, Mateos CP et al. (2006). Critical Comparison of 31 Commercially Available
Digital Slide Systems in Pathology. Int J Surg Pathol. 14(4):285-305.
[Rie06] Riesmeier J (2006). Ein generisches Verfahren zur adaptiven Visualisierung von strukturierten medizinischen Befundberichten. Carl von Ossietzky Universität Oldenburg: Dissertation am Department für
Informatik der Fakultät II. Aschenberg & Isensee (ISBN 3-89995-295-2).
[Sch06] Schöch W (2006). Integration terminologischer Softwaredienste zur automatischen Analyse von Verordnungsdaten. Universität zu Lübeck: Studienarbeit am Institut für Medizinische Informatik.
[SIM+98] Sturgis CD, Isoe C, McNeal NE et al. (1998). PAPNET – computer-aided rescreening for detection of
benign and malignant glandular elements in cervicovaginal smears: A review of 61 cases. Diagn Cytopathol.
1998 Apr;18(4):307-311.
[SLM02] Sluis D, Lee KP, Mankovich N (2002). DICOM SR – integrating structured data into clinical information systems. Medica Mundi. 2002;46(2):31-36.
http://www.medical.philips.com/main/news/assets/docs/medicamundi/mm_vol46_no2/sluis.pdf
[SM06] Singhal S, Mehta J (2006). Multiple Myeloma. Clin J Am Soc Nephrol. 2006;1:1322-1330.
[THL02] Tirado-Ramos A, Hu J, Lee KP (2002). Information Object Definition-based Unified Modeling Language Representation of DICOM Structured Reporting. J Am Med Inform Assoc. 2002 Jan/Feb;9(1):63-72.
[Tho92] Thomas C (1992). Histopathologie – Lehrbuch und Atlas für die Kurse der allgemeinen und speziellen
Pathologie, 11. Auflage. Stuttgart-New York: Schattauer (ISBN 3-7945-1460-2).
[Top01] Topley K (2001). Core JFC. Java Foundation Classes, 2nd edition. Prentice Hall International (ISBN
0-13090581-X).
Kapitel 10 The Tree Control: Managing Data with JTree verfügbar unter
http://www.informit.com/articles/article.aspx?p=26327&seqNum=1
[Uni06] Medizinische Fakultät der Otto-von-Guericke-Universität Magdeburg (2006). Neue Technik macht das
Mikroskop überflüssig. Universitätsklinikum Magdeburg aktuell. 2006 Apr;2:4-5.
http://www.med.uni-magdeburg.de/index.php?id=5483&suffix=pdf&nonactive=1&lang=de←&site=unimagdeburg mm
[VBM+08] Veronesi G, Bellomi M, Mulshine JL et al. (2008). Lung cancer screening with low-dose computed tomography: A non-invasive diagnostic protocol for baseline lung nodules. Lung Cancer. 2008 Feb; In
Veröffentlichung.
[VHi06] Verband der Hersteller von IT-Lösungen für das Gesundheitswesen e.V. (VHitG, 2006). Arztbrief auf
Basis der HL7 Clinical Document Architecture Release 2 für das deutsche Gesundheitswesen – Implementierungsleitfaden.
Seite 123
Literatur
http://www.hl7.de/download/documents/cdar2-arztbrief/Leitfaden-VHitG-Arztbrief-v150.pdf
[Wag08] Wagner J (2008). Abbildung von DICOM SR-Dokumenten in HL7 CDA-Dokumente. Universität zu
Lübeck: Ausarbeitung zum Hauptseminar Bildverarbeitung am Institut für Medizinische Informatik, Sommersemester 2008.
[Wen07] Wenz C (2007). JavaScript und AJAX – Das umfassende Handbuch, 7. Auflage. Bonn: Galileo Press
(ISBN 978-3-89842-859-0).
http://www.galileocomputing.de/openbook/javascript_ajax/
[WGC+06] Wu N, Gamsu G, Czum J et al. (2006). Detection of small pulmonary nodules using direct digital
radiography and picture archiving and communication systems. J Thorac Imaging. 2006 Mar;21(1):27-31.
[Win79] Wingert F (1979). Medizinische Informatik. Stuttgart: Teubner (ISBN 3-519-02453-5).
[WJT+07] Wollenweber T, Janke B, Teichmann A et al. (2007). Korrelation zwischen histologischem Befund
und einem Computer-assistierten Detektionssystem (CAD) für die Mammografie. Geburtsh Frauenheilk
2007;67:135-141.
http://www.thieme-connect.de/ejournals/pdf/gebfra/doi/10.1055/s-2006-955983.pdf
[Zha05] Zhao L, Lee KP, Hu J (2005). Generating XML Schemas for DICOM Structured Reporting Templates.
J Am Med Inform Assoc. 2005;12:72-83.
[Zuk05] Zukowski J (2005). The Definitive Guide to Java Swing, 3rd Edition. New York: Springer (ISBN 159059-447-9).
Webseiten
[1] 3DHistech Ltd. PathoNet – Slides by organs.
http://www.pathonet.org/index.php?module=slides-by-organs
[2] Adobe Systems Inc. Installing JSEclipse.
http://www.interaktonline.com/Documentation/JSEclipse/jseclipse.htm#2000_installing.htm
[3] Amazon.com, Inc. Amazon.de.
http://www.amazon.de/
[4] American National Standards Institute (ANSI). ANSI/HL7 CDA-R2 2005 – HL7 Clinical Document Architecture, Release 2.0.
http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI%2FHL7+CDA-R2+2005
[5] The Apache Software Foundation. Apache FOP.
http://xmlgraphics.apache.org/fop/index.html
[6] Aperio Technologies, Inc. Bringing Digital Pathology to Life.
http://www.aperio.com/
[7] Arbeitsgemeinschaft der Wissenschaftlichen Medizinischen Fachgesellschaften (AMWF). Wissenschaftlich
begründete Leitlinien für Diagnostik und Therapie.
http://leitlinien.net/
[8] Art & Science. Was kann die neue Bildarchitektur FlashPix?
http://www.photocd.de/flashpix.htm
[9] Boyd N et al. Rhino: JavaScript for Java.
http://www.mozilla.org/rhino/
[10] Carl Zeiss MicroImaging GmbH. MIRAX Solutions from Carl Zeiss.
http://www.zeiss.de/mirax
[11] Carnegie Mellon University. Sphinx-4 – A speech recognizer written entirely in the Java programming
language.
http://cmusphinx.sourceforge.net/sphinx4/
[12] Centre for Educational Sociology (CES), University of Edinburgh. COSMOS – Cluster Of Systems of
Seite 124
Literatur
Metadata for Official Statistics.
http://www.epros.ed.ac.uk/cosmos/
[13] Chapman J et al. BrowserLauncher2.
http://browserlaunch2.sourceforge.net/
[14] The Clinical Information Consultancy Ltd. CliniClue Software.
http://www.cliniclue.com/software
[15] Clunie D A. David Clunie’s Medical Image Format Site.
http://www.dclunie.com/
[16] Clunie D A. DICOM Information Sources.
http://www.dclunie.com/medical-image-faq/html/part8.html
[17] Clunie D A. DICOM Standard Status – Supplements by Number
http://www.dclunie.com/dicom-status/status.html#SupplementsByNumber
[18] Clunie D A. PixelMed Java DICOM Toolkit.
http://www.pixelmed.com/
[19] Crockford D. Einführung in JSON.
http://json.org/json-de.html
[20] The Cyclops Group. Research on Medical Imaging Software.
http://www.cyclops.ufsc.br/
[21] dc-systeme Informatik GmbH. dc-pathos/ipms – integriertes Pathologie-Management-System.
http://www.dc-systeme.de/Projekt/pathologie.html
[22] Definiens AG. Automated Image Analysis.
http://www.definiens.com/
[23] Deutsche Krebsgesellschaft e.V. Plasmozytom, Morbus Kahler, Multiples Myelom.
http://www.krebsgesellschaft.de/plasmozytom,27478.html
[24] Deutsches Institut für Medizinische Dokumentation und Information (DIMDI). ICD-O-3 – Internationale
Klassifikation der Krankheiten für die Onkologie, 3. Revision.
http://www.dimdi.de/static/de/klassi/diagnosen/icdo3/index.htm
[25] DICOM Standards Committee. Members of the DICOM Standards Committee.
http://medical.nema.org/members.pdf
[26] DICOM Standards Committee. Meeting Minutes. WG-6 (Base Standard).
http://medical.nema.org/Dicom/minutes/WG-06/
[27] DICOM Standards Committee. Procedures for the DICOM Standards Committee.
http://medical.nema.org/Dicom/Geninfo/Procedures.pdf
[28] E & L medical systems GmbH. Clinic WinData.
http://www.eundl.de/live/index.php?id=26
[29] Ecma International. Standard ECMA-262 – ECMAScript Language Specification.
http://www.ecma-international.org/publications/standards/Ecma-262.htm
[30] Erasure Wars Agency. Why Editable Table Cells Are Evil.
http://www.erasurewars.net/editabletablecells/
[31] The FreeBSD Project. FreeBSD Java Project.
http://www.freebsd.org/java/
[32] Fuchs T et al. script.aculo.us.
http://script.aculo.us/
[33] Gatell-Rica F. Java Dicom Buddy.
http://sourceforge.net/projects/jdicom-buddy/
Seite 125
Literatur
[34] Google. Willkommen bei Google Earth.
http://earth.google.de/
[35] Google. Google Web Toolkit.
http://code.google.com/webtoolkit/
[36] Grönemeyer-Institut für Mikrotherapie. Home.
http://www.microtherapy.de/
[37] The GTK+ Team. The GTK+ Project.
http://www.gtk.org/
[38] Haase C. Java on Vista: Yes, it Works.
http://weblogs.java.net/blog/chet/archive/2006/10/java_on_vista_y.html
[39] HAL9000 S.r.l. The Last Supper in Detail.
http://www.haltadefinizione.com/en/
[40] Hamamatsu Photonics Deutschland GmbH. Virtual Microscopy / NanoZoomer.
http://sales.hamamatsu.com/de/produkte/system-division/virtual-microscopy.php
[41] Health Level Seven, Inc. Health Level Seven.
http://www.hl7.org/
[42] heise online. Erstes Entwicklungskit für Open XML von Microsoft.
http://www.heise.de/newsticker/meldung/109299
[43] heise online. Java 6 für Mac OS X 10.5.
[44] heise online. Java Platform Standard Edition in der Version 6 verfügbar.
[45] HL7 Benutzergruppe in Deutschland e.V. Commonly Used UCUM Codes for Healthcare Units.
http://www.hl7.de/download/documents/ucum/ucum.html
[46] HL7 Benutzergruppe in Deutschland e.V. Technische Publikationen (Download-Übersicht).
http://www.hl7.de/publikationen/techdok.php
[47] van Hoff A et al. JmDNS.
http://sourceforge.net/projects/jmdns/
[48] The hsqldb Development Group. hsqldb - 100% Java Database.
http://www.hsqldb.org/
[49] IHE International. IHE Integration Statements.
http://www.ihe.net/Resources/ihe_integration_statements.cfm
[50] IHE International. Welcome to Integrating the Healthcare Enterprise.
http://www.ihe.net/
[51] Institut für Pathologie, Universitätsklinikum Schleswig-Holstein
Präparatekasten Histologie.
http://www.patho.uni-luebeck.de/praepkasten
(UK-SH),
Campus
Lübeck.
[52] International Health Terminology Standards Development Organisation (IHTSDO). SNOMED CT.
http://www.ihtsdo.org/snomed-ct/
[53] International Organization for Standardization (ISO). ISO 3166 code lists.
http://www.iso.org/iso/country_codes/iso_3166_code_lists.htm
[54] jOpenDocument.org. jOpenDocument.
http://www.jopendocument.org/
[55] Kay MH. SAXON – The XSLT and XQuery Processor.
http://saxon.sourceforge.net/
Seite 126
Literatur
[56] Kooperationsgemeinschaft Mammographie in der ambulanten vertragsärztlichen Versorgung GbR.
Mammographie-Screening.
http://www.mammographie-screening.org
[57] Leica Microsystems GmbH. Leica DMD108 – Digital microimaging device for clinical diagnostics labs.
http://www.leica-microsystems.com/WebSite/products.nsf/(ALLIDs)/←E972BA615AB8879EC12571D3004956AA
[58] Library of Congress. Codes for the Representation of Names of Languages. Downloadable text files.
http://www.loc.gov/standards/iso639-2/ascii_8bits.html
[59] Liu J. ZK vs. GWT : Server-Centric Matters!.
http://www.zkoss.org/smalltalks/gwtZk/
[60] Lyons M. Breaking the Gigapixel Barrier.
http://www.tawbaware.com/maxlyons/gigapixel.htm
[61] Malaterre M et al. Grass roots DiCoM (GDCM).
http://gdcm.sourceforge.net/wiki/index.php
[62] Malaterre M et al. Patching OpenOffice.org.
http://gdcm.sourceforge.net/wiki/index.php/Module_Attributes#Patching_OpenOffice.org
[63] The MARF Research and Development Group. MARF, The Modular Audio Recognition Framework, and
its Applications.
http://marf.sourceforge.net
[64] Medical Connections Ltd. DicomObjects Wiki – Basic DICOM Operations.
http://www.medicalconnections.co.uk/wiki/Basic_DICOM_Operations
[65] MEDNOVO Medical Solutions Software GmbH. MediColor - Überblick.
http://www.mednovo.de/produkte/software-fuer-krankenhaeuser/medicolor/ueberblick/
[66] medPACS GmbH.
http://www.medpacs.de/
[67] Metzmacher D. AJAX-Bibliotheken und -Frameworks - Teil 1.
http://www.drweb.de/programmierung/ajax-frameworks.shtml
[68] MHGS. DICOMpedia
(Nachschlagen von DICOM-Attributen und -UIDs)
http://www.dicom-solutions.com/dicompedia.shtm
[69] Microsoft Corp. Microsoft Office Binary (doc, xls, ppt) File Formats.
http://www.microsoft.com/interop/docs/OfficeBinaryFormats.mspx
[70] Microsoft Corp. Microsoft Virtual Earth: The Integrated Mapping, Imaging, Search, and Location Platform.
http://www.microsoft.com/virtualearth/
[71] Microsoft Corp. MSDN Library – Component Object Model.
http://msdn.microsoft.com/en-us/library/aa286559.aspx
[72] Milne P et al. TableRowSorter – a decorator for TableModels; adding sorting functionality to a supplied
TableModel.
http://www.devdaily.com/java/jwarehouse/hsqldb/src/org/hsqldb/util/←TableSorter.java.shtml
[73] National Electrical Manufacturers Association (NEMA). DICOM Homepage.
http://dicom.nema.org/
[74] NEXUS AG. NEXUS / PATHOLOGIE.
http://www.nexus-ag.de/web/0/inter/index.php?act=art&act2=show&←art id=dc 2007 06 21 9cb8f503c6b85d77ff
[75] Niemeyer P. BeanShell – Lightweight Scripting for Java.
http://www.beanshell.org/
Seite 127
Literatur
[76] Nikon Instruments Europe B.V. Products – Digital Pathology.
http://www.nikoninstruments.eu/digital_pathology/
[77] Novell, Inc. Mono Gui Toolkits.
http://www.mono-project.com/Gui_Toolkits
[78] Novell, Inc. Mono Project Roadmap.
http://www.mono-project.com/Mono_Project_Roadmap
[79] O’Conner J. Scripting for the Java Platform.
http://java.sun.com/developer/technicalArticles/J2SE/Desktop/scripting/
[80] O’Conner J. Using the Desktop API in Java SE 6.
http://java.sun.com/developer/technicalArticles/J2SE/Desktop/javase6/desktop_api/
[81] Object Management Group, Inc. Clinical Observations Access Service, version 1.0.
http://www.omg.org/technology/documents/formal/clinical_observation_access_service.htm
[82] OFFIS e. V. DCMTK – DICOM-Toolkit.
http://dicom.offis.de/dcmtk.php.de
[83] OFFIS e. V. DICOMscope – DICOM-Viewer.
http://dicom.offis.de/dscope.php.de
[84] Olympus America Inc. About Bacus Labratories, Inc..
http://www.olympusamerica.com/seg_section/seg_vm.asp
[85] Olympus Deutschland GmbH. dotSlide – Virtuelles Slide-System.
http://www.olympus.de/microscopy/22__slide.htm
[86] Olympus Soft Imaging Solutions GmbH. Slide Gallery.
http://dotslide.olympus-sis.com/
[87] OpenOffice.org. Writer.
http://de.openoffice.org/product/writer.html
[88] OTech, Inc. PACS, DICOM, & HL7 Training and Consulting.
http://www.otechimg.com/
[89] Philips Electronics N.V. Digital Radiography – CAD Chest.
http://www.medical.philips.com/main/products/xray/products/radiography/cad%5Fchest/
[90] Pilafian D. Bare Bones Browser Launch for Java.
http://www.centerkey.com/java/browser/
[91] Pobst J. Code Monkey: The Big Finale.
http://jpobst.blogspot.com/2008/05/big-finale.html
[92] Potix Corp. ZK.
http://www.zkoss.org/product/zk.dsp
[93] Prototype Core Team. Prototype JavaScript framework: Easy Ajax and DOM manipulation for dynamic
web applications.
http://www.prototypejs.org/
[94] Reed Business Information Ltd. New Scientist Invention Blog: Wide-angled gigapixel satellite surveillance.
http://www.newscientist.com/blog/invention/2007/09/wide-angled-gigapixel-satellite.html
[95] Regenstrief Institute, Inc. LOINC Downloads.
http://loinc.org/downloads
[96] Regenstrief Institute, Inc. UCUM – The Unified Code for Units of Measures.
http://www.regenstrief.org/medinformatics/ucum
[97] Santesoft. Sante DICOM HEXViewer.
http://www.santesoft.com/hexviewer.html
Seite 128
Literatur
[98] Schöch W. Diploma thesis Using DICOM SR in Pathology“. (Begleithomepage zu dieser Diplomarbeit)
”
http://www.schoech.de/diploma/
[99] Schöch W. List of DICOM Toolkits for Various Programming Languages.
http://www.schoech.de/diploma/toolkits.html
[100] Siemens AG. Software erkennt Lungenkrebs schon im Frühstadium.
http://a1.siemens.com/innovation/de/news_events/innovationnews/innovationnews-meldungen/
medizin/software_erkennt_lungenkrebs_schon_im_fruehstadium.htm
[101] Siemens AG. Digitale Gutachter verbessern Krebsvorsorge.
http://a1.siemens.com/innovation/de/news_events/innovationnews/innovationnews-meldungen/
medizin/digitale_gutachter_verbessern_krebsvorsorge.htm
[102] Simon listens. simon – open-source speech recognition.
http://www.simon-listens.org
[103] Smart J et al. wxWidgets Cross-Platform GUI Library.
http://www.wxwidgets.org/
[104] Sun Microsystems, Inc. Java 3D Downloads: Release Builds.
https://java3d.dev.java.net/binary-builds.html
[105] Sun Microsystems, Inc. Java DB at a Glance.
http://developers.sun.com/javadb/
[106] Sun Microsystems, Inc. The Java Tutorials. Creating a GUI with JFC/Swing.
http://java.sun.com/docs/books/tutorial/uiswing/
[107] Sun Microsystems, Inc. The Java Tutorials. Internationalization.
http://java.sun.com/docs/books/tutorial/i18n/
[108] Sun Microsystems, Inc. OpenJDK.
http://openjdk.java.net/
[109] Sun Microsystems, Inc. scripting.
https://scripting.dev.java.net/
[110] Sun Microsystems, Inc. Scripting for the Java Platform.
http://java.sun.com/javase/6/docs/technotes/guides/scripting/index.html
[111] Sun Microsystems, Inc. & Contributors: SwingLabs Sub Projects.
http://swinglabs.org/projects.jsp
[112] Systems Pathology Company (SPC), LLC. Products.
http://www.systemspath.com
[113] Topologi Pty. Ltd. Schematron – A language for making assertions about patterns found in XML documents.
http://www.schematron.com/
[114] Trochim WMK. Research Methods Knowledge Base – Types Of Questions.
http://www.socialresearchmethods.net/kb/questype.php
[115] Trolltech. Qt Cross-Platform Application Framework.
http://trolltech.com/products/qt
[116] Trygve Reenskaug. MVC.
http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
[117] U.S. National Library of Medicine (NLM) and National Institute of Health (NIH). PubMed Home.
http://www.ncbi.nlm.nih.gov/pubmed/
[118] Windoffer R, Leube R (Institut für Anatomie und Zellbiologie, Universität Mainz). Mainzer Histo Maps.
http://www.mhm.uni-mainz.de/
[119] World Wide Web Consortium (W3C). The XMLHttpRequest Object.
Seite 129
Literatur
http://www.w3.org/TR/XMLHttpRequest/
[120] World Wide Web Consortium (W3C). Document Object Model (DOM).
http://www.w3.org/DOM/
[121] xRez Studio. Extreme Resolution – Large-Scale Panoramic Image Creation.
http://www.xrez.com/
[122] Yahoo Inc. Yahoo! Design Pattern Library.
http://developer.yahoo.com/ypatterns/index.php
[123] Yahoo Inc. Yahoo! User Interface Library (YUI).
http://developer.yahoo.com/yui/
[124] Zeilinger G et al. dcm4che – Open Source Clinical Image and Object Management.
http://www.dcm4che.org/
Bilder
[125] Kollage IT-Landschaft im Krankenhaus“ (Abb. 7)
”
CT: http://www.uniklinikum-giessen.de/radiologie/comptomoen.html
C-Bogen, Ultraschall:
http://www.tierklinik-ludwigsburg.de/Leistungen02_TechnAusstattung.htm
Röntgen: http://www.radiology-equipment.com/detail.CFM?LineItemID=1456
SPECT, Mammographie-Röntgen: http://www.do-radiology.de/
RIS: http://www.dc-systeme.de/Projekt/diktat_p.html
PDMS: http://www.medical.siemens.com/siemens/de DE/gg hs FBAs/files/PLM-FE-MI/←Brochure-m-PDM-2005-08.pdf
Mamma-MRT-Bild: http://www.charite.de/rv/str/patinfo/mamma/mamma-mrt/index.php
Röntgenbild, Szintigraphie: http://www.journalonko.de/aktuellview.php?id=1038
MRT-Bild: http://www.kup.at/journals/abbildungen/gross/321.html
Angiographie: http://commons.wikimedia.org/wiki/←Image:Cerebral angiography, arteria vertebralis sinister injection.JPG
Befundungsmonitor: http://www.dimedtec.com/←3 Megapixel Graustufen Befundmonitore nach DIN 6868-57~~57.aspx
(Seite nicht mehr erreichbar)
Röntgenfilmbelichter: http://pw.carestreamhealth.com/en/global/en/health/←productsByType/mps/eqp/dry/dv6800.jhtml.htm
[126] Kamiyamane Y. Icons für die Einträge im DICOM-SR-Baum (Creative Commons Attribution 3.0 license).
http://www.pinvoke.com/
Seite 130

Einsatz von DICOM-SR in der Pathologie

Transcription

Similar documents

Diplomarbeit fuer Vortragsthema 15 (e-hoi)

Leseprobe

Programmhandbuch

Thema: Spiele (Inhalte/Narration)

Classroom Management in der Schuleingangsstufe

Anleitung zur HWPh-CD-ROM (PDF-Datei) - HWPh