EFA Kommunikationsmuster
(→Auflisten von Dokumenten: Text präzisiert und redundante Beschreibungen entfernt.) |
(→Abrufen von Dokumenten: Text präzisiert und redundante Beschreibungen entfernt.) |
||
Zeile 227: | Zeile 227: | ||
[[Datei:PIM_SEQ_Daten_Abrufen.png|516px]] | [[Datei:PIM_SEQ_Daten_Abrufen.png|516px]] | ||
− | + | Dieses Muster ist abhängig von [[cdaefa:EFA_Kommunikationsmuster#Auflisten_von_Dokumenten|Auflisten von Dokumenten]]. | |
− | + | ||
− | + | Um Dokumente einer Fallakte abzurufen: | |
− | + | # Das EFA-Teilnehmersystem (TNS) wählt die abzurufenden Dokumente aus der Liste der Dokumente aus. | |
− | + | # Das TNS ruft für jedes ausgewählte Dokumente die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#retrieveData|''retrieveData']] des EFA-Document-Repository auf. | |
− | # | + | # Das EFA-Document-Repository gibt jeweils das Datenobjekt des Dokument dem TNS. |
=== Registrierung einer neuen Einwilligung === | === Registrierung einer neuen Einwilligung === |
Version vom 21. Februar 2014, 21:19 Uhr
Dieses Dokument gibt wieder:
Implementierungsleitfaden EFA Kommunikationsmuster (0.9). Die Teilmaterialien gehören der Kategorie cdaefa an. |
February 2013
Jörg Caumanns, Raik Kuhlisch
Anmerkung: Die Kürzel unter den einzelnen Überschriften 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
- 1 Kommunikationsmuster
- 1.1 Aufbau des Sicherheitskontextes
- 1.2 Anlegen einer Fallakte
- 1.3 Anlegen einer Partition zu einer bestehenden Fallakte
- 1.4 Schließen einer Fallakte
- 1.5 Auflisten von Partitionen
- 1.6 Einstellen von Dokumenten
- 1.7 Auflisten von Dokumenten
- 1.8 Abrufen von Dokumenten
- 1.9 Registrierung einer neuen Einwilligung
- 1.10 Anfordern eines Berechtigungstoken
- 1.11 Einlösen eines Berechtigungstoken
- 1.12 Querverweise und Referenzen
Kommunikationsmuster
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01}
Kommunikationsmuster bilden die Ende-zu-Ende definierten EFA Interaktionsmuster auf einzelne logische Transaktionen zwischen technischen Akteuren ab. Sie sind ebenfalls funktional ausgerichtet und beschreiben, wie ein technischer Anwendungsfall über zwischen EFA Diensten definierte Ablaufsequenzen realisiert wird. Sie stellen damit das über den EFA Diensten definierte Protokoll dar.
Die nachfolgende Tabelle stellt die Umsetzung der Interaktionsmuster über die hier definierten Kommunikationsmuster dar.
Interaktionsmuster | Kommunikationsmuster | Anmerkungen |
---|---|---|
Auffinden der Fallakten eines Patienten | Auflisten von Partitionen | Mit dem Kommunikationsmuster werden alle mit einem angegebenen Patienten verknüpften EFA-Partitionen ermittelt, zu denen der Aufrufer zugangsberechtigt ist (d.h. diese Partitionen sind Bestandteil von Fallakten zu denen der Aufrufer vom Patient als Behandlungsteilnehmer benannt wurde). Die Sortierung der Partitionen zu Fallakten anhand des jeweils mit den Partitionen verbundenen Zwecks erfolgt im Teilnehmersystem. |
Browsing über eine Akte | Auflisten von Dokumenten | Das Kommunikationsmuster ruft die Metadaten aller in einer angegeben Partition enthaltenen Dokumente ab. Das Teilnehmersystem kann anhand dieser Daten eine nach beliebigen Kriterien strukturierte Ansicht für den Nutzer erzeugen, über die der EFA-Teilnehmer anschließend navigieren kann. Soll die Ansicht die gesamte Akte umfassen, müssen zunächst mit dem Kommunikationsmuster Auffinden der Fallakten eines Patienten alle Partitionen der Akte ermittelt werden. Anschließend muss das Kommunikationsmuster Auflisten von Dokumenten für jede einzelne dieser Partitionen abgespult werden. |
Abruf von Datenobjekten | Abrufen von Dokumenten | Der Abruf eines Dokuments erfordert die Angabe der Dokumenten-ID, die zuvor über das Kommunikationsmuster Auflisten von Dokumenten ermittelt werden muss. |
Einstellen von Datenobjekten | Einstellen von Dokumenten | Die im Interaktionsmuster beschriebenen Varianten (Ersetzen, Aktualisieren, Verknüpfen von Dokumenten) werden über das Kommunikationsmuster unterstützt. |
Invalidieren von Datenobjekten | Einstellen von Dokumenten | Datenobjekte werden invalidiert, indem sie durch ein (potenziell leeres) Dokument eines speziellen Typs ersetzt werden. Dieses Verhalten soll für alle im IHE Cookbook beschriebenen Aktentypen gleichermaßen definiert werden. Die konkrete Spezifikation des "Invalidierungsdokuments" und seiner Metadaten ist daher Gegenstand des IHE Cookbooks. |
Anlegen einer Fallakte | Anlegen einer Fallakte | Das Kommunikationsmuster ist eine 1:1 Abbildung des Interaktionsmusters und seiner Varianten/Ausnahmeszenarien. |
Anlegen und Registrieren einer Partition | Anlegen einer Partition | Die im Interaktionsmuster explizit benannten Registrierung einer neuen Partition an einer Fallakte ist auf Ebene des Kommunikationsmusters nur implizit, da alle zum gleichen Patienten und Zweck angelegten Partitionen implizit zu einer Fallakte zusammengefasst sind. Eine explizite Registrierung ist daher auf Ebene der technischen Anwendungsfälle nicht erforderlich. |
Schließen einer Fallakte | Schließen einer Fallakte | Das Kommunikationsmuster ist eine 1:1 Abbildung des Interaktionsmusters und seiner Varianten/Ausnahmeszenarien. |
Änderung einer Einwilligung | Registrierung einer neuen Einwilligung | Anpassungen des Teilnehmerkreises einer EFA erfordern eine neue Einwilligung des Patienten. Das Kommunikationsmuster übermittelt diese an den EFA-Provider, der die angegebenen Änderungen in der Konfiguration einer Fallakte und ihrer definierten Zugriffsrechte vornimmt. |
Autorisierung eines weiteren Teilnehmers | Anfordern eines Berechtigungstoken | Der Patient kann einer EFA weitere Teilnehmer über (Offline-)Token hinzufügen. Dieses Kommunikationsmuster beschreibt die Anforderung eines solchen Tokens durch einen bereits berechtigten EFA-Teilnehmer. |
Einlösen eines Berechtigungstoken | Der Patient kann einer EFA weitere Teilnehmer über (Offline-)Token hinzufügen. Dieses Kommunikationsmuster beschreibt, wie ein Leistungserbringer mit Hilfe eines solchen Tokens als Teilnehmer einer EFA autorisiert wird. | |
Zusammenführen von Fallakten | Registrierung einer neuen Einwilligung | Die Zusammenführung von zwei oder mehr Fallakten erfordert eine entsprechende Einwilligung des Patienten, in der insbesondere der Zweck und der Teilnehmerkreis der zusammengeführten Akte explizit benannt sind. Das Kommunikationsmuster übermittelt diese an den EFA-Provider, der die angegebenen Änderungen in der Konfiguration einer Fallakte und ihrer definierten Zugriffsrechte vornimmt. |
- | Aufbau des Sicherheitskontextes | Dieses Kommunikationsmuster bildet einen technischen Anwendungsfall ab, der im Idealfall keine Nutzerinteraktion beinhaltet und zu dem von daher auch kein Interaktionsmuster existiert. Der Aufbau eines Sicherheitskontextes ist Grundlage aller anderen Kommunikationsmuster und stellt sicher, dass den beim EFA-Provider angesiedelten Diensten alle Informationen authentisch und vollständig zur Verfügung stehen, die für die Prüfung und Durchsetzung der aus der Einwilligung abgeleiteten Berechtigungsregeln sowie zur datenschutzkonformen Protokollierung benötigt werden. |
Aufbau des Sicherheitskontextes
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.01}
Alle Operationen der EFA-Fachdienste und die meisten Operationen der EFA-Sicherheitsdienste müssen mit einem Sicherheitskontext aufgerufen werden. Er ermöglicht es den Diensten, EFA-Berechtigungsregeln zu prüfen und durchzusetzen sowie Dienstaufrufe datenschutzkonform zu protokollieren.
Um den Sicherheitskontext aufzubauen:
- Der EFA-Teilnehmer ist am EFA-Teilnehmersystem (TNS) authentisiert. Die Authentisierung am TNS unterliegt nicht der EFA-Spezifikation. Sie muss jedoch die Regularien des EFA-Sicherheitskonzeptes berücksichtigen.
- Das TNS ruft die Operation openContext des EFA-Kontext-Managers auf. Sie übernimmt die Credentials des EFA-Teilnehmers und gegebenenfalls weitere Identitätsmerkmale.
- Der EFA-Kontext-Manager ruft den Identitätsnachweis vom Identity Provider ab.
- Wenn das EFA-Sicherheitskonzept der Versorgungsdomäne das Policy-Push-Verfahren anwendet, dann ruft der EFA-Kontext-Manager den Berechtigungsnachweis vom Policy Provider ab.
- Der EFA-Kontext-Manager baut mit den Sicherheitsobjekten den Sicherheitskontext auf und gibt ihn dem TNS.
Anlegen einer Fallakte
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.02}
Um eine Fallakte anzulegen:
- Der Arzt hat das Kommunikationsmuster Aufbau des Sicherheitskontextes mit seinem EFA-Teilnehmersystem ausgeführt.
- Mit seinem EFA-Teilnehmersystem ruft der Arzt beim EFA-Ressourcen-Manager die Operation createECR auf.
- Der EFA-Ressourcen-Manager führt
- entweder die Variante Neu-Anlage einer Fallakte
- oder die Variante Fusion mit einer bestehenden Fallakte aus.
- Der EFA-Ressourcen-Manager gibt die Kennung der Partition dem EFA-Teilnehmersystem.
Neu-Anlage einer Fallakte
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.02.01}
Vorbedingung dieser Variante: Der EFA-Provider führt keine Fallakte mit dem gleichen Zweck für den Patienten.
Der EFA-Ressourcen-Manager
- erstellt eine Fallakte, die aus einer Partition besteht,
- speichert und registriert consentInfo sowie consentDoc,
- setzt die EFA-Berechtigungsregel der Fallakte so, dass sie konform zum consentInfo ist.
Fusion mit einer bestehenden Fallakte
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.02.02}
Vorbedingung dieser Variante: Der EFA-Provider führt eine bestehende Fallakte mit dem gleichen Zweck für den Patienten.
Der EFA-Ressourcen-Manager
- prüft, ob
- die EFA-Berechtigungsregel der bestehenden Fallakte den Arzt, der dieses Kommunikationsmuster ausführt, als Zugriffsberechtigen auszeichnet. Wenn nicht, dann wird der Vorgang abgebrochen und eine Fehlermeldung ausgegeben.
- die Einwilligung für das Anlegen der Fallakte die Übernahme einer bestehenden Fallkte autorisiert. Wenn nicht, dann wird der Vorgang abgebrochen und eine Fehlermeldung ausgegeben.
- erstellt eine Fallakte, die aus einer Partition besteht,
- speichert und registriert consentInfo sowie consentDoc,
- setzt die EFA-Berechtigungsregel der neuen Fallakte so, dass sie konform zum consentInfo ist. Die Einwilligung zu der bestehenden Fallakte wird außer Kraft gesetzt.
- verknüpft die Partitionen der bestehende Fallakte mit der neuen Fallakte.
Aktenfusion vs. Änderung der Einwilligung Der Zustand der Fallakte nach Ablauf dieses Kommunikationsmusters entspricht weitestgehend einem Zustand, der auch über das Kommunikationsmuster Registrierung einer neuen Einwilligung hergestellt werden kann. Die Aktenfusion findet jedoch immer im Rahmen einer Akten-Neuanlage statt, d.h. es wird davon ausgegangen, dass im nächsten Ablaufschritte Daten in diese Akte eingestellt werden. Daher wird bei der Akten-Neuanlage - und damit auch der Aktenfusion - immer auch eine neue Partition angelegt und ein Verweis auf diese Partition an den Aufrufer zurückgeliefert. Damit entspricht eine Aktenfusion einer Sequenz der Kommunikationsmuster Registrierung einer neuen Einwilligung und Anlegen einer Partition. |
Anlegen einer Partition zu einer bestehenden Fallakte
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.03}
Abhängigkeit zu anderen Kommunikationsmustern: Auflisten von Partitionen.
Um eine Partition zu einer bestehenden Fallakte anzulegen:
- Das EFA-Teilnehmersystem (TNS) wählt die Fallakte, für die die Partition angelegt werden soll, aus der Liste der Partitionen aus.
- Das TNS ruft die Operation createPartition des EFA-Ressourcen-Managers auf.
- Der EFA-Ressourcen-Manager
- legt die Partition an,
- registriert und speichert gegebenenfalls die Dokumente und verknüpft sie mit der Partition und
- gibt dem TNS den Verweis auf die Partition.
Schließen einer Fallakte
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.04}
Abhängigkeit zu anderen Kommunikationsmustern: Auflisten von Partitionen.
Um eine Fallakte zu schließen:
- Das EFA-Teilnehmersystem (TNS) wählt die zu schließende Fallakte aus der Liste der Partitionen aus.
- Das TNS ruf die Operation closeECR des EFA-Ressourcen-Managers auf.
- Der EFA-Ressourcen-Manager
- registriert und die speichert gegebenenfalls die Dokumente, die das Schließen begründen, und verknüpft sie mit der Fallakte,
- ändert den Status und die EFA-Berechtigungsregel der Fallakte gemäß des Lebenszyklus und
- gibt den Verweis auf die Partition, mit der die Dokumente verknüpft wurden, dem TNS.
Auflisten von Partitionen
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.05}
Dieses Kommunikationsmuster erlaubt es dem EFA-Teilnehmersystem (TNS), die Liste der Fallakten und derer Partitionen zu verarbeiten, die der EFA-Provider zu einem Patienten führt und für die der EFA-Teilnehmer zugriffsberechtigt ist.
Abhängigkeit zu anderen Kommunikationsmustern: Aufbau des Sicherheitskontextes.
Um die verfügbaren Partitionen des EFA-Providers aufzulisten:
- Das TNS ruft die Operation listPartitions des EFA-Ressourcen-Managers auf.
- Der EFA-Ressourcen-Manager
- sucht die verfügbaren Partitionen und
- gibt die Liste der Partitionen dem TNS.
Einstellen von Dokumenten
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.06}
Dieses Muster ist abhängig von:
- Auflisten von Partitionen und
- Auflisten von Dokumenten (optional).
Um Dokumente in eine Partition einer Fallakte einzustellen:
- Das EFA-Teilnehmersystem (TNS) wählt die Partition, in die die Dokumente eingestellt werden sollen, aus der Liste der Partitionen aus.
- Das TNS erfasst die Dokumentbeziehungen mithilfe der Liste der Dokumente (optional).
- Das TNS ruft die Operation provideData des EFA-Document-Repository auf.
- Das EFA-Document-Repository
- speichert das Datenobjekt (docData) jedes [[cdaefa:EFA_Business_Informationsmodell#document|Dokuments],
- ruft die Operation registerData des EFA-Document-Registry auf.
- Das EFA-Document-Registry gibt dem EFA-Document-Repository eine Status-Meldung.
- Das EFA-Document-Repository gibt dem TNS eine Status-Meldung.
Zuordnung von Teilnehmern zu Providern Jeder EFA-Teilnehmer ist immer einer oder mehreren Affinity-Domains zugeordnet. Jede Affinity-Domain wird durch einen EFA-Provider realisiert. Zwischen EFA-Teilnehmer und EFA-Provider besteht eine vertragliche Beziehung, die u.a. auch die Vorhaltung von Daten des Teilnehmers durch den Provider regelt. Wenn im Zusammenhang mit dem Einstellen von Daten somit von einem "EFA-Provider" die Rede ist, ist damit implizit immer ein EFA-Provider gemeint, mit dem der EFA-Teilnehmer eine vertragliche Beziehung hat, die ihm das Einstellen von EFA-Daten bei diesem Provider ermöglicht. Analog ist auch der Begriff "Document Repository" auf das Document Repository dieses Providers eingeschränkt, das dieser für die Daten des Teilnehmers vorgesehen hat. Ein Sonderfall ist die Konstellation, wenn ein Teilnehmer gleichzeitig Provider ist. In diesem Fall erfolgt die Datenvorhaltung analog zu den bestehenden Regularien für die Datenspeicherung innerhalb dieser Einrichtung. |
Auflisten von Dokumenten
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.07}
Dieses Muster ist abhängig von Auflisten von Partitionen.
Um die Dokumente einer Fallakte aufzulisten:
- Das EFA-Teilnehmersystem (TNS) wählt die Partitionen, deren Dokumente aufgelistet werden sollen, aus der Liste der Partitionen aus.
- Das TNS ruft für jede dieser Partitionen die Operation listPartitionContent des EFA-Document-Registry auf.
- Das EFA-Document-Registry ermittelt die Dokumente jeweils einer Partition und gibt deren Metadaten und Dokumentbeziehungen dem TNS.
Abrufen von Dokumenten
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.08}
Der Abruf von Dokumenten aus einer Fallakte erfolgt über deren eindeutige Dokumenten-ID (documentID), die beim Auflisten der Inhalte einer Partition als Teil der Dokumenten-Metadaten bereitgestellt wird.
Dieses Muster ist abhängig von Auflisten von Dokumenten.
Um Dokumente einer Fallakte abzurufen:
- Das EFA-Teilnehmersystem (TNS) wählt die abzurufenden Dokumente aus der Liste der Dokumente aus.
- Das TNS ruft für jedes ausgewählte Dokumente die Operation retrieveData' des EFA-Document-Repository auf.
- Das EFA-Document-Repository gibt jeweils das Datenobjekt des Dokument dem TNS.
Registrierung einer neuen Einwilligung
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.09}
Die Registrierung einer neuen Einwilligung erfolgt innerhalb eines gültigen EFA-Sicherheitskontexts und bedingt, dass der die Einwilligung registrierende Nutzer ein berechtigter Teilnehmer der Fallakte ist.
Das Registrieren einer neuen Einwilligung erfolgt in den folgenden Schritten:
- Aufbau eines Sicherheitskontextes, der dem EFA-Provider die sichere Identifizierung und Authentifizierung des Teilnehmers ermöglicht (siehe Kommunikationsmuster Aufbau des Sicherheitskontextes).
- Ermitteln der ecrRef, mittels der die Fallakte eindeutig identifizierbar sind, auf die sich die neue Einwilligung bezieht. Sofern diese ID nicht bereits bekannt ist, muss sie über das Kommunikationsmuster Auflisten von Partitionen ermittelt werden.
- Senden des Aktenverweises, der Angaben zur neuen Einwilligung sowie eine ggf. verfügbare elektronische Version des vom Patienten unterschriebenen Einwilligungsdokuments an den Ressource Manager des EFA-Providers.
- Der EFA-Provider prüft, ob der Teilnehmer zum Zugriff auf die Akte berechtigt ist und für diese Akte Änderungen an den Zugriffsrechten initiieren darf. Falls dies nicht der Fall sein sollte wird die Operation mit einer Fehlermeldung abgebrochen.
- Sofern in der Einwilligung ein konkretisierter Zweck benannt ist: Der EFA-Provider prüft, ob für den Patienten bereits eine Akte zu dem konkretisierten Zweck besteht. Ist dies der Fall, wird die Operation mit einer Fehlermeldung abgebrochen. Der Nutzer sollte in diesem Fall zunächst prüfen, ob eine Integration mit der bestehenden Akte sinnvoll ist und dann ggf. das Interaktionsmuster "Zusammenführen von Fallakten" ausführen.
- Der EFA-Provider prüft die Angaben zur Einwilligung und stellt sicher, dass er diese in seinem Berechtigungsmanagement abbilden kann:
- Die Angaben zur Identität der Teilnehmer ermöglichen eine sichere Identifizierung der Teilnehmer.
- Die Angaben zu den Rollen der Teilnehmer ermöglichen eine Zuordnung der Teilnehmer zu mit konkreten Zugriffsrechten hinterlegten EFA-Rollen.
- Die Angaben zur Gültigkeit der Einwilligung entsprechen den Vorgaben des Providers (z.B. in Bezug auf die maximale Gültigkeitsdauer von Fallakten)
- Der EFA-Provider identifiziert die aktuell gültige Einwilligung und stellt eine Verknüpfung der neuen Einwilligung zu der bestehenden Einwilligung her, aus der ersichtlich ist, dass die neue Einwilligung die bestehenden Einwilligung ersetzt.
- Sofern in der Einwilligung ein konkretisierter Zweck benannt ist: Der EFA-Provider ändert die Zweckbezeichnung aller Partitionen der Akte.
- Der EFA-Provider bildet den in der Einwilligung benannten Teilnehmerkreis in seinem internen Berechtigungsmanagement so ab, dass die Teilnehmer ihrer Rolle entsprechenden Zugriffsrechte auf der Akte erhalten.
- Der EFA-Provider legt die übergebenen Daten (Angaben zur Einwilligung, ggf. Einwilligungsdokument) zur sicheren Speicherung im Document Repository ab. Hierzu verfährt er analog zum Kommunikationsmuster Einstellen von Dokumenten
- Der EFA-Provider meldet dem Teilnehmer die erfolgreiche Anpassung der Fallakte an die neue Einwilligung.
Anfordern eines Berechtigungstoken
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.10}
Das Anfordern eines durch einen Dritten einlösbaren Berechtigungstoken erfolgt innerhalb eines gültigen EFA-Sicherheitskontexts und bedingt, dass der das Token anfordernde Nutzer ein berechtigter Teilnehmer der Fallakte ist.
Die Anforderung und Bereitstellung eines Berechtigungstoken erfolgt in den folgenden Schritten:
- Aufbau eines Sicherheitskontextes, der dem EFA-Provider die sichere Identifizierung und Authentifizierung des Teilnehmers ermöglicht (siehe Kommunikationsmuster Aufbau des Sicherheitskontextes).
- Ermitteln der ecrRef, mittels der die Fallakte eindeutig identifizierbar sind, für die ein Berechtigungstoken ausgestellt werden soll. Sofern diese ID nicht bereits bekannt ist, muss sie über das Kommunikationsmuster Auflisten von Partitionen ermittelt werden.
- Senden des Aktenverweises an den Ressource Manager des EFA-Providers.
- Der EFA-Provider prüft, ob der Teilnehmer für diese Akte Berechtigungstoken anfordern und ausgeben darf. Falls dies nicht der Fall sein sollte, wird die Operation mit einer Fehlermeldung abgebrochen.
- Der EFA-Provider prüft, ob die bestehende Einwilligung die Ausstellung von Berechtigungstoken zulässt. Falls dies nicht der Fall sein sollte, wird die Operation mit einer Fehlermeldung abgebrochen.
- Der EFA-Provider stellt ein Berechtigungstoken für die Akte aus und registriert dieses beim Policy Provider.
- Der EFA-Provider sendet dem Teilnehmer das Berechtigungstoken (accessToken-Object) zu.
Das Berechtigungstoken liegt beim Teilnehmer nun in digitaler Form vor und kann auf einen beliebigen Träger aufgebracht und an den Patienten übergeben werden.
Einlösen eines Berechtigungstoken
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.11}
Das Einlösen eines Berechtigungstoken erfolgt innerhalb eines gültigen EFA-Sicherheitskontexts. Durch das Einlösen eines Berechtigungstoken wird der einreichende Arzt berechtigter Teilnehmer der Fallakte, für die das Token ausgestellt wurde.
Das Einlösen eines Berechtigungstoken erfolgt in den folgenden Schritten:
- Aufbau eines Sicherheitskontextes, der dem EFA-Provider die sichere Identifizierung und Authentifizierung des als Teilnehmer zu registrierenden Leistungserbringers ermöglicht (siehe Kommunikationsmuster Aufbau des Sicherheitskontextes).
- Senden des Berechtigungstoken (accessToken-Object) an den Resource Manager des EFA-Providers.
- Der EFA-Provider extrahiert aus dem Berechtigungstoken die ecrRef, mittels der die Fallakte eindeutig identifizierbar ist, für die ein Berechtigungstoken eingelöst werden soll.
- Der EFA-Provider prüft, ob das Token authentisch und durch den einreichenden Leistungserbringer einlösbar ist. Falls dies nicht der Fall sein sollte, wird die Operation mit einer Fehlermeldung abgebrochen.
- Der EFA-Provider stellt für den Teilnehmer eine Berechtigungspolicy für die Akte aus. Sofern die Berechtigung mehrfach oder dauerhaft gültig ist, registriert der Policy Provider die Policy an seinem internen Berechtigungsmanagement.
- Der EFA-Provider sendet dem Teilnehmer die Berechtigungspolicy (subjectAccessPolicy-Objekt) zu.
Die Berechtigungspolicy kann von dem Teilnehmer über das Client-Policy-Push Verfahren unmittelbar zum Zugriff auf die Akte genutzt werden.