XDS-I
Dieses Material ist Teil des Leitfadens IHE Cookbook.
|
Inhaltsverzeichnis
Das XDS-I Profil
Das XDS-Profil ist „content agnostic" – es lassen sich alle möglichen Dokumentenformate austauschen, seien es PDF-Dateien oder (theoretisch) sogar proprietäre Formate wie Microsoft Word-Dokumente. Nun ist es jedoch sinnvoll, je nach Dokumenttyp zusätzliche Regeln (sog. Content Profiles) oder sogar zusätzliche Akteure und Transaktionen festzulegen. Genau dieser Weg wurde auch beschritten, um XDS für den Austausch medizinischer Dokumente im DICOM-Format (DICOM-Objekte wie Bilder) zu erweitern. Dieser Abschnitt beschreibt das von IHE dazu bereitgestellte Profil XDS-I (XDS for Imaging). Seit einiger Zeit besteht eine geringfügig weiter entwickelte Variante von XDS-I mit dem Namen XDS-I.b. Alle folgenden Erläuterungen beziehen sich auf diese noch nicht offiziell verabschiedete, jedoch zum Testen bereits freigegebene Spezifikation (Status: „For Trial Implementation").
Akteure und Transaktionen
XDS-I beschreibt keinen Ersatz für XDS, sondern definiert eine Erweiterung von XDS zur Verwaltung von DICOM-Objekten. Für den überwiegenden Teil der XDS-Akteure und Transaktionen ändert sich nichts. Die nachfolgende Abbildung zeigt die geänderten Transaktionen in orangefarbener Kursivbeschriftung. Eine XDS-I-spezifische Variante des Akteurs „Document Source" trägt die Bezeichnung „Image Document Source". Dieser Akteur hat zum einen spezielle Anforderungen an das Veröffentlichen der Dokumente zu erfüllen (Transaktion RAD-68), zum anderen einen Teil der Bilddaten selbst für den Abruf zur Verfügung zu stellen (RAD-55, RAD-69, RAD-16, RAD-17, RAD-31, RAD-45). Um die Bilddaten vom „Image Document Source" abzurufen, wird der Akteur „Image Document Consumer" benötigt, der mit dem XDS Document Consumer gruppiert ist.
Einstellen von DICOM-Objekten
Bilder (und andere DICOM-Objekte) belegen viel Speicherplatz. Zudem sind bei weitem nicht alle Bilder zum Austausch mit anderen Institutionen interessant. Vielmehr wird häufig nur ein Bruchteil verwendet, wie z. B. die befundrelevanten Bilder. Da der Consumer (bzw. dessen Benutzer) unter Umständen nicht im Vorfeld entscheiden kann, welche Bilder denn relevant sind, sollte möglichst eine Vorauswahl getroffen werden, damit nicht alle Bilder für eine XDS-Übertragung bereitgehalten oder gar übermitteln werden müssen. Aus diesen Überlegungen heraus wurde für XDS-I die Entscheidung getroffen, alle Bilder bei der Quelle zu belassen (d. h. üblicherweise im DICOM-Bildarchiv der Einrichtung) und nur eine Auswahl von Bildern überhaupt in der XDS Affinity Domain zu veröffentlichen.
Statt also Bilder an das Document Repository zu übertragen, wird von der Imaging Document Source ein sogenanntes Key Object Selection (KOS) Dokument erstellt und mit der Transaktion „Provide and Register Document Set – MTOM/XOP" (RAD-68) an das Repository zum Speichern versendet. Dieses spezielle DICOM-Dokument enthält nur Verweise auf die bei der Source bereitstehenden, relevanten DICOM-Bilder. Das Document Repository speichert ein solches DICOM-Objekt wie jedes andere Dokument und leitet die Meta-Informationen (in erster Linie Patienten- und Dokumentenkennung) an die Registry weiter.
Die Imaging Document Source speichert also im Gegensatz zur Document Source im normalen XDS-Profil gezwungenermaßen alle Dokumente (hier: DICOM-Bilder) selbst und teilt zunächst über die Registry mit den XDS-Partnern ausschließlich ein DICOM KOS-Dokument, das eine Auswahl von Bildern (genauer: Referenzen auf diese) zusammenstellt. Im Vergleich zum XDS-Profil benötigt also die (Image) Document Source in XDS-I besondere (DICOM-)Fähigkeiten zum Einstellen von Bildern. Registry und Repositories verlangen dagegen keine speziellen Anpassungen, müssen aber ggf. konfiguriert werden, um DICOM als Dokumententyp zu akzeptieren.
Herunterladen von DICOM-Objekten
Möchte ein Consumer DICOM-Bilder zu einem Patienten einsehen, muss er sich wie gehabt an die Registry wenden. Diese verwaltet allerdings in XDS-I nun nicht mehr Verweise auf die eigentlichen Bilder, sondern Verweise auf KOS-Dokumente in den Repositories, welche wiederum auf die Bilder verweisen. Ein XDS-I Image Document Consumer muss also gegenüber dem XDS Consumer einen Schritt mehr ausführen, um an die relevanten Informationen (Bilder) zu gelangen. Nach der Lokalisierung der entsprechenden KOS-Dokumente kann er diese mit der bereits bekannten XDS-Transaktion Retrieve Document Set herunterladen. Anschließend muss er das DICOM-Dokument parsen können, um die enthaltenen Bildverweise zu extrahieren. Entscheidet er sich, alle oder eine Auswahl der dabei entdeckten Bilder mittels der beiliegenden Kennung herunterzuladen, stehen ihm unterschiedliche Transaktionen zur Verfügung. Dabei erfolgt der Download direkt von der Imaging Document Source. Eine Möglichkeit besteht darin, eine Variante der üblichen Retrieve Document Set Transaktion auszuführen, die geringfügig für DICOM-Dokumente angepasst wurde und als Retrieve Imaging Document Set [RAD-69] zur Verfügung steht. Diese Transaktion sollte einfach zu implementieren sein, wenn ein XDS Document Consumer bereits die entsprechende XDS-Transaktion beherrscht. Alternativ lassen sich Transaktionen nutzen, die dem DICOM-Standard entlehnt wurden. Dabei gibt es zwei Varianten, die beide durch XDS-I unterstützt werden. Zum einen gibt es in DICOM seit vielen Jahren die Möglichkeit, DICOM-Objekte über das Web-Protokoll HTTP (HyperText Transfer Protocol) zu transferieren. Der entsprechende Teil des DICOM-Standards heißt WADO („Web Access to DICOM Persistent Objects") und wird in XDS-I durch die Transaktion „WADO Retrieve" (RAD-55) abgedeckt. Die zweite DICOM-konforme Variante besteht darin, das DICOM-spezifische Netzwerk-protokoll in Form der dort üblichen Retrieve- und Storage-Dienste zu nutzen. XDS-I sieht dabei für verschiedene Arten von DICOM-Objekten unterschiedliche Transaktionen vor, jeweils eine für Bilder (RAD-16), sogenannte Presentation States (RAD-27), Befunde (RAD-27), Key Image Notes (RAD-31) und weitere Objekttypen (RAD-45). Genau genommen werden DICOM-Retrieve Dienste im Study Root Modell (optional: Patient Root) in der Variante C-MOVE benutzt. Es bestehen zudem Vorgaben, welche Bildtypen (CT, MR, usw.) mindestens unterstützt werden müssen. Unterstützte Bildtypen müssen durch einen Imaging Document Consumer auch angezeigt werden können. In der Regel sind diese DICOM-konformen Transaktionsvarianten einfacher für bestehende DICOM-Systeme zu implementieren, die für XDS-I entsprechend erweitert werden sollen.
