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

Aus Hl7wiki
Wechseln zu: Navigation, Suche
(Motivation für den Change Request)
(Beschluss der 7er-Gruppe)
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) ==
 
== Vorschlag für die Änderung der EFAv2.0-Spezifikation (consentInfo) ==

Version vom 2. November 2015, 08:33 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
  • Ä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