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

Aus Hl7wiki
Wechseln zu: Navigation, Suche
(→‎Motivation für den Change Request)
K (→‎Vorschlag für die Änderung der EFAv2.0-Spezifikation (subjectIdentity))
 
(11 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 21: Zeile 21:
 
|Datum der Veröffentlichung im EFAv2.0 Wiki||09.04.15
 
|Datum der Veröffentlichung im EFAv2.0 Wiki||09.04.15
 
|-
 
|-
−
|Change Proposal Status||Eingereicht
+
|Change Proposal Status||Angenommen
 
|-
 
|-
 
|Abhängigkeit zum IHE Technical Framework<sup> </sup>||Nein  
 
|Abhängigkeit zum IHE Technical Framework<sup> </sup>||Nein  
Zeile 29: Zeile 29:
 
|Auswirkungen auf bestehende Implementierungen<sup> </sup>||Nein
 
|Auswirkungen auf bestehende Implementierungen<sup> </sup>||Nein
 
|-
 
|-
−
|Datum der letzten Aktualisierung des Change Proposal||08.04.15
+
|Datum der letzten Aktualisierung des Change Proposal||03.11.15
 
|-
 
|-
−
|Zugewiesener Bearbeiter||''Wird per Telefonkonferenz von der 7er-Gruppe festgelegt''
+
|Zugewiesener Bearbeiter||Jörg Caumanns, Fraunhofer FOKUS
 
|-
 
|-
 
|}
 
|}
Zeile 42: Zeile 42:
  
 
== Beschluss der 7er-Gruppe ==
 
== 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.
+
(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) ==
+
== Änderung der EFAv2.0-Spezifikation (Geschäftsobjekte) ==
  
 
{|class="wikitable"
 
{|class="wikitable"
−
|[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Business_Informationsmodell#consentInfo http://wiki.hl7.de/index.php?title=cdaefa:EFA_Business_Informationsmodell\#consentInfo]
+
|[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Geschäftsobjekte#Klasse_EFA-Teilnehmer http://wiki.hl7.de/index.php?title=EFA_Geschäftsobjekte#Klasse_EFA-Teilnehmer]
 
|}
 
|}
−
* Klassenmodell: Ändern von „subjectIdentity" in „authorizedSubjectIdentity"
+
 
−
* Ausformulieren der Klasse „authorizedSubjectIdentity"
+
'''Klasse EFA-Teilnehmer'''
−
** Klarstellen, dass sowohl Personen als auch Organisationen bzw. Organisationsbereiche autorisiert werden können
+
 
−
** Verweis auf [http://wiki.hl7.de/index.php?title=cdaefa:Patienteneinwilligung_zur_EFA Patienteneinwilligung zur EFA] setzen
+
Diese Klasse repräsentiert den Akteur EFA-Teilnehmer. <ins>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.</ins>
 +
 
 +
<ins>'''Klasse EFA-Nutzer'''</ins>
 +
 
 +
<ins>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.</ins>
 +
 
 +
== Änderung der EFAv2.0-Spezifikation (consentInfo) ==
 +
 
 +
{|class="wikitable"
 +
|[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Business_Informationsmodell#consentInfo http://wiki.hl7.de/index.php?title=cdaefa:EFA_Business_Informationsmodell#consentInfo]
 +
|}
 +
* UML-Diagramm: Ändern von „subjectIdentity" in „ecrParticipant"
 +
 
 +
Diese Klasse <del>Diese Klasse ist eine Profilierung des Informationsmodells einer Einwilligung (siehe Leitfaden "Einwilligung"). Es basiert auf dem Konzeptmodell des Domänenmodells "Einwilligung zur zweckgebundenen Kommunikation": </del><ins>setzt die Vorgaben zu den Inhalten einer [http://wiki.hl7.de/index.php?title=cdaefa:Patienteneinwilligung_zur_EFA Patienteneinwilligung zur EFA] technisch um</ins>:
 +
* Der Patient muss identifiziert sein.
 +
* Der Zweck muss angegeben sein. Dessen Kodierung unterliegt den Vorgaben der Klasse [[#purpose|purpose]].
 +
* Das Verfallsdatum der Akte muss angegeben sein.
 +
* Die EFA-Teilnehmer müssen identifiziert sein. <ins>In der über diese Klasse realisierten Dokumentation einer Einwilligung können ausschließlich Organisationen oder Organisationen zugeordnete Personen als EFA-Teilnehmer benannt werden.</ins>
 +
 
 +
Diese Klasse muss eine Umsetzung der im [[cdaefa:CIM_Anlegen_einer_Fallakte#Interaktionsmuster:_Fallakte_anlegen|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) ==
 
== Vorschlag für die Änderung der EFAv2.0-Spezifikation (subjectIdentity) ==
Zeile 59: Zeile 82:
 
|[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]
 
|}
 
|}
−
* Ändern des Klassennamens von „subjectIdentity" in „authenticatedSubjectIdentity"
+
 
−
** Entsprechende Anpassung aller Verweise auf diese Klasse
+
'''<ins>ecrParticipant</ins><del>subjectIdentity</del>'''
−
* 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
+
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 ''ecrParticipant''</ins><del>''subjectIdentity'' 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
 +
:Bei der Abbildung einer Patienteneinwilligung auf Berechtigungsregeln werden EFA-Teilnehmer durch eine eindeutige ID repräsentiert. In <del>der subjectIdentity</del><ins>einem ''ecrParticipant''-Nachweis</ins> muss ein eindeutiger Identifier des EFA-Teilnehmers enthalten sein, der zu der aus der Einwilligung abgeleiteten ID des Teilnehmers korrespondiert.
 +
;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>Zur besseren Nachvollziehbarkeit der Überführung einer Papier-Einwilligung auf eine elektronische Einwilligungsdokumentation, muss dort der Name des berechtigten Teilnehmers wie in der Einwilligung angegeben enthalten sein.</ins>
 +
 
 +
;<ins>'''ecrAuthenticatedUser'''</ins>
 +
<ins>Die Nutzung einer EFA ist nur für identifizierte und authentifizierte Personen möglich. Zum Zugriff auf eine konkrete EFA muss diese Person entweder
 +
* in der Einwilligung benannt oder
 +
* einer dort als berechtigt benannten Organisation angehören und gemäß den Regularien dieser Organisation zum Zugriff auf diese EFA berechtigt sein.
 +
</ins>
 +
<ins>Die Klasse ''ecrAuthenticatedUser''</ins> fasst Informationen zu einem <del>EFA-Teilnehmer</del><ins>EFA-Nutzer</ins> zusammen. 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.
 +
 
 +
In einem <del>''subjectIdentity''</del><ins>''ecrAuthenticatedUser''</ins> Nachweis müssen mindestens die folgenden Informationen enthalten sein:
 +
;ID des EFA-Teilnehmers
 +
: Bei der Abbildung einer Patienteneinwilligung auf Berechtigungsregeln werden EFA-Teilnehmer durch eine eindeutige ID repräsentiert. In <del>der subjectIdentity</del><ins>einem ''ecrAuthenticatedUser''-Objekt</ins> muss ein eindeutiger Identifier des <del>EFA-Teilnehmers</del><ins>EFA-Nutzers</ins> enthalten sein, der zu der aus der Einwilligung abgeleiteten ID des Teilnehmers korrespondiert (siehe oben).
 +
;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 <del>der subjectIdentity</del><ins>jedem ''ecrAuthenticatedUser''-Objekt</ins> muss der Klartextname des EFA-Teilnehmers enthalten sein, da diese Information für das Schreiben eines auch für den Patienten nachvollziehbaren Zugriffsprotokoll benötigt wird.
 +
;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 <del>eine subjectIdentity</del><ins>ein ''ecrAuthenticatedUser''-Objekt</ins> sichtbar machen, wie sich der <del>EFA-Teilnehmer</del><ins>EFA-Nutzer</ins> authentifiziert hat und welche Stelle die Richtigkeit und Sicherheit dieser Authentifizierung abgesichert hat.
 +
;Prüfdaten zur Feststellung der Authentizität des <del>EFA-Teilnehmers</del><ins>EFA-Nutzers</ins>
 +
: 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 <del>die subjectIdentity</del><ins>ein ''ecrAuthenticatedUser''-Objekt</ins> gebunden sein.
 +
;Prüfdaten zur Feststellung der Authentizität und Integrität <del>der subjectIdentity</del><ins>des ''ecrAuthenticatedUser''-Objekts</ins>
 +
: Eine Verifizierbarkeit der Daten eines <del>subjectIdentity</del><ins>''ecrAuthenticatedUser''-Objekt</ins> ist nur gegeben, wenn die subjectIdentity selbst integer und authentisch ist. Daher muss <del>jede subjectIdentity</del><ins>jedes ''ecrAuthenticatedUser''-Objekt</ins> von der ausstellenden Stelle signiert werden.
 +
;Point of Care
 +
: Zur Nachvollziehbarkeit der Instantiierung von an Organisationen vergebenen Berechtigungen muss in dem <del>subjectIdentity</del><ins>''ecrAuthenticatedUser''</ins> 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>

Aktuelle Version vom 13. Januar 2016, 14:13 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 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 ausschließlich Organisationen oder Organisationen zugeordnete 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 subjectIdentityeinem ecrParticipant-Nachweis muss ein eindeutiger Identifier des EFA-Teilnehmers enthalten sein, der zu der aus der Einwilligung abgeleiteten ID des Teilnehmers korrespondiert.
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.Zur besseren Nachvollziehbarkeit der Überführung einer Papier-Einwilligung auf eine elektronische Einwilligungsdokumentation, muss dort der Name des berechtigten Teilnehmers wie in der Einwilligung angegeben enthalten sein.
ecrAuthenticatedUser

Die Nutzung einer EFA ist nur für identifizierte und authentifizierte Personen möglich. Zum Zugriff auf eine konkrete EFA muss diese Person entweder

  • in der Einwilligung benannt oder
  • einer dort als berechtigt benannten Organisation angehören und gemäß den Regularien dieser Organisation zum Zugriff auf diese EFA berechtigt sein.

Die Klasse ecrAuthenticatedUser fasst Informationen zu einem EFA-TeilnehmerEFA-Nutzer zusammen. 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.

In einem subjectIdentityecrAuthenticatedUser Nachweis müssen mindestens die folgenden Informationen enthalten sein:

ID des EFA-Teilnehmers
Bei der Abbildung einer Patienteneinwilligung auf Berechtigungsregeln werden EFA-Teilnehmer durch eine eindeutige ID repräsentiert. In der subjectIdentityeinem ecrAuthenticatedUser-Objekt muss ein eindeutiger Identifier des EFA-TeilnehmersEFA-Nutzers enthalten sein, der zu der aus der Einwilligung abgeleiteten ID des Teilnehmers korrespondiert (siehe oben).
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 subjectIdentityjedem ecrAuthenticatedUser-Objekt muss der Klartextname des EFA-Teilnehmers enthalten sein, da diese Information für das Schreiben eines auch für den Patienten nachvollziehbaren Zugriffsprotokoll benötigt wird.
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 eine subjectIdentityein ecrAuthenticatedUser-Objekt sichtbar machen, wie sich der EFA-TeilnehmerEFA-Nutzer authentifiziert hat und welche Stelle die Richtigkeit und Sicherheit dieser Authentifizierung abgesichert hat.
Prüfdaten zur Feststellung der Authentizität des EFA-TeilnehmersEFA-Nutzers
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 subjectIdentityein ecrAuthenticatedUser-Objekt gebunden sein.
Prüfdaten zur Feststellung der Authentizität und Integrität der subjectIdentitydes ecrAuthenticatedUser-Objekts
Eine Verifizierbarkeit der Daten eines subjectIdentityecrAuthenticatedUser-Objekt ist nur gegeben, wenn die subjectIdentity selbst integer und authentisch ist. Daher muss jede subjectIdentityjedes ecrAuthenticatedUser-Objekt von der ausstellenden Stelle signiert werden.
Point of Care
Zur Nachvollziehbarkeit der Instantiierung von an Organisationen vergebenen Berechtigungen muss in dem subjectIdentityecrAuthenticatedUser 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.

Abgerufen von „https://wiki.hl7.de/index.php?title=cdaefa:CP-001-00&oldid=28573“