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

Aus Hl7wiki
Wechseln zu: Navigation, Suche
(Die Seite wurde neu angelegt: „= CP-001-00 Missverständliche Spezifikation der Klasse subjectIdentity = {|class="wikitable" |Titel des Change Request||Missverständliche Spezifikation der …“)
 
K
Zeile 31: Zeile 31:
 
|Datum der letzten Aktualisierung des Change Proposal||08.04.15
 
|Datum der letzten Aktualisierung des Change Proposal||08.04.15
 
|-
 
|-
|Zugewiesener Bearbeiter||''Wird per Telefnkonferenz von der 7er-Gruppe festgelegt''
+
|Zugewiesener Bearbeiter||''Wird per Telefonkonferenz von der 7er-Gruppe festgelegt''
 
|-
 
|-
 
|}
 
|}
Zeile 37: Zeile 37:
 
== Motivation für den Change Request ==
 
== 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 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.  
+
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.
 
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.
  

Version vom 10. April 2015, 07:54 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.


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
  • Ä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