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

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.

IHE XDS Metadata Update

Das IHE Profil XDS Metadata Update ist eine Ergänzung zum XDS.b Profil, welches das Verändern und Löschen von Metadaten in der Document Registry ermöglicht. Die zusätzlichen Transaktionen für das Verändern bzw. Löschen von Metadaten werden direkt von einem zusätzlichen Akteur, dem Document Administrator, initiiert und unmittelbar an die Document Registry gesendet. Die Transaktion Update Document Set \[ITI-57\] ermöglich die Veränderung der Metadaten von Dokumenten, Foldern oder Assoziationen sowie die Änderung des Verfügbarkeitsstatus dieser Objekte. Durch diese Transaktion kann auch die zentrale Patienten ID am Dokumente oder Folder geändert werden, wodurch Dokumente und Folder auch anderen Patienten zugeordnet werden können. Mit der Transaktion Delete Document Set \[ITI-62\] können die Metadaten beliebiger Objekte gelöscht werden. Die Löschung ist nicht nur eine Statusänderung von Metadaten, sondern das permanente Entfernen, das nicht rückgängig gemacht werden kann.

IHE Patient Identifier Cross-referencing (PIX)

Das IHE-Profil Patient Identifier Cross-referencing (PIX) ermöglicht die Verknüpfung von Patientenkennungen in einem Netzwerk von Einrichtungen, die für einen Patienten jeweils eigene Kennungen vergeben. Dafür werden dem sogenannten Patient Identifier Cross-reference Manager (PIX Manager) demographische Patientendaten und IDs übergeben, der die Daten des gleichen Patienten aus unterschiedlichen Einrichtungen verlinkt. Ein System, welches als Patient Identifier Cross-reference Consumer agiert, kann sich die Verknüpfungen entweder beim PIX Manager mit Hilfe einer bekannten ID aktiv anfragen oder (optional) sich darüber informieren lassen. Das PIX-Profil stellt damit eine Grundlage für den einrichtungsübergreifenden Dokumenten- und Bildaustausch auf Basis von XDS.b und XDS-I.b dar, da über dieses Profil die Daten aus unterschiedlichen Einrichtungen mit unterschiedlichen IDs für einen Patienten zusammengeführt werden können.

In der Praxis fungiert der PIX Manager in der Regel als Master Patient Index und stellt eine in der XDS Affinity Domain eindeutige Master Patient ID, die sogenannte XAD-Pid zu Verfügung. Durch diese Verbindung von PIX Manager und XDS.b Patient Identity Source wird Zuordnung lokal verwendeter Patientenkennungen zur einrichtungsübergreifend eindeutigen Master Patient ID möglich. Diese Master Patient ID wird in weiterer Folge zu Suche und Abruf von Dokumenten und radiologischen Bildern, sowie zur domänenweiten Protokollierung benötigt (siehe auch XDS.b).

Der PIX Manager erlaubt somit die Verwendung einer lokalen, in einer Einrichtung verwendeten Patienten-ID sowohl

1. zum Abruf der Master Patient ID, als auch
2. zum Abruf, der in den anderen Einrichtungen verwendeten lokalen Patienten-IDs

Jeder Patient wird im PIX Manager als eine Patientenidentität gespeichert, die demographische Daten des Patienten, die Master Patient ID, sowie dessen lokale IDs enthält. Der PIX Manager verknüpft mehrere lokale Patienten IDs, die von unterschiedlichen Einrichtungen zu einer Patientenidentität gemeldet wurden miteinander und bildet somit zusammen mit der Master Patient ID eine Linkgruppe. Die Bildung der Linkgruppe (die Erkennung, dass es sich bei den gemeldeten lokalen Patientenidentiäten um denselben physischen Patienten handelt) erfolgt anhand der demographischen Daten wie z.B. Vorname, Nachname, Versicherungsnummer, Geburtsdatum und Geschlecht.

Die IHE bietet 2 Versionen des PIX Profiles an, die sich auf die Schnittstellen beziehen. PIX ohne Versionszusatz bezeichnet HL7v2 Schnittstellen, PIXv3 bezeichnet HL7v3 Schnittstellen. Für die Transaktion Patient Identity Feed lauten die Transaktionskennungen ITI-8 (HL7v2) und ITI-44 (HL7v3). Für die PIX Query lauten die Transaktionskennungen ITI-9 (HL7v2) und ITI-45 (HL7v3). Für die Auswahl des entsprechenden Profils (HL7v2 oder HL7v3) im Rahmen der Umsetzung sollten folgende Aspekte berücksichtigt werden. Für die einrichtungsinterne Kommunikation (Patient Identity Source – Document Source / Document Consumer) können die heute von vielen Systemen unterstützten HL7v2-Schnittstellen eingesetzt werden. Für die einrichtungsübergreifende Kommunikation (Patient Identity Source / Document Source / Document Consumer – PIX Manager) sollten die auf Webservices basierenden HL7v3 Schnittstellen eingesetzt werden, was folgende Vorteile bringt:

• Netzwerk und Firewall: Webservices verwenden Standard HTTP(s) Ports und keine TCP Socket Verbindungen wie bei HL7v2
• Die Verschlüsselung über HTTP(s) ist einfacher umzusetzen als für HL7v2 Nachrichten (wird von gängigen Applicationservern unterstützt).
• Security Token für das Berechtigungssystem können im Soap Header der Webservice Nachricht integriert werden. Für HL7v2 stehen diese Möglichkeiten nicht zur Verfügung.

Patient Demographics Query (PDQ)

Das IHE-Profil Patient Demographics Query (PDQ) ermöglicht die Abfrage von Patienten und deren demographischen Informationen und Kennungen. Die Abfrage durch den Patient Demographics Consumer erfolgt nicht wie bei PIX auf Basis von IDs, sondern auf Basis von demographischen Daten wie z.B. Vorname, Nachname oder Geburtsdatum.

Der Patient Demographics Supplier ist in der Praxis oft mit dem PIX Manager verknüpft und sie verwenden den gleichen Datenbestand. Der PDQ Supplier ermöglicht über unterschiedliche Suchalgorithmen exakte Suche, Wildcard Suche, sowie phonetische Suche. Als Ergebnis werden im Gegensatz zum PIX Trefferlisten zurückgegeben. Um ein sogenanntes „Patientensurfing" (Wildcardsuche nach Suchkriterien, die auf eine Vielzahl oder auf alle gespeicherten Patienten zutreffen) zu vermeiden, sollte die maximale Trefferanzahl eingeschränkt werden. Übersteigt das erwartete Ergebnis dieses Limit, erfolgt eine Fehlermeldung mit dem entsprechenden Hinweis die Suchkriterien einzuschränken.

Die IHE bietet 2 Versionen des PDQ Profiles an, die sich auf die Schnittstellen beziehen. PDQ ohne Versionszusatz bezeichnet HL7v2 Schnittstellen \[ITI-21\], PDQv3 bezeichnet HL7v3 Schnittstellen \[ITI-47\]. Für den Einsatz der HL7v2 oder HL7v3 Transaktien gilt die gleiche Argumentation wie für das PIX Profil.

Healthcare Provider Directory (HPD)

Das IHE-Profil Healthcare Provider Directory (HPD) ermöglicht die Verwaltung und Abfrage eines Verzeichnisses mit Informationen zu Leistungserbringern im Gesundheitswesen, die im Weiteren kurz als Provider bezeichnet werden. Dabei wir im Profil zwischen Organisationen (z.B. Krankenhäuser, Arztpraxen etc.) und den Personen (Ärzte, Krankenschwestern, etc.) selbst unterschieden. Typische Informationen eines Providers sind Name, Adresse und Fachbereich aber auch Informationen zur elektronischen Kommunikation wie IDs, Emailadressen oder Zertifikate können gespeichert und zur Verfügung gestellt werden. Die Providerinformationen können durch die Provider Information Source oder auch durch einen direkten Zugang zum Provider Information Directory zur Verfügung gestellt werden. Die Transaktion Provider Information Feed ermöglicht es Providerinformationen hinzuzufügen, zu ändern oder zu löschen. Die Abfrage der Informationen erfolgt über die Transaktion Provider Information Query \[ITI-58\] durch den Provider Information Consumer (siehe Abbildung 13). Im Provider Information Directory können auch strukturelle Beziehungen der Provider zueinander abgebildet werden. Unter einer Wurzelorganisation wie z.B. einem Integrierten Versorgungsnetz können verschiedene weitere Organisationen wie z.B. Krankenhäuser oder Arztpraxen angeordnet sein. Die Krankenhäuser selbst können wiederum z.B. aus Fachabteilungen bestehen. Zu jeder der Organisationen können die im Versorgungsnetz handelnden Personen wie z.B. Ärzte mit ihren Informationen speichert werden, so dass flexiebel auch komplexe Organisationsstrukturen abgebildet werden können.

Abbildung 13 Akteure und Transaktionen des HPD Profils

IHE Consistent Time (CT)

Das IHE-Profil Consistent Time (CT) dient der Synchronisierung der Systemzeit zwischen den kommunizierenden Systemen, um Probleme zu verhindern, die inkonsistente Zeitangaben bei der Kommunikation verursachen können. CT bildet damit die Voraussetzung für praktisch jedes andere IHE Profil. Es definiert die Verwendung des Network Time Protocol (NTP), welches in RFC 1305 definiert ist.

Abbildung 14 Akteure und Transaktionen des CT Profils

IHE Audit Trail and Node Authentication (ATNA)

Das IHE-Profil Audit Trail and Node Authentication (ATNA) definiert die grundlegenden Sicherheitsanforderungen an die in einem Netzwerk kommunizierenden Systeme und wird von XDS.b als Sicherheitsinfrastruktur vorausgesetzt. Im Zusammenhang mit der Auditierung von Zugriffen auf Patientendaten werden die zu protokollierenden Ereignisse, das Format der Audit-Informationen sowie die Kommunikation mit einem zentralen Audit Repository zu Speicherung aller Audit-Informationen in einem Netzwerk definiert. Darüber hinaus spezifiziert ATNA die bidirektionale, zertifikatsbasierte Authentifizierung der kommunizierenden Systeme und ermöglicht die Transportverschlüsselung. Gemäß ATNA obliegt die Authentifizierung der Benutzer den Systemen selbst und für die systemübergreifende Authentifizierung von Benutzern wird auf andere IHE-Profile verwiesen. Nähere Informationen zu ATNA finden sich im IHE Technical Framework des Bereiches IT-Infrastruktur.

Abbildung 15 Akteure und Transaktionen des ATNA Profils

Cross-Enterprise User Assertion (XUA)

Das IHE-Profil Cross-Enterprise User Assertion (XUA) gibt die Möglichkeit, Informationen über authentifizierte Benutzer (Personen, Systeme, Anwendungen) über Einrichtungsgrenzen hinweg sicher zu kommunizieren. Dadurch können sich Benutzer innerhalb einer Einrichtung gegenüber ihrem Anwendungssystem oder einer zentralen Benutzerverwaltung authentifizieren und diese Informationen können im Rahmen der einrichtungsübergreifenden Kommunikation mit versendet werden, um im anderen System Berechtigungen oder Protokollierungen vornehmen zu können. Das XUA Profil basiert auf Webservice Security Standards und bildet ein Profil für SAML 2.0 Identity Assertions. Da über XUA neben der Identität eines Benutzers zwar auch weitere Attribute übertragen werden können, diese aber nicht festgelegt sind, wurde ergänzend das IHE Profil XUA++ spezifiziert. In XUA++ ist festgelegt, wie folgende zusätzliche Attribute übertragen werden können:

• Organisation,
• Rolle,
• Einwilligung,
• Patienten-ID,
• Verwendungszweck.

Abbildung 16 Akteure und Transaktionen des XUA Profils

IHE Basic Patient Privacy Consents (BPPC)

Das IHE Profil Basic Patient Privacy Consents (BPPC) ermöglicht es, die Zustimmung des Patienten zum Austausch seiner personenbezogenen Daten (demographische Daten, medizinische Daten, Kontaktdaten, Versicherungsdaten etc.) in einem Netzwerk kooperierender Einrichtungen festzuhalten. BPPC setzt voraus, dass in einem Netzwerk mehrere vordefinierte Datenschutzrichtlinien (Privacy Policies) für den Zugriff auf Patienteninformationen existieren können und der Patient die Möglichkeit hat, aus diesen Richtlinien die zutreffenden auszuwählen und damit die Zugriffsmöglichkeiten auf seine Daten zu definieren. Die Einwilligungserklärung des Patienten (Privacy Policy Acknowledgement Document) ist ein CDA-Dokument, welches die ID der gewählten Datenschutzrichtlinie und ggf. eine textuelle Beschreibung der Einwilligung enthält. Für patientenspezifische, strukturierte und kodierte Einwilligungserklärungen verweist BPPC auf andere Standards wie von HL7 oder OASIS und zukünftige IHE-Profile. Gemäß BPPC werden Datenschutzrichtlinien, welchen der Patient zugestimmt hat, von der entsprechenden Source bzw. vom Consumer der personenbezogenen Daten durchgesetzt, d.h. im Fall von XDS.b von der Document Source bzw. vom Document Consumer, die mit den Akteuren des BPPC Profils Content Creator bzw. Content Consumer zugeordnet sind (siehe Abbildung 17).

Abbildung 17 Akteure und Transaktionen des BPPC Profils

Für das Management von Einwilligungserklärungen selbst (d.h. Erstellen, Speichern, Ändern Abrufen etc.) kann wiederum eine XDS.b Infrastruktur eingesetzt werden. BPPC konzentriert sich auf die eigentliche Einwilligungserklärung selbst und lässt den Transportweg offen, da IHE hier neben XDS bspw. auch XDM und XDR definiert hat. BPPC geht von einer beschränkten Anzahl abzubildender Richtlinien aus. Die Einwilligungserklärung ist dem Patienten zugeordnet, ohne weitere Strukturierungsebenen in der Dokumentensammlung eines Patienten zu berücksichtigen und zwischen vielen verschiedenen Zugriffsberechtigten zu unterscheiden. Aufgrund dieser Einschränkungen ist BPPC grundsätzlich nur für eine grobgranulare Zugriffsteuerung geeignet.

Extensible Access Control Markup Language

Die Extensible Access Control Markup Language (XACML) ist ein XML-basierter OASIS Standard. Die aktuelle Version ist 2. Er bietet eine Syntax, mit der Policies, Autorisierungsanfragen und -antworten definiert werden können. Die gröbste Struktur ist dabei das Policy-Set. Es besteht aus einer oder mehreren Policies, kann aber auch weitere Policy-Sets enthalten. Eine Policy besteht aus Regeln (Rules). XACML spezifiziert außerdem, wie ein Policy-Set interpretiert werden muss, um eine Autorisierungsanfrage, beispielsweise einen Dokumentenzugriff, zu erlauben oder zu verbieten. Damit in einer definierten Systemumgebung, wie einer Affinity Domain, die Zugriffe und Berechtigungen auf Basis von XACML umgesetzt werden können, werden im Standard folgende Rollen definiert, die von konkreten Systemen implementiert werden: Der Policy Administration Point (PAP) ist für die Verwaltung der Policies zuständig. Der Policy Decicion Point (PDP) übernimmt die Evaluation von Anfragen, die Prüfung der Anfrage gegen die vorhandenen Policies und entscheidet über die Autorisierung. Der Policy Enforcement Point (PEP) ist schließlich für die Durchsetzung der Entscheidung des PDP verantwortlich. Der Policy Information Point (PIP) stellt externe Informationen für den PDP zur Verfügung. Verpflichtend ist die Implementierung mindestens eines PEP, eines PDP und eines PAP. Eine Policy ist eine Kombination aus verschiedenen Subkomponenten: Target, Rules, Rule combining algorithms und Obligations (siehe Abbildung 18). Jede Policy bezieht sich auf genau ein Target. Anhand des Targets wird entschieden, ob die Policy relevant für eine bestimmte Anfrage ist. Targets haben Attribute aus folgenden drei Kategorien: Subject, Resource, Action. Diese werden mit den Attributen der Anfrage abgeglichen. Bei einem Match wird die Policy als relevant angesehen und wird evaluiert. Jede Policy kann mehrere Regeln haben. Jede Regel setzt sich zusammen aus: Condition, Effect, Target. Conditions sind Statements über Attribute die bei der Evaluation entweder true, false oder indeterminate zurückgeben. Ein Effect ist das Ergebnis eines klaren Regelergebnisses. Er kann die Werte permit oder deny annehmen. Das Rule target ist analog dem Policy target entscheidend für die Beurteilung, ob die Regel relevant für die Anfrage ist. Das Ergebnis einer Regel hängt vom Rückgabewert ihrer Condition ab. Ist er indeterminate, so gibt die Regel ebenfalls indeterminate zurück. Steht die Condition auf false so gibt die Regel NotApplicable zurück. Gibt die Condition true zurück, ist der Rückgabewert der Regel der des Effects: permit oder deny. Rule combining algorithms sind dafür zuständig, Konflikte zu lösen, die beim Vorhandensein mehrerer Regel entstehen können. Dies ist notwendig, da jede Policy pro Anfrage zu einem Gesamtergebnis kommen muss. Pro Policy ist nur einer erlaubt. Folgende stehen zur Verfügung: Permit-override, Deny-override, First-applicable, Only-one-applicable). Obligations sind die Actions, die der PEP in Verbindung mit dem Enforcement einer Autorisierungsentscheidung ausführen muss. Dies kann beispielsweise die Protokollierung der Transaktion sein. Nach der Evaluation einer Policy werden Obligations an den PEP gesendet. Er ist verpflichtet, diese Actions zusammen mit dem Enforcement auszuführen (vgl. \[[1-]\]).

Abbildung 18 Übersicht der XACML Elemente

Security Assertion Markup Language

Die Security Assertion Markup Language (SAML) ist wie XACML ein XML-basierter OASIS Standard und liegt mittlerweile in Version 2 vor. Sie bietet Mechanismen, wie Authenfizierungs- und Autorisierungsentscheidungen transportiert und ausgetauscht werden können. Im Gegensatz dazu liefert XACML die Werkzeuge eine solche Entscheidung herbeizuführen.

Die SAML-Spezifikation besteht aus insgesamt vier Teilen von denen vor allem die folgenden beiden für den Architekturteil des Cookbooks von Bedeutung sind: Assertions and Protocol beschreibt die Syntax und die Semantik von XML-basierten Asserstions (Zusicherungen) sowie der Request- und der Response-Protokolle. Bindings and Profiles beinhaltet das Mapping dieser Protokolle auf Transportprotokolle wie z.B. SOAP über HTTP oder SOAP über FTP.

Assertions beinalten Informationen über die Authentifizierung eines Subjektes, seine Attribute und die Autorisierunsentscheidung, ob das Subjekt bestimmte Ressourcen zugreifen darf. Demnach gibt es drei Typen von Assertions: Authentication, Attribute und Authorization decision. Das SAML Request- und Resonse-Protokoll definiert ein Standardnachrichtenformat, um die Assertions zutransportieren (vgl. \[[2-]\]).

Ein Mapping der XACML und SAML Authorization Request Query und Response sind im SAML 2.0 Profile of XACML beschrieben. Es werden dort sechs Anfragetypen definiert:

• XACMLPolicyQuery: SAML Request to a PAP for Policies
• XACMLPolicyStatement: SAML Statement containing policies
• XACMLAttribute Query: SAML Request to Attribute Authority for user attributes
• XACMLAttribute Statement: SAML Statement containing one or more attributes
• XACMLAuthzDecisionQuery: SAML Request from PEP to PDP for Authorization Decision
• XACMLAuthzDecisionStatement: SAML Statement containing one or more Authorization Decisions