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 Telefnkonferenz 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)
- 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)
- Ä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
