XDS

Dieses Material ist Teil des Leitfadens IHE Cookbook. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Cross-Enterprise Document Sharing (XDS.b)

Das Profil XDS.b (Cross-Enterprise Document Sharing) legt den Grundstein für jede XDS-Umgebung, indem es wie bei IHE-Profilen üblich sogenannte Akteure einführt, die über Transaktionen miteinander kommunizieren. Das eigentliche XDS-Profil eignet sich zum Austausch von Dokumenten beliebigen Typs (Bilder, Befunde, Videos, etc.). XDS entkoppelt den Dokumenteninhalt (z.B. unstrukturiertes PDF-Dokument) von den Metadaten (strukturierte und suchbare Objektmerkmale, „Indices", „Verschlagwortung"). Das Profil „XDS.b" löste 2009 das Vorgängerprofil mit der Bezeichnung „XDS.a" ab, wodurch sich die Bedeutung des Begriffs „XDS" verändert hat. Im Weiteren werden „XDS" und „XDS.b" als gleichbedeutend verwendet. Die folgende Abbildung zeigt die im XDS-Profil beteiligten Akteure und Transaktionen. Es werden, wie bei allen nachfolgenden Grafiken und Erläuterungen auch, die in IHE gebräuchlichen englischen Bezeichnungen verwendet.

Akteure

Die Document Registry ist das Herzstück einer XDS-Umgebung. Sie verwaltet zentral die Verweise auf alle Dokumente, welche die angeschlossenen Partner untereinander teilen möchten. In jeder XDS-Umgebung existiert nur eine einzige Registry. Statt des Begriffs der XDS-Umgebung oder XDS-Installation wird von IHE stattdessen im Regelfall die Bezeichnung XDS Affinity Domain benutzt, um eine spezifische Registry und die daran angeschlossenen Akteure zu bezeichnen.

Desweiteren gibt es Document Repositories, welche die Dokumente selbst vorhalten. Wie die obige Abbildung bereits nahelegt, verweilen die Dokumente bei XDS also nicht in der Registry sondern in Document Repositories, von denen beliebig viele existieren können.

Hinweis zum Bild: Die grau dargestellten Aktoren und RAD/WADO Transaktionen sind spezifisch für XDS.i.

Die Registry verwaltet ausschließlich Meta-Daten, d. h. Informationen, welche Art von Dokumente zu welchen Patienten existieren und in welchem Document Repository diese gespeichert sind. Aus der Deployment-Sicht verbleiben die Repositories üblicherweise (jedoch nicht gezwungenermaßen) bei den jeweiligen Einrichtungen.

Akteure namens „Document Consumer" können Dokumente suchen und herunterladen. Dazu wendet sich ein Consumer zunächst mit einer Suchanfrage an die Registry, um die für ihn relevanten Dokumente ausfindig zu machen (z. B. Befunde zu einem bestimmten Patienten). Anschließend kann der Consumer die für ihn interessanten Dokumente vom entsprechenden Repository herunterladen.

Akteure namens „Imaging Document Consumer" laden sich eine Liste der relevanten Bilder (KOS) vom Document Repository. Im Anschluss werden die Bilder von der Document Imaging Source abgerufen.

Selbstverständlich existiert auch ein Akteur, der für das Einstellen von Dokumenten in ein Repository verantwortlich ist, die Document Source. Sie überträgt die Dokumente in ein (oder gar mehrere) Repositories und entscheidet somit darüber, welche Dokumente für die XDS-Partner zur Verfügung stehen, also „sichtbar" sind. Es können beliebig viele Document Sources in einer Affinity Domain integriert werden.

Ein System, welches Dokumente produziert und gleichzeitig lokal speichert, vereint in sich die Rollen „Document Source" und „Document Repository" – dies wird als „Integrated Source/Repository" bezeichnet. Der Hauptunterschied zum Actor Document Repository besteht darin, dass das Einstellen des Dokumenteninhalts in das Repository auf einem proprietären nicht-XDS-Weg erfolgen kannbzw. das erzeugende System die Dokumente auch selbst speichert.

Die Registry als „Spinne im Netz" ist Ansprechpartner für alle Document Consumer, wenn es um das Auffinden von Dokumenten geht. Deshalb muss sie nicht nur Informationen über alle Dokumente besitzen, sondern auch über alle dazugehörigen Patienten Bescheid wissen, da jedes Dokument zu genau einem Patienten gehört.

Für das Anlegen eines Patienten in der Registry sind in XDS nicht die Repositories verantwortlich. Stattdessen wird diese Verantwortlichkeit an einen separaten Akteur ausgegliedert, die Patient Identity Source, welche als einziger Akteur Patienten in einer Affinity Domain anlegt oder ändert. Dieser Akteur vergibt für jeden Patienten eine eindeutige Patientenkennung , die sogenannte XAD-Pid (XDS Affinity Domain Patient Identification, auch häufig XAD-PID geschrieben).

Insgesamt ergibt sich demnach folgendes Gesamtbild: Die Document Sources stellen Dokumente in die Document Repositories (häufig eine Source pro Repository) ein. Die Document Repositories informieren die Registries über neue Dokumente und teilen ihr u. a. mit, zu welchem Patienten diese gehören. Nur wenn die Patient Identity Source den jeweiligen Patienten vorher angelegt hat, wird die Registry einen Verweis auf das entsprechende Dokument übernehmen. Document Consumers können anschließend Dokumente in der Registry suchen und auf Wunsch vom jeweiligen Document Repository abrufen. Der nachfolgende Abschnitt geht nun näher auf die Nachrichten zwischen den einzelnen Akteuren ein.

Transaktionen

Die Transaktionen, über welche die Akteure Dokumente, Suchanfragen und ähnliches austauschen, lassen sich ebenfalls in obigen Abbildung ablesen. Dieser Abschnitt erläutert die den Inhalt der Nachrichten sowie die dabei benutzten Standards. Alle Transaktionen in IHE besitzen eine eindeutige Kennung, im Kontext von IT-Infrastructure und Radiologie fängt diese Kennung mit dem Präfix „ITI-" bzw. „RAD-„ an.

Patient Identity Feed

Wie im vorigen Abschnitt angedeutet, muss zunächst jeder Patient der Registry initial bekannt gemacht werden. Dies geschieht über die Transaktion (Nachricht) „Patient Identity Feed".

Die Nachricht verwendet den HL7 (Health Level 7) Standard, wobei sowohl eine Variante auf Basis von HL7 Version 2 (HL7v2) als auch unter Verwendung von HL7 Version 3 (HL7v3) zur Verfügung steht, von denen mindestens eine von Patient Identity Source und Registry unterstützt werden muss. Hier ist bei der Planung einer Affinity Domain sicherzustellen, dass beide Systeme dieselbe Variante oder sogar beide implementieren. Für Patient Identity Feed lauten die Transaktionskennungen ITI-8 (HL7v2) und ITI-44 (HL7v3). Bei ITI-8 handelt es sich technisch gesehen um verschiedene HL7-Nachrichten, die für verschiedene Zwecke eingesetzt werden:

Nachricht	HL7-Definition	IHE - Nutzung
ADT^A01	Einweisung eines Patienten	Anlegen einer Akte
ADT^A04	Ambulante Einweisung eines Patienten	dto.
ADT^A05	Ankündigung einer Patienteneinweisung	dto.
ADT^A08	Aktualisierung von Patienteninformationen	Ändern der Patientendaten
ADT^A40	Zusammenführen („Merge") von verschiedenen Patienten	Zusammenlegen von Akten

A01, A04 und A05 dienen aus Sicht der Registry ausschließlich dem Anlegen eines Patienten. Für die Registry ist dabei vor allem die zentrale Patientenkennung der Affinity Domain wichtig, die anschließend von Document Repositories und Document Sources bei der Kommunikation mit der Registry genutzt werden. Für Audit-Zwecke speichert die Registry zusätzlich auch einige demographische Patientendaten.
An dieser Stelle kommt die Frage auf, wie Repositories und Sources überhaupt die XAD-Pid herausbekommen, denn eine Document Source kennt üblicherweise nur den Namen des Patienten oder möglicherweise seine lokale Krankenhauskennung. Mögliche Lösungen bieten das PIX- sowie das PDQ-Profil, die in nachfolgenden Abschnitten beschrieben werden. In der Praxis implementiert i.d.R. ein Master Patient Index die Patient Identity Source des Affinity Domain und gleichzeitig die Akteure PIX Manager und PDQ Supplier und verlinkt die lokalen Krankenhauskennungen mit der zentralen Master Patient ID.
Die A40-Nachricht hat die Funktion, zwei Patienten (d. h. zwei unterschiedliche Master Patient IDs in der Registry) zusammenzuführen. Diese Aktion kann notwendig werden, wenn versehentlich für einen Patienten zwei Master Patient IDs angelegt wurden. Diese Situation kann mit dem Zusammenführen („Merge") der Kennungen auf Veranlassung der Patient Identity Source behoben werden. Die ADT^A08-Nachricht dient zur Aktualisierung von Patientendaten.

Wenn HL7v3 genutzt wird (ITI-44), können alle oben genannten Aktionen über die folgenden Nachricht durchgeführt werden:

Nachricht	Zweck
PRPA_IN201301UV02	Neuanlage von Patienteninformationen
PRPA_IN201302UV02	Aktualisierung von Patienteninformationen
PRPA_IN201304UV02	Zusammenführen von verschiedenen Patienten

(Provide and) Register Document Set-b

Das Einstellen von Dokumenten in XDS geschieht zweistufig: Zunächst wird ein Dokument von der Document Source über die Transaktion „Provide and Register Document Set-b" (ITI-41) an das gewünschte (üblicherweise institutionseigene) Document Repository zur Speicherung übergeben, zusammen mit einigen weiteren (Meta )Informationen wie etwa der Zuordnung zur zentralen Patientenkennung und dem Typ des Dokuments. Anschließend leitet das Repository mittels ITI-42 („Register Document Set-b") die Meta-Informationen (nicht das Dokument!) an die Registry weiter, angereichert um einige wenige weitere Datenfelder. Bei Erfolg ist das übermittelte Dokument nun für alle XDS Document Consumer in der Affinity Domain verfügbar.

Genau genommen lässt sich über beide Transaktionen nicht nur jeweils ein einzelnes Dokument übertragen. Wie ihre Bezeichnungen bereits andeuten, wird immer ein sogenanntes „Document Set" übertragen, in dem beliebig viele Dokumente (zu einem einzelnen Patienten) transportiert werden können. Neben einfachen Dokumenten definiert XDS zwei Konzepte, um Dokumente logisch zu gruppieren:

• Submission Set enthält alle Dokumente aus einer Transaktion, d. h. alle Dokumente, die zusammen „hochgeladen" wurden.
• Folder ist ein generischer „Container" für Dokumente. Über die genaue Anwendungsweise entscheidet die Affinity-Domain. Das Verschachteln von Folders lässt XDS nicht zu, dagegen ist die Zugehörigkeit eines Documents zu mehreren Folders möglich (ähnlich zu symbolischen Links in Unix-Filesysteme).

Dokumente, Folders und Submission Sets werden untereinander durch Beziehungsobjekte (Associations) verknüpft. ITI-41 und ITI-42 enthalten jeweils genau einen Submission Set. Die Verwaltung von Ordnern und Dokumentenstatus ist für Document Sources gemäß IHE Vorgabe optional, für Registries verpflichtend – die Repositories leiten die entsprechenden Datenfelder nur „blind" weiter. ITI-41 und ITI-42 verwenden Web Service Nachrichten, die wiederum auf dem SOAP-Standard aufsetzen. Die Nachrichteninhalte werden in XML (eXtensible Markup Language) kodiert. Zur möglichst effizienten Übertragung von etwaig eingebetteten Binärdaten (woraus die meisten Dokumente bestehen) kommt in ITI-41 MTOM/XOP (Message Transmission Optimization Mechanism und XML-binary Optimized Packaging) zum Einsatz. Dies ist für ITI-42 nicht notwendig, da hier nur Meta-Informationen, nicht die eigentlichen Dokumente in der Nachricht enthalten sind. Große Teile von XDS (Architektur und Meta-Informationen) und seinen Transaktionen basieren auf einem Standard namens ebXML (Electronic Business XML), der nicht gezielt für das Gesundheitswesen entwickelt wurde.

Registry Stored Query

Die Transaktion „Registry Stored Query" (ITI-18) dient der Suche nach Dokumenten in der Registry. Die Dokumente in einer XDS Affinity Domain sind üblicherweise über mehrere Document Repositories verteilt. Um als Document Consumer ein Dokument finden zu können, wendet sich dieser nicht etwa mit einer Anfrage an jedes einzelne Repository, sondern an die zentrale Document Registry. Dies ist eine Design-Entscheidung, die für XDS (bzw. ebXML) getroffen wurde und verbindlich für XDS-konforme Systeme ist.

Die Ausdrucksmöglichkeiten der Abfragen sind in XDS.b (gegenüber der Vorgängerversion) eingeschränkt. Es werden insgesamt 13 „vorgefertigte" Query-Arten definiert, die einzelne Anwendungsfälle einer Suche abdecken (deshalb „Stored Query"). So lassen sich Dokumente über ihre Patientenkennung, Datum, Ordner oder Submission Set finden. Bei komplizierteren Auswahlkriterien muss ein Document Consumer ggf. Ergebnisse von mehreren Abfragen miteinander kombinieren. Das Ergebnis der Abfrage enthält Verweise auf Document Repositories, mit Hilfe deren der Dokumentinhalt heruntergeladen werden kann. Optional kann das Abfrageergebnis auch sämtliche Metadaten der zurückgegebenen XDS-Objekte (Dokumente, Folders, Submission Sets) enthalten. Als Standards kommen wiederum u. a. Web Services, SOAP, MTOM/XOP und ebXML zum Einsatz.

Retrieve Document Set

Nachdem ein Document Consumer eine Menge von Dokumenten über die Registry lokalisiert hat, kann er diese vom jeweiligen Repository mittels der Transaktion „Retrieve Document Set" (ITI-43) herunterladen.

Dabei wird in erster Linie die Dokumentenkennung zur Identifikation des Dokuments angefragt. Anfrage und Antwort benutzen wiederum die bereits bekannten Web Service Standards und ebXML.