Marco Eichelberg (a), Jörg Riesmeier (a), Thomas Wilkens (a), Peter Jensch (b)

a OFFIS e.V., Escherweg 2, 26121 Oldenburg
b Carl von Ossietzky Universität Oldenburg, Department für Informatik, 26111 Oldenburg


Zusammenfassung

Im Jahre 2003 feierte der DICOM-Standard seinen zehnten Geburtstag. Neben dem Standard selbst wurde in demselben Jahr auch das OFFIS Open-Source DICOM-Toolkit DCMTK, das der Entwicklung von DICOM stetig folgte, zehn Jahre alt. Dieser Artikel blickt auf die wichtigsten Standardisierungsbemühungen in DICOM zurück und illustriert die entsprechenden Software-Entwicklungen in DCMTK. Bei der Entwicklung des DICOM-Standards lassen sich verschiedene Phasen des Fortschritts unterscheiden. In der ersten Phase zu Beginn der 90er Jahre wurden allgemeine Netzwerk-Dienste zur Bildübertragung und zur Bildabfrage eingeführt. Die zweite Phase in der Mitte der 90er Jahre war gekennzeichnet durch die Spezifi kation eines Dateiformates und die Einführung von Regeln zum Datenträgeraustausch. In einer dritten Phase behandelte DICOM vornehmlich das Problem der Workfl ow-Optimierung in Abteilungen mit Bild gebenden Modalitäten. In einer vierten Phase am Ende der 90er Jahre wurden Bemühungen hinsichtlich der Konsistenz der Bilddarstellung vorangetrieben. Derzeit werden Sicherheitserweiterungen in den Standard integriert. Parallel dazu wird seit Jahren die Entwicklung von DICOM „Structured Reporting“ vorangetrieben, einem Format für den Austausch strukturierter Messdaten und Befunde.

1 Einleitung

Im Jahre 2003 feierte der DICOMStandard (Digital Imaging and Communications in Medicine, [1]) seinen zehnten Geburtstag. Neben dem Standard selbst wurde in demselben Jahr auch das OFFIS Open-Source DICOM-Toolkit DCMTK [2], das der Entwicklung von DICOM seit seiner Entstehung stetig folgt, zehn Jahre alt. Dies soll Anlass sein, auf die wichtigsten Standardisierungsbemühungen in DICOM zurückzublicken und die entsprechende Entwicklung in DCMTK aufzuzeigen.

Im Laufe der letzten 10 Jahre wurden zahlreiche Erweiterungen des DICOMStandards verabschiedet, die den Umfang des Standards von 750 auf mehr als 2100 Seiten ansteigen ließen. Dies spiegelt nicht nur die ständig steigende Komplexität von Modalitäten und IT-Systemen im Gesundheitswesen wider, sondern ergibt sich auch daraus, dass der DICOM-Standard selbst seinen Anwendungsbereich erheblich erweitert hat. Zu Beginn der 90er Jahre waren Computernetze noch ein relativ neues Konzept für das Gesundheitswesen, mit dem die Idee eines digitalen radiologischen Bildarchivs (PACS, Picture Archiving and Communication Systems) endlich realisierbar erschien. Ziel der ersten Standardisierungsbemühungen in DICOM war, einen digitalen Versand verschiedener medizinischer Bilder zu einem zentralen Empfänger zu ermöglichen, damit herstellerunabhängige Bildarchive entwickelt werden konnten. Bilder sollten auf verschiedenen Befundungsstationen darstellbar sein, Modalitäten und Drucker sollten über ein Netzwerk voneinander entkoppelt werden. Nach einigen Jahren der Entwicklung durfte das Problem der Bildübertragung auf Transportebene als gelöst gelten. Es stellte sich aber heraus, dass ein funktionierendes PACS-System mehr als dies benötigte. Ein Konzept zur Workfl ow-Unterstützung war erforderlich, und wurde zwischen 1996 und 1998 durch neue DICOM-Dienste wie das „Worklist Management“ und „Modality Performed Procedure Step“ (MPPS) realisiert. Es zeigte sich auch, dass ein und dasselbe Bild, wenn es auf zwei verschiedenen Befundungsstationen dargestellt oder auf zwei verschiedenen Druckern ausgedruckt wurde, sehr unterschiedlich aussehen konnte. Ein Kalibrierungsmodell für Monitore und Drucker wurde benötigt – und unter der Bezeichnung „Grayscale Standard Display Function“ entwickelt. Andere Erweiterungen beschäftigten sich mit Datensicherheitsfragen, der Befunderstellung und dem Austausch von Speichermedien, was etwa in der Kardiologie sehr populär ist. Ein Thema, das DICOM von Beginn an verfolgt hatte und das bis heute immer noch nicht allgemein gelöst werden konnte ist das Thema der Konformität. Als sehr komplexe technische Spezifi kation bietet DICOM eine Menge Raum für Implementierungsfehler und Missverständnisse. Durch Software-Werkzeuge für Konformitätstests und durch organisatorische Ansätze, wie etwa herstellerübergreifende Testveranstaltungen, wurde versucht, diese Problematik zu lösen; als eine der wichtigsten Initiativen ist in diesem Zusammenhang „Integrating the Healthcare Enterprise“ (IHE) zu nennen.

Betrachtet man die Entwicklung des DICOM-Standards unter dem Gesichtspunkt der Funktionalität, lassen sich verschiedene Phasen des Fortschritts ausmachen. Da mehrere Arbeitsgruppen parallel an neuen Methoden und Konzepten arbeiteten, traten diese Phasen nicht in einer strengen chronologischen Reihenfolge auf. Nichtsdestotrotz orientiert sich die folgende Beschreibung der Entwicklung des Standards und des OFFIS DICOMToolkits an den oben genannten Phasen.

2 DICOM-Netzwerke und die Central Test Nodes

Im April 1993 entschied die Arbeitsgruppe Medizinische Informatik des Europäischen Komitees für Normung (CEN/TC 251), durch das Sponsoring einer Open-Source-Referenzimplementierung die Standardisierungsbemühungen um den angehenden DICOM-Standard zu unterstützen. Ziel der Maßnahme war es, die Software nach ihrer Fertigstellung auf dem jährlichen Treffen des amerikanischen Radiologenverbandes RSNA zu präsentieren.

Die Software-Entwicklung wurde von OFFIS, der Universität Oldenburg (Niedersachsen) und der CERIUM-Forschungsgruppe der Universität Rennes (Frankreich) ausgeführt. Parallel zu der europäischen Entwicklung wurde vom Mallinckrodt Institute of Radiology in den USA ebenfalls eine Open-Source- Implementierung vorangetrieben, die später als “Mallinckrodt CTN” (Central Test Node) Toolkit bekannt wurde [3]. Auf dem RSNA-Treffen von 1993 wurde auf der Basis der beiden als Bildarchiv agierenden Referenzimplementierungen ein 20 Hersteller umfassendes DICOMPilotnetzwerk aufgebaut. Abbildung 1 zeigt das funktionale Konzept dieser Demonstration, die auf mehreren anderen Veranstaltungen wiederholt wurde. Alles in allem dienten diese öffentlichen Demonstrationen zweierlei Zwecken: Auf der einen Seite wurde die Benutzergemeinde über die aktuelle Standardisierungsarbeit und über die sich durch DICOM bietenden Möglichkeiten informiert, auf der anderen Seite wurden die ersten herstellerübergreifenden Implementierungen des neuen Standards intensiv getestet. Alle Hersteller waren an die Central Test Nodes angeschlossen. In den Bildarchiven waren unterschiedliche Speicherzonen vorgesehen: Eine Speicherzone, auf die nur lesend zugegriffen werden konnte, enthielt eine Sammlung von Beispielbildern, die zuvor von allen teilnehmenden Herstellern zur Verfügung gestellt worden waren, eine Speicherzone bot Lese- und Schreibrechte für alle Systeme aller Hersteller an und jeweilige private Speicherzonen gewährten Lese- und Schreibzugriffe für die einzelnen Systeme der teilnehmenden Hersteller. Alles in allem kann die RSNA-Demonstration von 1993 als sehr erfolgreich angesehen werden; die Nachricht, dass der DICOM-Standard wirklich funktioniert, wurde der Besucherschaft eindrucksvoll präsentiert. Nach 1993 erschienen nach und nach die ersten Medizinprodukte mit einer DICOM-Basisfunktionalität, die der auf den Kongressen vorgestellten Funktionalität sehr ähnlich war...

Dokumentinformationen zum Volltext-Download
 

 
Rechtlicher Hinweis:

Ein Herunterladen des Dokuments ist ausschließlich  zum persönlichen Gebrauch erlaubt. Jede Art der Weiterverbreitung oder Weiterverarbeitung ist untersagt.