| ID
|
Author
|
Status
|
Section
|
Vote
|
Existing
|
Proposed
|
Comment
|
Comment Editor
|
Discussion
|
| 110
|
mr
|
included
|
Eecim.02.01 : context
|
|
Zugruffsberechtigungen
|
Zugriffsberechtigungen
|
|
|
|
| 111
|
mr
|
included
|
Eecim.02.01 : context
|
|
EWFA
|
EFA
|
|
|
|
| 112
|
fo
|
rejected
|
Eecim.02.02 : subjectIdentity
|
|
|
|
Die Inkonsistenz zum Cookbook muss ausgeräumt werden, da ansonsten der Profilieruingsmechanismus nicht greift.
Die einfachste Variante dürfte daher sein, diesen Mechanismus im Cookbook als optional aber empfohlen zu beschreiben.
|
Im Cookbook als optional definieren
|
|
| 113
|
ti
|
rejected
|
Eecim.02.02 : subjectIdentity
|
|
|
|
"Sofern in der EFA-Einwilligung eines Patienten Organisationen bzw. Organisationseinheiten als EFA-Teilnehmer benannt sind, muss der subjectIdentity-Nachweis weiter Informationen enthalten" Ich würde eine explizite Pflicht zur Organisations-ID vorziehen. Die hier zitierte Regel hiesse das der Identity Provider wissen muss wie die EFA Einwilligung strukturiert ist, d.h. ob darin nur Individuen oder auch Organisationen berechtigt werden (Sofern ... muss ...). Es muss ja auch nicht unbedingt eine OID sein. (ti, 29.05.2013)
|
"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."
|
Berechtigung der Organisation wurde als einziger Mechanismus erlaubt und muss in der Spezifikation auch so beschrieben werden
|
| 114
|
ti
|
included
|
Eecim.02.02 : subjectIdentity
|
|
|
|
Zur Assertion der angefragten Patienten ID: Ich kann die Argumente zu epSOS und SSO nachvollziehen. Diese wären durch eine von der Identity Assertion getrennte Assertion der relevanten Patienten ID addressierbar. Zum Thema Effizienzgewinn: Wenn ich bei einer reinkommenden Query durch die Patienten ID alle relevanten Policies abfrage, kann ich einen signifikanten Teil der Anfragen ohne Aufbauen des Request Context beantworten. Der Request Context würde ja im EFA Fall (wo die gesamte Akte auf einmal abgefragt wird) eine signifikante Größe haben. Alle Anfragen bei denen der LE kein Teilnehmer ist, benötigen keine Abfrage der kompletten Metadaten, sondern können alleine anhand der Policies, der Action (z.B. RegistryStoredQuery) und der Subject Informationen negativ beantwortet werden. Bevor Dokumente herausgegeben werden, wird natürlich trotzdem die dort referenzierte Patienten ID mit den Policies verglichen, die aufgrund der Patienten ID in der Assertion herangezogen werden. Wenn die Patienten ID in den Policies (die aus der Assertion stammt) anders ist als die Patienten ID in den Dokumenten Metadaten, matcht die XACML Rule nicht und der Zugriff wird nicht gestattet. Solange es wie bei der EFA keine expliziten Deny Regeln (z.B. pat.-spezifisches Blacklisting von bestimmten Ärzten) gibt, besteht hier auch kein Sicherheitsrisiko. TL;DR: Die Pat ID in der Assertion ist als "Hint" aufzufassen, der eine effizientere Verarbeitung gerade bei nicht authorisierten Benutzern führt. (ti, 29.05.2013)
|
Alert-Box beschreibt ausführlich die Gründe für die Trennung von Patient-ID und Assertion.
|
Cookbook: Identity Assertion mit Verweis auf Patienten ID soll als optional deklariert werden. Profil (hier: EFA) kann dann den Aufbau der Identity Assertion "überschreiben" oder klare Empfehlungen geben.
|
| 115
|
iw
|
included
|
Eecim.02.04 : accessToken
|
|
Die Struktur des Tokens ist in der EFA-1.2-Spezifikation eCR Offline Token - Service Architecture definiert.
|
|
Leider ist kein Verweis auf diese Spezifikation zu finden. Es wäre schön, wenn dies ergänzt würde. (15.08.2014)
|
Der Verweis wurde ergänzt. (bk, 12.09.2014)
|
|
