cdaefa Diskussion:EFA Security Informationsmodell

Aus Hl7wiki
Version vom 16. September 2014, 12:21 Uhr von Jcaumanns (Diskussion | Beiträge)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche

Kommentare

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)

Authors

Kürzel Name Organisation E-Mail
fh Frank Oemig Agfa Healthcare
ti Tarik Idris InterComponentWare AG
mr Michael Rübener X-tension
sh Salima Houta Fraunhofer ISST
jc Jörg Caumanns Fraunhofer FOKUS
bk Ben Kraufmann Fraunhofer FOKUS
iw Ingo Wolf gematik
mk Marcel Klötgen CompuGroup Medical