EFA Security Informationsmodell
K (Markup-Fehler behoben) |
(→subjectIdentity) |
||
| Zeile 36: | Zeile 36: | ||
Sofern weitere Sicherheitsnachweise über ein ''context''-Objekt verwaltet und ausgetauscht werden sollen, müssen diese direkt oder indirekt an das ''subjectIdentity''-Objekt gebunden sein, da nur so eine integre und authentische [[cdaefa:Kontext,_Akte,_Ressource#Kontext|Nachweis-Kette]] aufgebaut werden kann. | Sofern weitere Sicherheitsnachweise über ein ''context''-Objekt verwaltet und ausgetauscht werden sollen, müssen diese direkt oder indirekt an das ''subjectIdentity''-Objekt gebunden sein, da nur so eine integre und authentische [[cdaefa:Kontext,_Akte,_Ressource#Kontext|Nachweis-Kette]] aufgebaut werden kann. | ||
| − | ==== | + | ==== ecrParticipant ==== |
| − | |||
| − | Dieses Sicherheitsobjekt fasst Informationen zu einem EFA-Teilnehmer zusammen. | + | Dieses Sicherheitsobjekt fasst Informationen zu einem EFA-Teilnehmer zusammen und dient dessen eindeutiger Identifizierung im Kontext eine konkreten Fallakte. Ein EFA-Teilnehmer ist dabei immer eine Organisation oder eine einer Organisation zugeordnete Person. |
| − | In | + | In der Klasse ''ecrParticipant''werden die folgenden Informationen zu einem EFA-Teilnehmer zusammengefass: |
;ID des EFA-Teilnehmers | ;ID des EFA-Teilnehmers | ||
| − | : Bei der Abbildung einer Patienteneinwilligung auf Berechtigungsregeln werden EFA-Teilnehmer durch eine eindeutige ID repräsentiert. In | + | :Bei der Abbildung einer Patienteneinwilligung auf Berechtigungsregeln werden EFA-Teilnehmer durch eine eindeutige ID repräsentiert. In einem ''ecrParticipant''-Nachweis muss ein eindeutiger Identifier des EFA-Teilnehmers enthalten sein, der zu der aus der Einwilligung abgeleiteten ID des Teilnehmers korrespondiert. |
;Name des EFA-Teilnehmers | ;Name des EFA-Teilnehmers | ||
| − | : 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 | + | :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. |
| + | |||
| + | ==== ecrAuthenticatedUser ==== | ||
| + | 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 | ||
| + | * einer dort als berechtigt benannten Organisation angehören und gemäß den Regularien dieser Organisation zum Zugriff auf diese EFA berechtigt sein. | ||
| + | Die Klasse ''ecrAuthenticatedUser'' fasst Informationen zu einem EFA-Nutzer zusammen. Es wird mit jeder Anfrage an einen EFA-Dienst übermittelt und soll es dem aufgerufenen Dienst ermöglichen, den Aufrufer zu authentisieren und dessen Berechtigungen anhand der verfügbar gemachten Informationen auszuwerten und durchzusetzen. | ||
| + | |||
| + | In einem ''ecrAuthenticatedUser'' Nachweis müssen mindestens die folgenden Informationen enthalten sein: | ||
| + | ;ID des EFA-Teilnehmers | ||
| + | : Bei der Abbildung einer Patienteneinwilligung auf Berechtigungsregeln werden EFA-Teilnehmer durch eine eindeutige ID repräsentiert. In einem ''ecrAuthenticatedUser''-Objekt muss ein eindeutiger Identifier des EFA-Nutzers enthalten sein, der zu der aus der Einwilligung abgeleiteten ID des Teilnehmers korrespondiert (siehe oben). | ||
| + | ;Name des EFA-Teilnehmers | ||
| + | : 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 jedem ''ecrAuthenticatedUser''-Objekt muss der Klartextname des EFA-Teilnehmers enthalten sein, da diese Information für das Schreiben eines auch für den Patienten nachvollziehbaren Zugriffsprotokoll benötigt wird. | ||
;Art der Authentifizierung und authentifizierende Stelle | ;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 | + | : 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 ein ''ecrAuthenticatedUser''-Objekt sichtbar machen, wie sich der EFA-Nutzer authentifiziert hat und welche Stelle die Richtigkeit und Sicherheit dieser Authentifizierung abgesichert hat. |
| − | ;Prüfdaten zur Feststellung der Authentizität des EFA- | + | ;Prüfdaten zur Feststellung der Authentizität des EFA-Nutzers |
| − | : 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 | + | : 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 ein ''ecrAuthenticatedUser''-Objekt gebunden sein. |
| − | ;Prüfdaten zur Feststellung der Authentizität und Integrität | + | ;Prüfdaten zur Feststellung der Authentizität und Integrität des ''ecrAuthenticatedUser''-Objekts |
| − | : Eine Verifizierbarkeit der Daten eines | + | : Eine Verifizierbarkeit der Daten eines ''ecrAuthenticatedUser''-Objekt ist nur gegeben, wenn die subjectIdentity selbst integer und authentisch ist. Daher muss jedes ''ecrAuthenticatedUser''-Objekt von der ausstellenden Stelle signiert werden. |
| + | ;Point of Care | ||
| + | : Zur Nachvollziehbarkeit der Instantiierung von an Organisationen vergebenen Berechtigungen muss in dem ''ecrAuthenticatedUser''-Nachweis benannt sein, von wo aus der Zugriff auf Patientendaten erfolgt. | ||
| + | |||
| + | Ein ''ecrAuthenticatedUser''-Nachweis kann weitere Nutzerattribute enthalten. Diese müssen jedoch - im Gegensatz zu den oben aufgeführten Informationen - von dem angefragten Dienst nicht verarbeitet werden. | ||
| + | |||
{{AlertBox| | {{AlertBox| | ||
| − | Hier besteht noch eine Inkonsistenz zum ''IHE Cookbook''. Das Cookbook verlangt, dass eine Identity Assertion einen Verweis auf den Patienten enthält, um so bestehende Schwachstellen von IHE XDS auffangen zu können. Die EFA 2.0 Spezifikation schließt einen solchen Verweis zwar nicht aus, sieht diesen aber auch nicht als verpflichtenden Bestandteil einer | + | Hier besteht noch eine Inkonsistenz zum ''IHE Cookbook''. Das Cookbook verlangt, dass eine Identity Assertion einen Verweis auf den Patienten enthält, um so bestehende Schwachstellen von IHE XDS auffangen zu können. Die EFA 2.0 Spezifikation schließt einen solchen Verweis zwar nicht aus, sieht diesen aber auch nicht als verpflichtenden Bestandteil einer ecrAuthenticatedUser vor (logisches Pendant zur Identity Assertion). Die Gründe hierfür sind: |
| − | * auf der logischen Ebene repräsentiert | + | * auf der logischen Ebene repräsentiert der ''ecrAuthenticatedUser'' die ''Subject Domain'' des IHE 5-Domänen-Modells, die Beziehung zum Patienten ist jedoch Bestandteil der ''Context Domain'' und sollte daher - analog z.B. zu epSOS - in einer diese Domain abbildenden separaten Assertion erfasst werden. |
| − | * EFA zielt auf eine bestmögliche Unterstützung eines Single Sign-On ab. Ein Arzt soll in der Lage sein, innerhalb eines definierten Zeitraums mit einer einmal ausgestellten '' | + | * EFA zielt auf eine bestmögliche Unterstützung eines Single Sign-On ab. Ein Arzt soll in der Lage sein, innerhalb eines definierten Zeitraums mit einer einmal ausgestellten ''ecrAuthenticatedUser Assertion'' auf Daten und Anwendungen zu verschiedenen Patienten zugreifen zu können. |
* Sowohl EFA 2.0 als auch das IHE Cookbook binden Berechtigungen nicht an Patienten, sondern an Ordner bzw. mit Ordnern verknüpfte Attribute (EFA: Patient + Zweck-Codes). Da diese Daten im Registry verwaltet werden, muss in jedem Fall auch beim Aufruf der RetrieveDocument Transaktion ein Registry-Zugriff erfolgen, d.h. es gibt keinen Effizienzgewinn (dieser wäre auch bei Bindung der Rechte an den Patienten nicht zu erzielen, da auch hier gegen das Registry geprüft werden müsste, ob das Dokument überhaupt dem fraglichen Patienten zugeordnet ist). | * Sowohl EFA 2.0 als auch das IHE Cookbook binden Berechtigungen nicht an Patienten, sondern an Ordner bzw. mit Ordnern verknüpfte Attribute (EFA: Patient + Zweck-Codes). Da diese Daten im Registry verwaltet werden, muss in jedem Fall auch beim Aufruf der RetrieveDocument Transaktion ein Registry-Zugriff erfolgen, d.h. es gibt keinen Effizienzgewinn (dieser wäre auch bei Bindung der Rechte an den Patienten nicht zu erzielen, da auch hier gegen das Registry geprüft werden müsste, ob das Dokument überhaupt dem fraglichen Patienten zugeordnet ist). | ||
<nowiki></nowiki> | <nowiki></nowiki> | ||
}} | }} | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
==== subjectAccessPolicy ==== | ==== subjectAccessPolicy ==== | ||
Aktuelle Version vom 14. Februar 2016, 10:12 Uhr
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".
Inhaltsverzeichnis
EFA Sicherheitsinformationsmodell
EFA Sicherheitskontext
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eecim.01}
Alle Aufrufe einer EFA-Funktionalität erfolgen innerhalb eines definierten Sicherheitskontextes, der über den EFA Context Manager aufgebaut und verwaltet wird.
Grundsätzlich macht diese Spezifikation nur wenige Vorgaben, welche Sicherheitsobjekte im Sicherheitskontext abgelegt sind und wie diese Objekte in den Sicherheitskontext gelangen. Hierdurch entkoppelt der über ein context-Objekt gekapselte Sicherheitskontext die EFA-Anwendungsarchitektur von der darunter liegenden Sicherheitsarchitektur. EFA-Dienste erhalten mit jedem Operationsaufruf eine Kopie des lokalen context-Objekts und können anhand der darin enthaltenen Informationen die eigenen Sicherheitsdienste zur Authentisierung und Autorisierung ausführen.
PIM Data Structures
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eecim.02}
Die nachfolgend beschriebenen Objektklassen werden im Rahmen des EFA Service Functional Model verwendet und bilden das Informationsmodel des Platform Independent Model der EFA Sicherheitsarchitektur.
context
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eecim.02.01}
Die Klasse context entkoppelt Anwendungs- und Sicherheitsarchitektur der EFA. Jeder Aufruf einer EFA-Operation enthält eine Kopie des im lokalen EFA Context Manager des EFA-Clients verwalteten context-Objekts.
Während in der EFA-1.2-Spezifikation noch vier Sicherheitsnachweise über die Klasse context gekapselt wurden, sind in der EFA-2.0-Spezifikation zunächst nur zwei Nachweise normativ spezifiziert. Weitere Sicherheitsnachweise können für Ergänzungen dieser Spezifikation bzw. auch für einzelne Umsetzungen der EFA 2.0 definiert werden. Wesentlich ist lediglich, dass hierbei das logische Konstrukt des context zur Verwaltung und zum Austausch dieser Nachweise genutzt wird. Hierdurch sind die Interoperabilität auf der logischen Ebene sowie die grundsätzliche Migrationsfähigkeit in die Telematikinfrastruktur sichergestellt.
Die nebenstehende Abbildung stellt den Aufbau der context-Klasse dar:
- eine subjectIdentity kapselt die Identität des EFA-Teilnehmers und sichert bei Dienstaufrufen die Authentizität des EFA-Teilnehmers ab.
- eine subjectAccessPolicy beschreibt die Zugriffsberechtigungen des über die subjectIdentity identifizierten EFA-Teilnehmers.
In jedem Sicherheitskontext muss genau ein subjectIdentity-Objekt vorhanden sein. Dieses wird durch den EFA Context Manager im Rahmen der Identifizierung und Authentifizierung des EFA-Teilnehmers von einem Identity Provider ausgestellt. Die Umsetzung des Identity Providers kann flexibel ausgestaltet werden, wodurch nicht nur ein Single Sign-On aus einem Primärsystem heraus sondern auch eine Nutzung der Sicherheitsobjekte und -mechanismen der Telematikinfrastruktur unterstützt werden (siehe Optionen zur Authentifizierung von EFA-Teilnhemern).
Eine subjectAccessPolicy ist nur bei Verwendung eines Policy-Push Verfahrens Bestandteil des Sicherheitskontextes. Ansonsten erfolgt der Abruf von Berechtigungsregeln on demand über den EFA-Dienst, der die angefragte Ressource verwaltete.
Sofern weitere Sicherheitsnachweise über ein context-Objekt verwaltet und ausgetauscht werden sollen, müssen diese direkt oder indirekt an das subjectIdentity-Objekt gebunden sein, da nur so eine integre und authentische Nachweis-Kette aufgebaut werden kann.
ecrParticipant
Dieses Sicherheitsobjekt fasst Informationen zu einem EFA-Teilnehmer zusammen und dient dessen eindeutiger Identifizierung im Kontext eine konkreten Fallakte. Ein EFA-Teilnehmer ist dabei immer eine Organisation oder eine einer Organisation zugeordnete Person.
In der Klasse ecrParticipantwerden die folgenden Informationen zu einem EFA-Teilnehmer zusammengefass:
- ID des EFA-Teilnehmers
- Bei der Abbildung einer Patienteneinwilligung auf Berechtigungsregeln werden EFA-Teilnehmer durch eine eindeutige ID repräsentiert. In einem ecrParticipant-Nachweis muss ein eindeutiger Identifier des EFA-Teilnehmers enthalten sein, der zu der aus der Einwilligung abgeleiteten ID des Teilnehmers korrespondiert.
- Name des EFA-Teilnehmers
- 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.
ecrAuthenticatedUser
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
- einer dort als berechtigt benannten Organisation angehören und gemäß den Regularien dieser Organisation zum Zugriff auf diese EFA berechtigt sein.
Die Klasse ecrAuthenticatedUser fasst Informationen zu einem EFA-Nutzer zusammen. Es wird mit jeder Anfrage an einen EFA-Dienst übermittelt und soll es dem aufgerufenen Dienst ermöglichen, den Aufrufer zu authentisieren und dessen Berechtigungen anhand der verfügbar gemachten Informationen auszuwerten und durchzusetzen.
In einem ecrAuthenticatedUser Nachweis müssen mindestens die folgenden Informationen enthalten sein:
- ID des EFA-Teilnehmers
- Bei der Abbildung einer Patienteneinwilligung auf Berechtigungsregeln werden EFA-Teilnehmer durch eine eindeutige ID repräsentiert. In einem ecrAuthenticatedUser-Objekt muss ein eindeutiger Identifier des EFA-Nutzers enthalten sein, der zu der aus der Einwilligung abgeleiteten ID des Teilnehmers korrespondiert (siehe oben).
- Name des EFA-Teilnehmers
- 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 jedem ecrAuthenticatedUser-Objekt muss der Klartextname des EFA-Teilnehmers enthalten sein, da diese Information für das Schreiben eines auch für den Patienten nachvollziehbaren Zugriffsprotokoll benötigt wird.
- Art der Authentifizierung und authentifizierende Stelle
- Jeder EFA-Provider ist für den Schutz der bei ihm verwalteten Daten verantwortlich (siehe 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 ein ecrAuthenticatedUser-Objekt sichtbar machen, wie sich der EFA-Nutzer authentifiziert hat und welche Stelle die Richtigkeit und Sicherheit dieser Authentifizierung abgesichert hat.
- Prüfdaten zur Feststellung der Authentizität des EFA-Nutzers
- 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 ein ecrAuthenticatedUser-Objekt gebunden sein.
- Prüfdaten zur Feststellung der Authentizität und Integrität des ecrAuthenticatedUser-Objekts
- Eine Verifizierbarkeit der Daten eines ecrAuthenticatedUser-Objekt ist nur gegeben, wenn die subjectIdentity selbst integer und authentisch ist. Daher muss jedes ecrAuthenticatedUser-Objekt von der ausstellenden Stelle signiert werden.
- Point of Care
- Zur Nachvollziehbarkeit der Instantiierung von an Organisationen vergebenen Berechtigungen muss in dem ecrAuthenticatedUser-Nachweis benannt sein, von wo aus der Zugriff auf Patientendaten erfolgt.
Ein ecrAuthenticatedUser-Nachweis kann weitere Nutzerattribute enthalten. Diese müssen jedoch - im Gegensatz zu den oben aufgeführten Informationen - von dem angefragten Dienst nicht verarbeitet werden.
 |
Hier besteht noch eine Inkonsistenz zum IHE Cookbook. Das Cookbook verlangt, dass eine Identity Assertion einen Verweis auf den Patienten enthält, um so bestehende Schwachstellen von IHE XDS auffangen zu können. Die EFA 2.0 Spezifikation schließt einen solchen Verweis zwar nicht aus, sieht diesen aber auch nicht als verpflichtenden Bestandteil einer ecrAuthenticatedUser vor (logisches Pendant zur Identity Assertion). Die Gründe hierfür sind:
|
subjectAccessPolicy
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eecim.02.03}
Dieses Sicherheitsobjekt fasst Informationen zu den Berechtigungen eines EFA-Teilnehmers zusammen. Sofern für eine EFA-Umsetzung ein Policy-Push Verfahren genutzt wird, erfolgen Abruf und Austausch dieses Sicherheitsobjekts in folgender Sequenz:
- ein EFA-Provider oder ein EFA-Dienst gibt in seiner Schnittstellenbeschreibung an, dass die zum Zugriff zu überprüfenden Berechtigungen von einem dedizierten Sicherheitsdienst (EFA Policy Provider) verwaltet werden und als Teil des Dienstaufrufs vom EFA-Teilnehmer bereitgestellt werden müssen
- der Context Manager des EFA-Clients ruft die als subjectAccessPolicy kodierten Berechtigungen des über eine subjectIdentity identifizierten und authentisierten EFA-Teilnehmers vom EFA Policy Provider ab
- der Context Manager fügt jedem Dienstaufruf die subjectAccessPolicy bei.
- der aufgerufene Dienst wertet die subjectAccessPolicy unter Nutzung von Attributen der Ressource und des Nutzers (subjectIdentity) aus und setzt sie durch.
In einem subjectAccessPolicy Sicherheitsnachweis müssen mindestens die folgenden Informationen enthalten sein:
- Bindung an eine subjectIdentity
- Eine subjectAccessPolicy ist immer für einen bestimmten EFA-Teilnehmer gültig und kann auch nur von diesem für selbst veranlasste Zugriffe genutzt werden. Durch Bindung einer subjectAccessPolicy an eine subjectIdentity kann der aufgerufene Dienste verifizieren, dass die subjectAccessPolicy auch wirklich für den Aufrufer ausgestellt wurde und von diesem eingebracht wird.
- Prüfdaten zur Feststellung der Authentizität und Integrität der subjectAccessPolicy
- Eine Verifizierbarkeit der Daten einer subjectAccessPolicy ist nur gegeben, wenn die subjectAccessPolicy selbst integer und authentisch ist. Daher muss jede subjectAccessPolicy von der ausstellenden Stelle signiert werden.
Zusätzlich enthält die subjectAccessPolicy die Berechtigungen des EFA-Teilnehmers. Analog zum GDD Referenzmodell können diese Berechtigungen auf der Ebene der Anwendung oder auf der Ebene der Ressource definiert sein:
- Anwendungsberechtigungen: Die subjectAccessPolicy definiert die Berechtigungen eines Leistungserbringers im Kontext eines EFA-Providers. Hierzu zählen z.B. Berechtigungen zur Anlage von Fallakten, zum Einstellen von Daten bei diesem Provider oder zur Besetzung bestimmter Rollen (z.B. Berechtigung, als Fallaktenmanager zu agieren). Die Berechtigungen spiegeln damit die vertraglichen und organisatorischen Bindungen zwischen dem Leistungserbringer und einem EFA-Provider wider.
- Ressourceberechtigungen: Die subjectAccessPolicy definiert die Berechtigungen eines Leistungserbringers im Kontext einer konkreten Fallakte. Hierzu zählen insbesondere die aus der Einwilligung des Betroffenen abgeleiteten Zugriffsrechte auf dieser Fallakte. Die Berechtigungen spiegeln damit die vertraglichen Vereinbarungen zwischen dem Leistungserbringer und einem Patienten wider.
Grundsätzlich können beide Arten von Berechtigungen auch in einem Regelwerk kombiniert werden.
accessToken
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eecim.02.04}
Diese Klasse beschreibt ein Token, das ein EFA-Teilnehmer einreichen kann, um Zugang zu einer Fallakte zu erhalten. Das Token ist eine Referenz auf eine Token Redeem Policy. Sie ist beim Aussteller des Token registriert und beschreibt, welcher EFA-Teilnehmer das Token innerhalb welches Zeitfensters einreichen darf und welche Berechtigungen auf die Fallakte damit verknüpft sind.
Die Struktur des Tokens ist in der EFA-1.2-Spezifikation eCR Offline Token - Service Architecture definiert.
 |
Referenzen und Querverweise |
