Wir feiern den Standard

Nicht nur VISUS feiert in diesem Jahr einen wichtigen Geburtstag, sondern auch zwei der treuesten Wegbegleiter des Unternehmens: DICOM und IHE. DICOM hat mittlerweile 25 Jahre auf dem Buckel, IHE immerhin schon 20. Ein guter Grund, um einmal auf die Anfänge und auch die Erfolgsfaktoren beider Institutionen zu blicken. Einer, der sich seit den Anfängen mit beiden Regelwerken beschäftigt, ist Dr. Jörg Riesmeier, heute freiberuflicher Berater und Software-Entwickler. Ganz nebenbei ist er auch eng mit VISUS verbunden und an dem Vorläufer von JiveX nicht ganz unbeteiligt.

Herr Riesmeier, vorab die Frage: Was verbindet Sie mit VISUS?

Ich habe viele Jahre bei OFFIS gearbeitet, einem Forschungsinstitut für angewandte Informatik, das aus der Universität Oldenburg hervorgegangen ist. Noch bevor der DICOM-Standard 1993 in einer ersten Fassung veröffentlicht wurde, war OFFIS an einer prototypischen Implementierung im Auftrag der NEMA, der Herausgeberin des Standards, beteiligt. Die dabei entstandene Software wurde in den Folgejahren zu einem DICOM-Toolkit, dem heutigen DCMTK, weiterentwickelt. Gerade in der Anfangszeit hatte die hinter dem Standard stehende Industrie großes Interesse daran, DICOM auf seine Praxistauglichkeit hin zu überprüfen und die Ergebnisse der Fachöffentlichkeit zu präsentieren. So gab es über die Jahre zahlreiche weitere Ausschreibungen zur Entwicklung von prototypischen Implementierungen zu ganz unterschiedlichen Themen. Eines davon war die konsistente Bilddarstellung, verbunden mit den sogenannten Softcopy Presentation States. Konkret ging es darum, dass radiologische Bilder auf verschiedenen Monitoren und Druckern vergleichbar dargestellt werden sollten. Und darum, dass die Einstellungen, die der Radiologe im Rahmen der Befundung am Bild vorgenommen hatte – Graustufenfensterung, grafische und textuelle Annotationen etc. – nicht verloren gingen, sobald die Daten auf einem anderen Arbeitsplatz aufgerufen wurden. Wir bei OFFIS kannten uns zwar gut mit DICOM und der Visualisierung medizinischer Bilder aus, nicht aber mit der Entwicklung von grafischen Benutzungsoberflächen.

Und da kamen Klaus Kleber und Jörg Holstein ins Spiel, die zu dieser Zeit beim Institut für Mikrotherapie bei Prof. Dr. Dietrich Grönemeyer in Bochum an einer Java-basierten Benutzungsoberfläche für medizinische Anwendungen arbeiteten. Also bewarben wir uns gemeinsam um das Projekt und haben die Ausschreibung dann auch gewonnen. Die Software, die wir 1999 erstmals auf dem ECR in Wien und anschließend auf der RSNA in Chicago vorstellten, hieß DICOMscope – und rückblickend betrachtet kann man sicherlich sagen, dass es ein Vorläufer des heutigen JiveX war.

Sie sind also ein echter DICOM-Pionier und haben mit dafür gesorgt, dass der Standard in die Praxis kommt. Und da ist er nun seit 25 Jahren. Was hat sich in dieser Zeit alles getan?

Einiges. Das DICOM-Regelwerk umfasste zu Beginn gut 750 Seiten, heute sind es mehr als 6.000. Da liegt es auf der Hand, dass man sich in das Thema nicht mal eben so einlesen kann. Wenn man allerdings von Beginn an dabei war und am Ball geblieben ist, kann man sich wohl guten Gewissens als Experte bezeichnen. Die zahlreichen Neuerungen, die die Seiten über die Zeit gefüllt haben, sind ganz unterschiedlicher Natur. Eine große Erweiterung war Ende der 1990er-Jahre die eben genannte Bildkonsistenz mit den Presentation States. In den vergangenen 15 bis 20 Jahren hat sich aber auch der Anwendungsbereich des Standards enorm vergrößert. Anfänglich ging es nur um den herstellerübergreifenden Austausch von radiologischen Bildern. Später kamen die Bereiche Kardiologie, Strahlentherapie, Ophthalmologie, Chirurgie usw. hinzu. Parallel dazu wurden auch Datenstrukturen für Signaldaten und medizinische Befundberichte definiert. Seit vielen Jahren besteht zudem der Trend, immer weitere Teile des gesamten Workflows in einer Gesundheitseinrichtung abzubilden und zu automatisieren – nicht nur innerhalb der Einrichtungsmauern, sondern auch darüber hinaus. Und genau an diesem Punkt kommen die Spezifikationen der IHE ins Spiel, weil DICOM beim einrichtungsübergreifenden Austausch medizinischer Dokumente an bestimmte Grenzen stößt.

Was ist das Erfolgsgeheimnis von DICOM? Immerhin ist der Standard heute alternativlos, Gegenkonzepte sind weit und breit nicht in Sicht.

Um das zu verstehen, muss man einen Schritt zurückgehen, zum DICOM-Vorläufer, dem sogenannten ACR-NEMA-Standard. Dieser Ansatz stammt noch aus den 1980er-Jahren, als der Wunsch aufkam, Bilder von Großgeräten – also CT und MRT – auf ein anderes Gerät zu übertragen, um sie dort betrachten zu können. Schon damals hatten die Anwender ein Auge darauf, sich nicht von den Herstellern dieser Geräte abhängig zu machen. Allerdings war dieser Standard in einigen Punkten zu ungenau und ließ zu viel Gestaltungsspielraum bei der Umsetzung, sodass sich unter den Herstellern „Dialekte“ ausbildeten, die nicht von allen verstanden wurden. Und auch die Hersteller hatten ein Interesse an einer Vereinheitlichung, schließlich blieben ihre Geräte sehr lange im Einsatz und produzierten Daten, die mitunter bis zu 30 Jahre archiviert und damit lesbar gehalten werden müssen. Vor diesem Hintergrund entstand dann der DICOM-Standard, der zwar einige grundlegende Konzepte von ACR-NEMA übernahm, aber doch aus dessen Fehlern lernte. Diese Entwicklung war sowohl von Anwendern als auch von der Industrie getrieben.

Aus heutiger Sicht mögen die Konzepte hinter DICOM vielleicht etwas altbacken erscheinen und man sieht ihnen teilweise an, dass sie im Kern aus den 1980er/90er-Jahren stammen. Aber sie funktionieren immer noch hervorragend. Aus Sicht der Industrie gibt es überhaupt keinen Grund, daran etwas zu ändern. Schließlich haben sie jahrzehntelange Entwicklungsarbeit in DICOM und dessen Umsetzung gesteckt.

Aber in der IT gab es doch sehr lange auch das gegenteilige Konzept der proprietären Lösungen, das auch durchaus erfolgreich war.

Vor allem große Firmen wollten natürlich am liebsten alles aus einer Hand verkaufen – und wollen es vermutlich auch heute noch. Tatsächlich konnten große Hersteller bis vor einigen Jahren aufgrund ihrer Größe unter Umständen noch eigene Standards setzen. Das funktioniert aber aus zwei Gründen nicht mehr. Erstens gibt es gar nicht mehr diese marktbeherrschenden Unternehmen, an denen niemand vorbeikommt. Und zweitens lassen sich die Kunden nicht mehr auf solche Ansätze ein, weil Kosten- und Erfolgsdruck sie zwingen, von allem die beste Lösung einzusetzen. Und das geht nur, wenn ein System auf etablierte Standards setzt.

Bei den IHE-Profilen sieht die Sache etwas anders aus, sie werden nicht so zwingend eingesetzt wie der DICOM-Standard. Woran liegt das?

Es gibt ja viele unterschiedliche IHE-Domänen und die jeweiligen Profile sind sicherlich unterschiedlich erfolgreich. Aber nehmen wir die XDS-Profile für den einrichtungsübergreifenden Dokumentenaustausch. Diesen Prozess haben die Einrichtungen innerhalb von Verbünden oder Netzwerken seit Jahren selbst geregelt – sei es über Datenträger, VPN-Verbindungen oder per E-Mail. Das Interesse, die bestehende Infrastruktur zu ändern, also einen gut etablierten Prozess komplett neu aufzusetzen, ist nicht immer groß. Es müssen daher schon deutliche Vorteile mit einer Umstellung auf einen IHE-basierten Prozess einhergehen.

Ein weiterer Punkt ist dieser: Papier ist geduldig und manchmal wartet man vergeblich darauf, dass etwas Geschriebenes in der Praxis zum Leben erwacht. Bei IHE sind solche Karteileichen nicht so selten wie etwa bei DICOM. Vielleicht auch deshalb, weil die Anwendungsfälle nicht immer aus der Praxis kommen, sondern manchmal auch durch die Wissenschaftsbrille oder am grünen Tisch entwickelt werden. Bei IHE XDS ist dies sicherlich nicht der Fall. Das zeigt auch der Einsatz auf nationaler Ebene in unseren Nachbarländern Österreich und Schweiz, die IHE verpflichtend für die digitalen Akten bzw. Dossiers einsetzen.

Was ist denn das Erfolgsrezept eines guten Standards?

Der Standard muss frei zugänglich sein. Sowohl die Spezifikation von DICOM als auch HL7 war zu Beginn noch kostenpflichtig. Das hat sich dann aber geändert, bei DICOM sogar deutlich früher als bei HL7. Und so bekamen auch kleine, innovative Unternehmen die Chance, die Standards kostenfrei zu nutzen. Häufig müssen sie auch nicht bei null anfangen, sondern können eines der ebenfalls frei verfügbaren Toolkits verwenden. Daneben muss der Anwender einen wirklichen Nutzen, eine Verbesserung erkennen, die mit einem Standard einhergeht, da derartige Schnittstellen nicht selten aufpreispflichtig sind. Und schließlich muss die Industrie dahinterstehen. Man darf nicht vergessen: Die Unternehmen müssen Mitarbeiter abstellen, die sehr viel Ahnung von den Themen haben und die technischen Spezifikationen aus wirtschaftlicher und praktischer Sicht weiterentwickeln.