cdaefa:CP-001-00

CP-001-00 Missverständliche Spezifikation der Klasse subjectIdentity

Titel des Change Request	Missverständliche Spezifikation der Klasse subjectIdentity
Einreicher des Change Proposal	Jörg Caumanns, Fraunhofer FOKUS joerg.caumanns@fokus.fraunhofer.de
Datum der Einreichung des Change Proposal	08.04.15
Betroffene Revision der EFA-Spezifikation	1 (Release Januar 2015)
EFAv2.0 Wiki Perspective	Logical
EFAv2.0 Wiki Dimension	Information
Akteur / Klasse / Transaktion	subjectIdentity
Change Proposal ID	CP 001-00
Datum der Veröffentlichung im EFAv2.0 Wiki	09.04.15
Change Proposal Status	Angenommen
Abhängigkeit zum IHE Technical Framework	Nein
Abhängigkeit zum IHE-D Cookbook	Nein
Auswirkungen auf bestehende Implementierungen	Nein
Datum der letzten Aktualisierung des Change Proposal	03.11.15
Zugewiesener Bearbeiter	Jörg Caumanns, Fraunhofer FOKUS

Motivation für den Change Request

Im Rahmen der EFA-Umsetzung an der Uniklinik Aachen wurde die Frage aufgeworfen, ob analog zur EFAv1.2-Spezifikation auch in der Version 2.0 die Autorisierung von einzelnen Ärzten per Einwilligung möglich ist. Im Rahmen der Bearbeitung der Anfrage ist aufgefallen, dass die logische Klasse subjectIdentity sowohl aus der Klasse consentInfo (Geschäftsobjekt) als auch aus der Klasse context (Sicherheitsobjekt) referenziert wird. Auch wenn autorisierte und authentisierte Subjekte aufeinander abbildbar sein sollen, so müssen sie nicht zwingend über die selbe Klasse ausgedrückt werden. Dies gilt umso mehr, als dass ein autorisiertes Subjekt im Normalfall eine Organisation bezeichnet (wobei auch Individuen zulässig sind!) während ein authentifiziertes Subjekt immer eine Person bezeichnet.

Es wird vorgeschlagen, in der logischen Spezifikation unterschiedliche Klassen für autorisierte Subjekte und authentifizierte Subjekte zu definieren. Auf der Ebene der Implementierung ist diese Differenzierung bereits erfolgt und sollte daher auch auf der logischen Ebene deutlicher werden. Hierdurch wäre auch die eingangs dargestellte Thematik der Autorisierung von Einzelpersonen weniger missverständlich.

Beschluss der 7er-Gruppe

(30.10.2015) Der Änderungsvorschlag wird angenommen. Die Umsetzung soll in die Ende Januar 2016 zu veröffentlichende Revision 2 der EFAv2.0-Spezifikation einfließen. Ein Vorschlag für die Änderung der Spezifikation wird bis Ende 2015 durch das Fraunhofer FOKUS ausgearbeitet und der 7er-Gruppe zur Freigabe vorgelegt.

Änderung der EFAv2.0-Spezifikation (Geschäftsobjekte)

http://wiki.hl7.de/index.php?title=EFA_Geschäftsobjekte#Klasse_EFA-Teilnehmer

Klasse EFA-Teilnehmer

Diese Klasse repräsentiert den Akteur EFA-Teilnehmer. Ein EFA-Teilnehmer ist eine in der Einwilligung des Patienten benannte Organisation oder Person, die in die Behandlung des Patienten eingebunden ist. EFA-Teilnehmer müssen bei ihrer Benennung in der Einwilligung des Patienten eindeutig identifiziert werden und grundsätzlich zur Nutzung einer EFA befähigt sein.

Alle EFA-Teilnehmer sind über die Einwilligung gleichermaßen zur Nutzung einer gemeinsamen Fallakte autorisiert und können über diese eine gemeinsame Behandlungsdokumentation führen und/oder erforderliche Informationen austauschen. Durch die Zuweisung einer EFA-Rolle zu einem EFA-Teilnehmer können diese ungeachtet des einheitlichen Zugangs zu den über die EFA ausgetauschten medizinischen Daten unterschiedliche administrative Berechtigungen erhalten.

Klasse EFA-Nutzer

Ein EFA-Nutzer ist eine Person, die im Rahmen des konkreten Einsatzes einer Fallakte die Berechtigung eines EFA-Teilnehmers wahrnimmt und damit auch die Rolle dieses EFA-Teilnehmers instanziiert. Sofern der EFA-Teilnehmer eine Person ist, kann nur diese Person als EFA-Nutzer in der Rolle dieses Teilnehmers agieren. Ist als EFA-Teilnehmer eine Organisation benannt, können alle Mitglieder dieser Organisation gemäß organisationsinternen Vorgaben und vorbehaltlich ihrer Einbindung in die Behandlung als EFA-Nutzer in der Rolle des EFA-Teilnehmers agieren.

Änderung der EFAv2.0-Spezifikation (consentInfo)

http://wiki.hl7.de/index.php?title=cdaefa:EFA_Business_Informationsmodell#consentInfo

• UML-Diagramm: Ändern von „subjectIdentity" in „ecrParticipant"

Diese Klasse Diese Klasse ist eine Profilierung des Informationsmodells einer Einwilligung (siehe Leitfaden "Einwilligung"). Es basiert auf dem Konzeptmodell des Domänenmodells "Einwilligung zur zweckgebundenen Kommunikation": setzt die Vorgaben zu den Inhalten einer Patienteneinwilligung zur EFA technisch um:

• Der Patient muss identifiziert sein.
• Der Zweck muss angegeben sein. Dessen Kodierung unterliegt den Vorgaben der Klasse purpose.
• Das Verfallsdatum der Akte muss angegeben sein.
• Die EFA-Teilnehmer müssen identifiziert sein. In der über diese Klasse realisierten Dokumentation einer Einwilligung können dabei sowohl Organisationen als auch Personen als EFA-Teilnehmer benannt werden.

Diese Klasse muss eine Umsetzung der im Interaktionsmuster "Fallakte anlegen" beschriebenen Ausnahmeszenarien erlauben. Dies bedeutet, dass per Konvention oder per expliziter Aussage erkennbar sein muss, wie die Anlage einer Akte realisiert wird, wenn bereits eine Akte zu den benannten Zweck besteht.

Zu jedem Zeitpunkt hat eine Fallakte bei jedem beteiligten EFA-Provider genau eine wirksame Instanz von consentInfo. Eine neue Instanz invalidiert die bestehende Instanz.

Vorschlag für die Änderung der EFAv2.0-Spezifikation (subjectIdentity)

http://wiki.hl7.de/index.php?title=cdaefa:EFA_Security_Informationsmodell#subjectIdentity

ecrParticipantsubjectIdentity

Dieses Sicherheitsobjekt fasst Informationen zu einem EFA-Teilnehmer zusammen und dient dessen eindeutiger Identifizierung im Kontext eine konkreten Fallakte. Es wird mit jeder Anfrage an einen EFA-Dienst übermittelt und soll es dem aufgerufenen Dienst ermöglichen, den Aufrufer zu authentisieren und dessen Berechtigungen anhand der verfügbar gemachten Informationen auszuwerten und durchzusetzen. Ein EFA-Teilnehmer ist dabei immer eine Organisation oder eine einer Organisation zugeordnete Person.

In einem der Klasse ecrParticipantsubjectIdentity Nachweis müssen mindestens die folgenden Informationen enthalten sein werden die folgenden Informationen zu einem EFA-Teilnehmer zusammengefasst:

ID des EFA-Teilnehmers

Bei der Abbildung einer Patienteneinwilligung auf Berechtigungsregeln werden EFA-Teilnehmer durch eine eindeutige ID repräsentiert. In der subjectIdentity muss ein eindeutiger Identifier des EFA-Teilnehmers enthalten sein, der zu der aus der Einwilligung abgeleiteten ID des Teilnehmers korrespondiert (bzw. idealerweise sogar identisch ist).

Name des EFA-Teilnehmers

Anhand der im Audit Trail zu Datenschutzzwecken protokollierten Aktenzugriffe muss der Patient Information darüber erhalten können, wer wann und wieso auf welche Daten des Patienten zugegriffen hat. In der subjectIdentity muss der Klartextname des EFA-Teilnehmers (als Person) enthalten sein, da diese Information für das Schreiben eines auch für den Patienten nachvollziehbaren Zugriffsprotokoll benötigt wird.

ecrAuthenticatedUser

Art der Authentifizierung und authentifizierende Stelle

Jeder EFA-Provider ist für den Schutz der bei ihm verwalteten Daten verantwortlich (siehe EFA Sicherheitsprinzipien). Hierzu gehört, dass der Provider die Vertrauenswürdigkeit einer ggf. an anderer Stelle vorgenommenen Authentifizierung bewerten können muss. Aus diesem Grund muss die subjectIdentity sichtbar machen, wie sich der EFA-Teilnehmer authentifiziert hat und welche Stelle die Richtigkeit und Sicherheit dieser Authentifizierung abgesichert hat.

Prüfdaten zur Feststellung der Authentizität des EFA-Teilnehmers

Ein EFA-Provider muss verifizieren können, dass die einen Dienst aufrufende Person der EFA-Teilnehmer ist, für den er/sie sich ausgibt. Entsprechende Prüfdaten müssen fest an die subjectIdentity gebunden sein.

Prüfdaten zur Feststellung der Authentizität und Integrität der subjectIdentity

Eine Verifizierbarkeit der Daten eines subjectIdentity ist nur gegeben, wenn die subjectIdentity selbst integer und authentisch ist. Daher muss jede subjectIdentity von der ausstellenden Stelle signiert werden.

Point of Care

Zur Nachvollziehbarkeit der Instantiierung von an Organisationen vergebenen Berechtigungen muss in dem subjectIdentity Nachweis benannt sein, von wo aus der Zugriff auf Patientendaten erfolgt.

Ein ecrAuthenticatedUsersubjectIdentity Nachweis kann weitere Nutzerattribute enthalten. Diese müssen jedoch - im Gegensatz zu den oben aufgeführten Informationen - von dem angefragten Dienst nicht verarbeitet werden.

Sofern in der EFA-Einwilligung eines Patienten Organisationen bzw. Organisationseinheiten als EFA-Teilnehmer benannt sind, muss der subjectIdentity-Nachweis weiter Informationen enthalten, anhand derer eine einer Organisation zugehörige Person die für diese Person vergebenen Rechte instantiieren kann:

Organisations-ID

Bei der Abbildung einer Patienteneinwilligung auf Berechtigungsregeln werden EFA-Teilnehmer durch eine eindeutige ID repräsentiert. Wenn der in der Einwilligung benannte berechtigte Teilnehmer eine Organisation(seinheit) ist, muss in der subjectIdentity ein eindeutiger Identifier der Organisation enthalten sein, der der Aufrufer angehört. Sofern sich diese IDs eindeutig aufeinander abbilden lassen (bzw. identisch sind) kann der Aufrufer die für seine Organisation(seinheit) definierten Rechte in Anspruch nehmen.

• Ändern des Klassennamens von „subjectIdentity" in „authenticatedSubjectIdentity"
  • Entsprechende Anpassung aller Verweise auf diese Klasse
• Deutlicher darstellen, dass das authentifizierte Subjekt immer eine Person sein muss
• Deutlicher klarstellen, dass eine Organisationszugehörigkeit in einer Form angegeben sein muss, die eine Zuordnung zu einer „authorizedSubjectIdentity" erlaubt