cdaefa:CP-001-00 - Versionsgeschichte

Jcaumanns: /* Vorschlag für die Änderung der EFAv2.0-Spezifikation (subjectIdentity) */

2016-01-13T14:13:54Z

‎Vorschlag für die Änderung der EFAv2.0-Spezifikation (subjectIdentity)

Jcaumanns: /* Vorschlag für die Änderung der EFAv2.0-Spezifikation (subjectIdentity) */

2016-01-13T14:13:18Z

‎Vorschlag für die Änderung der EFAv2.0-Spezifikation (subjectIdentity)

Jcaumanns: /* Vorschlag für die Änderung der EFAv2.0-Spezifikation (subjectIdentity) */

2016-01-13T14:09:21Z

‎Vorschlag für die Änderung der EFAv2.0-Spezifikation (subjectIdentity)

Jcaumanns: /* Änderung der EFAv2.0-Spezifikation (consentInfo) */

2016-01-13T13:54:56Z

‎Änderung der EFAv2.0-Spezifikation (consentInfo)

Jcaumanns: /* Änderung der EFAv2.0-Spezifikation (consentInfo) */

2016-01-13T13:53:48Z

‎Änderung der EFAv2.0-Spezifikation (consentInfo)

Jcaumanns: /* Änderung der EFAv2.0-Spezifikation (consentInfo) */

2016-01-13T13:52:28Z

‎Änderung der EFAv2.0-Spezifikation (consentInfo)

Jcaumanns: /* Vorschlag für die Änderung der EFAv2.0-Spezifikation (subjectIdentity) */

2015-11-29T10:11:23Z

‎Vorschlag für die Änderung der EFAv2.0-Spezifikation (subjectIdentity)

Jcaumanns: /* Vorschlag für die Änderung der EFAv2.0-Spezifikation (consentInfo) */

2015-11-03T11:43:59Z

‎Vorschlag für die Änderung der EFAv2.0-Spezifikation (consentInfo)

Jcaumanns: /* CP-001-00 Missverständliche Spezifikation der Klasse subjectIdentity */

2015-11-03T09:25:07Z

‎CP-001-00 Missverständliche Spezifikation der Klasse subjectIdentity

Jcaumanns: /* Vorschlag für die Änderung der EFAv2.0-Spezifikation (consentInfo) */

2015-11-03T09:23:20Z

‎Vorschlag für die Änderung der EFAv2.0-Spezifikation (consentInfo)

← Nächstältere Version		Version vom 13. Januar 2016, 14:13 Uhr
Zeile 129:		Zeile 129:
	: Bei der Abbildung einer Patienteneinwilligung auf Berechtigungsregeln werden EFA-Teilnehmer durch eine eindeutige ID repräsentiert. 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. Sofern sich diese IDs eindeutig aufeinander abbilden lassen (bzw. identisch sind) kann der Aufrufer die für seine Organisation(seinheit) definierten Rechte in Anspruch nehmen.		: Bei der Abbildung einer Patienteneinwilligung auf Berechtigungsregeln werden EFA-Teilnehmer durch eine eindeutige ID repräsentiert. 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. Sofern sich diese IDs eindeutig aufeinander abbilden lassen (bzw. identisch sind) kann der Aufrufer die für seine Organisation(seinheit) definierten Rechte in Anspruch nehmen.
	</del>		</del>
−
−
−	* Ä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

@@ Zeile 89: / Zeile 89: @@
 In <del>einem</del> <ins>der Klasse ''ecrParticipant''</ins><del>''subjectIdentity'' Nachweis müssen mindestens die folgenden Informationen enthalten sein</del> <ins>werden die folgenden Informationen zu einem EFA-Teilnehmer zusammengefasst</ins>:
 ;ID des EFA-Teilnehmers
-:<del>Bei der Abbildung einer Patienteneinwilligung auf Berechtigungsregeln werden EFA-Teilnehmer durch eine eindeutige ID repräsentiert. In der subjectIdentity muss ein eindeutiger Identifier des EFA-Teilnehmers enthalten sein, der zu der aus der Einwilligung abgeleiteten ID des Teilnehmers korrespondiert (bzw. idealerweise sogar identisch ist).</del>
+:Bei der Abbildung einer Patienteneinwilligung auf Berechtigungsregeln werden EFA-Teilnehmer durch eine eindeutige ID repräsentiert. In <del>der subjectIdentity</del><ins>einem ''ecrParticipant''-Nachweis</ins> muss ein eindeutiger Identifier des EFA-Teilnehmers enthalten sein, der zu der aus der Einwilligung abgeleiteten ID des Teilnehmers korrespondiert.
 ;Name des EFA-Teilnehmers
-:<del>Anhand der im Audit Trail zu Datenschutzzwecken protokollierten Aktenzugriffe muss der Patient Information darüber erhalten können, wer wann und wieso auf welche Daten des Patienten zugegriffen hat. In der subjectIdentity muss der Klartextname des EFA-Teilnehmers (als Person) enthalten sein, da diese Information für das Schreiben eines auch für den Patienten nachvollziehbaren Zugriffsprotokoll benötigt wird.</del>
+:<del>Anhand der im Audit Trail zu Datenschutzzwecken protokollierten Aktenzugriffe muss der Patient Information darüber erhalten können, wer wann und wieso auf welche Daten des Patienten zugegriffen hat. In der subjectIdentity muss der Klartextname des EFA-Teilnehmers (als Person) enthalten sein, da diese Information für das Schreiben eines auch für den Patienten nachvollziehbaren Zugriffsprotokoll benötigt wird.</del><ins>Zur besseren Nachvollziehbarkeit der Überführung einer Papier-Einwilligung auf eine elektronische Einwilligungsdokumentation, muss dort der Name des berechtigten Teilnehmers wie in der Einwilligung angegeben enthalten sein.</ins>
-<ins>'''ecrAuthenticatedUser'''</ins>
+;<ins>'''ecrAuthenticatedUser'''</ins>
 <ins>Die Nutzung einer EFA ist nur für identifizierte und authentifizierte Personen möglich. Zum Zugriff auf eine konkrete EFA muss diese Person entweder
 * in der Einwilligung benannt oder

@@ Zeile 94: / Zeile 94: @@
 <ins>'''ecrAuthenticatedUser'''</ins>
 ;Art der Authentifizierung und authentifizierende Stelle
-: Jeder EFA-Provider ist für den Schutz der bei ihm verwalteten Daten verantwortlich (siehe [[cdaefa:Prinzipien_für_Datenschutz_und_Datensicherheit#Policy_Enforcement_dicht_an_den_Ressourcen|EFA Sicherheitsprinzipien]]). Hierzu gehört, dass der Provider die Vertrauenswürdigkeit einer ggf. an anderer Stelle vorgenommenen Authentifizierung bewerten können muss. Aus diesem Grund muss die subjectIdentity sichtbar machen, wie sich der EFA-Teilnehmer  authentifiziert hat und welche Stelle die Richtigkeit und Sicherheit dieser Authentifizierung abgesichert hat.
+: Jeder EFA-Provider ist für den Schutz der bei ihm verwalteten Daten verantwortlich (siehe [[cdaefa:Prinzipien_für_Datenschutz_und_Datensicherheit#Policy_Enforcement_dicht_an_den_Ressourcen|EFA Sicherheitsprinzipien]]). Hierzu gehört, dass der Provider die Vertrauenswürdigkeit einer ggf. an anderer Stelle vorgenommenen Authentifizierung bewerten können muss. Aus diesem Grund muss <del>eine subjectIdentity</del><ins>ein ''ecrAuthenticatedUser''-Objekt</ins> sichtbar machen, wie sich der <del>EFA-Teilnehmer</del><ins>EFA-Nutzer</ins> authentifiziert hat und welche Stelle die Richtigkeit und Sicherheit dieser Authentifizierung abgesichert hat.
-;Prüfdaten zur Feststellung der Authentizität des EFA-Teilnehmers
+;Prüfdaten zur Feststellung der Authentizität des <del>EFA-Teilnehmers</del><ins>EFA-Nutzers</ins>
-: Ein EFA-Provider muss verifizieren können, dass die einen Dienst aufrufende Person der EFA-Teilnehmer ist, für den er/sie sich ausgibt. Entsprechende Prüfdaten müssen fest an die subjectIdentity gebunden sein.
+: Ein EFA-Provider muss verifizieren können, dass die einen Dienst aufrufende Person der EFA-Teilnehmer ist, für den er/sie sich ausgibt. Entsprechende Prüfdaten müssen fest an <del>die subjectIdentity</del><ins>ein ''ecrAuthenticatedUser''-Objekt</ins> gebunden sein.
-;Prüfdaten zur Feststellung der Authentizität und Integrität der ''subjectIdentity''
+;Prüfdaten zur Feststellung der Authentizität und Integrität <del>der subjectIdentity</del><ins>des ''ecrAuthenticatedUser''-Objekts</ins>
-: Eine Verifizierbarkeit der Daten eines subjectIdentity ist nur gegeben, wenn die subjectIdentity selbst integer und authentisch ist. Daher muss jede subjectIdentity von der ausstellenden Stelle signiert werden.
+: Eine Verifizierbarkeit der Daten eines <del>subjectIdentity</del><ins>''ecrAuthenticatedUser''-Objekt</ins> ist nur gegeben, wenn die subjectIdentity selbst integer und authentisch ist. Daher muss <del>jede subjectIdentity</del><ins>jedes ''ecrAuthenticatedUser''-Objekt</ins> von der ausstellenden Stelle signiert werden.
 ;Point of Care
-: Zur Nachvollziehbarkeit der Instantiierung von an Organisationen vergebenen Berechtigungen muss in dem subjectIdentity Nachweis benannt sein, von wo aus der Zugriff auf Patientendaten erfolgt.
+: Zur Nachvollziehbarkeit der Instantiierung von an Organisationen vergebenen Berechtigungen muss in dem <del>subjectIdentity</del><ins>''ecrAuthenticatedUser''</ins> Nachweis benannt sein, von wo aus der Zugriff auf Patientendaten erfolgt.
 Ein <ins>ecrAuthenticatedUser</ins><del>subjectIdentity</del> Nachweis kann weitere Nutzerattribute enthalten. Diese müssen jedoch - im Gegensatz zu den oben aufgeführten Informationen - von dem angefragten Dienst nicht verarbeitet werden.

@@ Zeile 71: / Zeile 71: @@
 * Der Zweck muss angegeben sein. Dessen Kodierung unterliegt den Vorgaben der Klasse [[#purpose|purpose]].
 * Das Verfallsdatum der Akte muss angegeben sein.
-* Die EFA-Teilnehmer müssen identifiziert sein. <ins>In der über diese Klasse realisierten Dokumentation einer Einwilligung können ausschließlich Organisationen als EFA-Teilnehmer benannt werden.</ins>
+* Die EFA-Teilnehmer müssen identifiziert sein. <ins>In der über diese Klasse realisierten Dokumentation einer Einwilligung können ausschließlich Organisationen oder Organisationen zugeordnete Personen als EFA-Teilnehmer benannt werden.</ins>
 Diese Klasse muss eine Umsetzung der im [[cdaefa:CIM_Anlegen_einer_Fallakte#Interaktionsmuster:_Fallakte_anlegen|Interaktionsmuster "Fallakte anlegen"]]  beschriebenen Ausnahmeszenarien erlauben. Dies bedeutet, dass per Konvention oder per expliziter Aussage erkennbar sein muss, wie die Anlage einer Akte realisiert wird, wenn bereits eine Akte zu den benannten Zweck besteht.

@@ Zeile 71: / Zeile 71: @@
 * Der Zweck muss angegeben sein. Dessen Kodierung unterliegt den Vorgaben der Klasse [[#purpose|purpose]].
 * Das Verfallsdatum der Akte muss angegeben sein.
-* Die EFA-Teilnehmer müssen identifiziert sein. <ins>In der über diese Klasse realisierten Dokumentation einer Einwilligung können dabei sowohl Organisationen als auch Personen als EFA-Teilnehmer benannt werden.</ins>
+* Die EFA-Teilnehmer müssen identifiziert sein. <ins>In der über diese Klasse realisierten Dokumentation einer Einwilligung können ausschließlich Organisationen als EFA-Teilnehmer benannt werden.</ins>
 Diese Klasse muss eine Umsetzung der im [[cdaefa:CIM_Anlegen_einer_Fallakte#Interaktionsmuster:_Fallakte_anlegen|Interaktionsmuster "Fallakte anlegen"]]  beschriebenen Ausnahmeszenarien erlauben. Dies bedeutet, dass per Konvention oder per expliziter Aussage erkennbar sein muss, wie die Anlage einer Akte realisiert wird, wenn bereits eine Akte zu den benannten Zweck besteht.

@@ Zeile 65: / Zeile 65: @@
 |[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Business_Informationsmodell#consentInfo http://wiki.hl7.de/index.php?title=cdaefa:EFA_Business_Informationsmodell#consentInfo]
 |}
-* Klassenmodell: Ändern von „subjectIdentity" in „ecrParticipant"
+* UML-Diagramm: Ändern von „subjectIdentity" in „ecrParticipant"
-* Ausformulieren der Klasse „ecrParticipant"
-** Klarstellen, dass sowohl Personen als auch Organisationen bzw. Organisationsbereiche autorisiert werden können
+Diese Klasse <del>Diese Klasse ist eine Profilierung des Informationsmodells einer Einwilligung (siehe Leitfaden "Einwilligung"). Es basiert auf dem Konzeptmodell des Domänenmodells "Einwilligung zur zweckgebundenen Kommunikation": </del><ins>setzt die Vorgaben zu den Inhalten einer [http://wiki.hl7.de/index.php?title=cdaefa:Patienteneinwilligung_zur_EFA Patienteneinwilligung zur EFA] technisch um</ins>:
-** Verweis auf [http://wiki.hl7.de/index.php?title=cdaefa:Patienteneinwilligung_zur_EFA Patienteneinwilligung zur EFA] setzen
+* Der Patient muss identifiziert sein.
 == Vorschlag für die Änderung der EFAv2.0-Spezifikation (subjectIdentity) ==

@@ Zeile 44: / Zeile 44: @@
 (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) ==
+== Änderung der EFAv2.0-Spezifikation (Geschäftsobjekte) ==
 {|class="wikitable"
-|[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Business_Informationsmodell#consentInfo http://wiki.hl7.de/index.php?title=cdaefa:EFA_Business_Informationsmodell\#consentInfo]
+|[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Geschäftsobjekte#Klasse_EFA-Teilnehmer http://wiki.hl7.de/index.php?title=EFA_Geschäftsobjekte#Klasse_EFA-Teilnehmer]
 |}
 * Klassenmodell: Ändern von „subjectIdentity" in „ecrParticipant"

@@ Zeile 21: / Zeile 21: @@
 |Datum der Veröffentlichung im EFAv2.0 Wiki||09.04.15
 |-
-|Change Proposal Status||Eingereicht
+|Change Proposal Status||Angenommen
 |-
 |Abhängigkeit zum IHE Technical Framework<sup> </sup>||Nein
@@ Zeile 29: / Zeile 29: @@
 |Auswirkungen auf bestehende Implementierungen<sup> </sup>||Nein
 |-
-|Datum der letzten Aktualisierung des Change Proposal||08.04.15
+|Datum der letzten Aktualisierung des Change Proposal||03.11.15
 |-
-|Zugewiesener Bearbeiter||''Wird per Telefonkonferenz von der 7er-Gruppe festgelegt''
+|Zugewiesener Bearbeiter||Jörg Caumanns, Fraunhofer FOKUS
 |-
 |}