Lösungsarchitektur

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

Lösungsarchitektur

Das Kapitel Lösungsarchitektur stellt dar, wie unter Berücksichtigung der datenschutz- und sicherheitsrechtlichen Rahmenbedingungen (vgl. Kapitel 2.1) die im Kapitel 3 beschriebenen Use-Cases mithilfe der im Kapitel 4.3 beschriebenen Lösungskomponenten als Bausteine technisch umgesetzt werden können. Dabei wird zunächst von einigen Grundsätzen ausgegangen, die zwingend von allen Architekturen berücksichtigt werden müssen. Die Umsetzung von Datenschutz und Datensicherheit wird erläutert. Für jede o.g. Aktenart wird die auf den Lösungskomponenten basierende Architektur beschrieben sowie die Umsetzung der den Anwendungsfällen zugrundeliegenden technischen Use-Cases mit ihren Datenflüssen und Transaktionen.

Grundsatzentscheidungen

Die nachfolgenden Grundsätze sind der Lösungsarchitektur zu Grunde gelegt:

• Primat des Bürgers: Die Datenhoheit und Steuerung der Zugriffsberechtigungen liegt uneingeschränkt bei ihm. Entweder indem erdiese selbst aktiv steuert oder diese Aufgabe an einen Stellvertreter delegiert.

• Sämtliche Zugriffsberechtigungen und ihre Änderungen sind durch alle an die Akte angebundenen Systeme, wie KIS, PVS, etc. (in der jeweiligen Affinity Domain) umzusetzen.

• Das Recht auf „Vergessen" (Löschung) ist hierbei ein wesentliches Grundprinzip und auf jeden Fall in allen Bereichen zu berücksichtigen.

• Die Steuerung der Zugriffsberechtigungen soll granular (abh. vom jeweiligen Aktensystem) möglich sein, um dem Patienten/Bürger eine dezidierte Möglichkeit zur Wahrung seiner informationellen Selbstbestimmung zu erlauben und die momentane Situation im realen Leben abzubilden.
• Als eine der untersten Ebenen bei der Granularität der Berechtigungssteuerung durch den Patienten/Bürger wird das Dokument definiert. D.h. es gibt keine Berechtigungssteuerung innerhalb eines Dokumentes.
• Semantische Interoperabilität der Dokumenteninhalte und die Kommunikation zwischen verschiedenen Affinity Domains wird in späteren Versionen des Cookbooks angestrebt.

Um einen Leitfaden für die Implementierung von IHE XDS basierten Vernetzungslösungen in Deutschland zu definieren, muss die Lösungsarchitektur grundsätzlich den nachfolgenden Paradigmen folgen.

Flexible Umsetzungen

Die Einhaltung der notwendigen Sicherheitsarchitektur wie auch der Vorgaben zum Nachweis der informierten Einwilligung der Patientinnen und Patienten können in unterschiedlichen Anwendungsszenarien voneinander unterscheiden. Um diese Grundsätze dennoch einzuhalten wird die Architektur verschiedene Umsetzungen ermöglichen.

Transparente Ergänzungen vorhandener Profile und Empfehlungen

Die in der Architektur eingesetzten IHE Profile werden umfänglich, in ihrer vorliegenden Form zum Einsatz gebracht. Die notwendigen, nationalen Ergänzungen, Festlegungen und Empfehlungen sollen sich dabei auf Ausprägungen und inhaltliche Vorgaben für die definierten Informationsobjekte und deren Parameter beschränken. Dabei muss die o.g. Flexibilität erhalten bleiben, um projektspezifische Implementierungen nicht einzuschränken. Die Funktionalitäten der eingesetzten Akteure und Transaktionen sollen in ihrer ursprünglichen Form erhalten bleiben, um den Einsatz bereits vorhandener Lösungen zu ermöglichen.

Unterstützung von feingranularen Zugriffsregelungen

Gerade um eine möglichst breite Nutzung der hier vorgeschlagenen Architektur zu gewährleisten muss eine Reihe von Nutzer-Parametern (ID, Rolle, Organisation, Spezialität, etc.) nutzbar sein. Diese Parameter müssen dann auf den Ebenen Affinity Domain, Patient, Folder und Dokument anwendbar sein.

Ausschließliche Verwendung von existierenden Standards

Alle die IHE Profile ergänzenden Architekturelemente werden explizit auf existierende Standards (z.B. HL7, XACML, SAML) aufgesetzt. Es ist nicht Ziel dieses Dokumentes neue IT Standards zu definieren.

Umsetzung von Datenschutz und Datensicherheit

Für die erfolgreiche Nutzung der beschriebenen Lösungsarchitekturen sind neben den funktionalen Aspekten auch Vorgaben für die Umsetzung der in Abschnitt 2.1.5 beschriebenen Datenschutzanforderungen gemäß Anlage zu §9 BDSG zu berücksichtigen. Im Folgenden sind die Maßnahmen beschrieben, durch die die jeweiligen Datenschutzanforderungen erfüllt werden sollen.

Zugangskontrolle

Die Zugangskontrolle wird dadurch sichergestellt, dass sich alle Benutzer des Gesamtsystems bzw. seiner Komponenten (Personen, Systeme, Anwendungen) sicher authentifizieren müssen. Dies kann auf unterschiedliche Art und Weise geschehen, so dass Benutzernamen und sichere Passwörter, Zugangstoken oder Zertifikate zur Authentifizierung der Nutzer verwendet werden können. Zur sicheren Übermittlung von Informationen authentifizierter Benutzer wird das Profil XUA verwendet, welches in Abschnitt 2.2.9 beschrieben ist. Die bidirektionale, zertifikatsbasierte Authentifizierung bei der Kommunikation von Systemkomponenten sowie die Protokollierung von Nutzerdaten erfolgen auf Basis des ATNA Profils, welches in Abschnitt 2.2.8 beschrieben ist.

Zugriffskontrolle

Die Zugriffskontrolle wird dadurch sichergestellt, dass den authentifizierten Benutzern Rollen zugewiesen werden und diesen Rollen die jeweiligen Zugriffsrechte auf die unterschiedlichen Daten zugeordnet sind. Durch die Verwendung von feingranularen Policies auf Basis von XACML (siehe Abschnitt 2.2.11) können die beteiligten Einrichtungen und Patienten spezifische Zugriffsrechte für Organisationen, Rollen etc. definieren, die das Gesamtsystem bzw. die einzelnen Systemkomponenten bei jedem Datenzugriff (Speichern, Lesen, Ändern Löschen) prüfen und durchsetzen. Die Protokollierung von Datenzugriff erfolgt auf Basis des ATNA Profils, welches in Abschnitt 2.2.8 beschrieben ist.

Weitergabekontrolle

Im Rahmen der Weitergabekontrolle ist durch die Verwendung der feingranularen Policies auf Basis von XACML (siehe Abschnitt 2.2.11) ersichtlich, wer wann welche Daten weitergeben kann und wer dann auf die Daten Zugriff hat. Die Protokollierung von Datenweitergaben erfolgt auf Basis des ATNA Profils, welches in Abschnitt 2.2.8 beschrieben ist. Bei Transport der Daten sind diese zu verschlüsseln und die kommunizierenden Systemkomponenten sind sicher zu authentifizieren, was ebenfalls im ATNA Profil beschrieben ist.

Eingabekontrolle

Die Eingabekontrolle erfolgt durch Verwendung des ATNA Profils, da alle Datenzugriffe im zentralen Audit Repository gespeichert und ausgewertet werden können.

Auftragskontrolle

Im Rahmen der Auftragskontrolle muss beachtet werden, dass administrative und medizinische Rollen und die entsprechenden Zugriffsberechtigungen strikt getrennt werden und nur auf Daten entsprechend den Weisungen des Auftraggebers zugegriffen werden kann. Die Auftragskontrolle umfasst ebenfalls die verschlüsselte Ablage der medizinischen Daten. Dies kann durch systembasierten Datenverschlüsselung erfolgen.

Trennungsgebot

Das Trennungsgebot wird dadurch umgesetzt, dass administrative Patientendaten, Dokumente und Bilder zu jeder Zeit unabhängig voneinander gespeichert, verändert, übermittelt, gesperrt oder gelöscht werden können. Diese Forderung kann durch die Verwendung spezifischer Transaktionen und Möglichkeiten der Profile PIX, XDS.b, XDS-I.b und XDS Metadata Update sowie XACML durchgesetzt werden.

Standardisierte Lösungsmodule

Hier folgen die Beschreibungen der standardisierten Lösungsmodule, die von allen Aktentypen verwendet werden.

Patientenidentifikation

Für das Thema Patientenidentifikation werden üblicherweise 3 unterschiedliche Lösungsansätze diskutiert. Alle 3 Lösungsansätze führen zur Erzeugung einer XAD-Pid und damit zum "Anlegen einer Patientenakten".

1. Master Patient Index
2. Patientenregister
3. Verteilte Erstellung ohne Abfragemöglichkeit

Im folgenden wird erläutert wie die Lösungsansätze im Detail umgesetzt werden können.

Master Patient Index

Ein Master Patient Index (MPI) speichert Verknüpfungen zwischen lokalen Patientenidentitäten. Üblicherweise stellt ein MPI ausserdem für jeden eindeutig identifizierten Patienten eine eindeutige ID (Master Patient ID) und einen kanonischen Datensatz zur Verfügung, der die neusten und genausten Stammdaten des Patienten sammelt. Der MPI hat üblicherweise die Aufgabe Verknüpfungen zwischen Patienten automatisch zu erstellen oder einem Benutzer in einer sogenannten Clearingstelle Verknüpfungsvorschläge zu unterbereiten.

Minimal erlaubt ein IHE konformer MPI die Anlieferung von lokalen Patientenidentitäten per Patient Identity Feed (PIX Feed) und die Abfrage der Master Patient ID oder der in den anderen Einrichtungen verwendeten lokalen Patienten-IDs per PIX Query. Um einem Datenaustausch per IHE XDS zu ermöglichen, muss der MPI natürlich auch seine Mater Patient IDs komplett oder in Teilen mit der XDS Document Registry per Patient Identity Feed (hier als Patient Identity Source) synchronisieren.

Optional kann ein MPI auch eine Suche per PDQ anbieten, wobei üblicherweise der kanonische Datensatz, die Master Patient ID und die lokalen IDs zurückgegeben wird. Eine Suche per GUI wird häufig auch angeboten. Da oft nicht alle anzubindenden Systeme ihre Patientenidentitäten übertragen können oder wollen, gibt es ausser den vom MPI geführten Verknüpfungen häufig auch noch patientenführende Systeme, die ihre eigenen Patienteneinträge um die Master Patient ID erweitern. Dadurch ergeben sich Szenarien in denen der MPI nur einen Teil der Verknüpfungen zwischen Patientenidentitäten speichert und verwaltet. Die lokal geführten Verknüpfungen sind natürlich nicht durch die Ähnlichkeitsalgorithmen des MPI geprüft und können nicht zentral verwaltet werden.

Die Übertragung der Patientenidentität über ein Medium — wie z.B. ein Papierausdruck oder eine Smartcard — kann auch bei einem MPI genutzt werden.

Patientenregister

Ein Patientenregister verwaltet zentrale Patientenidentitäten. Im Gegensatz zu einem MPI speichert ein solches Register üblicherweise nicht die Verknüpfungen zwischen den lokalen Identitäten. Das Patientenregister lässt sich über PDQ oder eine GUI abfragen und überlässt es den anfragenden Systemen die Verknüpfung zu ihrer lokalen Patienten-ID abzuspeichern. Um einem Datenaustausch per IHE XDS zu ermöglichen, muss das Patientenregister natürlich auch seine Einträge bzw. die IDs komplett oder in Teilen mit der XDS Document Registry per Patient Identity Feed (als Patient Identity Source) synchronisieren.

Die Daten des Patientenregisters werden üblicherweise über eine GUI gepflegt, wobei gerade zum initialen Befüllen auch ein Batch Import aus einer autoritativen Quelle in Frage kommt.

Optional kann auch der PIX Query Mechanismus genutzt werden um zentrale Patientenidentitäten abzufragen. Da im Patientenregister aber keine Verknüpfungen zu lokalen Patienten-IDs gespeichert werden, kann eine solche Abfrage aber nur über eine alternative ID des Patienten — wie z.B. die Nummer der Krankenversicherten-Karte — durchgeführt werden.

Die Übertragung der Patientenidentität über ein Medium — wie z.B. ein Papierausdruck oder eine Smartcard — kann auch bei einem Patientenregister genutzt werden.

Verteilte Erstellung ohne Abfragemöglichkeit

In diesem Ansatz wird ein Algorithmus eingesetzt, der sicherstellt, dass nicht miteinander verbundene Systeme unabhängig voneinander Patienten-IDs erstellen können, ohne dass es zu Überschneidungen kommt. Dies ermöglicht es den patientenführenden Systemen eigenständig eine zentrale ID für Austauschzwecke zu definieren (d.h. eine XAD-PID).

Eine XDS Document Registry erwartet eine einzige Quelle für alle Patient Identity Feed Nachrichten. Alle zusammengeschlossenen Systeme, die XAD-PIDs erstellen, müssen daher die gleiche OID als Namespace Identifier verwenden. Ausserdem muss ein Proxy die Nachrichten sammeln und an die Document Registry weiterleiten. Dadurch wird sichergestellt, dass die Document Registry nur einen Kommunikationspartner sieht und sich dieser standard-konform verhält.

Alternativ zu dieser Vorgehensweise kann jedes System seine eigene Affinity Domain im Zusammenspiel mit einer Registry spielen. Über Cross-Affinity-Gateways lassen sich dann die anderen Registries befragen.

Da es prinzipbedingt keine Online-Abfragemöglichkeit gibt, muss die Patientenidentität bei diesem Ansatz über ein Offline Medium übertragen werden. Zur Zeit bietet sich hier ein Papierausdruck an, der dem Patienten mitgegeben wird oder an den Patienten oder einen Arzt verschickt wird. Alternativ könnten in Zukunft auch Smartcards oder die eGK als Transport Medium genutzt werden. Aber auch das IHE-Profil XDM bietet sich hier an.

Solange die Eindeutigkeit sichergestellt ist und die Patienten-ID als eine OID ausgedrückt werden kann, bleibt die Wahl des Algorithmus dem Hersteller der Austauschplattform überlassen. Die Algorithmen reichen in der Komplexität von einfachen Präfixen, die den Namensraum statisch aufteilen, bis zu den gebräuchlichen UUIDs nach RFC 4122.

Zusammenfassung

Die folgende Tabelle vergleicht welche Features bei welchem Ansatz sinnvoll genutzt werden können. Pro Feature wird gelistet ob es ein Kernaspekt ist, ohne den der Ansatz nutzlos ist ("notwendig"), ob es ein Feature ist das mit dem Ansatz sinnvoll verbunden werden kann ohne notwendig zu sein ("optional") oder ob das Feature normalerweise nicht sinnvoll mit dem Ansatz kombinierbar ist ("-").

Übersicht der vorgestellten Lösungsansätze zur Patientenidentifikation

Feature	Master Patient Index	Patientenregister	Verteilte Erstellung
PIX Feed annehmen (ITI-8 oder ITI-44 als Patient Identifier Cross-reference Manager)	notwendig	-	-
PIX Query beantworten (ITI-9 oder ITI-45 als Patient Identifier Cross-reference Manager)	notwendig	optional	-
PIX Update senden (ITI-10 oder ITI-46 als Patient Identifier Cross-reference Manager)	optional	-	-
PDQ Patient Demographics Query (ITI-21 oder ITI-47 als Patient Demographics Supplier)	optional	notwendig	-
PIX Feed an die XDS Document Registry senden (ITI-8 oder ITI-44 als Patient Identifier Source)	notwendig	notwendig	notwendig
Suche nach zentraler Patientenidentität per GUI	optional	notwendig	-
Hinzufügen einer zentralen Patientenidentität per GUI	-	notwendig	-
Identitätsverknüpfungen können dezentral gespeichert werden	optional	notwendig	notwendig
Identitätsverknüpfungen können zentral gespeichert werden	notwendig	-	-
Übertragung der XAD-PID auf einem Medium	optional	optional	notwendig

Benutzerauthentifizierung und -identifikation

Einrichtungsübergreifenden Datenaustausch stellt besondere Ansprüche an Datenschutz (siehe Kapitel 4.2). Anforderungen bzgl. Nachvollziehbarkeit und Zugriffkontrolle sind grundsätzlich nur mit Hilfe eines personalisierten Zugriffs auf die zu schützenden Daten erfüllbar. Um die Zugriffsrechte zu definieren und zu prüfen, werden in der Regel weitere Eigenschaften der Nutzeridentitäten (z. B. Organisationszugehörigkeit) und des Kontexts (z. B. Verwendungsweck) herangezogen. Daraus ergeben sich die folgenden Rahmenanforderungen:

• Mindestens eine Benutzerverwaltung mit unterscheidbaren Nutzeridentitäten (Benutzeridentifikation) ist etabliert.
• Es kann sichergestellt werden, dass der der Benutzer und die angegebene Benutzeridentität übereinstimmen (Benutzerauthentifizierung).
• Zusätzliche Merkmale der Benutzeridentität sind bekannt und abrufbar (Organisationsverzeichnis), ebenso Merkmale des Nutzungskontexts

Von einer Passwort-basierten Authentifizierung für Systeme wird abgeraten, da die Speicherung des Passworts im Klartext ein Sicherheitsrisiko darstellt und Best Practices des Passwort-Managements — wie kurze Gültigkeitsfristen für Passwörter, forcierte Änderungsaufforderungen beim Login, etc. — nicht sinnvoll eingesetzt werden können.

Eine 2-Faktor Authentifizierung ist generell zu empfehlen, aber keine zwingende Anforderung für ein solches System. In der Literatur zu Identity Management Systemen unterscheidet man üblicherweise Föderiertes Identitäts-Management von zentralem Identitäts-Management. Bei Vernetzungsprojekten im deutschen Gesundheitswesen muss aufgrund der Kombination aus heterogenen Systemlandschaften und hohen Sicherheitsanforderungen in den meisten Fällen ein gemischter Ansatz verwendet werden. Im Folgenden wird daher nicht weiter darauf eingegangen ob das resultierende Sicherheitssystem als zentral oder als föderiert interpretiert werden sollte.

Die Benutzeridentitäten des jeweiligen angeschlossenen Systems werden im Folgenden als "lokale Benutzeridentitäten" bezeichnet. Es ist nicht zu erwarten, dass angeschlossene Systeme wie ein KIS oder ein PVS/AIS ihre eigene Benutzerverwaltung aufgeben und stattdessen auf eine gemeinsame, an das einrichtungsübergreifende Aktensystem angeschlossene Benutzerverwaltung aufsetzen. Daher wird es nötig sein für die einrichtungsübergreifende Kommunikation entweder ein Mapping von der lokalen Benutzeridentität auf die zentrale Benutzeridentität durchzuführen oder direkt lokale Benutzeridentitäten einzusetzen (siehe Abschnitt Verwendung lokaler Benutzeridentitäten).

Außer der Entscheidung hinsichtlich des Mappings auf eine zentrale Benutzeridentität, muss auch geklärt werden, wer die Benutzeridentität über eine kryptografisch gesicherte Aussage (eine Assertion) bestätigt. Die Möglichkeiten der Realisierung werden im Weiteren beschrieben.

Charakterisierung der Lösung

Die Kernaufgabe der Benutzeridentifikation und -authentifizierung ist es sicherzustellen, dass beim Empfänger zusammen mit einer Transaktion eine Aussage über die Person ankommt, die die Transaktion initiert hat. Diese Aussage (Assertion) muss vertrauenswürdig und unversehrt sein. Ebenfalls muss der Inhalt der Aussage dafür ausreichen, dass der Empfänger über die Zulässigkeit der Transaktion entscheiden kann. Die Assertion enthält die Information über den Benutzer, der die Transaktion angestoßen hat, über dessen Eigenschaften sowie über den Kontext der Transaktion. Die Erstellung und Überprüfung der Assertion wird durch die Akteure der Integrationsprofile XUA/XUA++ (siehe 2.2.9) umgesetzt: X-Service-User, X-Service-Provider, User Authentication Provider und X-Assertion Provider. Die Gruppierung eines User Authentication Provider und X-Assertion-Provider entspricht dem gängigen Verständnis eines Security Token Service (STS). Die vom jeweiligem Zugriffskontext unabhängigen Zusatzinformation für Benutzeridentitäten werden durch eine Healthcare Provider Directory (siehe 2.2.6) exponiert und von einem Provider Information Consumer abgefragt. Das Zusammenspiel der genannten Komponenten wird im Weiteren beschrieben.

Zuordnung zwischen der lokalen und der zentralen Benutzeridentität

Bei der Handhabung der zentralen Benutzeridentität sind folgende Ansätze denkbar:

• zentrale Benutzeridentität wird nicht verwendet
• zentrale Benutzeridentität wird interaktiv eingegeben.
• das initiierende System unterhält ein Mapping zwischen lokalen und zentralen Benutzeridentitäten, entweder statisch oder dynamisch.

Die ersten beiden Fälle werden in Abschnitten Verwendung lokaler Benutzeridentitäten und Lokale Eingabe der zentralen Benutzeridentität diskutiert. Die dritte Alternative wird in den beiden darauf folgenden Abschnitten Dynamisches Mapping der Benutzeridentität und Statisches Mapping der Benutzeridentität erläutert. Anschliessend werden die technischen Aspekte detailliert dargestellt.

Verwendung lokaler Benutzeridentitäten

Um lokale Benutzeridentitäten zu verwenden, sendet das anfragende System eine (SAML) Identity Assertion und mehrere Attribute Assertions, die den Benutzer und seine Attribute so detailliert beschreiben, dass das Berechtigungsmodul des zentralen Aktensystems eine sinnvolle Berechtigungsentscheidung treffen kann. Dadurch müssen für diese Benutzer keine zentralen Benutzeridentitäten gepflegt werden.
Bei der ausschließlichen Verwendung lokaler Benutzeridentitäten kann auf eine zentrale Benutzerverwaltung verzichtet werden. Üblich ist jedoch ein begrenzter Einsatz von lokalen Benutzeridentitäten aus Systemen, die viele lokale Benutzer verwalten und deren Personal häufig wechselt, d.h. vor allem größere Krankenhäuser. Da die lokalen Benutzeridentitäten nicht in einem zentralen Healthcare Provider Directory (HPD) bekannt sind, können sie nicht ohne weiteres bei der Berechtigungsvergabe verwendet werden. Um trotzdem eine Vergabe von Berechtigungen an Teilnehmer mit nur lokal gepflegten Benutzeridentitäten zu ermöglichen, sollten zumindest die Organisationsstrukturen von Einrichtungen, die lokale Benutzeridentitäten verwenden, zentral bekannt sein. Die Organisationen werden als Organizational Providers im HPD abgebildet, mitsamt ihren Beziehungen untereinander, aber ohne die zugehörigen Benutzer (d.h. ohne Individual Providers). Dabei ist es entscheidend, dass die Systeme, die lokale Benutzeridentitäten verwenden, in den Attribute Assertions die gleichen Organisationsidentifikatoren verwenden, die auch für die Berechtigungsvergabe verwendet werden.

Die Organisationen sollten zumindest auf einer Granularitätsstufe zentral bekannt gemacht werden, die eine sinnvolle Berechtigungsvergabe ermöglicht. Zum Beispiel reicht eine einzelne Organisation "Universitätsklinikum X" nicht aus. Selbst eine Aufteilung auf Fachkliniken (z.B. "Universitätsklinikum X - Chirurgische Klinik") kann schon zu grobgranular sein. Sinnvoll ist eine Abbildung der zu berechtigenden Organisationen im zentralen System, die den Kreis der dadurch berechtigten Ärzte auf ca. 20 oder weniger beschränkt (z.B. "Universitätsklinikum X - Chirurgische Klinik - Gefässchirurgie"). Wenn eine Einrichtung, die lokale Benutzeridentitäten verwaltet, es anderen Teilnehmern ermöglichen will, ihre lokal verwalteten Benutzer direkt zu berechtigen, muss sie zusätzlich eine HPD Provider Information Query Schnittstelle anbieten. Der zentrale HPD Server kann dann als virtuelles Verzeichnis auftreten und Anfragen nicht nur mit den eigenen Daten beantworten, sondern auch die Antworten aus den dezentralen Verzeichnissen aggregieren. Die Möglichkeit die lokalen Benutzeridentitäten zentral abzufragen, kann auch für andere Anwendungen sinnvoll genutzt werden, z.B. für Addressbuchfunktionen in einem Secure Messaging Dienst.

Lokale Eingabe der zentralen Benutzeridentität

Dieser Ansatz setzt die Eingabe des zentralen Benutzernamens und des zugehörigen Passworts durch den Benutzer voraus. Die Aufgabe der Zuordnung einer zentralen Identität wird dadurch auf den Benutzer verlagert. Die Assertion mit der zentralen Benutzeridentität wird von einem zentralen Service geholt – der Ablauf deckt sich mit der technischen Lösung „Zentrale Ausstellung der Assertion“.

Im Gegensatz zu den anderen hier vorgestellten Methoden ist die Nutzung für den medizinischen Benutzer eher umständlich. Dies kann durch eine temporäre Speicherung des Passworts zwar gelindert werden, aus Sicherheitsgründen sollte aber keine permanente Speicherung des Passworts im anfragenden System durchgeführt werden. Ein sinnvoller Kompromiss wäre es, das Passwort im flüchtigen Speicher für die Dauer der Session zu halten, um bei zeitlich kurz aufeinanderfolgenden Abfragen und Additionen zur zentralen Akte das Passwort nicht mehrfach eingeben zu müssen. Ein Vorteil der manuellen Eingabe von zentralem Benutzernamen und Passwort gegenüber den anderen Ansätzen ist die Möglichkeit die Eingabe bei Installationen einzusetzen die — trotz anderslautender Datenschutz-Empfehlungen — einen lokalen Benutzeraccount für mehrere Benutzer verwenden (z.B. ein Login für alle Mitarbeiter einer Station eines Krankenhauses). Im Gegensatz zu einer Arztpraxis gibt es bei einem Stationslogin üblicherweise eine größere Anzahl an pflegerischen und ärztlichen Benutzern, die somit auch als unterschiedliche Benutzer in der zentralen Akte auftreten sollten. Während das lokale System keine Unterscheidung zwischen den unterschiedlichen Benutzern macht, kann die Kommunikation mit der zentralen Akte somit trotzdem einen spezifischen Benutzerkontext verwenden.

Dynamisches Mapping der Benutzeridentität

Die Ermittlung der zentralen Benutzeridentität (Schritt 0) besteht hier in der Abfrage an das HPD. Das lokale System erfragt über einen eigenen Identifier oder über einen unabhängig vergebenen Identifier den zentralen Benutzernamen des lokalen Benutzers und erstellt dadurch eine Verknüpfung zwischen der lokalen und der zentralen Benutzeridentität. Der zentrale Benutzername wird durch eine nicht signierte SAML Assertion im SOAP Header der Antwort übertragen. Um die Verknüpfung zwischen dem lokalen und dem zentralen Benutzeraccount herzustellen, muss ein im lokalem System gepflegter Identifikator auch im zentralen HPD vorhanden sein. Idealerweise werden dazu unabhängig vergebene Identifikatoren verwendet, d.h. Identifikatoren die landesweit (oder zumindest regional) eindeutig und öffentlich bekannt sind. Im kassenärtzlichen Bereich ist für Ärzte die LANR (Lebenslange Arztnummer) dafür geeignet. Im stationären Bereich gibt es für ärztliche Benutzer derzeit keinen äfquivalenten Identifikator. In einigen Fällen lässt sich ggf. die Mitgliedsnummer der jeweiligen Ärztekammer nutzen. Jedoch muss dies aus Sicherheitsgründen mit den Ärztekammern abgesprochen werden, da einige Ärztekammern die Mitgliedsnummer als Teil des Logins für einen Mitgliederbereich nutzen. In Zukunft lässt sich der Heilberufsausweis als Quelle einer eindeutigen Identifikation nutzen, da der Distinguished Name des Zertifikats eindeutig und nicht geheim sein sollte. Wenn kein von unabhängiger Stelle vergebener Identifikator verwendbar ist, kann ein System alternativ auch einen "lokalen" Provider Identifier zur zentralen Benutzeridentität hinzufügen. Ein solcher lokaler Identifier wäre z.B. die Benutzernummer im KIS. Aus Sicherheitsgründen sollte hier nicht der (lokale) Benutzername verwendet werden, der eine Anmeldung im lokalen System erlaubt (d.h. die Arztnummer im KIS eignet sich, der Benutzername des Arztes im KIS eignet sich nicht.) Ähnlich wie bei einem MPI würden die Quellsysteme ihre Benutzeridentitäten über die Feed Transaktion abliefern und das Healthcare Provider Directory würde voll- oder halbautomatisch Zuordnungen zu einer zentralen Benutzeridentität herstellen und den lokalen Provider Identifier zum zentralen HPD Eintrag hinzufügen. Ein solcher Mechanismus kann über die HPD Provider Information Feed [ITI-59] Transaktion angestoßen werden, wenn das Healthcare Provider Directory eine automatische "disambiguation" unterstützt. Da die für die Zuordnung verwendeten Provider Identifier im Healthcare Provider Directory gespeichert werden, sollte das lokale System den durch die ITI-58 Query ermittelten zentralen Benutzernamen nicht persistent im eigenen System ablegen. Die exklusive permanente Speicherung im HPD stellt sicher, dass Änderungen an der Zuordnung eines Provider Identifiers im HPD auch Auswirkungen im lokalen System haben und es somit nicht zu einem Auseinanderlaufen der beteiligten Systeme kommt. Um niedrige Antwortzeiten bei der Arbeit mit dem einrichtungsübergreifendem Aktensystem zu ermöglichen ist eine temporäre Zwischenspeicherung des zentralen Benutzernamens (d.h. ein Caching) aber durchaus angebracht und sinnvoll. Der Empfänger der per Provide X-User Assertion [ITI-40] übertragenen Benutzeridentität verwendet dann die Provider Information Query [ITI-58] aus IHE HPD um die nicht bekannten Benutzerattribute abzurufen. Der Ansatz ein automatisches Mapping der Benutzeridentität durchzuführen ist für mittelgroße Krankenhäuser sinnvoll. Kleinere Krankenhäuser mit wenigen Benutzern können effizienter mit einem manuellen Mapping arbeiten (siehe Abschnitt "Manuelles Mapping durch einen Administrator"), um die Integration möglichst einfach zu gestalten. Größere Krankenhäuser können einen umfangreichen Abgleich der Benutzeridentitäten vermeiden, in dem sie ihre lokalen Benutzeridentitäten verwenden und einen eigenen HPD Dienst anbieten (siehe Abschnitt "Verwendung lokaler Benutzeridentitäten").

Statisches Mapping der Benutzeridentität

In vielen Fällen ist die Minimallösung, die zentrale Identität des Benutzers durch einen Administrator im lokalen System fest zu konfigurieren, durchaus ausreichend (z.B. in einer Arztpraxis). Der Administrator erfährt die zu konfigurierenden Benutzernamen über einen beliebigen Mechanismus — z.B. per Post, Email, ein Webportal, ein HPD client. Der zentrale Benutzername wird im lokalen System permanent gespeichert. Anschliessend besteht die Ermittlung der zentralen Benutzeridentität nur darin, die ID vom lokalen Speicher abzurufen. Das lokale System fügt den Anfragen an das zentrale Aktensystem eine selbst-ausgestellte SAML Assertion hinzu, die den zentralen Benutzernamen beinhält. Wenn das anfragende System mehrere zentrale Benutzernamen gespeichert hat, muss es über den gerade aktiven Benutzer oder Mandanten den passenden zentralen Benutzernamen auswählen. Das zentrale Aktensystem benutzt den Benutzernamen aus der Assertion um die Benutzerattribute im zentralen Healthcare Provider Directory nachzuschlagen. Die vom lokalen System ausgestellte Assertion entspricht prinzipiell den Vorgaben des XUA Profils mit den weiter unten beschriebenen Anpassungen für lokal ausgestellte Assertions. Der Ansatz eignet sich besonders für Arztpraxen und Einrichtungen mit wenigen Benutzern (z.B. kleinere Krankenhäuser, MVZs). In Arztpraxen (Individual- und Gemeinschaftspraxen) wäre eine Identifikation einzelner Benutzer (z.B. ArzthelferInnen) nicht praxisgerecht, da der Arzt dort üblicherweise Tätigkeiten an seine MitarbeiterInnen delegiert und diese im Berechtigungskontext des Arztes ausgeführt werden sollten. Entsprechend sollten Berechtigungen auch auf der Ebene der Arztpraxis gewährt werden, um die realen Zugriffsmöglichkeiten für alle Teilnehmer transparent sichtbar zu machen. Bei MVZs und Praxisgemeinschaften, die ihre Daten durch unterschiedliche Mandanten trennen, könnte eine zentrale Benutzeridentität pro Mandant verwendet werden. In einem kleinen Krankenhaus würde für jeden Benutzer, der einen Zugriff auf das zentrale Aktensystem benötigt, jeweils eine eigene zentrale Benutzeridentität geführt werden.

Zentrales Healthcare Provider Directory

Durch ein zentrales Benutzerverzeichnis sind alle zentralen Benutzeridentitäten und alle für die Zugriffskontrolle relevanten Organisationen über einen zentralen Dienst abrufbar. Ein solcher zentralisierter Dienst sollte in einem IHE-basierten System durch den Akteur Provider Information Directory des IHE HPD Profils (siehe 2.2.6) abgebildet werden. Ausser den im HPD Profil beschriebenen Funktionalitäten, ist es für einen Verzeichnisdienst in vielen Fällen sinnvoll auch einen WS-Trust Secure Token Service (STS) zu implementieren. Der STS kann über die Request Security Token Transaktion eine SAML Assertion bezüglich der Identität und Attribute eines Benutzers ausstellen (siehe Abschnitt "Eingabe des zentralen Benutzernamens und eines Passworts durch den Benutzer"). Eine besondere Variante des zentralen Benutzerverzeichnisses ist ein hierarchischer Verzeichnisbaum. Der zentrale Dienst ist dann nur ein virtuelles Verzeichnis, das die Anfragen an die untergeordneten Verzeichnisse weiterleitet und die Antworten bündelt und normalisiert. Ein hierarchisches System unterscheidet sich in der Pflege der Verzeichnisdaten (die dezentral durchgeführt wird), verhält sich für die Suche und die Authentifizierung aber effektiv wie ein einziges System (siehe Abschnitt "Verwendung lokaler Benutzeridentitäten").

Eigenschaften der Assertion

Das ITI TF Supplement "Cross-Enterprise User Assertion - Attribute Extension (XUA++)" beschreibt wie

• der Klarname des Benutzers (Subject ID),
• die Organisations-ID (Subject Organization ID),
• der Organisationsnamen (Subject Organization),
• die Home Community ID (homeCommunity ID),
• den Verwendungszweck (Purpose of Use),
• die Rolle (Subject-Role) und
• die gerade relevante Patienten-ID (Patient Identifier Attribute)

in einer SAML Assertion übertragen werden können. Jedes Attribut kann dabei laut XUA++ nur einen Wert annehmen, d.h. eine Übertragung von mehreren Rollen ist nicht möglich. Das empfangende zentrale Aktensystem kann viele dieser Informationen auch aus dem vorhandenem zentralen Benutzerverzeichnis (HPD) abfragen. Wenn ein lokales System eines dieser Attribute jedoch in der Assertion mitliefert, muss das Aktensystem ausschliesslich den AttributeValue aus der Assertion für Berechtigungsprüfung, Auditierung und alle anderen Zwecke verwenden. Eine Ausnahme stellen dem zentralen Aktensystem nicht bekannte oder verständliche Werte dar. Das heisst, wenn das anfragende System einen im zentralen Aktensystem geführten Rollencode mitgibt, gilt diese Rolle als einzige Rolle des Benutzers für diese Transaktion, auch wenn für den Benutzer noch andere Rollen im Benutzerverzeichnis geführt werden. Dadurch können z.B. auch Belegarzt-Konstellationen sinnvoll abgebildet werden: Ein Belegarzt ist im HPD zwei Organisationen zugeordnet (KH und eigene Arztpraxis), aber arbeitet entweder gerade mit dem KIS des KH oder mit seinem AIS. Da das KIS ggf. Kopien der Daten anfertigt und sie anderen Krankenhausärzten zur Verfügung stellt, ist es angebracht einen unterschiedlichen Sicherheitskontext für den Zugriff über das KIS zu etablieren.

Das in diesem Dokument beschriebene Sicherheitssystem hat folgende, über XUA hinausgehende Anforderung:

Beim ersten Mapping Ansatz (siehe Abschnitt "Verwendung lokaler Benutzeridentitäten") sind die verwendeten Benutzeridentitäten nicht unbedingt in einem zentralen Verzeichnis vorhanden. Daher müssen bei diesem Ansatz ausser der Patienten-ID auch folgende Attribute in der Assertion vorhanden sein:

• der Klarname des Benutzers (Subject ID),
• die Organisations-ID (Subject Organization ID),
• der Organisationsnamen (Subject Organization) und
• die Rolle (Subject-Role).

Wenn dies für die durchzuführende Transaktion angebracht ist, können optional auch der Verwendungszweck und die Home Community ID als Teil der Assertion übertragen werden.

Zentrale Ausstellung der Assertion

Diese Architektur entspricht dem Integrationsprofil XUA. Neben den zusätzlichen Festlegungen für Assertion-Inhalte (siehe oben) werden im Weiteren zusätzliche Annahmen getroffen. Diese technische Lösung sollte nur dann eingesetzt werden, wenn der in Abschnitt 4.3.2.4 beschriebene Mapping Ansatz verwendet wird, da ansonsten die Assertion lokal ausgestellt wird.

Das lokale System, nachdem es den zentralen Benutzernamen und das Passwort vom Benutzer eingeholt hat, stellt eine WS-Trust 1.3 konforme Request Security Token (RST) Anfrage an einen mit dem HPD gekoppelten X-Assertion Provider. Die Anfrage wird (wie jegliche hier beschriebene Kommunikation) über beidseitig authentifiziertes HTTPS abgesichert. Der Benutzername und das Passwort werden als UsernameToken (http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf) mit Password (im Klartext) im OnBehalfOf Element der Request Security Token Anfrage übermittelt (http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.html#_Toc162064988). Der X-Assertion Provider (hier ein WS-Trust STS) ist mit dem HPD gekoppelt und überprüft die Benutzername - Passwort Kombination. Wie diese Überprüfung kommuniziert wird, kann von der Implementierung festgelegt werden. Da das HPD Profil DSML zur Kommunikation verwendet wird, bietet sich eine Authentifizierung per DSML über den "BIND" Mechanismus oder den "whoami" Mechanismus an. Nach einer erfolgreichen Prüfung vom zentralen Benutzernamen und Passwort, stellt der WS-Trust STS eine Assertion aus und kommuniziert diese in einer WS-Trust Request Security Token Response. Die Assertion wird dabei vom STS signiert. Als SubjectConfirmationMethod wird "bearer" verwendet. Es muss in diesem Fall ausserdem "PasswordProtectedTransport" als Authorization Context Class verwendet werden (http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf). Die so erhaltene Identity Assertion, die vom X-Assertion Provider signiert wurde, fügt der X-Service Consumer in den durchzuführenden SOAP Aufruf im SOAP Header als WS-Security spezifizierte SAML Assertion ein, wie es in der IHE XUA Transaktion Provide X-User Assertion [ITI-40] beschrieben wird. Die Assertion kann optional auch noch durch eine Signatur des X-Service Consumers an die spezifische Nachricht gebunden werden. Dies ist nicht zwingend notwendig, da durch die HTTPS Verbindung ein Auslesen des Tokens (und somit die Verwendung in einem "Replay" Angriff) verhindert werden kann.

Der Benutzer gibt nur den Benutzernamen und das Passwort ein; die zugehörigen Attribute wie Rolle, Organisation, Fachrichtung, etc. sind nicht unbedingt im anfragendem System verfügbar, weil sie entweder dort anders geführt werden (z.B. in anderen Kodiersystemen oder kombiniert mit anderen Attributen) oder einfach nicht bekannt sind. Daher muss das zentrale Aktensystem die Attribute des Benutzers in einem zentralen Verzeichnis per HPD nachschlagen. Dazu verwendet das empfangende System (d.h. der X-Service Provider) einen Provider Information Consumer, der über die Provider Information Query [ITI-58] die Attribute des über die Assertion identifizierten Benutzers abfragt. Da der X-Assertion-Provider in Form eines WS-Trust Secure Token Service (STS) in diesem Ansatz mit dem Actor HPD gruppiert ist, hat der STS die Möglichkeit AttributeStatements eigenständig hinzuzufügen. Dies gilt für die (auch) im HPD gepflegten Attribute Organization Name, Organization ID, Subject ID, Subject Role und homeCommunity ID. Da die Assertion vom STS ausgestellt und signiert wird, müssen die Attribute als Claims in der Request Security Token Nachricht vorliegen. Während das automatische Hinzufügen von Attributen, die nicht per Claim vom X-Service User angefragt wurden, durchaus sinnvoll ist, sollte das Prüfen von Claims vermieden werden. Das lokale System kann den gerade relevanten Sicherheitskontext normalerweise weitaus besser festlegen. Wenn zum Beispiel ein Benutzer nicht der Organisation KH 1 zugeordnet ist, er aber konsiliarisch hinzugezogen wird und seinen (zentralen) Benutzernamen und sein Passwort in der entsprechenden KIS-Maske eingibt, ist der Claim "Organization=KH1" korrekt, obwohl er vom zentralen HPD nicht verifiziert werden kann. Ein weiterer Aspekt ist, dass ein gewisses Vertrauen in das lokale System sowieso schon notwendig ist, da einige Claims überhaupt nicht automatisch zentral geprüft werden können (Patienten-ID, Verwendungszweck).

Lokale Ausstellung der Assertion

In diesem Ansatz ist der X-Assertion Provider mit dem X-Service User gruppiert. Dies kann sinnvoll in den unter Verwendung lokaler Benutzeridentitäten, Dynamisches Mapping der Benutzeridentität und Statisches Mapping der Benutzeridentität beschriebenen Mapping Ansätzen verwendet werden. Da hier das anfragende System die Assertion selbst ausstellt, kann es ohne weiteres beliebige Attribute Statements hinzufügen, die dem zentralen Aktensystem die oben beschriebenen Attribute des Benutzers mitteilen. Bei einer Gruppierung der Actors X-Service User und X-Assertion Provider ergeben sich gegenüber den aktuellen Vorgaben des XUA Profils zwei Vereinfachungen. Erstens ist als 'SubjectConfirmationMethod' "SenderVouches" zu verwenden. Dies signalisiert dem Empfänger, dass der Sender für die Identität des Benutzers "bürgt" und nicht ein Drittsystem (wie ein zentraler Verzeichnisdienst) die Verantwortung trägt. Zweitens muss die Assertion nicht signiert werden, da das gleiche System die Kommunikation über ihr SSL Zertifikat verschlüsselt und die zusätzliche Signatur der Assertion durch ein zweites Zertifikat desselben Systems keinen Sicherheitsgewinn bringt. IHE Deutschland wird sich für eine entsprechende Anpassung des IHE XUA Profils im Rahmen des Change Proposal Prozesses für Revision 10 des ITI Technical Frameworks einsetzen.

Zusammenfassung

Es wurden verschiedene Ansätze zur Benutzeridentifikation vorgestellt und technisch beschrieben. Jeder der Ansätze eignet sich für eine spezifische Anwenderzielgruppe:

Übersicht der vorgestellten Lösungsansätze zur Benutzeridentifikation.

Nummer	Mapping Ansatz	Zielgruppe	Bemerkungen
1	Verwendung lokaler Benutzeridentitäten	Große Krankenhäuser	Optional: lokales HPD als Teil eines zentralen virtuellen Verzeichnis
2	Eingabe des zentralen Benutzernamens und eines Passworts durch den Benutzer	Krankenhäuser mit Stations-Login	Assertions werden zentral ausgestellt und signiert
3	Automatisches Mapping über einen Identifier	Mittelgroße Krankenhäuser	Entweder über unabhängig vergebene Benutzer-IDs oder durch MPI-ähnliche Zuordnung lokaler Benutzer-IDs zum zentralen Account
4	Manuelles Mapping durch einen Administrator	Arztpraxen, Gemeinschaftspraxen, Praxisgemeinschaften, MVZ, kleine Krankenhäuser

Ein zentrales Healthcare Provider Directory (HPD) wird in allen Fällen gebraucht, aber bei Ansatz 1 ist es nur für die Organisationen (d.h. die Organizational Providers) verpflichtend. Die Benutzeridentität wird immer über eine SAML Assertion im SOAP-Header kommuniziert. Diese Assertion muss zumindest die Patienten-ID als AttributeStatement enthalten. Wenn die Assertion weitere Attribute beinhaltet, sind diese anstelle der im zentralen HPD vorhandenen Attribute zuverwenden. Nach der hier beschriebenen Übertragung der Benutzeridentität als SAML Assertion und einer ggf. notwendigen Abfrage der Benutzerattribute kennt das zentrale Aktensystem unabhängig vom gewählten Ansatz immer die folgende Information zur laufenden Transaktion: Namen des Benutzers (ID und Klartext), seine Rolle und Organisation, die relevante Patienten-ID sowie den Verwendungszweck.

Verwalten von Berechtigungen

Der Patient steuert die Zugriffsrechte in der elektronischen Patientenakte über Patientenzustimmungsdokumente (hier synonym mit "Einwilligungserklärung", "Patient Consent" und "Privacy Policy Acknowledgment Document"). Das IHE BPPC Profil, wie in Abschnitt 2.2.10 erläutert, ermöglicht keine feingranulare Zugriffskontrolle. Eine solche feingranulare Kontrolle (z.B. Einschränkung auf berechtigte Organisationen) ist in deutschen Vernetzungsprojekten (unabhängig vom Aktentyp) jedoch notwendig (siehe Abschnitt 2.1). Daher wird in diesem Abschnitt ein alternativer Ansatz zur Zugriffskontrolle beschrieben. Dieser Ansatz basiert auf der in Abschnitt 2.2.11 vorgestellten eXtensible Access Control Markup Language (XACML). IHE Deutschland wird die hier vorgestellten Konzepte in zukünftigen Spezifikationen und Integrationsprofilen als CDA Entry Level Template weiter formalisieren und international einbringen.

Während in diesem Abschnitt (4.3.3) die Erstellung, die zentrale Ablage und die Struktur von Patientenzustimmung und den Zugriffsregeln beschrieben wird, erläutert der Abschnitt 4.3.4 die Entscheidungsfindung für Zugriffsentscheidungen, deren Durchsetzung sowie die Anwendung auf die Cookbook-relevanten IHE Profile und Transaktionen.

Welche Steuerungsmöglichkeiten für seine Zugriffsrechte (d.h. für einen Fall, die ganze Akte, ein Dokument, etc.) der Patient hat, sowie die Form und der Zeitpunkt der Zustimmung werden spezifisch für jeden Aktentyp im Kapitel 4.4 beschrieben.

Verwaltung der Patientenzustimmung und Zugriffsregeln

Der Advanced Consent Creator erstellt ein elektronisches Patientenzustimmungsdokument als CDA-Dokument, gegebenenfalls mit eingebetteten XACML Regeln. Dieses Dokument wird über einen gruppierten Document Source Akteur an die XDS Infrastruktur übertragen. Ein Policy Definition Creator empfängt das Patientenzustimmungsdokument über einen gruppierten Document Consumer Akteur. Der Policy Definition Creator wandelt die Patientenzustimmung in ein detailliertes, direkt vom Authorisierungssystem nutzbares XACML PolicySet um und legt dieses, sowie die eingebetteten XACML Regeln, im Policy Repository ab. Der Advanced Consent Creator muss in vielen Fällen mit einem HPD Provider Information Consumer gruppiert werden, um die zu berechtigenden Organisationen oder Leistungserbringer eindeutig identifizieren zu können.

Struktur des Patientenzustimmungsdokuments

Es gibt zwei Möglichkeiten bei der Abbildung des Patientenzustimmungsdokuments:

1. als klassisches Basic Patient Privacy Consent Acknowledgment Document
2. als "bvitg-efa Patientenzustimmungs-CDA" mit optional eingebettetem XACML

Das klassische BPPC Acknowledgment Document wird unterstützt um Kompatibilität mit bestehenden BPPC-basierten Patientenzustimmungen zu ermöglichen. Während das gleiche CDA-Dokument wie bei BPPC verwendet wird, werden die Privacy Policies in Form von vorher hinterlegten XACML Policy Definitionen nach dem weiter unten detaillierten Standard abgebildet. Dadurch kann ein Zugriff auf Patientenakten ermöglicht werden, bei denen der Patient der Verwendung mittels eines BPPC Acknowledgment Documents zugestimmt hat. Die Durchsetzung der Zugriffsregeln wird dabei aber auf der in diesem Cookbook beschriebenen technologischen Basis umgesetzt.

Das bvitg-efa Patientenzustimmungs-CDA bietet die Möglichkeit Organisationen oder Benutzer zu benennen die vordefinierte Zugriffsrechte haben, ohne dafür XACML-Konstrukte verwenden zu müssen. Dies ist zum Beispiel bei zweckgebundenen Akten wie Fallakten hilfreich, da dort üblicherweise alle Mitbehandler über die gleichen Berechtigungen für den gleichen Zeitraum verfügen. Um auch Aktentypen mit komplexeren Berechtigungen umsetzen zu können, ermöglicht das CDA die Einbettung von XACML Regeln (wie weiter unten noch zu beschreiben). Die eingebetteten XACML Regeln erlauben feingranulare patientenspezifische und organisationsspezifische Zugriffsbeschränkungen.

Struktur der Zugriffsregeln

Das Abrufen und Prüfen des Patientenzustimmungsdokuments während der Entscheidungsfindung für eine Abfrage medizinischer Daten würde eine unnötig lange Verzögerung nach sich ziehen. Daher wird in diesem Abschnitt beschrieben wie die XACML Policy Definition Sprachkonstrukte genutzt werden können um sowohl die relevanten Teile der Patientenzustimmung als auch die eingebetteten oder referenzierten Zugriffsregeln abzubilden.

Die im vorherigen Abschnitt vorgestellten Varianten der Patientenzustimmungsdokumente können folgende für die Zugriffsentscheidung relevanten Informationen beinhalten:

Daten	1) BPPC	2) Advanced Consent / bvitg-eFA Consent
Patienten ID (XAD-PID)	ja	ja
Gültig von (Datum)	ja	ja
Gültig bis (Datum)	ja	ja
Behandlungsgrund	nein	ja
Autorisierte Organisationen	nein	ja
Referenz auf einen Regelsatz	ja	ja
Pat. spezifische Ausnahmeregeln	nein	ja

Die Daten "Patienten ID", "Gültig von/bis", "Behandlungsgrund", "Autorisierte Organisationen" werden als ein PolicySet in XACML abgebildet. Dieses PolicySet ist eine direkte Entsprechung der Patientenzustimmung und an deren Lifecycle gebunden. D.h. wenn das Patientenzustimmungsdokument als ungültig markiert wird (z.B. durch Änderung des XDSDocumentEntry.availabilityStatus auf "Deprecated"), muss auch das PolicySet invalidiert werden. Wenn die Patientenzustimmung eine oder mehrere patientenspezifische Ausnahmeregelungen beinhält, werden diese als eigenständige XACML Policy Elemente dem Policy Repository hinzugefügt und von dem Patientenzustimmungs-PolicySet referenziert. Dazu wird der XACML Mechanismus PolicyIdReference verwendet. Bei Referenzen auf einen vorhandenen (d.h. nicht in die Patientenzustimmung eingebetteten) Regelsatz, wird die PolicyIdReference zum Verweis auf die vorhandene Policy genutzt.

Beispiel zur Umsetzung der Patientenzustimmung auf XACML Konstrukte

Überprüfen von Berechtigungen

Akteure und Transaktionen

In diesem Leitfaden werden folgende neue Akteure zur Feststellung und Durchsetzung der Zugriffsbeschränkungen eingesetzt:

Der neue Use Case "Authorization Decision Query" beschreibt die initiale Feststellung und Durchsetzung der Zugriffsbeschränkungen. Der Akteur Authorization Requestor ist für den Schutz einer bestimmten Ressource (z.B. eines Dokuments) verantwortlich. Ein Zugriff auf die Ressource wird nur gestattet, wenn eine Evaluierung der Zugriffsregeln durch den Akteur Authorization Decision Provider ergibt, dass ein Zugriff in dieser spezifischen Situation konform zu den Zugriffsregeln ist. Die Evaluation der Regeln durch den Authorization Decision Provider geschieht auf Anfrage des Authorization Requestor. Dafür greift der Authorization Decision Provider auf die Details der Anfrage und auf patienten-spezifische Zugriffsregeln (d.h. Policies) zu, die im Policy Repository abgelegt sind. Das Policy Repository gibt auf Anfrage einen Satz von Zugriffsregeln zurück und hat eine (weiter oben diskutierte) Schnittstelle zum Ablegen der Zugriffsregeln.

Die erste Transaktion ist die Anfrage des Authorization Requestor an den Authorization Decision Provider und wird als "Request Authorization Decisions" bezeichnet. Die Transaktion nutzt das SAML-binding für XACML, genauer die Methode "XACMLAuthzDecisionQuery", wobei der Authorization Requestor als XACML Policy Enforcement Point (PEP) agiert und der Authorization Decision Provider als XACML Policy Decision Point (PDP). Als Teil der Anfrage müssen die Benutzer-Identität und Attribute kommuniziert werden. Die Methoden zur Feststellung und Überprüfung der Attribute wird im Abschnitt "Benutzerauthentifizierung und -identifikation" weiter oben diskutiert. Ausserdem müssen die für die zu schützende IHE Transaktion notwendigen Informationen zur Ressource übermittelt werden (z.B. Patienten ID, Dokumenten IDs, etc.). Details zu den zu übermittelnden Informationen werden weiter unten transaktionspezifisch erläutert. Um mehrere Zugriffsentscheidungen auf einmal abfragen zu können (z.b. eine Entscheidung pro Dokument in einer ITI-18 Antwort) wird das "Multiple resource profile of XACML v2.0" eingesetzt.

Die zweite Transaktion, "Request Policies" wird vom Authorization Decision Provider ausgelöst und an das Policy Repository gerichtet. Technisch wird dies über die Methode "XACMLPolicyQuery" des SAML-bindings für XACML abgebildet, wobei der Authorization Decision Provider als PDP fungiert und das Policy Repository als Policy Administration Point (PAP). Um die Komplexität der Kommunikation und des Policy Repositories zu reduzieren, beschränkt sich die Anfrage hierbei auf die Identifikation des Patienten. Das Policy Repository liefert somit alle für diesen Patienten möglicherweise relevanten Policies zurück an den Authorization Decision Provider. Dieser muss die Anwendbarkeit und die Gültigkeit prüfen, d.h. ist der Regelsatz für die Zugriffsentscheidung zum jetzigen Zeitpunkt relevant oder gilt sie z.B. nicht mehr. Die Antwort wird in der dritten zu diskutierenden Transaktion, "Provide Policies", vom Policy Repository an den Authorization Decision Provider geliefert. Hierfür kommt die SAML/XACML Methode "XACMLPolicyStatement" zum Einsatz. Die Antwort beinhaltet alle Policies, die der in der Anfrage erwähnten Patientennummer zugeordnet werden können und alle Policies, die unabhängig vom spezifischen Patienten gültig sind (z.B. organisations- oder jurisdiktionsspezifische Zugriffsregelungen). Das Policy Repository muss ausser der Absicherung der Kommunikation durch beidseitige Zertifikate keine Sicherheitsüberprüfung durchführen und somit dem Authorization Decision Provider einen ungefilterten Zugriff auf die Policies des Patienten ermöglichen.

"Provide Authorization Decisions" ist die letzte Transaktion des Use Case "Authorization Decision Query". Sie stellt die Antwort des Authorization Decision Provider an den Authorization Requestor dar. Abgebildet wird dies durch die SAML/XACML Methode "XACMLAuthzDecisionStatement". Mittels dieser Methode gibt der Authorization Decision Provider (hier als PDP) dem Authorization Requestor (als PEP) eine Zugriffsentscheidung pro Ressource (z.B. pro Dokument für eine ITI-18 Registry Stored Query Antwort). Um mehrere Zugriffsentscheidungen auf einmal zurückliefern zu können (z.b. eine Entscheidung pro Dokument in einer ITI-18 Antwort) wird das "Multiple resource profile of XACML v2.0" eingesetzt. Diese vierte und letzte Transaktion folgt nicht direkt auf die dritte Transaktion "Provide Policies" sondern setzt vorraus, dass der Authorization Decision Provider die Informationen aus der ersten ("Request Authorization Decision") und die Policies aus der dritten Transaktion mit allen anderen relevanten Informationen (z.B. den Dokumentenmetadaten) kombiniert und eine Entscheidung pro Ressource fällt.

Wenn zwei oder mehr dieser Akteure im gleichen System implementiert werden, müssen die zwischen Ihnen notwendigen Transaktionen nicht über die definierten Schnittstellen umgesetzt werden, sondern können aus Effizienzgründen auch über andere, proprietäre Schnittstellen übertragen werden. So muss z.B. eine XDS Document Registry, die sowohl Authorization Requestor als auch Authorization Decision Provider ist, die Transaktionen "Authorization Decision Query Request" und "Authorization Decision Query Response" nicht wie dargestellt über die standardisierten, interoperablen Schnittstellen durchführen, sondern kann dafür interne Mechanismen nutzen, solange die resultierende Zugriffsentscheidung dadurch kein anderes Resultat hat.

Kombination mit zu existierenden Akteuren und Transaktionen

Aufgrund der sehr unterschiedlichen Semantiken der zu schützenden Transaktionen ist es nicht ausreichend den Ablauf der im vorigen Abschnitt vorgestellten Transaktionen unabhängig von XDS, PDQ, etc. zu diskutieren. Daher wird im folgenden darauf eingegangen wie man die Autorisierungs-Transaktionen und -Akteure mit den in diesem Leitfaden diskutierten grundlegenden IHE-ITI Transaktionen kombinieren sollte.

1. ITI-18 XDS Registry Stored Query
2. ITI-41 XDS Provide & Register Document Set-b und ITI-42 XDS Register Document Set-b
3. ITI-43 XDS Retrieve Document Set
4. TODO ITI-21 PDQ Query
5. TODO ITI-47 PDQv3 Query

In den folgenden Abschnitten wird dabei immer angenommen, dass die Patientenidentifikation über einen der unter 4.3.1 diskutierten Mechanismen zwischen den Akteuren ausgetauscht wurde und somit alle Kommunikationspartner die XAD-PID des Patienten kennen. Eine weitere Annahme ist, dass einer der unter 4.3.2 diskutierten Mechanismen zur Benutzerauthentifizierung verwendet wurde und das empfangende System somit zumindest den Namen des Benutzers (ID und Klartext), seine Rolle und Organisation, die relevante Patienten-ID sowie den Verwendungszweck kennt.

1. Autorisierung für ITI-18 XDS Registry Stored Query

Der Document Consumer stellt eine gewöhnliche XDS-konforme ITI-18 Anfrage an die Document Registry. Die Document Registry ist nun dafür verantwortlich die Ergebnismenge so zu filtern, dass nur Einträge herausgegeben werden, auf die der Benutzer berechtigt ist. Somit ist die Registry in der Rolle des Authorization Requestors. Der Authorization Decision Provider wird immer mit der Document Registry gruppiert, um einen möglichst direkten Zugriff auf die Dokumentenmetadaten und XDSFolders zu ermöglichen, die (kombiniert mit den Policies und den Benutzerattributen) ausschlaggebend für die Zugriffsentscheidung sind. Da sowohl der Authorization Requestor als auch der Authorization Decision Provider mit der Document Registry gruppiert sind, müssen die Transaktionen nicht über die standardisierten Schnittstellen umgesetzt werden, sondern dürfen über Document Registry-interne Mechanismen implementiert werden.

Risiko Patienten ID in Assertion

Die Abfrage der Policies durch den mit der Document Registry gruppierten Authorization Decision Provider wird anhand der in der 4.3.2.8 beschriebenen Attribute Assertion durchgeführt, die die XAD-PID des Patienten beinhält. Dies birgt natürlich das Risiko, dass es zu einer Differenz zwischen der Patienten ID in der Assertion und der Patienten ID in der Registry Stored Query kommt. Unbeabsichtige Konflikte treten wahrscheinlich am ehesten bei den Get* Queries auf (z.B. GetDocuments), da die Patienten ID hier nicht explizit als Query Parameter übermittelt wird, sondern sich aus der Patienten ID des abgefragten Objekts (also z.B. der XDSDocumentEntry.PatientID) ergibt. Diese Situation kann zum Beispiel eintreten, wenn sich der Patientenbezug eines Dokuments wegen einer Zuordnungsänderung im MPI geändert hat, während der Document Consumer zugreift. Andererseits ist natürlich auch eine absichtliche Differenz zwischen der Patienten ID in der Assertion und der Patienten ID der Query denkbar, d.h. ein Document Consumer, der versucht Zugriffsbeschränkungen zu umgehen. In den meisten Fällen wird dies in leeren Ergebnismengen resultieren, da die Policies des in der Assertion referenzierten Patienten den Zugriffskontext bestimmen und nicht auf die Dokumente der Query Response passen. Problematisch wäre ausschliesslich ein (in Deutschland rechtlich nicht umsetzbares) Opt-out Szenario, da hier durch eine falsche Patienten ID in der Assertion das Laden von Deny Regeln verhindert werden könnte und keine patienten-spezifischen Permit Rechte notwendig sind.

2. Autorisierung für ITI-41 XDS Provide & Register Document Set-b und ITI-42 XDS Register Document Set-b

Die Document Source stellt eine ITI-41 Provide and Register Document Set-b Anfrage unter Einsatz der in 4.3.2 beschriebenen Authentifizierungsmechanismen. Das Document Repository muss in dieser Situation keinerlei Prüfung durchführen, ob der Benutzer berechtigt ist, das Dokument zur Patientenakte hinzuzufügen bzw. die gewünschten Änderungen an der Patientenakte durchzuführen. Dies ist möglich, da die Document Registry in der zwangsweise folgenden Transaktion ITI-42 Register Document Set involviert ist und eine Ablehnung der Dokumente zu einem Rollback (d.h. einer Löschung der Dokumente im Repository) führt. Die Registry ist in der "Register"-Transaktion ohnehin verpflichtet eine eigene Prüfung der Berechtigungen durchzuführen (Schritte 3. bis 6. im obigen Diagramm). Falls die Änderung an der Patientenakte aufgrund fehlender Rechte nicht durchgeführt werden kann, wird dies in Schritt 7. über die ITI-42 Response an das Document Repository gemeldet. Das Repository muss nun die Speicherung der Daten rückgängig machen und die Document Source über den Fehler informieren. Dies geschieht über die im heutigen Standard schon dafür vorgeschriebenen Rollback Mechanismen, die auch für Metadaten Fehler (z.B. falsche Codes, Ersetzung eines obsoleten Dokuments, etc.). verwendet werden.
Um der Document Registry eine Prüfung zu ermöglichen, muss das Document Repository den Benutzerkontext der ITI-41 (Provide & Register) in die ITI-42 einbringen, d.h. die Identity Assertion und alle bekannten Attribute Assertions weiterreichen. Da die Document Source die Assertions, die sie an das Document Repository sendet, nicht signieren muss und da das Document Repository ggf. noch weitere Benutzerattribute in einem HPD Verzeichnis abgefragt hat, muss das Document Repository sich gegenüber der Registry als verantwortlich für die Assertions bezeichnen. Dies geschieht technisch über den SAML SubjectConfirmation Mechanismus "Sender-Vouches". Das Repository muss alle bekannten Informationen über den Benutzer an die Registry weiterleiten, d.h. alle von der Source gesendeten oder per HPD nachgeschlagenen Benutzerattribute, unabhängig davon ob das Repository diese selbst verwendet oder versteht.

3. Autorisierung für ITI-43 XDS Retrieve Document Set

Eine Abfrage der Dokumenteninhalte aus dem Document Repository wird unter Einsatz der in 4.3.2 beschriebenen Authentifizierungsmechanismen durch den Document Consumer veranlasst. Das Document Repository stellt daraufhin eine Authorization Decision Query Anfrage an den mit der Document Registry gruppierten Authorization Decision Provider. Die dafür verwendete Transaktion wird durch die Benutzeridentität und -attribute der ITI-43 Transaktion des Document Consumer begleitet. D.h. wie im vorherigen Abschnitt beschrieben wird der Benutzerkontext über SAML Assertions mit SubjectConfirmation Methode "Sender-Vouches" im SOAP Header der zweiten Transaktion (siehe Diagramm) übertragen. Eine empfohlene Optimierung für den üblichen Use Case "ITI-18 mit folgender ITI-43" ist der Einsatz eines "Authorization Decision Cache" im Authorization Decision Provider. Wenn ein Document Consumer zuerst die Metadaten für einige Dokumente eines Patienten abfragt und danach eines (oder mehrere) dieser Dokumente von einem Repository abruft, kann ein solcher Cache hilfreich sein. Er vermeidet, dass die Policy neu abgefragt wird und die Evaluierung der Policies, Dokumentenmetadaten und Benutzerattribute erneut erfolgt. Ein solcher Cache wird empfohlen, ist aber nicht zwingend notwendig. Wenn ein solcher Cache eingesetzt wird, muss sichergestellt sein, dass eine neue Autorisierungsentscheidung getroffen wird, sobald sich eines der Benutzerattribute von denen unterscheidet, die bei der usprünglichen Anfrage verwendet wurden. Ausserdem sollten Cache-Einträge gelöscht werden, wenn sich die betrachteten Ressourcen (d.h. Dokumentenmetadaten) oder die (allgemeingültigen oder patientenspezifischen) Policies ändern. Um eine manuelles Invalidieren des Cache bei Änderungen an Ressourcen oder Policies zu vermeiden, kann auch eine begrenzte Gültigkeitsdauer für Cache-Einträge verwendet werden, die aber eine Stunde nicht überschreiten sollte.

Folder Management

Bei longitudinalen Akten stellt sich die Frage, wie die eingestellten Objekte - sprich Dokumente - verwaltet werden können. Die in IHE XDS vorhandenen Ordner (Folder) entsprechen Markierungen (oft auch als "Tags" bezeichnet), wobei einem Dokument auch mehrere solche Markierungen problemlos zugewiesen werden können. Dies entspricht dem bei Blogs häufig verwendetem System, bei dem ein Artikel mit einem oder mehreren Tags versehen werden. Dies erlaubt es, die Blog Einträge in mehrere, sich überschneide Teilmengen aufzuteilen, die unterschiedliche Themengebiete darstellen. Im Gegensatz zu Tags bei Blog Software werden die Folder in XDS jedoch nicht durch eine frei wählbare Zeichenkette festgelegt, sondern durch einen oder mehrere Codes.

Die Ordner (Folder) in XDS entsprechen somit nicht dem Ordnerprinzip, mit dem die verbreiteten Betriebssysteme (Windows, UNIX, Linux) Dokumente organisieren. Dort werden die Dokumente in hierarchischen Strukturen entsprechenden Ankerpunkten zugeordnet. Diese Strukturen werden dabei über Pfadangaben realisiert, die durch voneinander getrennten Zeichenketten organisiert werden. Somit übernehmen diese zusammengesetzten Zeichenketten die Ablagelogik. (z.B. "C \ Windows \ System" oder "usr \ local"). Ein Dokument kann in diesen Systemen typischerweise nur einem Ordner zugeordnet werden. (Manche Betriebssysteme ermöglichen auch eine Mehrfachzuordnung, dies ist dann aber relativ aufwendig und führt zu anderen Nebeneffekten.) Die Ordner in XDS sind per se ersteinmal nicht hierarchisch, da sich keine Beziehungen zwischen Ordnern (wie Ordner A1 ist ein Unterordner von Ordner A) abbilden lassen.

Strukturierung der Akte in der Benutzeroberfläche

Viele heute am Markt befindliche Systeme strukturieren medizinische Akten durch verschachtelte Ordner bzw. Baumstrukturen.So kann der Benutzer z.B. zuerst den administrativen Fall auswählen, dort dann die Befunde auswählen und auf der nächsten Unterebene dann die Laborbefunde zur Anzeige auswählen. Um eine solche Navigation zu ermöglichen, muss ein XDS-basiertes System keine Ordner-Hierarchie aufbauen. Stattdessen könnte eine Implementierung Ordner verwenden um die administrativen Fälle abzubilden, den XDSDocumentEntry.classCode um zwischen Befunden, Arztbriefen etc. zu unterscheiden und den XDSDocumentEntry.typeCode (oder den XDSDocumentEntry.practiceSettingCode) verwenden um Laborbefunde von radiologischen Befunden zu unterscheiden. Die hierarchische Darstellung an der Oberfläche muss nicht mühsam durch die einstellenden Systeme über XDSFolder angelegt werden, sondern ergibt sich aus den Metadaten der Dokumente.

Die Einsatzzwecke von Ordnern in XDS sind vielfältig und werden durch das IHE Cookbook nicht weiter eingeschränkt. Stattdessen werden in diesem Abschnitt Hilfestellungen gegeben, um gebräuchliche Strukturierungskonstrukte (z.B. Administrative Fälle) mithilfe von XDS Foldern auf eine interoperable Art und Weise abzubilden. Über die hier vorgestellten Konstrukte hinaus, können Anwendungsprojekte und andere Profilierungsinitiativen somit noch weitere Anwendungsgebiete für Folder definieren. Um redundante Kennzeichnungen, die zu Widersprüchen führen können, zu vermeiden, wird empfohlen keine Ordner anzulegen, die die im XDSDocumentEntry vorhandenen Metadaten (unter der Berücksichtigung der empfohlenen und vorgeschriebenen Wertebereiche) duplizieren. Z.b. ist eine Grobklassifizierung von Dokumenten durch den classCode schon gegeben, daher muss kein XDSFolder für "Befunde" angelegt werden. Ebenso sind die Fachrichtungen durch den practiceSettingCode abgebildet, daher kann der code für Labormedizin verwendet werden, anstatt einen Ordner für Labordaten anzulegen. Die Nutzung der XDSDocumentEntry Metadaten ist prinzipiell zu bevorzugen, da sich diese in XDS Anfragen weitaus flexibler einsetzen lassen.

Abbildung Administrativer Fallinformationen durch XDS Folder

Ein administrativer Fall sollte in XDS immer zumindest durch die folgenden Codes im Feld XDSFolder.codeList gekennzeichnet werden:

• Ein Eintrag in der codeList um den Typ des administrativen Falls spezifischer einzugrenzen
  • code value (nodeRepresentation) = "VISIT"; display name = "Besuch bei niedergelassenem Arzt"; codingScheme TBD
  • code value (nodeRepresentation) = "OUTPAT"; display name = "Ambulanter Klinikaufenthalt (outpatient)"; codingScheme TBD
  • code value (nodeRepresentation) = "INPAT"; display name = "Stationärer Klinikaufenthalt (inpatient)"; codingScheme TBD
  • code value (nodeRepresentation) = "REHA"; display name = "Rehabilitation (rehabilitation)"; codingScheme TBD
• Ein Eintrag in der codeList um je nach spezifischer administrativer Fallart weitere Informationen zu transportieren
  • Bei administrativer Fallart "VISIT"
    • code value (nodeRepresentation) = Quartal (z.B. "Q2/2012"); display name = textuelle Beschreibung des Quartals (z.B. "Besuch in Q2/2012"); codingScheme TBD
  • Bei administrativer Fallart "OUTPAT", "INPAT" oder "REHA"
    • code value (nodeRepresentation) = Fallnummer (z.B. "72839181"); display name = textuelle Beschreibung des adm. Falls (z.B. "stationärer Aufenthalt mit Fallnummer 72839181"); codingScheme = OID-des Namespace (z.B. "2.16.840.1.113883.3.37.4.1.1")

Ein durch diese codes gekennzeichnete Folder beinhält Dokumente, die mit einem spezifischen administrativen Fall assoziiert sind. Ein solcher Folder kann durch weitere codes auch als zweckgebunden gekennzeichnet werden (s.u.). Ein solcher Folder sollte nicht durch weitere codes als Patientenordner oder Notfallordner gekennzeichnet werden. Um Dokumente aus einem administrativen Fallordner als notfallrelevant zu kennzeichnen, sollten díe relevanten Dokumente mit einem unabhängigen Notfallordner assoziiert werden.

Abbildung von Ordnern zur Zweckbindung durch XDS Folders

Ein Ordner zur Zweckbindung sollte in XDS immer zumindest durch die folgenden Codes im Feld XDSFolder.codeList gekennzeichnet werden:

• Ein Eintrag in der codeList um den Typ der Zweckbindung spezifischer einzugrenzen
  • code value (nodeRepresentation) = "DIAG"; display name = "medizinischer Fall auf Diagnose Basis"; codingScheme TBD
  • code value (nodeRepresentation) = "DMP"; display name = "Disease Management Programm"; codingScheme TBD
  • code value (nodeRepresentation) = "IVA"; display name = "Integrierte Versorgung (IVa-Vertrag)"; codingScheme TBD
  • code value (nodeRepresentation) = "IVB"; display name = "Integrierte Versorgung (IVb-Vertrag)"; codingScheme TBD
• Ein Eintrag in der codeList um je nach spezifischer Zweckbindung weitere Informationen zu transportieren
  • Bei Zweckbindung "DIAG"
    • code value (nodeRepresentation) = ICD-10 Diagnose, ggf. mit eingeschränkter Granularität (z.B. "S52"); display name = textuelle Beschreibung des ICD Codes (z.B. "Fraktur des Unterarmes"); codingScheme = OID des Verwendeten ICD Katalogs (z.B. "1.2.276.0.76.5.413" für ICD-10 GM 2013)
  • Bei Zweckbindung "DMP", "IVA" oder "IVB"
    • code value (nodeRepresentation) = Code aus KBV Tabelle S_VDX_VERTRAGSART (z.B. "30" für DMP Diabetes mellitus Typ 2); display name = textuelle Beschreibung aus KBV Tabelle S_VDX_VERTRAGSART (z.B. "DMP Diabetes mellitus Typ 2"); codingScheme = "1.2.276.0.76.5.257" (OID der KBV Tabelle S_VDX_VERTRAGSART)

Ein durch diese codes gekennzeichnete Folder beinhält Dokumente, die einer Zweckbindung (EFA) unterliegen. Ein solcher Folder kann durch weitere codes auch mit administrativen Fallinformationen angereichert werden (s.o.). Ein solcher Folder sollte nicht durch weitere codes als Patientenordner oder Notfallordner gekennzeichnet werden. Um Dokumente aus einem zweckgebundenen Ordner als notfallrelevant zu kennzeichnen, sollten díe relevanten Dokumente mit einem unabhängigen Notfallordner assoziiert werden.

Abbildung von Patientenordnern

Ein Patientenordner sollte in XDS immer zumindest durch die folgenden Codes im Feld XDSFolder.codeList gekennzeichnet werden:

• Ein Eintrag in der codeList um den Odner als Patientenordner zu kennzeichnen
  • code value (nodeRepresentation) = "PATI"; display name = "Durch Patient hinzugefügter Ordner"; codingScheme TBD

Ein durch diese codes gekennzeichnete Folder beinhält Dokumente, die der Patient selbst hinzugefügt hat. Die im Titel und Kommentarfeld hinterlegten Informationen und die in der codeList verwendeten Codes, die über die hier spezifizierten hinausgehen, sind unter der Kontrolle des Patienten und sollten daher von Leistungserbringern entsprechend interpretiert werden. Es wird empfohlen alle vom Patienten hinzugefügte Dokumente mit Patientenordnern zu assoziieren. Da die Dokumente aber durchaus auch für andere Folder relevant sein können (z.B. für die Behandlung im Rahmen eines IG-Vertrags oder im Rahmen einer Fallakte) und somit ggf. in anderen Foldern auftauchen können, ohne dass der Patientenordner für den Benutzer sichtbar wird, müssen alle vom Patienten beigefügten Dokumente zusätzlich durch einen XDSDocumentEntry.eventCode gekennzeichnet werden. Dies ist unabhängig davon, ob die Daten durch den Patienten erstellt wurden (z.B. Schmerztagebuch) oder nur von diesem elektronisch verfügbar gemacht wurden (z.B. Hochladen eines eingescannten OP-Bericht). Als eventCode wird dabei folgender Code eingesetzt:

• code value (nodeRepresentation) = "PAT_PROVIDED"; display name = "Vom Patienten zur Verfügung gestelltes Dokument"; codingScheme TBD

Ein Patientenordner sollte nicht durch weitere codes als administrativer Fallordner, zweckgebundener Ordner oder Notfallordner gekennzeichnet werden. Um Dokumente aus einem Patientenordner als notfallrelevant zu kennzeichnen, sollten díe relevanten Dokumente mit einem unabhängigen Notfallordner assoziiert werden.

Abbildung von Notfallordnern

Ein Norfallordner sollte in XDS immer zumindest durch die folgenden Codes im Feld XDSFolder.codeList gekennzeichnet werden:

• Ein Eintrag in der codeList um den Odner als Notfallordner zu kennzeichnen
  • code value (nodeRepresentation) = "EMERG"; display name = "Notfall-relevante Dokumente"; codingScheme TBD

Besonderheiten der Aktentypen

Einrichtungsübergreifende elektronische Patientenakte (eEPA)

Die eEPA wird im Kernbereich von medizinischen Fachkräften (Health Professionals) geführt und verantwortet, welche sich dem entsprechenden Netzwerk zum Dokumentenaustausch angeschlossen haben. Der Patient kann einen Health-Professional als Aktenmoderator benennen, um ihm damit weiterführende Verwaltungsrechte zu übertragen. Der Patient kann im Kernbereich einzustellende Inhalte nicht beeinflussen, ändern oder löschen. Damit ist sichergestellt, dass die Inhalte der eEPA eine Qualität besitzen, auf welcher medizinisches Handeln auch forensisch abgesichert sinnvoll aufbauen kann. Der Patient muss entscheiden, ob er eine eEPA überhaupt führen will (sogenanntes "Opt-In").

Die eEPA ermöglicht die Vergabe differenzierter Zugriffsrechte. Soweit ein Behandlungsverhältnis vorliegt, kann der Aktenzugriff vom Patienten vor Behandlungsbeginn optional über Kriterien eingeschränkt werden. Gewählte Kriterien sind:

• Gesundheitsdienstleister
• Dokumententyp
• Medizinisches Fachgebiet der Dokumente und
• Zeitraum.

Zusätzlich wird geprüft, ob seitens des Patienten Dokumente für den Zugriff gesperrt sind. Gesperrte Dokumente sind grundsätzlich nicht sichtbar. Die jeweils gewährten Zugriffsrechte werden protokolliert.

Integration in Primärsysteme

Die Daten und Dokumente der eEPA sind aus technischen und forensischen Gründen redundante Informationen der institutionellen Akten in den Primärsystemen (u.a. Krankenhaus- und Arztpraxen-systeme). Inhalte der eEPA können automatisiert in die Primärsysteme heruntergeladen und aus den Primärsystemen hochgeladen werden. Darin unterscheidet sich die eEPA wesentlich von der PEPA.

Funktionsfähigkeit mit und ohne Abfragemöglichkeit für Patienten IDs

Die eEPA-Spezifikation lässt die Patientenidentifikation sowohl über die in Abschnitt 4.3 diskutierten Schnittstellen zu, wie auch den in 4.3.1.3 vorgestellten Ansatz ohne Abfragemöglichkeit. Wenn keine Abfragemöglichkeit besteht, muss die Patienten ID über ein anderes Verfahren übertragen werden, zum Beispiel über einen Ausdruck mit der Patienten ID im Klartext und/oder als Barcode, per USB-Stick, per eGK, per Secure Email, etc. So kann z.B. der Patient die Patienten ID über einen Ausdruck (oft auch "Ticket" oder "Offline-Token" genannt) an seinen Arzt oder die Aufnahmekraft im Krankenhaus übergeben. Dieser kann dann eine Patientenzustimmung für den so identifizierten Patienten hochladen und darüber den Behandlungszusammenhang abbilden und die Berechtigungen erweitern.

Benutzerauthentifizierung an einer eEPA

Die eEPA kann mit allen in Abschnitt 4.3.2 vorgestellten Authentifizierungsmethoden genutzt werden. Dabei sollte beachtet werden, dass für die Autorisierung von einzelnen Benutzern diese über ein zentrales Benutzerverzeichnis verfügbar sein müssen (siehe 4.3.2.7). Andernfalls kann das System, das das elektronische Patientenzustimmungsdokument erstellen muss, nicht die eindeutige Identifikation des Benutzers in den Zugriffsregeln sicherstellen. Eine Autorisierung von Einrichtungen ist aber immer ohne Einschränkungen möglich.

Benutzeroberfläche der eEPA

Grundsätzlich benötigt die eEPA keine eigene Benutzeroberfläche. Der Datenaustausch erfolgt über Primärsysteme, welche Dokumente bzw. Daten der eEPA abrufen und im Primärsystem nutzen und Dokumente bzw. Daten aus Primärsystemen in die eEPA laden.

Die ausschließliche Analyse der eEPA-Inhalte über Primärsysteme besitzt Grenzen, wenn der Patient autonom Zugriff auf „seine“ eEPA bekommen soll. Zum Beispiel ist es für den lesenden Zugriff des Patienten oft nicht praktikabel den Hausarzt aufzusuchen. Für den Zugriff auf eigene Daten oder das Einstellen von eigenen Daten kann eine Art Patientenportal bereitgestellt werden. Im Übrigen verlangt die „gesetzliche Akte“ nach § 291a SGB V, dass der Patient selber ein Zugriffsrecht auf die Akte besitzt.

Schließlich ist eine eigene eEPA-Benutzeroberfläche als Interimsszenario für den Arzt sinnvoll, sofern das Primärsystem noch keine Kommunikation mit der eEPA unterstützt. Auch für technische Administrationsfunktionen der eEPA kann ein Frontend notwendig sein.

Fähigkeit zur Einbindung in die Telematik-Infrastruktur

Die Einbindung der eEPA in die Telematik-Infrastruktur kann mit zwei Zielrichtungen erfolgen. Als sogenannte „Mehrwertanwendung“ (keine explizite gesetzliche Spezifikation) oder als gesetzliche Akte nach § 291a Abs. 3 SGB V.

Für die Einbindung als Mehrwertanwendung wird derzeit von der DKG im Auftrag der gematik ein Zertifizierungsverfahren entwickelt. Vor dessen Abschluss sind keine validen Empfehlungen zur Einbindung möglich. Für die gesetzliche Akte ist eine Spezifikation der Vorgaben des § 291a SGB seitens des Gesetzgebers bzw. der gematik noch nicht erfolgt. Grundsätzlich wird davon ausgegangen, dass aufgrund der flexiblen eEPA Architektur – insbesondere bei Umsetzung autonomer Zugriffsmöglichkeiten des Patienten und dem Angebot des Hinzufügens von Daten durch den Patienten über ein Portal – die eEPA das Potential als gesetzliche Akte besitzt. Für Aktensystemhersteller bedeutet die erfolgreiche Qualifizierung für die gesetzliche Akte ein wertvolles Produktmerkmal.

Spezifikation bzgl. Betrieb und (Langzeit-) Archivierung einer eEPA

Der Langzeitbetrieb eines Aktensystems sollte grundsätzlich so ausgelegt sein, dass z.B. der Wechsel des Aktenanbieters unterstützt werden kann. Soweit Daten der eEPA an ein (elektronisches) Archivsystem übergeben werden, ist sicherzustellen, dass die Daten innerhalb gesetzlicher Fristen wieder lesbar gemacht werden können.

Use Cases

Akte Anlegen

• Identifikation erzeugen
• Identity Feed ausführen
• Ticket ausstellen
• notwendige Ordner anlegen
• Patientenzustimmung ablegen (legt gleichzeitig die Berechtigungen fest)

Dokument einstellen

• Voraussetzung: Ticket ist eingelesen bzw. Patienten-ID bekannt
• Dokument einstellen

Dokument abrufen

• Voraussetzung: Ticket ist eingelesen bzw. Patienten-ID bekannt
• Registry befragen
• Dokument abrufen

Berechtigungen ändern

• neues Patientenzustimmungs-Dokument erstellen
• Patientenzustimmungs-Dokument einstellen

Persönliche einrichtungsübergreifende elektronische Patientenakte (PEPA)

In diesem Kapitel werden die Besonderheiten der PEPA hinsichtlich der Verwendung der Standardisierten Lösungskomponenten, der Architektur sowie der darauf aufbauenden technischen Use-Cases beschrieben.

Patientenidentifikation

Für die Patientenidentifikation ist für die PEPA zwingend ein Master Patient Index (MPI) erforderlich. Dieser wird entsprechend den Ausführungen zum MPI im Kapitel „Standardisierte Lösungskomponenten“ verwendet.

Benutzeridentifikation und –authentifikation

Die Benutzeridentifikation und –authentifikation erfolgt für die PEPA im Rahmen der entsprechenden Ausführungen im Kapitel „Standardisierte Lösungskomponenten“. Es werden zwei der drei beschriebenen Möglichkeiten unterstützt, die beide ein zentrales HPD voraussetzen: Lokale Eingabe der zentralen Benutzeridentität und dynamisches Mapping der Benutzeridentität.

Verwaltung und Prüfung von Berechtigungen

Die Verwaltung und Prüfung von Berechtigungen erfolgt entsprechend den Ausführungen im Kapitel „Standardisierte Lösungskomponenten“. Für die PEPA ist die Verwendung der elektronischen Patientenzustimmung mit eingebettetem XACML (siehe 4.3.3.2) zwingend erforderlich. Die Erstellung der Einwilligung liegt primär in der Hand des Patienten. Deshalb ist im Portal der Aktor Advanced Consent Creator zu implementieren. Da ein Patient jedoch die Verwaltung auch an einen von ihm bestimmten Stellvertreter (z.B. Hausarzt oder den behandelnden Arzt) delegieren kann, muss auch das Professional-Portal diesen Aktor implementieren. Optional kann er auch von Primärsystemen implementiert werden.

Architektur

Für den Aufbau einer Affinity Domain basierend auf einer PEPA sind folgende Komponenten erforderlich:

Zentrale Komponenten der PEPA sind:

• Für den MPI: PIX Patient Identfier Cross-reference Manager
• Health Provider Directory (HPD)
• XDS(I).b Registry und Repository
• ATNA-Repository
• Time Server
• Authorization Decision Provider
• Policy Repository
• Authorization Requestor (PEP)
• Advanced Consent Creator
• Professional-Portal (Document Consumer, Document Source)
• Patienten-Portal (Document Consumer, Document Source)

Dezentrale Komponenten in den Primärsystemen sind:

• Patient Identity Source
• Document Sources
• Authorization Requestor (PEP)
• XDS(I).b Repository (optional)
• Advanced Consent Creator (optional)

Benutzeroberflächen / Portale

Für den Abruf von Inhalten und Dokumenten sind im PEPA-Ansatz allein die Portale verantwortlich. Eine direkte Übernahme von PEPA-Inhalten in die Primärsysteme mittels dort implementierten Document Consumern ist solange nicht vorgesehen, bis es eine adäquate Möglichkeit gibt, das „Recht auf Löschen“, sofern es nicht mit anderen Gesetzten in Widerspruch steht, umsetzen zu können.

Strukturierung der Akteninhalte

Mittels dem im Kapitel „Standardisierte Lösungskomponenten“ beschriebenen Konzept der XDS-Folder, können Inhalte der PEPA strukturiert werden. Dies sind insbesondere folgende Bereiche:

• Administrative Fälle und Besuche
• Bewegungen

Eine Auswahl des Codierungssystems für die Dokumentenklassen (z.B. LOINC) und weiteren, für die Affinity Domain nötigen Bezeichner muss noch erfolgen.

Primärsystemintegration

Damit Primärsysteme an die PEPA angeschlossen werden können, müssen sie die o.g. dezentralen Komponenten implementieren. Damit sich die Benutzer nicht unnötiger Weise auch am Portal authentifzieren müssen und den aktuellen Patienten erneut suchen müssen, wird eine kontext-basierte Integration des Professional-Portals in die Primärsysteme empfohlen.

Einbindung in die Telematikinfrastruktur

Sobald die Telematikinfrastruktur (TI) vorhanden ist, wird es möglich sein, eine PEPA als Mehrwertanwendung zu betreiben. In diesem Fall können die Mechanismen der TI, wie beispielsweise zur Identifikation und Authentifikation für Patienten und Benutzer, verwendet werden.

Use-Cases

Aktivierung des Zugangs zum Patientenportal

Damit der Patient/Bürger auf die Inhalte seiner PEPA zugreifen und dort auch die Berechtigungen steuern kann, braucht er einen separaten Zugang. Dieser wird über ein Portal realisiert, das vergleichbar mit einem Onlinebanking-Portal oder einem Webmailkonto, durch eine Benutzername-Passwort-Kombination mit einer zusätzlichen TAN gesichert ist. Initialer Zugang: Authentifizierung über ein Email-Konto. In Zukunft denkbar: Zertifikat des ePersonalausweises oder der eGK, de-mail Konto (vlg. Auch BSI).
Klickt der Patient auf den durch die initiale Anlage seiner Akte erzeugten Link, aktiviert er die Akte, die mit seinem Index-Patienten des PIX-Managers verknüpft ist. Dazu werden weitere, bei der Aufnahme noch nicht abgefragte Angaben erhoben: Auswahl des TAN-Verfahrens (TAN-Generierung per SMS, Telefon). Hinterlegung einer Handynummer, Sicherheitsfragen bei vergessenem Passwort, Nennung von bevollmächtigten Personen.

Aufnahme, Einwilligung und initiale Anlage der Akte

Entsprechend dem Grundsatz, dass jeder Zugriff, jede Übermittlung und Anlage von med. Dokumenten vom Patienten autorisiert sein muss (vgl. Kapitel Datenschutz), beschreibt dieser Usecase wie eine initiale PEPA für einen Patienten bei der Aufnahme in einer Gesundheitseinrichtung angelegt wird. Dabei wird auch der Fall betrachtet, dass der Patient bereits über eine PEPA verfügt, die aufnehmende Einrichtung jedoch noch nicht berechtigt ist. Alle Workflows berücksichtigen, dass Aufnahmekräften und medizinischem Personal keine signifikanten Mehraufwände entstehen. Das Anlegen einer Akte kann zu jedem Zeitpunkt im Behandlungsprozess geschehen. Hier wird der typische Fall während der Aufnahme betrachtet. Vorbedingungen: Die den Patienten aufnehmende Einrichtung und ihr medizinisches Personal sind im zentralen Provider Information Directory (HPD) mit ihren lokalen Identifiern registriert. Das Einwilligungsmodul des Primärsystems hat den Provider Information Consumer des Profils Health Provider Directory implementiert und im Modul stehen so alle der Affinity Domain zugehörigen Gesundheitsdiensteanbieter für die Einwilligung zur Verfügung.

Patienten suchen

Für die Suche nach Patienten in der zentralen PEPA gibt es zwei Mechanismen. Wird der Patient bereits in einem Primärsystem gesucht und hat dort einen lokalen Identifier und wird anschließend über eine Kontextintegration das Ärzteportal der PEPA aufgerufen, so kann mithilfe der lokalen ID per PIX-Query der globale Identifier (d.h. die XAD-PID) ermittelt werden. Alle weiteren Transaktionen können mit ihm erfolgen (siehe 4.3.1). In der zweiten Variante ist ein Benutzer direkt auf dem Ärzteportal der PEPA angemeldet und nutzt die vorhandene Suche anhand von Attributen wie Name, Vorname und Geburtsdatum. In diesem Fall ist kein lokaler Patientenidentifier verfügbar. Deshalb erfolgt die Suche über die Transaktion Patient Demographics Query zwischen den beiden Aktoren Patient Demographie Consumer und Patient Demographic Supplier (siehe 4.3.1). Gibt es zu den vorhandenen Parametern mehrere Treffer, so ist eine Nutzerinteraktion erforderlich, um den richtigen Patienten zu wählen.

Einstellen

In diesem Usecase wird dargestellt, wie ein Primärsystem einer Gesundheitseinrichtung oder ein Patientenportal Dokumente in die PEPA einstellen kann. Der Fall Dokumente über ein Ärzteportal einzustellen weicht insofern davon ab, dass die globale Patienten-ID des PIX-Managers nicht über eine PIX-Query Transaktion erfragt werden kann, da im Ärzteportal keine lokale Patienten-ID als Anfrageparameter existiert. Daher muss z.B. über die Parameter Vorname, Nachname und Geburtsdatum über die Transaktion PID-Query, die globale ID erfragt werden (vgl. Auch Usecase Patientensuche), wodurch sowohl auf Client als auch auf Server Seite ein separater Aktor erforderlich ist (Patient Demographics Consumer und Supplier).

Vorbedingung: Der Patient, zu dem Dokumente übermittelt werden sollen, hat bereits eine PEPA. Die Einrichtung und ihr medizinisches Personal sind im zentralen Provider Information Directory mit ihren lokalen Identifiern registriert.

Abrufen

In diesem Usecase wird beschrieben, wie Dokumente aus der PEPA eingesehen werden können. Dabei werden die spezifizierten Lösungskomponenten verwendet. Zwei Möglichkeiten existieren. Bei der direkten Verwendung der Portaloberfläche muss sich der Gesundheitsdiensteanbieter zunächst mit seinem Account am Portal anmelden und über die Suchfunktion den gewünschten Patienten auswählen. Ist das Portal per Kontextintegration in das Primärsystem eingebunden, muss der Gesundheitsdienstleister im Primärsystem den Patienten suchen und von dort im Kontext in das Portal “abspringen”. Näheres zu den Such-Typen im Usecase Patientensuche.

Vorbedingung: Der Patient, zu dem Dokumente eingesehen werden sollen, hat bereits eine PEPA. Die Einrichtung und ihr medizinisches Personal sind im zentralen Provider Information Directory mit ihren lokalen Identifiern registriert. Egal welche der oben beschriebenen Möglichkeiten verwendet wurde, die globale Patienten-ID der Affinity Domain (MPI-ID) ist bereits bekannt.

A) Standardablauf

B) Notfall

Ändern/Löschen

Zum updaten einer neuen Dokumentenversion steht die Transaktion [ITI41] Provide & Register Document Set-b mit eintsprechender Replacement Option zur Verfügung. Sollen lediglich Meta-Informationen geändert werden (Dokument umhängen, Fallrevision), wird das Profil XDS-Meta-Data-Update verwendet. Der Akteur Document Administrator stellt dazu die Transaktion [ITI57] Update Document Set bereit. Das Löschen von Inhalten erfolgt lediglich Meta-Daten-basiert in der Registry. Hierzu wird die Transaktion [ITI62] Delete Document Set des selben Aktors verwendet.

Berechtigungen verwalten

In diesem Usecase wird beschreiben, welche Lösungskomponenten involviert sind und wie sie zusammen arbeiten, wenn der Patient seine Einwilligung durch Hinzufügen oder Entziehen von Berechtigungen ändert. Vorbedingungen: Der Patient hat bereits eine eigene PEPA und einen autorisierten Zugang. Das Einwilligungsmodul des Patientenportals hat den Provider Information Consumer des Profils Health Provider Directory implementiert und im Modul stehen so alle der Affinity Domain zugehörigen Gesundheitsdiensteanbieter für die Einwilligung zur Verfügung.

Fallbezogene einrichtungsübergreifende elektronische Patientenakte (eFA)

Siehe die (sich zur Zeit ebenfalls in einer Kommentierungsphase befindliche) cdaefa:EFA Spezifikation v2.0