cdaefa:CP-001-00: Unterschied zwischen den Versionen

Aus Hl7wiki
Wechseln zu: Navigation, Suche
(→‎Beschluss der 7er-Gruppe)
(→‎Vorschlag für die Änderung der EFAv2.0-Spezifikation (subjectIdentity))
Zeile 59: Zeile 59:
 
|[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Security_Informationsmodell#subjectIdentity http://wiki.hl7.de/index.php?title=cdaefa:EFA_Security_Informationsmodell#subjectIdentity]
 
|[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Security_Informationsmodell#subjectIdentity http://wiki.hl7.de/index.php?title=cdaefa:EFA_Security_Informationsmodell#subjectIdentity]
 
|}
 
|}
 +
 +
'''<ins>ecrParticipant</ins><del>subjectIdentity</del>'''
 +
 +
Dieses Sicherheitsobjekt fasst Informationen zu einem EFA-Teilnehmer zusammen <ins>und dient dessen eindeutiger Identifizierung im Kontext eine konkreten Fallakte</ins>. <del>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.</del> <ins>Ein EFA-Teilnehmer ist dabei immer eine Organisation oder eine einer Organisation zugeordnete Person.</ins>
 +
 +
In <del>einem</del> <ins>der Klasse</ins>''subjectIdentity''<del>Nachweis müssen mindestens die folgenden Informationen enthalten sein</del> <ins>werden die folgenden Informationen zu einem EFA-Teilnehmer zusammengefasst</ins>:
 +
;ID des EFA-Teilnehmers
 +
:<del>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).</del>
 +
;Name des EFA-Teilnehmers
 +
:<del>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.</del>
 +
 +
<ins>'''ecrAuthenticatedUser'''</ins>
 +
;Art der Authentifizierung und authentifizierende Stelle
 +
: Jeder EFA-Provider ist für den Schutz der bei ihm verwalteten Daten verantwortlich (siehe [[cdaefa:Prinzipien_für_Datenschutz_und_Datensicherheit#Policy_Enforcement_dicht_an_den_Ressourcen|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 <ins>ecrAuthenticatedUser</ins><del>subjectIdentity</del> Nachweis kann weitere Nutzerattribute enthalten. Diese müssen jedoch - im Gegensatz zu den oben aufgeführten Informationen - von dem angefragten Dienst nicht verarbeitet werden.
 +
 +
 +
{{AlertBox|
 +
Hier besteht noch eine Inkonsistenz zum ''IHE Cookbook''. Das Cookbook verlangt, dass eine Identity Assertion einen Verweis auf den Patienten enthält, um so bestehende Schwachstellen von IHE XDS auffangen zu können. Die EFA 2.0 Spezifikation schließt einen solchen Verweis zwar nicht aus, sieht diesen aber auch nicht als verpflichtenden Bestandteil eine<ins>r</ins><del>s ''subjectIdentity''</del><ins>ecrAuthenticatedUser</ins> (logisches Pendant zur Identity Assertion). Die Gründe hierfür sind:
 +
* auf der logischen Ebene repräsentiert <del>die ''subjectIdentity''</del><ins>der ''ecrAuthenticatedUser''</ins> die ''Subject Domain'' des IHE 5-Domänen-Modells, die Beziehung zum Patienten ist jedoch Bestandteil der ''Context Domain'' und sollte daher - analog z.B. zu epSOS - in einer diese Domain abbildenden separaten Assertion erfasst werden.
 +
* EFA zielt auf eine bestmögliche Unterstützung eines Single Sign-On ab. Ein Arzt soll in der Lage sein, innerhalb eines definierten Zeitraums mit einer einmal ausgestellten <del>''subjectIdentity''</del><ins>''ecrAuthenticatedUser Assertion''</ins> auf Daten und Anwendungen zu verschiedenen Patienten zugreifen zu können.
 +
* Sowohl EFA 2.0 als auch das IHE Cookbook binden Berechtigungen nicht an Patienten, sondern an Ordner bzw. mit Ordnern verknüpfte Attribute (EFA: Patient + Zweck-Codes). Da diese Daten im Registry verwaltet werden, muss in jedem Fall auch beim Aufruf der RetrieveDocument Transaktion ein Registry-Zugriff erfolgen, d.h. es gibt keinen Effizienzgewinn (dieser wäre auch bei Bindung der Rechte an den Patienten nicht zu erzielen, da auch hier gegen das Registry geprüft werden müsste, ob das Dokument überhaupt dem fraglichen Patienten zugeordnet ist).
 +
<nowiki></nowiki>
 +
}}
 +
 +
<del>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.
 +
</del>
 +
 +
 
* Ändern des Klassennamens von „subjectIdentity" in „authenticatedSubjectIdentity"
 
* Ändern des Klassennamens von „subjectIdentity" in „authenticatedSubjectIdentity"
 
** Entsprechende Anpassung aller Verweise auf diese Klasse
 
** Entsprechende Anpassung aller Verweise auf diese Klasse
 
* Deutlicher darstellen, dass das authentifizierte Subjekt immer eine Person sein muss
 
* 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
 
* Deutlicher klarstellen, dass eine Organisationszugehörigkeit in einer Form angegeben sein muss, die eine Zuordnung zu einer „authorizedSubjectIdentity" erlaubt

Version vom 3. November 2015, 09:21 Uhr

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 Eingereicht
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 08.04.15
Zugewiesener Bearbeiter Wird per Telefonkonferenz von der 7er-Gruppe festgelegt

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.

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

http://wiki.hl7.de/index.php?title=cdaefa:EFA_Business_Informationsmodell\#consentInfo
  • Klassenmodell: Ändern von „subjectIdentity" in „authorizedSubjectIdentity"
  • Ausformulieren der Klasse „authorizedSubjectIdentity"
    • Klarstellen, dass sowohl Personen als auch Organisationen bzw. Organisationsbereiche autorisiert werden können
    • Verweis auf Patienteneinwilligung zur EFA setzen

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


Attention icon.svg Hier besteht noch eine Inkonsistenz zum IHE Cookbook. Das Cookbook verlangt, dass eine Identity Assertion einen Verweis auf den Patienten enthält, um so bestehende Schwachstellen von IHE XDS auffangen zu können. Die EFA 2.0 Spezifikation schließt einen solchen Verweis zwar nicht aus, sieht diesen aber auch nicht als verpflichtenden Bestandteil einers subjectIdentityecrAuthenticatedUser (logisches Pendant zur Identity Assertion). Die Gründe hierfür sind:
  • auf der logischen Ebene repräsentiert die subjectIdentityder ecrAuthenticatedUser die Subject Domain des IHE 5-Domänen-Modells, die Beziehung zum Patienten ist jedoch Bestandteil der Context Domain und sollte daher - analog z.B. zu epSOS - in einer diese Domain abbildenden separaten Assertion erfasst werden.
  • EFA zielt auf eine bestmögliche Unterstützung eines Single Sign-On ab. Ein Arzt soll in der Lage sein, innerhalb eines definierten Zeitraums mit einer einmal ausgestellten subjectIdentityecrAuthenticatedUser Assertion auf Daten und Anwendungen zu verschiedenen Patienten zugreifen zu können.
  • Sowohl EFA 2.0 als auch das IHE Cookbook binden Berechtigungen nicht an Patienten, sondern an Ordner bzw. mit Ordnern verknüpfte Attribute (EFA: Patient + Zweck-Codes). Da diese Daten im Registry verwaltet werden, muss in jedem Fall auch beim Aufruf der RetrieveDocument Transaktion ein Registry-Zugriff erfolgen, d.h. es gibt keinen Effizienzgewinn (dieser wäre auch bei Bindung der Rechte an den Patienten nicht zu erzielen, da auch hier gegen das Registry geprüft werden müsste, ob das Dokument überhaupt dem fraglichen Patienten zugeordnet ist).

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
Abgerufen von „https://wiki.hl7.de/index.php?title=cdaefa:CP-001-00&oldid=26690“