EFA Kommunikationsmuster

Aus Hl7wiki
(Teildokument von CDA für die elektronische Fallakte)
Wechseln zu: Navigation, Suche
K
(Invalidieren eines Dokuments)
 
(74 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
{{Infobox Dokument
+
{{DocumentPart
|Title    = EFA Kommunikationsmuster
 
|Short    = EFA Kommunikationsmuster
 
|Namespace = cdaefa
 
|Type      = Implementierungsleitfaden
 
|Version  = 0.9
 
|Submitted = February 2013
 
|Author    = Jörg Caumanns, Raik Kuhlisch
 
|Date      = March 2013
 
|Copyright = 2012-2013
 
|Status    = Draft
 
|Period    = xxx
 
|OID      = n.n.
 
|Realm    = Deutschland
 
 
}}
 
}}
 +
''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.<br>Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "[[cdaefa:Kommentierung EFAv2.0|Kommentierung EFAv2.0]]".''
 +
----
 +
 +
== Kommunikationsmuster ==
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01}</tt>
 +
 +
Kommunikationsmuster beschreiben die geschäftlichen [[cdaefa:Interaktionsmuster_der_EFA|Interaktionsmuster der EFA]] mit logischen Transaktionen zwischen den [[cdaefa:EFA_Dienste|technischen Akteuren]] der EFA.
 +
 +
Die nachfolgende Tabelle zeigt, welches Kommunikationsmuster welches Interaktionsmuster auf der logischen Ebene realisiert.
 +
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!Interaktionsmuster
 +
!Kommunikationsmuster
 +
!Anmerkungen
 +
|-
 +
|[[cdaefa:CIM Auffinden der Fallakten eines Patienten|Auffinden der Fallakten eines Patienten]]
 +
|[[#Auflisten von Partitionen|Auflisten von Partitionen]]
 +
|Das Kommunikationsmuster gibt dem EFA-Teilnehmersystem eine Liste aller verfügbaren EFA-Partionen eines Patienten. Sie sind mit dem Zweck der Fallakte verknüpft, sodass das EFA-Teilnehmersystem eine Liste der Fallakten erstellen kann.
 +
|-
 +
|[[cdaefa:CIM Browsing über eine Akte oder eine Partition|Browsing über eine Akte]]
 +
|[[#Auflisten von Dokumenten einer Partition|Auflisten von Dokumenten]]
 +
|Das Kommunikationsmuster gibt dem EFA-Teilnehmersystem die Metadaten der Dokumente einer EFA-Partition. Diese Daten ermöglichen es dem Teilnehmersystem, eine strukturierte, navigierbare Sicht für den Arzt zu erzeugen. Das Muster kann für verschiedene Partitionen wiederholt werden.
 +
|-
 +
|[[cdaefa:CIM Abruf von Datenobjekten|Abruf von Datenobjekten]]
 +
|[[#Abrufen von Dokumenten|Abrufen von Dokumenten]]
 +
|
 +
|-
 +
|[[cdaefa:CIM:Einstellen von Datenobjekten|Einstellen von Datenobjekten]]
 +
|[[#Einstellen von Dokumenten|Einstellen von Dokumenten]]
 +
|
 +
|-
 +
|[[cdaefa:CIM Invalidieren von Datenobjekten|Invalidieren von Datenobjekten]]
 +
|[[#Invalidieren eines Dokuments|Invalidieren eines Dokuments]]
 +
|
 +
|-
 +
|[[cdaefa:CIM Anlegen einer Fallakte|Anlegen einer Fallakte]]
 +
|[[#Anlegen einer Fallakte|Anlegen einer Fallakte]]
 +
|
 +
|-
 +
|[[cdaefa:CIM Anlegen und Registrieren einer Partition|Anlegen und Registrieren einer Partition]]
 +
|[[#Anlegen einer Partition zu einer bestehenden Fallakte|Anlegen einer Partition]]
 +
|
 +
|-
 +
|[[cdaefa:CIM Schließen einer Fallakte|Schließen einer Fallakte]]
 +
|[[#Schließen einer Fallakte|Schließen einer Fallakte]]
 +
|
 +
|-
 +
|[[cdaefa:CIM Anpassen des Teilnehmerkreises|Änderung einer Einwilligung]]
 +
|[[#Registrierung einer neuen Einwilligung|Registrierung einer neuen Einwilligung]]
 +
|
 +
|-
 +
| rowspan="2"|[[cdaefa:CIM_Autorisierung_eines_weiteren_Teilnehmers|Autorisierung eines weiteren Teilnehmers]]
 +
|[[#Anfordern eines Berechtigungstoken|Anfordern eines Berechtigungstoken]]
 +
|Der Patient erhält vom berechtigten EFA-Teilnehmer ein Offline-Token für die Fallakte.
 +
|-
 +
|[[#Einlösen eines Berechtigungstoken|Einlösen eines Berechtigungstoken]]
 +
|Der Patient übergibt das Offline-Token einem anderen Arzt und berechtigt ihn somit, auf die Fallakte zuzugreifen.
 +
|}
 +
 +
=== Aufbau des Sicherheitskontextes ===
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.01}</tt>
 +
 +
Alle Operationen der EFA-Fachdienste und die meisten Operationen der EFA-Sicherheitsdienste müssen mit einem [[cdaefa:EFA_Security_Informationsmodell#context|Sicherheitskontext]] aufgerufen werden. Er ermöglicht es den Diensten, [[EFA-Berechtigungsregel|EFA-Berechtigungsregeln]] zu prüfen und durchzusetzen sowie Dienstaufrufe datenschutzkonform zu protokollieren.
 +
 +
[[Datei:PIM_SEQ_Kontext_aufbauen.png|705px]]
 +
 +
Dieses Muster ist abhängig von der Authentisierung des Arztes am EFA-Teilnehmersystem (TNS). Sie unterliegt nicht der EFA-Spezifikation, muss jedoch die Regularien des EFA-Sicherheitskonzeptes berücksichtigen.
 +
 +
Um den Sicherheitskontext aufzubauen:
 +
# Das TNS ruft die Operation [[cdaefa:EFA_Context_Manager_SFM#Operation:_OpenContext|''openContext'']] des [[cdaefa:EFA_Context_Manager_SFM|EFA-Kontext-Managers]] auf. Sie übernimmt die Credentials des EFA-Teilnehmers und gegebenenfalls weitere Identitätsmerkmale.
 +
# Der EFA-Kontext-Manager ruft die Operation [[cdaefa:EFA_Identity_Provider_SFM|''requestHPIdentityAssertion'']] des Identity Providers auf.
 +
# Wenn das Sicherheitskonzept der EFA-Provider-Domäne das Policy-Push-Verfahren anwendet, dann ruft der EFA-Kontext-Manager die Operation [[cdaefa:EFA_Policy_Provider_SFM|''requestPolicy'']] des Policy Providers auf.
 +
# Der EFA-Kontext-Manager baut mit den Sicherheitsobjekten den Sicherheitskontext auf und gibt ihn dem TNS.
 +
 +
=== Anlegen einer Fallakte ===
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.02}</tt>
 +
 +
Dieses Muster ist abhängig von [[cdaefa:EFA_Kommunikationsmuster#Aufbau_des_Sicherheitskontextes|''Aufbau des Sicherheitskontextes'']].
 +
 +
Um eine Fallakte anzulegen:
 +
# Mit dem EFA-Teilnehmersystem ruft der Arzt die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#createECR|createECR]] des EFA-Ressourcen-Manager 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.
 +
 +
[[Datei:PIM_SEQ_EFA_Anlegen_var1.png|611px]]
 +
 +
==== Neu-Anlage einer Fallakte ====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.02.01}</tt>
 +
 +
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,
 +
* erstellt und aktiviert für die Fallakte eine [[EFA-Berechtigungsregel]], die konform zum consentInfo ist.
  
Status: [[Datei:Icon_33_percent.png]]
+
==== Fusion mit einer bestehenden Fallakte ====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.02.02}</tt>
  
Offene Punkte:
+
Vorbedingung dieser Variante: Der EFA-Provider führt eine bestehende Fallakte mit dem gleichen Zweck für den Patienten.
* Anlegen Partition
 
* Schließen Fallakte
 
* Abruf Fallakten/Partitionen
 
* Browsing Akte/Partition
 
* Abruf Dokument
 
* Einstellen Dokument
 
* Invalidieren Dokument
 
  
== Akteure der EFA-Kommunikationsmuster ==
+
Der EFA-Ressourcen-Manager
 +
# prüft, ob
 +
## die [[EFA-Berechtigungsregel]] der bestehenden Fallakte den zugreifenden Arzt als Berechtigten auszeichnet. Wenn nicht, dann wird der Vorgang mit einer Fehlermeldung abgebrochen.
 +
## die Einwilligung für das Anlegen der Fallakte die Übernahme einer bestehenden Fallkte autorisiert. Wenn nicht, dann wird der Vorgang mit einer Fehlermeldung abgebrochen.
 +
# erstellt eine Fallakte, die aus einer Partition besteht,
 +
# speichert und registriert consentInfo sowie consentDoc,
 +
# erstellt und aktiviert für die Fallakte eine [[EFA-Berechtigungsregel]], die 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.
  
Die logische Anwendungsebene einer Fallakten-Infrastruktur besteht im einfachsten Fall aus fünf Klassen von Akteuren:
+
{{NoteBox|'''Aktenfusion vs. Änderung der Einwilligung'''<br>
* Ein EFA-Kontext-Manager ('''eCR Context Manager''') baut den Sicherheitskontext zur Nutzung von Fallakten auf und verwaltet die darin bereit gestellten Sicherheitsnachweise des EFA-Teilnehmers.
+
Der Zustand der Fallakte nach Ablauf dieses Kommunikationsmusters entspricht weitestgehend einem Zustand, der auch über das Kommunikationsmuster [[cdaefa:EFA_Kommunikationsmuster#Registrierung_einer_neuen_Einwilligung|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.
* Ein EFA-Ressource-Manager('''eCR Resource Manager''') stellt ein Verzeichnis zur Verwaltung von Fallakten und EFA-Partitionen bereit. Mit dem selben Patienten und dem selben Zweck verbundene Partitionen bilden eine Fallakte.
 
* Ein EFA-Daten-Register ('''eCR Document Registry''') stellt ein Verzeichniss zur Verwaltung von Dokumenten bereit. In einem regionalen Gesundheitsnetz kann ein einzelner EFA-Teilnehmer das EFA-Register für das gesamte Netzwerk anbieten.
 
* Ein EFA-Speichersystem ('''eCR Repository''') hält die registrierten Dokumente vor und stellt sie für berechtigte Nutzer zum Abruf bereit. Jeder EFA-Teilnehmer kann ein eigenes EFA-Speichersystem bereitstellen und an das EFA-Register anbinden.
 
* Ein EFA-Teilnehmersystem ('''eCR Consumer''') bildet eine Nutzerschnittstelle ab, über die ein Arzt Behandlungsdaten anderer Ärzte aus an einem EFA-Register registrierten Speichersystemen abrufen kann bzw. in einem Speichersystem verwaltete Behandlungsdaten am EFA-Register registrieren kann.
 
  
Hinzu kommen zwei Klassen von Sicherheitstoken-Diensten, die jeweils Sicherheitsnachweise zum Aufbau eines zwischen EFA-Teilnehmersystem und EFA-Fachdienst (Register bzw. Speichersystem) geteilten Sicherheitskontextes bereit stellen:
+
Damit entspricht eine Aktenfusion einer Sequenz der Kommunikationsmuster [[cdaefa:EFA_Kommunikationsmuster#Registrierung_einer_neuen_Einwilligung|Registrierung einer neuen Einwilligung]] und [[cdaefa:EFA_Kommunikationsmuster#Anlegen_einer_Partition_zu_einer_bestehenden_Fallakte|Anlegen einer Partition]].
* Ein '''Identity Provider''' stellt einen von allen anderen EFA-Akteuren als vertrauenswürdig akzeptierten Identitätsnachweis für authentifizierte Nutzer aus. Der Identity Provider unterstützt potenziell beliebige Verfahren der Authentifizierung (z. B. mittels Passwort, HBA oder SMC-B).  
+
}}
* Ein '''Policy Provider''' liefert die für den aufrufenden Nutzer gültigen Berechtigungsregeln (Policy) auf einer spezifischen Fallakte.
 
  
Der Aufruf der Sicherheitstoken-Dienste und die Verwaltung der von diesen abgerufenen Sicherheitsnachweise wird gegenüber dem EFA-Teilnehmersystem über den EFA-Kontext-Manager gekapselt.
+
=== Anlegen einer Partition zu einer bestehenden Fallakte ===
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.03}</tt>
  
[[Datei:PIM_EFA_Dienste.png|480px]]
+
[[Datei:PIM_SEQ_Partition_Anlegen.png|386px]]
  
== Aufbau des Sicherheitskontextes ==
+
Dieses Muster ist abhängig von [[cdaefa:EFA_Kommunikationsmuster#Auflisten_von_Partitionen|Auflisten von Partitionen]].
  
Die nachfolgende Abbildung stellt das Kommunikationsmuster zum Aufbau des Sicherheitskontextes im Überblick dar. Jeder nachfolgende Aufruf eines EFA-Dienstes erfordert, dass der im EFA-Kontext-Manager verwaltete Sicherheitskontext in Form von authentischen Sicherheitsnachweisen an den aufgerufenen Dienst übergeben wird. Dieser wird so in die Lage versetzt, den Sicherheitskontext des Aufrufers zu rekonstruieren und dadurch den Aufruf innerhalb dieses Kontextes gegen die geltenden Sicherheitsregeln zu verifizieren.
+
Um eine Partition zu einer bestehenden Fallakte anzulegen:
 +
# Das EFA-Teilnehmersystem (TNS) wählt die Fallakte aus der [[cdaefa:EFA_Business_Informationsmodell#partitionList|Liste der Partitionen]] aus.
 +
# Das TNS ruft die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#createPartition|''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 die Kennung der Partition.
  
[[Datei:PIM_SEQ_Kontext_aufbauen.png|640px]]
+
=== Schließen einer Fallakte ===
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.04}</tt>
  
# Der EFA-Teilnehmer authentisiert sich gegenüber dem EFA-Teilnehmersystem. Die EFA Spezifikation macht hierzu keine normativen technischen Vorgaben, Umsetzungen müssen jedoch die Regularien des EFA Sicherheitskonzepts berücksichtigen.
+
[[Datei:PIM_SEQ_EFA_Close.png|584px]]
# Das EFA-Teilnehmersystem (TNS) erfasst die für die EFA-Nutzung wichtigen Informationen zum EFA-Teilnehmer und übermittelt sie an den EFA-Kontext-Manager. Hierzu wird die [[cdaefa:EFA_Context_Manager_SFM#Operation:_OpenContext|funktionale Schnittstelle ''openContext'']] des [[cdaefa:EFA_Context_Manager_SFM|EFA-Kontext-Managers]] verwendet.
 
# Der [[cdaefa:EFA_Context_Manager_SFM|EFA-Kontext-Manager]] nutzt die übergebenen Informationen, um für den EFA-Teilnehmer von den EFA-Sicherheitsdiensten Sicherheitsnachweise abzurufen, die von den EFA-Fachdiensten prüfbar sind. Welche Dienste aufgerufen werden, hängt von der konkreten Sicherheitspolitik eines EFA-Netzwerks ab. Eine typische Konfiguration umfasst den Aufruf des ''Identity Providers'' zum Abruf eines netzweit gültigen Identitäts- und Authentisierungsnachweises. Optional können auch Teile der für den Teilnehmer geltenden Zugriffspolitik bereits vor dem Aufruf der EFA-Fachdienste von einem ''EFA Policy Provider'' abgefragt werden.
 
# Der [[cdaefa:EFA_Context_Manager_SFM|EFA-Kontext-Manager]] verknüpft die abgerufenen Sicherheitsnachweise mit der aktuellen Nutzersitzung und liefert einen Verweis auf den so gebildeten Sicherheitskontext an das EFA-Teilnehmersystem zurück.
 
  
== Anlegen einer Fallakte ==
+
Dieses Muster ist abhängig von [[cdaefa:EFA_Kommunikationsmuster#Auflisten_von_Partitionen|Auflisten von Partitionen]].
  
Eine neue Fallakte wird angelegt, indem im EFA-Ressource-Manager eines EFA-Providers für den betroffenen Patienten eine neue Partition angelegt wird, die sowohl mit einem Zweck als auch einer Einwilligung verbunden ist:
+
Um eine Fallakte zu schließen:
* Gemäß der Vorgaben des Interaktionsmusters [[cdaefa:CIM_Anlegen_einer_Fallakte|''Anlegen einer Fallakte'']] erteilt der Patient eine informierte, schriftliche Einwilligung über die Nutzung einer Fallakte zur Unterstützung einer Behandlung. Die vom Patienten benannten Teilnehmer der Behandlung sind die zugriffsberechtigten Teilnehmer der Fallakte.
+
# Das EFA-Teilnehmersystem (TNS) wählt die zu schließende Fallakte aus der [[cdaefa:EFA_Business_Informationsmodell#partitionList|Liste der Partitionen]] aus.
* Der Arzt baut über sein EFA-Teilnehmersystem den zur Anlage einer EFA erforderlichen Sicherheitskontext auf (siehe Kommunikationsmuster [[cdaefa:EFA_Kommunikationsmuster#Aufbau_des_Sicherheitskontextes|Aufbau des Sicherheitskontextes]]).
+
# Das TNS ruf die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#closeECR|''closeECR'']] des EFA-Ressourcen-Managers auf.
* Der Arzt fordert beim von seinem EFA-Provider bereit gestellten ''EFA-Ressource-Manager'' die Anlage einer neuen Fallakte an. Hierbei benennt der den Zweck der Akte sowie die als Teilnehmer zu berechtigenden Personen und Organisationen. Mit der Anlage einer Fallakte ist implizit die Anlage einer Partition verknüpft.
+
# Der EFA-Ressourcen-Manager
 +
## führt für die Dokumente, die das Schließen begründen, das Muster [[cdaefa:EFA_Kommunikationsmuster#Speichern_und_Registrieren_von_Dokumenten|Speichern und Registrieren von Dokumenten]] aus,
 +
## ändert den Status und die EFA-Berechtigungsregel der Fallakte gemäß des [[cdaefa:EFA_Business_Lebenszyklus|Lebenszyklus]] und
 +
## gibt die Kennung der Partition, mit der die Dokumente verknüpft sind, dem TNS.
  
[[Datei:PIM_SEQ_EFA_Anlegen_var1.png|560px]]
+
{{NoteBox|'''Eine Fallakte im EFA-Verbund schließen'''<br>
 +
Die Partitionen einer Fallakte können auf mehrere EFA-Provider verteilt sein. In diesem Fall schließt dieses Kommunikationsmuster lediglich die Partitionen, die in der Community des Arztes (also bei dessen EFA-Provider) geführt werden.
  
* Der EFA-Provider prüft, ob für den Patienten bereits eine Fallakte existiert, die mit dem angegebenen Zweck assoziiert ist. Im Ergebnis dieser Prüfung müssen zwei Konstellationen unterschieden werden:
+
Um die gesamte Fallakte zu schließen, müssen die restlichen teilnehmenden EFA-Provider benachrichtigt werden. Dieser Prozess unterliegt nicht der EFA-Spezifikation. Ein EFA-Verbund muss aber zumindest einen organisatorischen Prozess definieren.
** Es besteht noch keine Fallakte für den benannten Patienten und den benannten Zweck: Eine neue, aus einer einzigen Partition bestehende Fallakte wird angelegt
+
}}
** Es besteht bereits eine Fallakte für den benannten Patienten und den benannten Zweck: Im Ergebnis der angeforderten Anlage einer neuen EFA wird diese der bestehenden Fallakte als weitere Partition hinzugefügt. Der Teilnehmerkreis (und damit die Zugriffsrechte) werden wie in der neuen Einwilligung angegeben angepasst.
 
  
Die nachfolgenden Abschnitte definieren das Verhalten des EFA-Providers in diesen beiden Konstellationen.  
+
=== Auflisten von Partitionen ===
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.05}</tt>
  
=== Neu-Anlage einer Fallakte ===
+
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.
  
* Im EFA-Berechtigungsmanagement des EFA-Providers wird eine neue Berechtigungsregel registriert, die den für die Aktenanlage angegebenen Zweck und die Patientenidentität mit den in der Patienteneinwilligung angegebenen Vorgaben zu den EFA-Teilnehmern und der Gültigkeit der Fallakte verknüpft.
+
[[Datei:PIM_SEQ_Partitionen_Auflisten.png|609px]]
** (Patient, Zweck) -> (Teilnehmer, Gültigkeit)
 
* Der EFA-Provider legt zu der Akte eine initiale Partition als Container-Objekt an, mit dem Dokumente verknüpft werden können.
 
* Sofern die Einwilligung des Patienten als (gescanntes) Dokument vorliegt, wird diese als Dokument in die neu angelegte Partition eingestellt.
 
  
=== Fusion mit einer bestehenden Fallakte ===
+
Dieses Muster ist abhängig von [[cdaefa:EFA_Kommunikationsmuster#Aufbau_des_Sicherheitskontextes|Aufbau des Sicherheitskontextes]].
  
* Im EFA-Berechtigungsmanagement des EFA-Providers wird die Patienteneinwilligung (Berechtigungsregel) für die bestehende Fallakte darauf hin geprüft, ob
+
Um die verfügbaren Partitionen aufzulisten:
** der Arzt, der die neue Akte anlegen möchte, als Teilnehmer an der bereits zum selben Zweck bestehenden Akte registriert ist. Ist dieses der Fall, wird der Vorgang abgebrochen und eine Fehlermeldung ausgegeben. Ein bereits berechtigter EFA-Teilnehmer kann zu einer bestehenden Akte eine neue Partition hinzufügen oder eine neue/erweiterte Patienteneinwilligung registrieren. Eine gleichzeitige Ausführung beider Aktionen ist nicht möglich, da sich in diese Aktivität unterschiedliche Motivationen hinein interpretieren ließen, die jeweils zu einer unterschiedlichen Verarbeitung der übergebenen Berechtigungen führen würden.
+
# Das TNS ruft die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listPartitions|''listPartitions'']] des Resource Managers auf.
** die zu der bestehenden Akte registrierte Einwilligung eine Erweiterung der Berechtigungen durch aktuell nicht registrierte Personen/Organisationen zulässt. Ist dies nicht der Fall, wird der Vorgang abgebrochen und eine Fehlermeldung ausgegeben. In diesem Szenario müsste ein bereits berechtigter Teilnehmer zunächst die neue Einwilligung des Patienten an der Akte registrieren. Anschließend könnte der so zum Aktenzugang berechtigte Arzt eine neue Partition an der Akte registrieren.
+
# Der Resource Manager
** die vom Patienten für die neue Akte gegebene Einwilligung die Fusion mit einer eventuell bereits bestehenden Akte autorisiert. Ist dies nicht der Fall, wird der Vorgang abgebrochen und eine Fehlermeldung ausgegeben. Um die bestehende Akte dennoch um eine weitere Partition erweitern zu können, muss eine entsprechend erweiterte Einwilligung des Patienten vorliegen.
+
## identifiziert die lokal verfügbaren Partitionen,
* Die bestehende Akte wird um eine neue Partition erweitert.
+
## ruft für jeden Mount-Point die Operation ''listPartitions'' des für den Mount-Point verantwortlichen Resource Managers eines benachbarten EFA-Providers auf und
* Die im EFA-Berechtigungsmanagement des EFA-Providers bereits registrierten Berechtigungsregeln werden um die in der neuen Einwilligungserklärung benannten Teilnehmer erweitert.
+
## gibt die [[cdaefa:EFA_Business_Informationsmodell#partitionList|Liste der Partitionen]] dem TNS.
* Sofern die neue/erweiterte Einwilligung des Patienten als (gescanntes) Dokument vorliegt, wird diese als Dokument in die neu angelegte Partition eingestellt.
+
 
 +
=== Einstellen von Dokumenten ===
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.06}</tt>
 +
 
 +
[[Datei:PIM_SEQ_Daten_Einstellen.png|540px]]
 +
 
 +
Dieses Muster ist abhängig von:
 +
* [[cdaefa:EFA_Kommunikationsmuster#Auflisten_von_Partitionen|Auflisten von Partitionen]] und
 +
* [[cdaefa:EFA_Kommunikationsmuster#Auflisten_von_Dokumenten|Auflisten von Dokumenten]] (optional).
 +
 
 +
Um Dokumente in eine Partition einzustellen:
 +
# Das EFA-Teilnehmersystem (TNS) wählt die Partition aus der [[cdaefa:EFA_Business_Informationsmodell#partitionList|Liste der Partitionen]] aus.
 +
# Das TNS erfasst die [[cdaefa:EFA_Business_Informationsmodell#docRelationship|Dokumentbeziehungen]] mithilfe der Liste der Dokumente (optional).
 +
# Das TNS ruft die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#provideData|''provideData'']] des EFA-Document-Repository auf.
 +
# Das EFA-Document-Repository
 +
## speichert das Datenobjekt (docData) jedes [[cdaefa:EFA_Business_Informationsmodell#document|Dokuments]],
 +
## ruft die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#registerData|''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.
 +
 
 +
{{NoteBox|'''Zuordnung von Teilnehmern zu Providern'''<br>
 +
Jeder EFA-Teilnehmer ist immer einer oder mehreren [[cdaefa:EFA_Provider|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 ===
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.07}</tt>
 +
 
 +
[[Datei:PIM_SEQ_Daten_Auflisten.png|779px]]
 +
 
 +
Dieses Muster ist abhängig von [[cdaefa:EFA_Kommunikationsmuster#Auflisten_von_Partitionen|Auflisten von Partitionen]].
 +
 
 +
Um die Dokumente einer Fallakte aufzulisten:
 +
# Das EFA-Teilnehmersystem (TNS) wählt die Partitionen, deren Dokumente aufgelistet werden sollen, aus der [[cdaefa:EFA_Business_Informationsmodell#partitionList|Liste der Partitionen]] aus.
 +
# Das TNS ruft für jede gewählte Partitionen die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listPartitionContent|''listPartitionContent'']] des EFA-Document-Registry auf.
 +
# Das EFA-Document-Registry
 +
## sucht die Dokumente der jeweiligen Partition entweder lokal,
 +
## oder ruft die Operation ''listPartitionContent'' des Document Registry des für die Partition zuständigen EFA-Providers auf,
 +
## und gibt Dokument-Metadaten und Dokumentbeziehungen dem TNS.
 +
 
 +
 
 +
=== Abrufen von Dokumenten ===
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.08}</tt>
 +
 
 +
[[Datei:PIM_SEQ_Daten_Abrufen.png|599px]]
 +
 
 +
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 Dokumente aus der Liste der Dokumente aus.
 +
# Das TNS ruft für jedes gewählte Dokumente die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#retrieveData|''retrieveData'']] des EFA-Document-Repository auf.
 +
# Das EFA-Document-Repository
 +
## sucht das Datenobjekt entweder lokal
 +
## oder ruft die Operation ''retrieveData'' des Document Repository in der für das Dokument zuständigen Affinity Domain auf und
 +
## gibt das Datenobjekt des Dokument dem TNS.
 +
 
 +
=== Invalidieren eines Dokuments ===
 +
Beim Invalidieren eines Dokuments wird dessen Status auf "ungültig" gesetzt.
 +
 
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.15}</tt>
 +
 
 +
[[Datei:PIM_SEQ_Dokumente-invalidieren.png|417px]]
 +
 
 +
Dieses Muster ist abhängig von:
 +
* [[cdaefa:EFA_Kommunikationsmuster#Auflisten_von_Dokumenten|Auflisten von Dokumenten]].
 +
 
 +
Um ein Dokument zu invalidieren:
 +
# Das EFA-Teilnehmersystem (TNS) wählt das zu ersetzende Dokument aus.
 +
# Das TNS ruft die Operation [cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#invalidateData|''invalidateData'']] des EFA-Document-Registry auf.
 +
# Das EFA-Document-Registry markiert das referenzierte Dokument als ungültig, sofern dieses in der lokalen Affinity Domain registriert ist
 +
# Das EFA-Document-Repository gibt dem TNS eine Status-Meldung.
 +
 
 +
=== Registrierung einer neuen Einwilligung ===
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.09}</tt>
 +
 
 +
[[Datei:PIM_SEQ_Einwilligung_Einstellen.png|718px]]
 +
 
 +
Dieses Muster ist abhängig von [[cdaefa:EFA_Kommunikationsmuster#Auflisten_von_Partitionen|Auflisten von Partitionen]].
 +
 
 +
Um eine neue Einwilligung zu registrieren:
 +
# Das EFA-Teilnehmersystem (TNS) wählt die Fallakte aus der [[cdaefa:EFA_Business_Informationsmodell#partitionList|Liste der Partitionen]] aus.
 +
# Das TNS ruft die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#registerConsent|''registerConsent'']] des EFA-Ressourcen-Managers auf.
 +
# Der EFA-Ressourcen-Manager führt das Muster [[cdaefa:EFA_Kommunikationsmuster#Speichern_und_Registrieren_von_Dokumenten|Speichern und Registrieren von Dokumenten]] für die Einwilligungsdokumente aus.
 +
# Wenn das consentInfo eine Änderung des Zwecks anzeigt, dann konfiguriert der EFA-Ressourcen-Manager die Metadaten der Partitionen der Fallaktion bei der Document Registry.
 +
# Der EFA-Ressourcen-Manager registriert die neue EFA-Berechtigungsregel beim Policy Provider und
 +
# gibt dem TNS eine Status-Meldung.
 +
 
 +
=== Anfordern eines Berechtigungstoken ===
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.10}</tt>
 +
 
 +
[[Datei:PIM_SEQ_Token_ausstellen.png|438px]]
 +
 
 +
Dieses Muster ist abhängig von [[cdaefa:EFA_Kommunikationsmuster#Auflisten_von_Partitionen|Auflisten von Partitionen]].
 +
 
 +
Um ein Berechtigungstoken anzufordern:
 +
# Das EFA-Teilnehmersystem (TNS) wählt die Fallakte, für die das Berechtigungstoken angefordert werden soll, aus der [[cdaefa:EFA_Business_Informationsmodell#partitionList|Liste der Partitionen]] aus.
 +
# Das TNS ruft die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#issueAccessToken|''issueAccessToken'']] des Policy Providers auf.
 +
# Der Policy Provider gibt das [[cdaefa:EFA_Security_Informationsmodell#accessToken|Berechtigungstoken]] dem TNS.
 +
# Der EFA-Teilnehmer kann das Berechtigungstoken auf einen Träger aufbringen und dem Patienten geben.
 +
 
 +
=== Einlösen eines Berechtigungstoken ===
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.11}</tt>
 +
 
 +
Ein EFA-Teilnehmer löst ein Berechtigungstoken ein, um sich als Zugriffsberechtigter einer Fallakte zu registrieren.
 +
 
 +
[[Datei:PIM_SEQ_Token_einloesen.png|675px]]
 +
 
 +
Dieses Muster ist abhängig von [[cdaefa:EFA_Kommunikationsmuster#Aufbau_des_Sicherheitskontextes|Aufbau des Sicherheitskontextes]].
 +
 
 +
Um ein Berechtigungstoken einzulösen:
 +
# Der EFA-Teilnehmer entnimmt das [[cdaefa:EFA_Security_Informationsmodell#accessToken|Berechtigungstoken]] dem vom Patienten bereitgestellten Träger.
 +
# Das EFA-Teilnehmersystem (TNS) ruft die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#redeemAccessToken|''redeemAccessToken'']] des EFA-Policy-Providers auf.
 +
# Wenn das Berechtigungstoken nicht vom eigenen EFA-Provider ausgestellt wurde, dann ruft der EFA-Policy-Provider die Operation ''redeemAccessToken'' des ausstellenden EFA-Providers auf.
 +
# Der Policy Provider gibt die Subject Access Policy für das Berechtigungstoken dem Policy Provider in der einreichenden EFA-Provider-Domäne.
 +
# Der Policy Provider registriert die Subject Access Policy und führt das Kommunikationsmuster ''Fallakte konsolidieren'' aus.
 +
# Der Policy Provider gibt dem TNS die Subject Access Policy.
 +
 
 +
Wenn der EFA-Provider das [[cdaefa:Gruppierung_von_Anwendungs-_und_Sicherheitsdiensten#Client_Policy_Push|Client-Policy-Push]]-Verfahren erlaubt, dann ruft der Context Manager des TNS die Operation [[cdaefa:EFA_Policy_Provider_SFM#requestPolicy|''requestPolicy'']] des Policy Providers auf.
 +
 
 +
=== Konsolidieren von Fallakten ===
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.14}</tt>
 +
 
 +
Ein EFA-Policy-Provider hat ein Berechtigungstoken für einen EFA-Teilnehmer eingelöst und registriert. Der EFA-Ressourcen-Manager muss daraufhin die eigens geführten Partitionen der Fallakte bei den teilnehmenden EFA-Providern registrieren. Der Ressourcen-Manager der ausstellenden EFA-Provider-Domäne kennt alle teilnehmenden EFA-Provider.
 +
 
 +
[[Datei:PIM_SEQ_Fallakten_konsolidieren.png|652px]]
 +
 
 +
Um eine Fallakte zu konsolidieren:
 +
# Wenn der eigene EFA-Provider keine Partitionen der Fallakte führt:
 +
## Der EFA-Ressource-Manager ruft die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listRecordLocations|''listRecordLocations'']] des EFA-Ressourcen-Managers in der ausstellenden EFA-Provider-Domäne auf.
 +
## Für jede communityID in der Ergebnisliste des Operationsaufrufs: Der EFA-Ressourcen-Manager ruft die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#registerRecordLocation|''registerRecordLocation'']] des EFA-Ressource-Managers der entsprechenden EFA-Provider-Domäne auf.
 +
 
 +
=== Speichern und Registrieren von Dokumenten ===
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.12}</tt>
 +
 
 +
Mit diesem Muster speichert und registriert ein Resourcen Manager Dokumente im Document Repository und Document Registry.
 +
 
 +
[[Datei:PIM_SEQ_Dokumente-speichern-und-registrieren.png|369px]]
 +
 
 +
Um Dokumente zu speichern und zu registrieren:
 +
# Der Resource Manager ruft die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#provideData|''provideData'']] des Document Repository auf.
 +
# Das Document Repository
 +
## speichert das Datenobjekt (docData) jedes [[cdaefa:EFA_Business_Informationsmodell#document|Dokuments]],
 +
## ruft die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#registerData|''registerData'']] des Document Registry auf.
 +
# Das Document Registry gibt dem Document Repository eine Status-Meldung.
 +
# Das Document Repository gibt dem Resource Manager eine Status-Meldung.
 +
 
 +
=== Verteilen einer Einwilligung im EFA-Verbund ===
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.13}</tt>
 +
 
 +
Mit diesem Muster verteilt ein Resource Manager eine Einwilligung im EFA-Verbund. Alle an einer Fallakte beteiligten EFA-Provider können so ihre [[EFA-Berechtigungsregeln]] anpassen.
 +
 
 +
[[Datei:PIM_SEQ_Einwilligung-verteilen.png|748px]]
 +
 
 +
Um eine Einwilligung zu verteilen:
 +
# Der Resource Manager ruft für jeden Mount-Point der Fallakte die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#notifyOfConsent|''notifyOfConsent'']] des für den jeweiligen Mount-Point verantwortlichen Resource Manager einer benachbarten Affinity Domain auf.
 +
# Der Resource Manager der benachbarten Affinity Domain
 +
## ruft das die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#retrieveData|''retrieveData'']] des Document Repository der lokalen Affinity Domain auf und erhält das consentInfo,
 +
## führt das Muster [[cdaefa:EFA_Kommunikationsmuster#Speichern_und_Registrieren_von_Dokumenten|Speichern und Registrieren von Dokumenten]] aus,
 +
## berechnet die EFA-Berechtigungsregel und registriert sie beim Policy Provider.
  
== Anlegen einer Partition zu einer bestehenden Fallakte ==
 
  
[[Datei:PIM_SEQ_Partition_Anlegen.png|400px]]
 
  
== Schließen einer Fallakte ==
 
  
 
----
 
----
  
* zurück zur [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]
+
 
 +
{{NoteBox|'''Referenzen und Querverweise'''
 +
* [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]
 +
<nowiki></nowiki>
 +
}}

Aktuelle Version vom 17. Februar 2016, 07:45 Uhr

Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

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".


Kommunikationsmuster

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01}

Kommunikationsmuster beschreiben die geschäftlichen Interaktionsmuster der EFA mit logischen Transaktionen zwischen den technischen Akteuren der EFA.

Die nachfolgende Tabelle zeigt, welches Kommunikationsmuster welches Interaktionsmuster auf der logischen Ebene realisiert.

Interaktionsmuster Kommunikationsmuster Anmerkungen
Auffinden der Fallakten eines Patienten Auflisten von Partitionen Das Kommunikationsmuster gibt dem EFA-Teilnehmersystem eine Liste aller verfügbaren EFA-Partionen eines Patienten. Sie sind mit dem Zweck der Fallakte verknüpft, sodass das EFA-Teilnehmersystem eine Liste der Fallakten erstellen kann.
Browsing über eine Akte Auflisten von Dokumenten Das Kommunikationsmuster gibt dem EFA-Teilnehmersystem die Metadaten der Dokumente einer EFA-Partition. Diese Daten ermöglichen es dem Teilnehmersystem, eine strukturierte, navigierbare Sicht für den Arzt zu erzeugen. Das Muster kann für verschiedene Partitionen wiederholt werden.
Abruf von Datenobjekten Abrufen von Dokumenten
Einstellen von Datenobjekten Einstellen von Dokumenten
Invalidieren von Datenobjekten Invalidieren eines Dokuments
Anlegen einer Fallakte Anlegen einer Fallakte
Anlegen und Registrieren einer Partition Anlegen einer Partition
Schließen einer Fallakte Schließen einer Fallakte
Änderung einer Einwilligung Registrierung einer neuen Einwilligung
Autorisierung eines weiteren Teilnehmers Anfordern eines Berechtigungstoken Der Patient erhält vom berechtigten EFA-Teilnehmer ein Offline-Token für die Fallakte.
Einlösen eines Berechtigungstoken Der Patient übergibt das Offline-Token einem anderen Arzt und berechtigt ihn somit, auf die Fallakte zuzugreifen.

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.

PIM SEQ Kontext aufbauen.png

Dieses Muster ist abhängig von der Authentisierung des Arztes am EFA-Teilnehmersystem (TNS). Sie unterliegt nicht der EFA-Spezifikation, muss jedoch die Regularien des EFA-Sicherheitskonzeptes berücksichtigen.

Um den Sicherheitskontext aufzubauen:

  1. Das TNS ruft die Operation openContext des EFA-Kontext-Managers auf. Sie übernimmt die Credentials des EFA-Teilnehmers und gegebenenfalls weitere Identitätsmerkmale.
  2. Der EFA-Kontext-Manager ruft die Operation requestHPIdentityAssertion des Identity Providers auf.
  3. Wenn das Sicherheitskonzept der EFA-Provider-Domäne das Policy-Push-Verfahren anwendet, dann ruft der EFA-Kontext-Manager die Operation requestPolicy des Policy Providers auf.
  4. 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}

Dieses Muster ist abhängig von Aufbau des Sicherheitskontextes.

Um eine Fallakte anzulegen:

  1. Mit dem EFA-Teilnehmersystem ruft der Arzt die Operation createECR des EFA-Ressourcen-Manager auf.
  2. Der EFA-Ressourcen-Manager führt
    1. entweder die Variante Neu-Anlage einer Fallakte
    2. oder die Variante Fusion mit einer bestehenden Fallakte aus.
  3. Der EFA-Ressourcen-Manager gibt die Kennung der Partition dem EFA-Teilnehmersystem.

PIM SEQ EFA Anlegen var1.png

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,
  • erstellt und aktiviert für die Fallakte eine EFA-Berechtigungsregel, die 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

  1. prüft, ob
    1. die EFA-Berechtigungsregel der bestehenden Fallakte den zugreifenden Arzt als Berechtigten auszeichnet. Wenn nicht, dann wird der Vorgang mit einer Fehlermeldung abgebrochen.
    2. die Einwilligung für das Anlegen der Fallakte die Übernahme einer bestehenden Fallkte autorisiert. Wenn nicht, dann wird der Vorgang mit einer Fehlermeldung abgebrochen.
  2. erstellt eine Fallakte, die aus einer Partition besteht,
  3. speichert und registriert consentInfo sowie consentDoc,
  4. erstellt und aktiviert für die Fallakte eine EFA-Berechtigungsregel, die konform zum consentInfo ist. Die Einwilligung zu der bestehenden Fallakte wird außer Kraft gesetzt.
  5. verknüpft die Partitionen der bestehende Fallakte mit der neuen Fallakte.

Anlegen einer Partition zu einer bestehenden Fallakte

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.03}

PIM SEQ Partition Anlegen.png

Dieses Muster ist abhängig von Auflisten von Partitionen.

Um eine Partition zu einer bestehenden Fallakte anzulegen:

  1. Das EFA-Teilnehmersystem (TNS) wählt die Fallakte aus der Liste der Partitionen aus.
  2. Das TNS ruft die Operation createPartition des EFA-Ressourcen-Managers auf.
  3. Der EFA-Ressourcen-Manager
    1. legt die Partition an,
    2. registriert und speichert gegebenenfalls die Dokumente und verknüpft sie mit der Partition und
    3. gibt dem TNS die Kennung der Partition.

Schließen einer Fallakte

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.04}

PIM SEQ EFA Close.png

Dieses Muster ist abhängig von Auflisten von Partitionen.

Um eine Fallakte zu schließen:

  1. Das EFA-Teilnehmersystem (TNS) wählt die zu schließende Fallakte aus der Liste der Partitionen aus.
  2. Das TNS ruf die Operation closeECR des EFA-Ressourcen-Managers auf.
  3. Der EFA-Ressourcen-Manager
    1. führt für die Dokumente, die das Schließen begründen, das Muster Speichern und Registrieren von Dokumenten aus,
    2. ändert den Status und die EFA-Berechtigungsregel der Fallakte gemäß des Lebenszyklus und
    3. gibt die Kennung der Partition, mit der die Dokumente verknüpft sind, 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.

PIM SEQ Partitionen Auflisten.png

Dieses Muster ist abhängig von Aufbau des Sicherheitskontextes.

Um die verfügbaren Partitionen aufzulisten:

  1. Das TNS ruft die Operation listPartitions des Resource Managers auf.
  2. Der Resource Manager
    1. identifiziert die lokal verfügbaren Partitionen,
    2. ruft für jeden Mount-Point die Operation listPartitions des für den Mount-Point verantwortlichen Resource Managers eines benachbarten EFA-Providers auf und
    3. gibt die Liste der Partitionen dem TNS.

Einstellen von Dokumenten

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.06}

PIM SEQ Daten Einstellen.png

Dieses Muster ist abhängig von:

Um Dokumente in eine Partition einzustellen:

  1. Das EFA-Teilnehmersystem (TNS) wählt die Partition aus der Liste der Partitionen aus.
  2. Das TNS erfasst die Dokumentbeziehungen mithilfe der Liste der Dokumente (optional).
  3. Das TNS ruft die Operation provideData des EFA-Document-Repository auf.
  4. Das EFA-Document-Repository
    1. speichert das Datenobjekt (docData) jedes Dokuments,
    2. ruft die Operation registerData des EFA-Document-Registry auf.
  5. Das EFA-Document-Registry gibt dem EFA-Document-Repository eine Status-Meldung.
  6. Das EFA-Document-Repository gibt dem TNS eine Status-Meldung.

Auflisten von Dokumenten

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.07}

PIM SEQ Daten Auflisten.png

Dieses Muster ist abhängig von Auflisten von Partitionen.

Um die Dokumente einer Fallakte aufzulisten:

  1. Das EFA-Teilnehmersystem (TNS) wählt die Partitionen, deren Dokumente aufgelistet werden sollen, aus der Liste der Partitionen aus.
  2. Das TNS ruft für jede gewählte Partitionen die Operation listPartitionContent des EFA-Document-Registry auf.
  3. Das EFA-Document-Registry
    1. sucht die Dokumente der jeweiligen Partition entweder lokal,
    2. oder ruft die Operation listPartitionContent des Document Registry des für die Partition zuständigen EFA-Providers auf,
    3. und gibt Dokument-Metadaten und Dokumentbeziehungen dem TNS.


Abrufen von Dokumenten

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.08}

PIM SEQ Daten Abrufen.png

Dieses Muster ist abhängig von Auflisten von Dokumenten.

Um Dokumente einer Fallakte abzurufen:

  1. Das EFA-Teilnehmersystem (TNS) wählt die Dokumente aus der Liste der Dokumente aus.
  2. Das TNS ruft für jedes gewählte Dokumente die Operation retrieveData des EFA-Document-Repository auf.
  3. Das EFA-Document-Repository
    1. sucht das Datenobjekt entweder lokal
    2. oder ruft die Operation retrieveData des Document Repository in der für das Dokument zuständigen Affinity Domain auf und
    3. gibt das Datenobjekt des Dokument dem TNS.

Invalidieren eines Dokuments

Beim Invalidieren eines Dokuments wird dessen Status auf "ungültig" gesetzt.

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.15}

PIM SEQ Dokumente-invalidieren.png

Dieses Muster ist abhängig von:

Um ein Dokument zu invalidieren:

  1. Das EFA-Teilnehmersystem (TNS) wählt das zu ersetzende Dokument aus.
  2. Das TNS ruft die Operation [cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#invalidateData|invalidateData]] des EFA-Document-Registry auf.
  3. Das EFA-Document-Registry markiert das referenzierte Dokument als ungültig, sofern dieses in der lokalen Affinity Domain registriert ist
  4. Das EFA-Document-Repository gibt dem TNS eine Status-Meldung.

Registrierung einer neuen Einwilligung

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.09}

PIM SEQ Einwilligung Einstellen.png

Dieses Muster ist abhängig von Auflisten von Partitionen.

Um eine neue Einwilligung zu registrieren:

  1. Das EFA-Teilnehmersystem (TNS) wählt die Fallakte aus der Liste der Partitionen aus.
  2. Das TNS ruft die Operation registerConsent des EFA-Ressourcen-Managers auf.
  3. Der EFA-Ressourcen-Manager führt das Muster Speichern und Registrieren von Dokumenten für die Einwilligungsdokumente aus.
  4. Wenn das consentInfo eine Änderung des Zwecks anzeigt, dann konfiguriert der EFA-Ressourcen-Manager die Metadaten der Partitionen der Fallaktion bei der Document Registry.
  5. Der EFA-Ressourcen-Manager registriert die neue EFA-Berechtigungsregel beim Policy Provider und
  6. gibt dem TNS eine Status-Meldung.

Anfordern eines Berechtigungstoken

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.10}

PIM SEQ Token ausstellen.png

Dieses Muster ist abhängig von Auflisten von Partitionen.

Um ein Berechtigungstoken anzufordern:

  1. Das EFA-Teilnehmersystem (TNS) wählt die Fallakte, für die das Berechtigungstoken angefordert werden soll, aus der Liste der Partitionen aus.
  2. Das TNS ruft die Operation issueAccessToken des Policy Providers auf.
  3. Der Policy Provider gibt das Berechtigungstoken dem TNS.
  4. Der EFA-Teilnehmer kann das Berechtigungstoken auf einen Träger aufbringen und dem Patienten geben.

Einlösen eines Berechtigungstoken

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.11}

Ein EFA-Teilnehmer löst ein Berechtigungstoken ein, um sich als Zugriffsberechtigter einer Fallakte zu registrieren.

PIM SEQ Token einloesen.png

Dieses Muster ist abhängig von Aufbau des Sicherheitskontextes.

Um ein Berechtigungstoken einzulösen:

  1. Der EFA-Teilnehmer entnimmt das Berechtigungstoken dem vom Patienten bereitgestellten Träger.
  2. Das EFA-Teilnehmersystem (TNS) ruft die Operation redeemAccessToken des EFA-Policy-Providers auf.
  3. Wenn das Berechtigungstoken nicht vom eigenen EFA-Provider ausgestellt wurde, dann ruft der EFA-Policy-Provider die Operation redeemAccessToken des ausstellenden EFA-Providers auf.
  4. Der Policy Provider gibt die Subject Access Policy für das Berechtigungstoken dem Policy Provider in der einreichenden EFA-Provider-Domäne.
  5. Der Policy Provider registriert die Subject Access Policy und führt das Kommunikationsmuster Fallakte konsolidieren aus.
  6. Der Policy Provider gibt dem TNS die Subject Access Policy.

Wenn der EFA-Provider das Client-Policy-Push-Verfahren erlaubt, dann ruft der Context Manager des TNS die Operation requestPolicy des Policy Providers auf.

Konsolidieren von Fallakten

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.14}

Ein EFA-Policy-Provider hat ein Berechtigungstoken für einen EFA-Teilnehmer eingelöst und registriert. Der EFA-Ressourcen-Manager muss daraufhin die eigens geführten Partitionen der Fallakte bei den teilnehmenden EFA-Providern registrieren. Der Ressourcen-Manager der ausstellenden EFA-Provider-Domäne kennt alle teilnehmenden EFA-Provider.

PIM SEQ Fallakten konsolidieren.png

Um eine Fallakte zu konsolidieren:

  1. Wenn der eigene EFA-Provider keine Partitionen der Fallakte führt:
    1. Der EFA-Ressource-Manager ruft die Operation listRecordLocations des EFA-Ressourcen-Managers in der ausstellenden EFA-Provider-Domäne auf.
    2. Für jede communityID in der Ergebnisliste des Operationsaufrufs: Der EFA-Ressourcen-Manager ruft die Operation registerRecordLocation des EFA-Ressource-Managers der entsprechenden EFA-Provider-Domäne auf.

Speichern und Registrieren von Dokumenten

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.12}

Mit diesem Muster speichert und registriert ein Resourcen Manager Dokumente im Document Repository und Document Registry.

PIM SEQ Dokumente-speichern-und-registrieren.png

Um Dokumente zu speichern und zu registrieren:

  1. Der Resource Manager ruft die Operation provideData des Document Repository auf.
  2. Das Document Repository
    1. speichert das Datenobjekt (docData) jedes Dokuments,
    2. ruft die Operation registerData des Document Registry auf.
  3. Das Document Registry gibt dem Document Repository eine Status-Meldung.
  4. Das Document Repository gibt dem Resource Manager eine Status-Meldung.

Verteilen einer Einwilligung im EFA-Verbund

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.13}

Mit diesem Muster verteilt ein Resource Manager eine Einwilligung im EFA-Verbund. Alle an einer Fallakte beteiligten EFA-Provider können so ihre EFA-Berechtigungsregeln anpassen.

PIM SEQ Einwilligung-verteilen.png

Um eine Einwilligung zu verteilen:

  1. Der Resource Manager ruft für jeden Mount-Point der Fallakte die Operation notifyOfConsent des für den jeweiligen Mount-Point verantwortlichen Resource Manager einer benachbarten Affinity Domain auf.
  2. Der Resource Manager der benachbarten Affinity Domain
    1. ruft das die Operation retrieveData des Document Repository der lokalen Affinity Domain auf und erhält das consentInfo,
    2. führt das Muster Speichern und Registrieren von Dokumenten aus,
    3. berechnet die EFA-Berechtigungsregel und registriert sie beim Policy Provider.