IHE DE Cookbook

Vorwort

Das Interesse an Themen der einrichtungsübergreifenden Kommunikation, in Deutschland auch intersektorale Kommunikation oder integrierte Versorgung genannt, hat in den vergangenen Jahren massiv zugenommen. Die technischen Möglichkeiten der Gesundheits-IT (GIT) bilden hierbei oft eine tragende Säule, so dass sich unter dem Begriff eHealth ein weitgehend neues Feld innerhalb der Medizin-Informatik entwickelt hat, auch wenn die konzeptuellen und technischen Grundlagen hierfür bereits vor geraumer Zeit gelegt wurden.

Viele europäische Länder haben auf nationaler Ebene eHealth Projekte initiiert oder durchgeführt. Gleichzeitig haben aber auch viele Regionen in derartige Projekte investiert. Diese unterscheiden sich dabei aus technischer Sicht oft in zwei Hauptaspekten: den architektonischen Ansätzen und dem Maß der Verwendung internationaler GIT-Standards, wobei hinsichtlich des letzten Punktes die Grenzen zwischen der Verwendung internationaler Standards und eher nationaler Ansätze oft fließend sind.

Der GIT-Standard, der sich international am ehesten für den eHealth Bereich etabliert hat ist IHE. In Deutschland lag der Fokus bisher auf nationalen Spezifikationen, was unter anderem an besonderen Anforderungen hinsichtlich des Datenschutzes und der IT-Sicherheit gelegen haben mag. Andererseits werden sowohl aus Anwender- und Betreiber- als auch aus Herstellersicht nationale Spezifikationen und Umsetzungen stets kritisch beäugt, da sie erhebliche Risiken u.a. hinsichtlich ihrer Zukunftssicherheit und Wirtschaftlichkeit beinhaltet. So ist auch in mehreren eHealth Evaluations-Studien die mangelnde Standardisierung als ein Haupthemmfaktor (inhibiting factor) identifiziert worden, der entsprechend auch die jeweilige Marktentwicklung erheblich verzögert, wenn nicht gar unterbunden hat.

Das Hauptziel der Erarbeitung des hier vorliegenden Cookbooks war somit die „Nationalisierung" der internationalen IHE-Profile und damit der Anpassung eines internationalen Standards auf die spezifisch deutschen Gegebenheiten. Ein derartiges Vorgehen ist innerhalb von IHE vorgesehen, bricht also nicht mit dem internationalen Ansatz.

Unter dem Begriff eHealth werden verschieden technische Verfahren zusammengefasst. Historisch gesehen haben sich die Telemedizin und in ihrem Gefolge die Home Care-Szenarien als erste platziert. Hauptmangel bei diesen Verfahren ist jedoch ihre Eindimensionalität, da sie oft nur einen Teilbereich bzw. einen zeitlichen Ausschnitt isoliert betrachten. Diese Defizite können durch einrichtungsübergreifende elektronische Akten kompensiert werden, die deshalb meistens auch als Grundpfeiler und Hauptelement einer weitergehenden Optimierung der Gesundheitsversorgung angesehen werden, wobei der Bildkommunikation oft eine besondere Bedeutung beikommt. Entsprechend wurde hier der inhaltliche Schwerpunkt für das Cookbook gesetzt und Umsetzungsempfehlungen für die drei in Deutschland gängigsten Architekturmodell für einrichtungsübergreifende Akten entworfen.

Das Cookbook wurde, wie bei IHE üblich, gemeinschaftlich von Anwendern, Betreibern und Herstellen geschrieben. Von eminenter Bedeutung war es dabei eine möglichst breite Basis zu schaffen um die Akzeptanz zu gewährleisten. Gleichzeitig war allen Autoren klar, dass es sich um einen dynamischen Prozess und ein sich änderndes Dokument handeln würde. Aus beiden Gründen begrüßen wir alle Kommentare und die Mitarbeit von jeder Seite ausdrücklich! Bitte wenden Sie sich bei Interesse einfach an die Geschäftsstelle von IHE-Deutschland.

Grundlagen

Im Folgenden werden rechtliche und technische Rahmenbedingungen im Zusammenhang mit dem einrichtungsübergreifenden Austausch von Bild- und Befunddaten in Deutschland aufgeführt, um daraus Anforderungen an die technischen Lösungen ableiten zu können.

Rechtliche Rahmenbedingungen

Grundsätzlich sind die folgenden rechtlichen Rahmenbedingungen relevant für die konforme Spezifikation des einrichtungsübergreifenden Datenaustauschs:

• der konkrete Behandlungsauftrag
• die konkrete Patienteneinwilligung
• deutsche Datenschutzgesetze in Umsetzung der aktuellen EU-Datenschutzrichtlinie
• Patientenrechte (z. B.: BMG-Eckpunkte)
• Strafrecht
• Haftungsrecht

Eine etwaige zukünftige EU-Verordnung (im Gegensatz zur derzeitigen EU-Direktive) zum Datenschutz würde übrigens direkt als nationale Gesetzgebung gelten, so dass heutige nationale Gesetzgebungen als Ergänzung zur kommenden Verordnung angesehen werden können. Allerdings ist nach derzeitigem Stand die Spezialgesetzgebung (z. B. Arbeitnehmerdatenschutz, Gesundheitsdatenschutz) weiterhin in nationaler gesetzgeberischer Verantwortung. Ob eine EU-Verordnung kommt, gilt heute noch als unsicher. Dementsprechend können hier natürlich auch keine Zeitangaben erfolgen. Es muss gesondert erwähnt werden, dass derzeit kein Konsens über die Angemessenheit technischer und organisatorischer Mittel zur Wahrung o.g. Rechtsgrundlagen besteht, sodass die konkrete elektronische Umsetzung des Datenaustauschs zwischen verschiedenen Einrichtungen in Deutschland nur auf einer vertraglich gesicherten Basis zwischen den Institutionen erfolgen kann, wie es beispielsweise auch bei der Teleradiologie nach Röntgenverordnung vorgeschrieben ist. Liegt eine Auftragsdatenverarbeitung vor, muss der Vertrag natürlich auch die entsprechenden bundesrechtlichen Anforderungen (§11 BDSG, §80 SGB X) wie auch ggf. vorhandene bundeslandspezifischen Anforderungen (z. B. NRW §11 DSG NRW) berücksichtigen.

Vertraulichkeit patientenbezogener Information

Datenschutz steht für die Idee, dass jeder Mensch grundsätzlich selbst entscheidet, wer wann unter welchen Umständen auf welche seiner persönlichen Daten zugreifen darf. Dementsprechend ist der Zweck datenschutzrechtlicher Gesetze, „den Einzelnen davor zu schützen, dass er durch den Umgang mit seinen personenbezogenen Daten in seinem Persönlichkeitsrecht beeinträchtigt wird" (BDSG §1 Abs. 1). Der Datenschutz hat eine besondere Bedeutung für den einrichtungsübergreifenden Austausch von Bild- und Befunddaten, da die Akzeptanz entsprechender Lösungen bei Ärzten und Patienten zu Recht nur dann gegeben ist, wenn Datenschutz und Datensicherheit umfänglich berücksichtigt sind und so die Vertraulichkeit zwischen Patient und Behandler gewährleistet ist. Aus diesem Grund ist Datenschutz ein besonderer Schwerpunkt im Cookbook. Für die Bundesbehörden und den privaten Bereich, z. B. für Krankenhäuser mit privater Trägerschaft oder niedergelassene Ärzte regelt das Bundesdatenschutzgesetz (BDGS) den Datenschutz auf Bundesebene. Daneben regeln die Datenschutzgesetze der Länder den Datenschutz in Landes- und Kommunalbehörden, weshalb diese für Krankenhäuser mit öffentlich-rechtlicher Trägerschaft gelten. In beiden Fällen wird jedoch nicht der Umgang mit den im Krankenhaus bei der Behandlung anfallenden Gesundheitsdaten geregelt. Daher gibt es noch länderspezifische Gesetze, welche genau dieses regeln. Diese Gesetze gelten in der Regel für die Verarbeitung personenbezogener Daten von Personen, welche

• in einem (zugelassenen) Krankenhaus im Sinne von §107 Abs. 1 und §108 SGB V oder
• in einer Vorsorge- und Rehabilitationseinrichtung gemäß §107 Abs. 2 und §111 SGB V

ambulant oder stationär untersucht oder behandelt werden. Kirchen und Religionsgemeinschaften wiederum haben das Recht für von Ihnen betriebene Einrichtungen eigene Gesetze zu erlassen, dementsprechend gelten für kirchliche Krankenhäuser ebenfalls eigene Gesetze, wie z.B. die Anordnung über den kirchlichen Datenschutz (KDO) für katholische Krankenhäuser und das Datenschutzgesetz der Evangelischen Kirche Deutschlands (DSG-EKD) für evangelische Krankenhäuser.

Umgang mit personenbezogenen Daten

Auf Grund der Vielfältigkeit der Gesetze kann an dieser Stelle nicht auf die Bundeslandspezifischen Anforderungen eingegangen werden, so dass die jeweilige Zulässigkeit im jeweiligen Projekt geprüft werden muss. Eine Übersicht der wichtigsten rechtlichen und normativen Anforderungen befindet sich im Anhang.

Bundesdatenschutzgesetz

Der Zweck des Bundesdatenschutzgesetzes ist es, gemäß §1 den Einzelnen davor zu schützen, dass er durch den Umgang mit seinen personenbezogenen Daten in seinem Persönlichkeitsrecht beeinträchtigt wird. § 3 Abs. 1 BDSG definiert personenbezogene Daten als Einzelangaben über persönliche oder sachliche Verhältnisse einer bestimmten oder bestimmbaren natürlichen Person (Betroffener). § 3 Abs. 3 BDSG definiert das Erheben als das Beschaffen von Daten über den Betroffenen. Das Verarbeiten ist gemäß § 3 Abs. 4 BDSG das Speichern, Verändern, Übermitteln, Sperren und Löschen personenbezogener Daten, wobei in diesem Zusammenhang das Speichern und Übermitteln von besonderer Bedeutung sind. Das Speichern umfasst das Erfassen, Aufnehmen oder Aufbewahren personenbezogener Daten auf einem Datenträger zum Zweck ihrer weiteren Verarbeitung oder Nutzung. Das Übermitteln ist das Bekanntgeben gespeicherter oder durch Datenverarbeitung gewonnener personenbezogener Daten an einen Dritten in der Weise, dass

• die Daten an den Dritten weitergegeben werden oder
• der Dritte zur Einsicht oder zum Abruf bereitgehaltene Daten einsieht oder abruft.

Das Nutzen ist gemäß § 3 Abs. 5 BDSG jede Verwendung personenbezogener Daten, soweit es sich nicht um Verarbeitung handelt. § 3 Abs. 9 BDSG definiert zusätzlich noch besondere Arten personenbezogener Daten als Angaben über die rassische und ethnische Herkunft, …, Gesundheit oder Sexualleben. Nach § 4 Abs. 1 BDSG sind die Erhebung, Verarbeitung und Nutzung personenbezogener Daten nur zulässig, soweit dieses Gesetz oder eine andere Rechtsvorschrift dies erlaubt oder anordnet oder der Betroffene eingewilligt hat. Der Patienteneinwilligung kommt demnach eine besondere Bedeutung zu, weshalb diese in § 4 Abs. 1 BDSG konkretisiert wird. Werden personenbezogene Daten beim Betroffenen erhoben, so ist er, sofern er nicht bereits auf andere Weise Kenntnis erlangt hat, von der verantwortlichen Stelle über

1. die Identität der verantwortlichen Stelle,
2. die Zweckbestimmungen der Erhebung, Verarbeitung oder Nutzung und
3. die Kategorien von Empfängern nur, soweit der Betroffene nach den Umständen des Einzelfalles nicht mit der Übermittlung an diese rechnen muss,

zu unterrichten. Letzteres bedeutet, dass der Patient im Fall des einrichtungsübergreifenden Austausches von Bild- und Befunddaten über die Übermittlung seiner personenbezogenen Daten von der behandelnden Einrichtung unterrichtet werden muss, da er nicht mit dieser Übermittlung rechnen muss. Gemäß § 28 Abs. 7 BDSG ist das Erheben von besonderen Arten personenbezogener Daten (§ 3 Abs. 9) zulässig, wenn dies zum Zweck der Gesundheitsvorsorge, der medizinischen Diagnostik, der Gesundheitsversorgung oder Behandlung oder für die Verwaltung von Gesundheitsdiensten erforderlich ist und die Verarbeitung dieser Daten durch ärztliches Personal oder durch sonstige Personen erfolgt, die einer entsprechenden Geheimhaltungspflicht unterliegen. Die Verarbeitung und Nutzung von Daten zu den in Satz 1 genannten Zwecken richtet sich nach den für die in Satz 1 genannten Personen geltenden Geheimhaltungspflichten. Allerdings gelten – abgesehen von den vom Bund betriebenen Krankenhäusern wie Bundeswehrkrankenhäusern – in nahezu allen Krankenhäusern die Spezialgesetzgebungen des Landes.

Sozialgesetzbuch

Entsprechend §35 Abs. SGB I ist eine Erhebung, Verarbeitung und Nutzung von Sozialdaten nur unter den Voraussetzungen der §§ 67a bis 78 des SGB X zulässig. Daher erfordert eine Zweckänderung der zum Zwecke der Patientenversorgung erhobenen Daten eine (schriftliche) Einwilligung des betroffenen Patienten. Entsprechend §67d ist eine Übermittlung von Sozialdaten ist nur zulässig, soweit eine gesetzliche Übermittlungsbefugnis nach den §§ 68 bis 77 oder nach einer anderen Rechtsvorschrift in diesem Gesetzbuch vorliegt. Dies sind:

• § 68 Übermittlung für Aufgaben der Polizeibehörden, der Staatsanwaltschaften und Gerichte, der Behörden der Gefahrenabwehr oder zur Durchsetzung öffentlich-rechtlicher Ansprüche.
• § 69 Übermittlung für die Erfüllung sozialer Aufgaben.
• § 70 Übermittlung für die Durchführung des Arbeitsschutzes.
• § 71 Übermittlung für die Erfüllung besonderer gesetzlicher Pflichten und Mitteilungsbefugnisse.
• § 72 Übermittlung für den Schutz der inneren und äußeren Sicherheit.
• § 73 Übermittlung für die Durchführung eines Strafverfahrens.
• § 74 Übermittlung bei Verletzung der Unterhaltspflicht und beim Versorgungsausgleich.
• § 75 Übermittlung von Sozialdaten für die Forschung und Planung.
• § 76 Einschränkung der Übermittlungsbefugnis bei besonders schutzwürdigen Sozialdaten.
• § 77 Übermittlung ins Ausland und an über- oder zwischenstaatliche Stellen.

Entsprechend §78 ist die Übermittlung von Sozialdaten, die einer in § 35 des Ersten Buches genannten Stelle von einem Arzt oder einer anderen in § 203 Abs. 1 und 3 des Strafgesetzbuches genannten Person zugänglich gemacht worden sind, nur unter den Voraussetzungen zulässig, unter denen diese Person selbst übermittlungsbefugt wäre. D.h., nur wenn die für den Datenschutz verantwortliche erhebende ärztliche Stelle eine Übermittlung durchführen darf, ist dies nach dem SGB erlaubt. D.h., auch eine Datenübermittlung von zum Zwecke der Patientenversorgung erhobenen Daten erfordert eine (schriftliche) Einwilligung des betroffenen Patienten, wenn keine Rechtsvorschrift die Übermittlung fordert.

Telemediengesetz und Datenschutz

Das Telemediengesetz gilt erst einmal prinzipiell für die Betreiber von Webseiten, d.h. bei einem Gesundheitsportal sind selbstverständlich die Anforderungen des TMG gültig. Dementsprechend gelten die Vorschriften:

• zur Bekämpfung von Spam, d.h. das Verbot einer Verschleierung und Verheimlichung von Absender und Inhalt bei Werbe-E-Mails ist zu beachten; Werbe-E-Mails können Mails an Patienten, Krankenhäuser und Arztpraxen sein, welche zur Nutzung des Portals auffordern
• zur Haftung von Dienstebetreibern für gesetzeswidrige Inhalte in Telemediendiensten
• zum Datenschutz beim Betrieb von Telemediendiensten und zur Herausgabe von Daten

natürlich auch für Portallösungen im Gesundheitswesen. Dementsprechend muss der Diensteanbieter entsprechend §13 TMG unter anderem gewährleisten, dass

• der Patient der Einwilligung jederzeit abrufen und mit Wirkung für die Zukunft widerrufen kann, wobei der Diensteanbieter dies dem Patienten vor der Einwilligung mitzuteilen hat
• die personenbezogenen Daten über die Nutzung verschiedener Telemedien durch denselben Nutzer getrennt verwendet werden können
• die Nutzung von Telemedien wie auch der evtl. erforderlichen Bezahlung anonym oder unter einem Pseudonym möglich ist (Zumutbarkeit und technische Möglichkeit vorausgesetzt) und muss dem Nutzer der Telemedien hiervon unterrichten.

Auftragsdatenverarbeitung - Funktionsübertragung

Die Abgrenzung von Auftragsdatenverarbeitung zu Funktionsübertragung ist in der Praxis oft schwierig, die Konsequenzen aus der Entscheidung jedoch weitreichend: im Fall der Auftragsdatenverarbeitung handelt es sich nicht um eine Übermittlung, so dass der Auftraggeber für den Schutz der Daten verantwortlich bleibt und der Auftragnehmer geringeren gesetzlichen Anforderungen unterliegt. Im Fall der Funktionsübertragung handelt es sich um eine Übermittlung mit den daraus folgenden Lasten der Überprüfung, ob diese überhaupt zulässig ist und der Einholung der Einwilligung und/oder der Unterrichtung der jeweils betroffenen Person bzgl. der geplanten Datenverarbeitung. Die Auftragsdatenverarbeitung stellt also eine privilegierte Funktionsübertragung dar. Zudem ist eine Auftragsdatenverarbeitung nur im EWG möglich, außerhalb des EWF fällt immer eine Datenübermittlung mit den entsprechenden Anforderungen an. Erkennungsmerkmale für Auftragsdatenverarbeitung können sein:

• fehlende Entscheidungsbefugnis des Auftragnehmers
• Weisungsgebundenheit des Auftragnehmers bezüglich dessen, was mit den Daten geschieht
• Umgang nur mit Daten, die der Auftraggeber zur Verfügung stellt; es sei denn, der Auftrag ist auch auf die Erhebung personenbezogener Daten gerichtet
• Ausschluss der Verarbeitung oder Nutzung der Daten zu eigenen Zwecken des Auftragnehmers
• keine (vertragliche) Beziehung des Auftragnehmers zum Betroffenen
• Auftragnehmer tritt (gegenüber dem Betroffenen) nicht in eigenem Namen auf.

Dementsprechend können folgende Erkennungsmerkmale auf eine Funktionsübertragung hindeuten:

• Weisungsfreiheit des Dienstleisters bezüglich dessen, was mit den Daten geschieht
• Überlassung von Nutzungsrechten an den Daten
• eigenverantwortliche Sicherstellung von Zulässigkeit und Richtigkeit der Daten durch den Dienstleister, einschließlich des Sicherstellens der Rechte von Betroffenen (Benachrichtigungspflicht, Auskunftsanspruch)
• Handeln des Dienstleisters (gegenüber dem Betroffenen) im eigenen Namen
• Entscheidungsbefugnis des Dienstleisters in der Sache

Einen Sonderfall bildet die Prüfung oder Wartung automatisierter Verfahren oder von Datenverarbeitungsanlagen. Solche Tätigkeiten sind z.B.

• Installation, Wartung, Pflege und Prüfung von Netzwerken, Hardware (einschließlich Telekommunikationsanlagen) und Software u.a. (Betriebssysteme, Middleware, Anwendungen)
• Parametrisieren von Software
• Programmentwicklungen/-anpassungen/-umstellungen, Fehlersuche und Tests
• Durchführung von Migrationen im Produktivsystem

Sie können direkt vor Ort oder per Fernwartung durchgeführt werden. Die Tätigkeiten sind nicht auf den Umgang mit personenbezogenen Daten gerichtet, allerdings ist die Kenntnisnahme von personenbezogenen Daten nicht immer ausgeschlossen. Daher unterwirft der Bundesgesetzgeber im Bundesdatenschutzgesetz (BDSG) gänzlich und der Landesgesetzgeber (LDSG) weitgehend die Erbringung von Wartungs- und Pflegearbeiten den Regelungen zur Auftragsdatenverarbeitung, soweit bei diesen Tätigkeiten ein Zugriff auf personenbezogene Daten unvermeidlich ist und die Tätigkeit innerhalb des EWG durchgeführt wird. Einige Landesgesetze wie auch das SGB X gestatten nur die Auftragsdatenverarbeitung, so dass eine Funktionsübertragung nicht möglich ist. Analog zum BDSG wird in §80 SGB X ein schriftlicher Vertrag gefordert, welcher mindestens die folgenden Punkte beinhalten muss:

1. der Gegenstand und die Dauer des Auftrags,
2. der Umfang, die Art und der Zweck der vorgesehenen Erhebung, Verarbeitung oder Nutzung von Daten, die Art der Daten und der Kreis der Betroffenen,
3. die nach § 78a zu treffenden technischen und organisatorischen Maßnahmen,
4. die Berichtigung, Löschung und Sperrung von Daten,
5. die bestehenden Pflichten des Auftragnehmers, insbesondere die von ihm vorzunehmenden Kontrollen,
6. die etwaige Berechtigung zur Begründung von Unterauftragsverhältnissen,
7. die Kontrollrechte des Auftraggebers und die entsprechenden Duldungs- und Mitwirkungspflichten des Auftragnehmers,
8. mitzuteilende Verstöße des Auftragnehmers oder der bei ihm beschäftigten Personen gegen Vorschriften zum Schutz von Sozialdaten oder gegen die im Auftrag getroffenen Festlegungen,
9. der Umfang der Weisungsbefugnisse, die sich der Auftraggeber gegenüber dem Auftragnehmer vorbehält,
10. die Rückgabe überlassener Datenträger und die Löschung beim Auftragnehmer gespeicherter Daten nach Beendigung des Auftrags.

Einwilligung

Entsprechend dem allgemeinen Vertragsrecht ist eine verständliche und umfassende Information eine Grundvoraussetzung für die Wirksamkeit einer erlangten Einwilligungserklärung. Wäre diese Information nicht auf Anhieb für den Patienten als solche zu erkennen, so bestünde die Gefahr einer fehlerhaften Einschätzung dessen, was dem Patienten mit dem betreffenden Papier vermittelt werden soll. Daher gilt für eine Einwilligungserklärung der Grundsatz der „Laienverständlichkeit": nur ein informierter und aufgeklärter Patient kann eine wirksame Einverständniserklärung abgeben. Gemäß § 4a Abs. 1 BDSG ist die Einwilligung nur wirksam, wenn sie auf der freien Entscheidung des Betroffenen beruht. Entsprechend §4 Abs. 3 Satz 2 besteht die Verpflichtung, dem Aufzuklärenden auf die Freiwilligkeit bzgl. der Teilnahme hinzuweisen. Auf Verlangen muss dem Patienten auch die Folgen der Verweigerung einer Einwilligung mitgeteilt werden. Ist die Kenntnis dieser Folgen für den Patienten zwingender Bestandteil für eine informierte Einwilligung, sollte dem Patienten diese Information auf jedem Fall mitgeteilt werden. Ansonsten kann es sein, dass die Einwilligung auf Grund der fehlenden Aufklärung des Patienten nicht rechtskräftig ist. §4a Abs. 1 Satz 2 BDSG verlangt die Nennung des Zweckes der Datenerhebung, -verarbeitung oder -nutzung, wobei die Erklärung für den Patienten verständlich sein muss, zugleich auch inhaltlich und formal einwandfrei sein muss. Eine Zweckänderung muss dem Patienten mitgeteilt werden und - falls keine andere Rechtsvorschrift die Zweckänderung verlangt - darf nur mit ausdrücklicher Einwilligung des Patienten erfolgen. Entsprechend §4a Abs. 3 muss sich bei besonderen Arten von personenbezogenen Daten (dies sind u. a. auch Gesundheitsdaten) die Einwilligung ausdrücklich auf die Daten beziehen. Daher gehört eine Auflistung der Art der erhobenen Daten notwendigerweise zu einer wirksamen Einverständniserklärung dazu. Allerdings wäre eine vollständige Auflistung der einzelnen Daten (z.B. HB, Leukozyten, GOT, GPT, HZV, usw.) für den Patienten nicht überschaubar und in vielen Fällen auch unverständlich, so dass die jeweiligen Kategorien genannt werden müssen. Damit die Kategorien für den Patienten verständlich sind, können Beispiele hilfreich sein. Nach §4 Abs. 3 sind die Kategorien von Empfängern zu benennen, wenn Daten übermittelt werden. Auch wenn diese Vorschrift nur die Übermittlung an sich betrifft, muss hier das Urteil des Bundesverfassungsgerichtes entsprechend berücksichtigt werden: „Mit dem Recht auf informationelle Selbstbestimmung wären eine Gesellschaftsordnung und eine diese ermöglichende Rechtsordnung nicht vereinbar, in der Bürger nicht mehr wissen können, wer was wann und bei welcher Gelegenheit über sie weiß." D.h., mit dem Verzicht der Nennung der Nutzungsberechtigten würde das datenschutzrechtliche Grundziel der informellen Selbstbestimmung verfehlt und die Einverständniserklärung nichtig. Die Einwilligung bedarf der Schriftform, soweit nicht wegen besonderer Umstände eine andere Form angemessen ist. Soll die Einwilligung zusammen mit anderen Erklärungen schriftlich erteilt werden, ist sie besonders hervorzuheben. Ein Hinweis in einer Einverständniserklärung, welcher aufzeigt, dass der Patient Möglichkeiten zur Fragestellung hatte, verdeutlicht, dass der Patient vor Abgabe seiner Willenserklärung alle Möglichkeiten zur Information hatte. Selbstverständlich müssen eventuell erfolgte Zusatzabsprachen in der Einverständniserklärung schriftlich festgehalten werden. Eine Abstufung ermöglicht dem Patienten zu entscheiden, welcher Datenübermittlung und Datennutzung er zustimmt, z.B.:

• Qualitätssicherung
• Forschung
• Beidem
• Keine der genannten Möglichkeiten.

Da der Patient die ausdrückliche Wahl der Zustimmung oder des Widerspruchs hat, wird hier der informellen Selbstbestimmung des Patienten genüge getan. Entsprechend §35 Abs. 2 BDSG sind personenbezogene Daten zu löschen, sobald „ihre Kenntnis für die Erfüllung des Zwecks der Speicherung nicht mehr erforderlich ist". Bei einer unspezifischen Zeitangabe – insbesondere mit dem Vorbehalt auf die Nutzung weiterer Vorhaben (z.B. epidemiologischer Forschung) – muss dem Patienten unmissverständlich klar gemacht werden, das dies ggf. eine dauerhafte Speicherung seiner Daten zur Folge hat, ebenso dass er jederzeit widersprechen kann. Im Rahmen der Einwilligung ist es nicht möglich, die Rechte auf Auskunft, Berichtigung, Sperrung und Löschung der Daten auszuschließen oder zu beschränken (§ 6 Abs.1 BDSG).

Schutz der personenbezogenen Daten

Gemäß § 9 BDSG haben öffentliche und nicht-öffentliche Stellen, die selbst oder im Auftrag personenbezogene Daten erheben, verarbeiten oder nutzen, die technischen und organisatorischen Maßnahmen zu treffen, die erforderlich sind, um die Ausführung der Vorschriften dieses Gesetzes, insbesondere die in der Anlage zu diesem Gesetz genannten Anforderungen, zu gewährleisten. Erforderlich sind Maßnahmen nur, wenn ihr Aufwand in einem angemessenen Verhältnis zu dem angestrebten Schutzzweck steht. Die in § 9 BDSG referenzierte Anlage definiert, dass wenn personenbezogene Daten automatisiert verarbeitet oder genutzt werden, die innerbehördliche oder innerbetriebliche Organisation so zu gestalten ist, dass sie den besonderen Anforderungen des Datenschutzes gerecht wird. Dabei sind insbesondere Maßnahmen zu treffen, die je nach der Art der zu schützenden personenbezogenen Daten oder Datenkategorien geeignet sind,

• Unbefugten den Zutritt zu Datenverarbeitungsanlagen, mit denen personenbezogene Daten verarbeitet oder genutzt werden, zu verwehren (Zutrittskontrolle),
• zu verhindern, dass Datenverarbeitungssysteme von Unbefugten genutzt werden können (Zugangskontrolle),
• zu gewährleisten, dass die zur Benutzung eines Datenverarbeitungssystems Berechtigten ausschließlich auf die ihrer Zugriffsberechtigung unterliegenden Daten zugreifen können, und dass personenbezogene Daten bei der Verarbeitung, Nutzung und nach der Speicherung nicht unbefugt gelesen, kopiert, verändert oder entfernt werden können (Zugriffskontrolle),
• zu gewährleisten, dass personenbezogene Daten bei der elektronischen Übertragung oder während ihres Transports oder ihrer Speicherung auf Datenträger nicht unbefugt gelesen, kopiert, verändert oder entfernt werden können, und dass überprüft und festgestellt werden kann, an welche Stellen eine Übermittlung personenbezogener Daten durch Einrichtungen zur Datenübertragung vorgesehen ist (Weitergabekontrolle),
• zu gewährleisten, dass nachträglich überprüft und festgestellt werden kann, ob und von wem personenbezogene Daten in Datenverarbeitungssysteme eingegeben, verändert oder entfernt worden sind (Eingabekontrolle),
• zu gewährleisten, dass personenbezogene Daten, die im Auftrag verarbeitet werden, nur entsprechend den Weisungen des Auftraggebers verarbeitet werden können (Auftragskontrolle),
• zu gewährleisten, dass personenbezogene Daten gegen zufällige Zerstörung oder Verlust geschützt sind (Verfügbarkeitskontrolle),
• zu gewährleisten, dass zu unterschiedlichen Zwecken erhobene Daten getrennt verarbeitet werden können.

Eine Maßnahme nach Satz 2 Nummer 2 bis 4 ist insbesondere die Verwendung von dem Stand der Technik entsprechenden Verschlüsselungsverfahren.

Zusammenfassung: Anforderungen an die Umsetzung

Wie oben erläutert, muss die elektronische Einwilligung des Patienten in die Daten¬verarbeitung

• mit Schutzmaßnahmen erfolgen
• neben gleichzeitig erfassten Erklärungen gesondert hervorgehoben werden
• den Grund für die Datenerhebung und -speicherung nennen
• die Folgen der Verweigerung nennen
• Die Daten selbst benennen bzw. bei eindeutiger Kenntnis durch den Patienten reichen auch die Kategorien der Daten aus
• die (Kategorien der) Empfänger nennen

Die Spezifikation des Cookbooks kann die ersten zwei Maßnahmen nach § 9 BDSG (Anlage) nicht bzw. nur unterstützend umsetzen:

• Zutrittskontrolle, die wesentlich außerhalb Software stattfindet, und
• Verfügbarkeitskontrolle, die durch Maßnahmen des Softwarebetriebs sicherzustellen ist

wohingegen die folgenden Maßnahmen nach § 9 BDSG (Anlage) wesentliche Anforderungen an das Cookbook sind:

• Zugangskontrolle
• Zugriffskontrolle
• Weitergabekontrolle
• Eingabekontrolle
• Auftragskontrolle
• Trennung der Verarbeitung nach Zweck

IHE-Profile und weitere Standards

Im Folgenden werden aktuell verfügbare Standards und Profile aufgeführt, die für die einrichtungsübergreifende elektronische Kommunikation von Bildern und Befunden eine Rolle spielen. In der folgenden Abbildung sind diese zusammenfassend dargestellt. Ausgehend vom IHE-Profil XDS-I werden diejenigen relevanten IHE-Profile benannt und kurz erläutert, die den Ausgangspunkt für die technische Spezifikation bilden. Sofern diese als nicht ausreichend angesehen werden, wird auf zusätzliche internationale Standards eingegangen, um eine tragfähige Lösung zu erreichen. Die Spezifikationen werden an dieser Stelle nur kurz und kontextbezogen erläutert, um relevante Details darzustellen. Für weitergehende Informationen sei auf die Spezifikationen selbst verwiesen.

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.

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. Bilder zu einem bestimmten Patienten). Anschließend kann der Consumer die für ihn interessanten Dokumente vom entsprechenden Repository herunterladen.

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 kann.

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 Master Patient ID oder auch XAD-Pid (XDS Affinity Domain Patient Identification). Die Begriffe Master Patient ID, zentrale Patientenkennung und XAD-Pid werden im weiteren synonym verwendet.

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 Identify 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	Zweck
ADT^A01	Einweisung eines Patienten
ADT^A04	Ambulante Einweisung eines Patienten
ADT^A05	Ankündigung einer Patienteneinweisung
ADT^A08	Aktualisierung von Patienteninformationen
ADT^A40	Zusammenführen („Merge") von verschiedenen Patienten

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 diese 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 Dokument 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.

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. Abbildung 9 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 die 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.

Abbildung 9 Akteure und Transaktionen des XDS-I-b Profils

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 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.