EFA Kommunikationsmuster

Aus Hl7wiki
(Teildokument von CDA für die elektronische Fallakte)
Wechseln zu: Navigation, Suche
(Anlegen einer Partition zu einer bestehenden Fallakte: Text präzisiert, redundante Beschreibungen entfernt.)
(Invalidieren eines Dokuments)
 
(25 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]]".''
 
''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]]".''
 
----
 
----
Zeile 21: Zeile 7:
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01}</tt>
  
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 [[cdaefa:EFA_Dienste|EFA Diensten]] definierte Ablaufsequenzen realisiert wird. Sie stellen damit das über den EFA Diensten definierte Protokoll dar.
+
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 stellt die Umsetzung der Interaktionsmuster über die hier definierten Kommunikationsmuster dar.
+
Die nachfolgende Tabelle zeigt, welches Kommunikationsmuster welches Interaktionsmuster auf der logischen Ebene realisiert.
  
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
Zeile 32: Zeile 18:
 
|[[cdaefa:CIM Auffinden der Fallakten eines Patienten|Auffinden der Fallakten eines Patienten]]
 
|[[cdaefa:CIM Auffinden der Fallakten eines Patienten|Auffinden der Fallakten eines Patienten]]
 
|[[#Auflisten von Partitionen|Auflisten von Partitionen]]
 
|[[#Auflisten von Partitionen|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.
+
|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]]
 
|[[cdaefa:CIM Browsing über eine Akte oder eine Partition|Browsing über eine Akte]]
 
|[[#Auflisten von Dokumenten einer Partition|Auflisten von Dokumenten]]
 
|[[#Auflisten von Dokumenten einer Partition|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 [[cdaefa:CIM Auffinden der Fallakten eines Patienten|Auffinden der Fallakten eines Patienten]] alle Partitionen der Akte ermittelt werden. Anschließend muss das Kommunikationsmuster [[#Auflisten von Dokumenten|Auflisten von Dokumenten]] für jede einzelne dieser Partitionen abgespult werden.
+
|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]]
 
|[[cdaefa:CIM Abruf von Datenobjekten|Abruf von Datenobjekten]]
 
|[[#Abrufen von Dokumenten|Abrufen von Dokumenten]]
 
|[[#Abrufen von Dokumenten|Abrufen von Dokumenten]]
|Der Abruf eines Dokuments erfordert die Angabe der Dokumenten-ID, die zuvor über das Kommunikationsmuster [[#Auflisten von Dokumenten|Auflisten von Dokumenten]] ermittelt werden muss.
+
|
 
|-
 
|-
 
|[[cdaefa:CIM:Einstellen von Datenobjekten|Einstellen von Datenobjekten]]
 
|[[cdaefa:CIM:Einstellen von Datenobjekten|Einstellen von Datenobjekten]]
 
|[[#Einstellen von Dokumenten|Einstellen von Dokumenten]]
 
|[[#Einstellen von Dokumenten|Einstellen von Dokumenten]]
|Die im Interaktionsmuster beschriebenen Varianten (Ersetzen, Aktualisieren, Verknüpfen von Dokumenten) werden über das Kommunikationsmuster unterstützt.
+
|
 
|-
 
|-
 
|[[cdaefa:CIM Invalidieren von Datenobjekten|Invalidieren von Datenobjekten]]
 
|[[cdaefa:CIM Invalidieren von Datenobjekten|Invalidieren von Datenobjekten]]
|[[#Einstellen von Dokumenten|Einstellen von Dokumenten]]
+
|[[#Invalidieren eines Dokuments|Invalidieren eines Dokuments]]
|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.
+
|
 
|-
 
|-
 
|[[cdaefa:CIM Anlegen einer Fallakte|Anlegen einer Fallakte]]
 
|[[cdaefa:CIM Anlegen einer Fallakte|Anlegen einer Fallakte]]
 
|[[#Anlegen einer Fallakte|Anlegen einer Fallakte]]
 
|[[#Anlegen einer Fallakte|Anlegen einer Fallakte]]
|Das Kommunikationsmuster ist eine 1:1 Abbildung des Interaktionsmusters und seiner Varianten/Ausnahmeszenarien.
+
|
 
|-
 
|-
 
|[[cdaefa:CIM Anlegen und Registrieren einer Partition|Anlegen und Registrieren einer Partition]]
 
|[[cdaefa:CIM Anlegen und Registrieren einer Partition|Anlegen und Registrieren einer Partition]]
 
|[[#Anlegen einer Partition zu einer bestehenden Fallakte|Anlegen einer Partition]]
 
|[[#Anlegen einer Partition zu einer bestehenden Fallakte|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.
+
|
 
|-
 
|-
 
|[[cdaefa:CIM Schließen einer Fallakte|Schließen einer Fallakte]]
 
|[[cdaefa:CIM Schließen einer Fallakte|Schließen einer Fallakte]]
 
|[[#Schließen einer Fallakte|Schließen einer Fallakte]]
 
|[[#Schließen einer Fallakte|Schließen einer Fallakte]]
|Das Kommunikationsmuster ist eine 1:1 Abbildung des Interaktionsmusters und seiner Varianten/Ausnahmeszenarien.
+
|
 
|-
 
|-
 
|[[cdaefa:CIM Anpassen des Teilnehmerkreises|Änderung einer Einwilligung]]
 
|[[cdaefa:CIM Anpassen des Teilnehmerkreises|Änderung einer Einwilligung]]
 
|[[#Registrierung einer neuen Einwilligung|Registrierung einer neuen Einwilligung]]
 
|[[#Registrierung einer neuen 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.
+
|
 
|-
 
|-
 
| rowspan="2"|[[cdaefa:CIM_Autorisierung_eines_weiteren_Teilnehmers|Autorisierung eines weiteren Teilnehmers]]
 
| rowspan="2"|[[cdaefa:CIM_Autorisierung_eines_weiteren_Teilnehmers|Autorisierung eines weiteren Teilnehmers]]
 
|[[#Anfordern eines Berechtigungstoken|Anfordern eines Berechtigungstoken]]
 
|[[#Anfordern eines Berechtigungstoken|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.
+
|Der Patient erhält vom berechtigten EFA-Teilnehmer ein Offline-Token für die Fallakte.
 
|-
 
|-
 
|[[#Einlösen eines Berechtigungstoken|Einlösen eines Berechtigungstoken]]
 
|[[#Einlösen eines Berechtigungstoken|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.
+
|Der Patient übergibt das Offline-Token einem anderen Arzt und berechtigt ihn somit, auf die Fallakte zuzugreifen.
|-
 
|[[cdaefa:CIM Zusammenführen von Fallakten|Zusammenführen von Fallakten]]
 
|[[#Registrierung einer neuen Einwilligung|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|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 ===
 
=== Aufbau des Sicherheitskontextes ===
Zeile 88: Zeile 65:
 
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.
 
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|640px]]
+
[[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:
 
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 [[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.
 
# 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 [[cdaefa:EFA_Context_Manager_SFM|EFA-Kontext-Manager]] ruft den [[cdaefa:EFA_Security_Informationsmodell#subjectIdentity|Identitätsnachweis]] vom [[cdaefa:EFA_Identity_Provider_SFM|Identity Provider]] ab.  
+
# Der EFA-Kontext-Manager ruft die Operation [[cdaefa:EFA_Identity_Provider_SFM|''requestHPIdentityAssertion'']] des Identity Providers auf.
# Wenn das EFA-Sicherheitskonzept der Versorgungsdomäne das Policy-Push-Verfahren anwendet, dann ruft der [[cdaefa:EFA_Context_Manager_SFM|EFA-Kontext-Manager]] den [[cdaefa:EFA_Security_Informationsmodell#subjectIdentity|Berechtigungsnachweis]] vom [[cdaefa:EFA_Policy_Provider_SFM|Policy Provider]] ab.  
+
# 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 [[cdaefa:EFA_Context_Manager_SFM|EFA-Kontext-Manager]] baut mit den Sicherheitsobjekten den Sicherheitskontext auf und gibt ihn dem TNS.
+
# Der EFA-Kontext-Manager baut mit den Sicherheitsobjekten den Sicherheitskontext auf und gibt ihn dem TNS.
  
 
=== Anlegen einer Fallakte ===
 
=== Anlegen einer Fallakte ===
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.02}</tt>
 
<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:
 
Um eine Fallakte anzulegen:
# Der Arzt hat das Kommunikationsmuster [[cdaefa:EFA_Kommunikationsmuster#Aufbau_des_Sicherheitskontextes|''Aufbau des Sicherheitskontextes'']] mit seinem EFA-Teilnehmersystem ausgeführt.
+
# Mit dem EFA-Teilnehmersystem ruft der Arzt die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#createECR|createECR]] des EFA-Ressourcen-Manager auf.
# Mit seinem EFA-Teilnehmersystem ruft der Arzt beim EFA-Ressourcen-Manager die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#createECR|createECR]] auf.
 
 
# Der EFA-Ressourcen-Manager führt
 
# Der EFA-Ressourcen-Manager führt
 
## entweder die Variante ''Neu-Anlage einer Fallakte''
 
## entweder die Variante ''Neu-Anlage einer Fallakte''
Zeile 108: Zeile 87:
 
# Der EFA-Ressourcen-Manager gibt die Kennung der Partition dem EFA-Teilnehmersystem.
 
# Der EFA-Ressourcen-Manager gibt die Kennung der Partition dem EFA-Teilnehmersystem.
  
[[Datei:PIM_SEQ_EFA_Anlegen_var1.png|560px]]
+
[[Datei:PIM_SEQ_EFA_Anlegen_var1.png|611px]]
  
 
==== Neu-Anlage einer Fallakte ====
 
==== Neu-Anlage einer Fallakte ====
Zeile 118: Zeile 97:
 
* erstellt eine Fallakte, die aus einer Partition besteht,
 
* erstellt eine Fallakte, die aus einer Partition besteht,
 
* speichert und registriert consentInfo sowie consentDoc,
 
* speichert und registriert consentInfo sowie consentDoc,
* setzt die [[EFA-Berechtigungsregel]] der  Fallakte so, dass sie konform zum consentInfo ist.
+
* erstellt und aktiviert für die Fallakte eine [[EFA-Berechtigungsregel]], die konform zum consentInfo ist.
  
 
==== Fusion mit einer bestehenden Fallakte ====
 
==== Fusion mit einer bestehenden Fallakte ====
Zeile 127: Zeile 106:
 
Der EFA-Ressourcen-Manager
 
Der EFA-Ressourcen-Manager
 
# prüft, ob
 
# 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 [[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 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 mit einer Fehlermeldung abgebrochen.
 
# erstellt eine Fallakte, die aus einer Partition besteht,
 
# erstellt eine Fallakte, die aus einer Partition besteht,
 
# speichert und registriert consentInfo sowie consentDoc,
 
# 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.
+
# 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.  
 
# verknüpft die Partitionen der bestehende Fallakte mit der neuen Fallakte.  
  
Zeile 143: Zeile 122:
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.03}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.03}</tt>
  
[[Datei:PIM_SEQ_Partition_Anlegen.png|400px]]
+
[[Datei:PIM_SEQ_Partition_Anlegen.png|386px]]
  
Abhängigkeit zu anderen Kommunikationsmustern: [[cdaefa:EFA_Kommunikationsmuster#Auflisten_von_Partitionen|Auflisten von Partitionen]].
+
Dieses Muster ist abhängig von [[cdaefa:EFA_Kommunikationsmuster#Auflisten_von_Partitionen|Auflisten von Partitionen]].
  
 
Um eine Partition zu einer bestehenden Fallakte anzulegen:
 
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 [[cdaefa:EFA_Business_Informationsmodell#partitionList|Liste der Partitionen]] aus.
+
# 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.
 
# Das TNS ruft die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#createPartition|''createPartition'']] des EFA-Ressourcen-Managers auf.
 
# Der EFA-Ressourcen-Manager
 
# Der EFA-Ressourcen-Manager
 
## legt die Partition an,
 
## legt die Partition an,
 
## registriert und speichert gegebenenfalls die Dokumente und verknüpft sie mit der Partition und
 
## registriert und speichert gegebenenfalls die Dokumente und verknüpft sie mit der Partition und
## gibt dem TNS den Verweis auf die Partition.
+
## gibt dem TNS die Kennung der Partition.
  
 
=== Schließen einer Fallakte ===
 
=== Schließen einer Fallakte ===
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.04}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.04}</tt>
  
Eine Fallakte wird durch den EFA-Provider geschlossen, wenn die vom betroffenen Patienten gegebene Einwilligung ihre Gültigkeit verliert (siehe auch Zustandsdiagramme zu den EFA-Geschäftsobjekten).  
+
[[Datei:PIM_SEQ_EFA_Close.png|584px]]
  
Die Gültigkeit der Einwilligung erlischt implizit mit Erreichen des in der Einwilligung angegebenen Gültigkeitsdatums. Hier ist es Verantwortung des EFA-Providers, den entsprechenden [[cdaefa:EFA_Business_Lebenszyklus|Zustandsübergang]] anzustoßen und die Zugriffsrechte auf die Akten entsprechend anzupassen. Darüber hinaus erlischt die Einwilligung, wenn sie entweder explizit vom Patienten zurückgenommen wird oder wenn der Zweck der EFA nicht mehr gegeben ist. In diesen Fällen greift das Interaktionsmuster "[[cdaefa:CIM_Schließen_einer_Fallakte|EFA Schließen]]".
+
Dieses Muster ist abhängig von [[cdaefa:EFA_Kommunikationsmuster#Auflisten_von_Partitionen|Auflisten von Partitionen]].
 
Das Kommunikationsmuster "Schließen einer Fallakte" entspricht weitgehend dem gleichnamigen Interaktionsmuster und besteht im wesentlichen in der Übermittlung der Aufforderung zur Schließung der Akte an den EFA-Provider.
 
  
[[Datei:PIM_SEQ_EFA_Close.png|480px]]
+
Um eine Fallakte zu schließen:
 +
# Das EFA-Teilnehmersystem (TNS) wählt die zu schließende Fallakte aus der [[cdaefa:EFA_Business_Informationsmodell#partitionList|Liste der Partitionen]] aus.
 +
# Das TNS ruf die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#closeECR|''closeECR'']] des EFA-Ressourcen-Managers auf.
 +
# 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.
  
Im Einzelnen werden die folgenden Schritte durchlaufen:
+
{{NoteBox|'''Eine Fallakte im EFA-Verbund schließen'''<br>
# Aufbau eines Sicherheitskontextes, der dem EFA-Provider die sichere Identifizierung und Authentifizierung des Teilnehmers ermöglicht (siehe Kommunikationsmuster [[cdaefa:EFA_Kommunikationsmuster#Aufbau_des_Sicherheitskontextes|Aufbau des Sicherheitskontextes]]).
+
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.
# Auffinden und Öffnen der Fallakte, die geschlossen werden soll. Hierzu werden Metadaten der die Akte repräsentierenden Partitionen abgerufen, in denen u.a. die eindeutige Referenz auf die Akte kodiert ist (siehe Kommunikationsmuster [[cdaefa:EFA_Kommunikationsmuster#Auflisten_von_Partitionen|Auflisten von Partitionen]]). Dieser Schritt ist erforderlich, da Angaben zum Grund der Aktenschließung als Dokument in der Akte abgelegt werden und damit die Voraussetzungen für diesen Schreibzugriff hergestellt werden müssen.
+
 
# Schließen der Akte innerhalb des Sicherheitskontextes durch Angabe der Referenz auf diese Akte sowie der Begründung zur Schließung der Akte.
+
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.
## Der EFA-Provider prüft, ob der Teilnehmer zum Zugriff auf die Akte berechtigt ist. Falls dies nicht der Fall sein sollte, wird die Operation mit einer Fehlermeldung abgebrochen.
+
}}
## Der EFA-Provider verknüpft die Begründung zur Aktenschließung und die ggf. übergebenen Dokumente mit einer bestehenden Partition der Akte.
 
## Der EFA-Provider leitet die Schließung der Akte ein, indem er den Status der Akte und die Zugriffsberechtigungen gemäß des [[cdaefa:EFA_Business_Lebenszyklus|Lebenszyklus]] einer EFA ändert.
 
  
 
=== Auflisten von Partitionen ===
 
=== Auflisten von Partitionen ===
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.05}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.05}</tt>
  
Eine Fallakte ist ein Verbund von Partitionen, die mit dem selben Patienten und dem selben Zweck verknüpft sind. Um auf eine Fallakte zuzugreifen müssen in einem ersten Schritt Informationen zu den zugehörigen Partitionen abgerufen werden. Anhand der so ermittelten Aktenreferenz ([[cdaefa:EFA_Business_Informationsmodell#ecrRef|ecrRef]]) und Partitions-Identifier ([[cdaefa:EFA_Business_Informationsmodell#partitionID|partitionID]]) können anschließend Daten aus der Akte ausgelesen und in die Akte eingestellt werden.
+
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.
  
[[Datei:PIM_SEQ_Partitionen_Auflisten.png|400px]]
+
[[Datei:PIM_SEQ_Partitionen_Auflisten.png|609px]]
  
Das Auflisten der Partitionen der für den anfragenden Nutzer zugreifbaren Fallakten erfolgt in den folgenden Schritten:
+
Dieses Muster ist abhängig von [[cdaefa:EFA_Kommunikationsmuster#Aufbau_des_Sicherheitskontextes|Aufbau des Sicherheitskontextes]].  
# Aufbau eines Sicherheitskontextes, der dem EFA-Provider die sichere Identifizierung und Authentifizierung des Teilnehmers ermöglicht (siehe Kommunikationsmuster [[cdaefa:EFA_Kommunikationsmuster#Aufbau_des_Sicherheitskontextes|Aufbau des Sicherheitskontextes]]).
+
 
# Senden der ID des Patienten, dessen EFAs gefunden und genutzt werden sollen, an den EFA-Provider.
+
Um die verfügbaren Partitionen aufzulisten:
## Der EFA-Provider sucht nach Aktenreferenzen (Patienten-ID und Zweck) an die eine Zugangsberechtigung für den anfragenden Arzt gebunden ist.
+
# Das TNS ruft die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listPartitions|''listPartitions'']] des Resource Managers auf.
## Der EFA-Provider sucht nach Partitionen, die mit den gefundenen Aktenreferenzen verknüpft sind und sendet die Metadaten dieser Partitionen an den Aufrufer zurück
+
# Der Resource Manager
# Das Teilnehmersystem (Primärsystem) zeigt dem Aufrufer die gefundenen Akten und zugehörigen Partitionen an
+
## identifiziert die lokal verfügbaren Partitionen,
 +
## ruft für jeden Mount-Point die Operation ''listPartitions'' des für den Mount-Point verantwortlichen Resource Managers eines benachbarten EFA-Providers auf und
 +
## gibt die [[cdaefa:EFA_Business_Informationsmodell#partitionList|Liste der Partitionen]] dem TNS.
  
 
=== Einstellen von Dokumenten ===
 
=== Einstellen von Dokumenten ===
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.06}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.06}</tt>
  
Daten zu einer Fallakte werden immer in eine an diese Akte gekoppelte Partition eingestellt. Das Einstellen von Daten erfolgt innerhalb eines gültigen EFA-Sicherheitskontexts und bedingt, dass der die Daten einstellende Nutzer ein berechtigter Teilnehmer der Fallakte ist, zu der er Daten hinzufügen möchte.  
+
[[Datei:PIM_SEQ_Daten_Einstellen.png|540px]]
  
Die Benennung der Ziel-Partition erfolgt über eine ''[[cdaefa:EFA_Business_Informationsmodell#partitionID|partitionID]]''. Sofern diese nicht bereits im Primärsystem des Nutzers bekannt ist (z.B. aufgrund einer statischen Verknüpfung eines internen Fall-Identifiers mit dieser Partiton), muss dieser Identifier zunächst durch Öffnen der Fallakte - d.h. Auflisten der zugängigen Partitionen - ermittelt werden. Beziehungen zwischen Daten (z.B. Aktualisierung oder Ergänzung eines bestehenden Dokuments) müssen explizit benannt werden.
+
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).
  
[[Datei:PIM_SEQ_Daten_Einstellen.png|640px]]
+
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 Einstellen von Daten in eine Partition erfolgt in den folgenden Schritten:
+
# Das TNS erfasst die [[cdaefa:EFA_Business_Informationsmodell#docRelationship|Dokumentbeziehungen]] mithilfe der Liste der Dokumente (optional).
# Aufbau eines Sicherheitskontextes, der dem EFA-Provider die sichere Identifizierung und Authentifizierung des Teilnehmers ermöglicht (siehe Kommunikationsmuster [[cdaefa:EFA_Kommunikationsmuster#Aufbau_des_Sicherheitskontextes|Aufbau des Sicherheitskontextes]]).
+
# Das TNS ruft die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#provideData|''provideData'']] des EFA-Document-Repository auf.
# Ermitteln der ''[[cdaefa:EFA_Business_Informationsmodell#partitionID|partitionID]]'', mittels der die Ziel-Partition und deren übergeordnete Fallakte eindeutig identifizierbar sind. Sofern diese ID nicht bereits bekannt ist, muss sie über das Kommunikationsmuster ''[[cdaefa:EFA_Kommunikationsmuster#Auflisten_von_Partitionen|Auflisten von Partitionen]]'' ermittelt werden.
+
# Das EFA-Document-Repository
# Sofern die eingestellten Dokumente eine Aktualisierung oder Ergänzung in der EFA bereits vorhandener Daten darstellen: Ermitteln der documentIDs der zu aktualisierenden bzw. zu ergänzenden Dokumente (z.B. über das Kommunikationsmuster [[cdaefa:EFA_Kommunikationsmuster#Auflisten_von_Dokumenten|Auflisten von Dokumenten]])
+
## speichert das Datenobjekt (docData) jedes [[cdaefa:EFA_Business_Informationsmodell#document|Dokuments]],
# Senden der partitionID und der in diese Partition einzustellenden Daten an das Document Repository des EFA-Providers (siehe auch Hinweisbox weiter unten). Ggf. anzulegende Dokumentenbeziehungen müssen dabei explizit angegeben werden.
+
## ruft die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#registerData|''registerData'']] des EFA-Document-Registry auf.
## Der EFA-Provider prüft, ob der Teilnehmer zum Zugriff auf die der Partition übergeordneten Akte berechtigt ist. Falls dies nicht der Fall sein sollte, wird die Operation mit einer Fehlermeldung abgebrochen.
+
# Das EFA-Document-Registry gibt dem EFA-Document-Repository eine Status-Meldung.
## Der EFA-Provider prüft, ob der Teilnehmer berechtigt ist, bei diesem Provider Daten abzulegen (siehe auch Infobox weiter unten). Falls dies nicht der Fall sein sollte, wird die Operation mit einer Fehlermeldung abgebrochen.
+
# Das EFA-Document-Repository gibt dem TNS eine Status-Meldung.
## Der EFA-Provider legt die übergebenen Daten zur sicheren Speicherung im Document Repository ab
 
## Das Document Repository sendet die Benennung der Ziel-Partition, die Metadaten der empfangenen Dokumente sowie ggf. benannte Dokumentenbeziehungen zur Registrierung an das Document Registry des EFA-Providers
 
## Der EFA-Provider verknüpft die übergebenen Dokumente im Document Registry mit der angegebenen Partition und speichert die Metadaten und Dokumentenbeziehungen sicher ab
 
## Sofern benannte Dokumentenbeziehungen die Ersetzung bestehender Dokumente anzeigen, wird der Status dieser Dokumente entsprechend geändert.  
 
# Der EFA-Provider meldet dem Teilnehmer die erfolgreiche Bereitstellung der übergebenen Dokumente zurück.
 
  
 
{{NoteBox|'''Zuordnung von Teilnehmern zu Providern'''<br>
 
{{NoteBox|'''Zuordnung von Teilnehmern zu Providern'''<br>
Zeile 217: Zeile 197:
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.07}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.07}</tt>
  
Daten zu einer Fallakte werden immer in an diese Akte gekoppelten Partition verwaltet. Das Auflisten der verwalteten Daten erfolgt immer auf Ebene dieser Partitionen, d.h. um alle mit einer Fallakte verknüpften Daten aufzulisten müssen alle Partitionen "angefasst" werden.  
+
[[Datei:PIM_SEQ_Daten_Auflisten.png|779px]]
  
Die Benennung der auszulesenden Partition erfolgt über eine ''[[cdaefa:EFA_Business_Informationsmodell#partitionID|partitionID]]'', die im Rahmen des Öffnens einer Fallakte beim Auflisten der zugängigen Partitionen ermittelt werden kann. Das Auflisten der Daten einer Partition liefert die Metadaten aller in der Partition enthaltenen Dokumente sowie die Beziehungen, die zwischen diesen Dokumenten und Dokumenten in dieser oder anderen Partitionen bestehen.
+
Dieses Muster ist abhängig von [[cdaefa:EFA_Kommunikationsmuster#Auflisten_von_Partitionen|Auflisten von Partitionen]].
  
[[Datei:PIM_SEQ_Daten_Auflisten.png|416px]]
+
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.
  
Das Auslesen der Metadaten zu allen an einer vorgegebenen Partition registrierten Dokumenten erfolgt in den folgenden Schritten:
 
# Aufbau eines Sicherheitskontextes, der dem EFA-Provider die sichere Identifizierung und Authentifizierung des Teilnehmers ermöglicht (siehe Kommunikationsmuster [[cdaefa:EFA_Kommunikationsmuster#Aufbau_des_Sicherheitskontextes|Aufbau des Sicherheitskontextes]]).
 
# Ermitteln der ''[[cdaefa:EFA_Business_Informationsmodell#partitionID|partitionID]]'', mittels der die auszulesende Partition und deren übergeordnete Fallakte eindeutig identifizierbar sind. Sofern diese ID nicht bereits bekannt ist, muss sie über das Kommunikationsmuster ''[[cdaefa:EFA_Kommunikationsmuster#Auflisten_von_Partitionen|Auflisten von Partitionen]]'' ermittelt werden.
 
# Senden der partitionID an das Document Registry des EFA-Providers.
 
## Der EFA-Provider prüft, ob der Teilnehmer zum Zugriff auf die der Partition übergeordneten Akte berechtigt ist. Falls dies nicht der Fall sein sollte wird die Operation mit einer Fehlermeldung abgebrochen.
 
## Im Document Registry werden die mit der Partition verknüpften Dokumente ermittelt und deren Metadaten zu einer Antwortnachricht zusammengestellt.
 
## Die ausgehenden Beziehungen der gefundenen Dokumente zu anderen Dokumenten werden ermittelt und der Antwortnachricht hinzugefügt.
 
# Der EFA-Provider übermittelt dem Teilnehmer die Metadaten und Dokumentenbeziehungen der in der Partition registrierten Dokumente zurück.
 
  
 
=== Abrufen von Dokumenten ===
 
=== Abrufen von Dokumenten ===
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.08}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.08}</tt>
  
Der Abruf von Dokumenten aus einer Fallakte erfolgt über deren eindeutige Dokumenten-ID (''[[cdaefa:EFA_Business_Informationsmodell#documentID|documentID]]''), die beim Auflisten der Inhalte einer Partition als Teil der Dokumenten-Metadaten bereitgestellt wird.
+
[[Datei:PIM_SEQ_Daten_Abrufen.png|599px]]
  
[[Datei:PIM_SEQ_Daten_Abrufen.png|516px]]
+
Dieses Muster ist abhängig von [[cdaefa:EFA_Kommunikationsmuster#Auflisten_von_Dokumenten|Auflisten von Dokumenten]].
  
Das Abrufen von Dokumenten aus einer Fallakte erfolgt in den folgenden Schritten:
+
Um Dokumente einer Fallakte abzurufen:
# Aufbau eines Sicherheitskontextes, der dem EFA-Provider die sichere Identifizierung und Authentifizierung des Teilnehmers ermöglicht (siehe Kommunikationsmuster [[cdaefa:EFA_Kommunikationsmuster#Aufbau_des_Sicherheitskontextes|Aufbau des Sicherheitskontextes]]).
+
# Das EFA-Teilnehmersystem (TNS) wählt die Dokumente aus der Liste der Dokumente aus.
# [[cdaefa:EFA_Kommunikationsmuster#Auflisten_von_Partitionen|Auflisten der Partitionen]] einer Fallakte und [[cdaefa:EFA_Kommunikationsmuster#Auflisten_von_Dokumenten|Auflisten der darin enthaltenen Dokumente]].
+
# Das TNS ruft für jedes gewählte Dokumente die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#retrieveData|''retrieveData'']] des EFA-Document-Repository auf.
# Senden der ''documentIDs'' der abzurufenden Dokumente an das Document Repository des EFA-Providers, der die Partition verwaltet, in dem sich die angeforderten Dokumente befinden.
+
# Das EFA-Document-Repository
## Der EFA-Provider prüft, ob der Teilnehmer zum Zugriff auf die den Dokumenten übergeordnete Akte berechtigt ist. Falls dies nicht der Fall sein sollte wird die Operation mit einer Fehlermeldung abgebrochen.
+
## sucht das Datenobjekt entweder lokal
# Der EFA-Provider übermittelt dem Teilnehmer die angefragten Dokumente zurück.
+
## 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 ===
 
=== Registrierung einer neuen Einwilligung ===
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.09}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.09}</tt>
  
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.
+
[[Datei:PIM_SEQ_Einwilligung_Einstellen.png|718px]]
  
[[Datei:PIM_SEQ_Einwilligung_Einstellen.png|640px]]
+
Dieses Muster ist abhängig von [[cdaefa:EFA_Kommunikationsmuster#Auflisten_von_Partitionen|Auflisten von Partitionen]].
  
Das Registrieren einer neuen Einwilligung erfolgt in den folgenden Schritten:
+
Um eine neue Einwilligung zu registrieren:
# Aufbau eines Sicherheitskontextes, der dem EFA-Provider die sichere Identifizierung und Authentifizierung des Teilnehmers ermöglicht (siehe Kommunikationsmuster [[cdaefa:EFA_Kommunikationsmuster#Aufbau_des_Sicherheitskontextes|Aufbau des Sicherheitskontextes]]).
+
# Das EFA-Teilnehmersystem (TNS) wählt die Fallakte aus der [[cdaefa:EFA_Business_Informationsmodell#partitionList|Liste der Partitionen]] aus.
# Ermitteln der ''[[cdaefa:EFA_Business_Informationsmodell#ecrRef|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 ''[[cdaefa:EFA_Kommunikationsmuster#Auflisten_von_Partitionen|Auflisten von Partitionen]]'' ermittelt werden.
+
# Das TNS ruft die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#registerConsent|''registerConsent'']] des EFA-Ressourcen-Managers auf.
# 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-Ressourcen-Manager führt das Muster [[cdaefa:EFA_Kommunikationsmuster#Speichern_und_Registrieren_von_Dokumenten|Speichern und Registrieren von Dokumenten]] für die Einwilligungsdokumente aus.
## 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.
+
# Wenn das consentInfo eine Änderung des Zwecks anzeigt, dann konfiguriert der EFA-Ressourcen-Manager die Metadaten der Partitionen der Fallaktion bei der Document Registry.
## 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-Ressourcen-Manager registriert die neue EFA-Berechtigungsregel beim Policy Provider und
## Der EFA-Provider prüft die Angaben zur Einwilligung und stellt sicher, dass er diese in seinem Berechtigungsmanagement abbilden kann:
+
# gibt dem TNS eine Status-Meldung.
### 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|Einstellen von Dokumenten]]
 
# Der EFA-Provider meldet dem Teilnehmer die erfolgreiche Anpassung der Fallakte an die neue Einwilligung.
 
  
 
=== Anfordern eines Berechtigungstoken ===
 
=== Anfordern eines Berechtigungstoken ===
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.10}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.10}</tt>
  
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.
+
[[Datei:PIM_SEQ_Token_ausstellen.png|438px]]
 
 
[[Datei:PIM_SEQ_Token_ausstellen.png|560px]]
 
  
Die Anforderung und Bereitstellung eines Berechtigungstoken erfolgt in den folgenden Schritten:
+
Dieses Muster ist abhängig von [[cdaefa:EFA_Kommunikationsmuster#Auflisten_von_Partitionen|Auflisten von Partitionen]].
# Aufbau eines Sicherheitskontextes, der dem EFA-Provider die sichere Identifizierung und Authentifizierung des Teilnehmers ermöglicht (siehe Kommunikationsmuster [[cdaefa:EFA_Kommunikationsmuster#Aufbau_des_Sicherheitskontextes|Aufbau des Sicherheitskontextes]]).
 
# Ermitteln der ''[[cdaefa:EFA_Business_Informationsmodell#ecrRef|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 ''[[cdaefa:EFA_Kommunikationsmuster#Auflisten_von_Partitionen|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 ([[cdaefa:EFA_Security_Informationsmodell#accessToken|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.
+
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 ===
 
=== Einlösen eines Berechtigungstoken ===
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.11}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.11}</tt>
  
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.
+
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_Token_einloesen.png|560px]]
+
[[Datei:PIM_SEQ_Fallakten_konsolidieren.png|652px]]
  
Das Einlösen eines Berechtigungstoken erfolgt in den folgenden Schritten:
+
Um eine Fallakte zu konsolidieren:
# Aufbau eines Sicherheitskontextes, der dem EFA-Provider die sichere Identifizierung und Authentifizierung des als Teilnehmer zu registrierenden Leistungserbringers ermöglicht (siehe Kommunikationsmuster [[cdaefa:EFA_Kommunikationsmuster#Aufbau_des_Sicherheitskontextes|Aufbau des Sicherheitskontextes]]).
+
# Wenn der eigene EFA-Provider keine Partitionen der Fallakte führt:
# Senden des Berechtigungstoken ([[cdaefa:EFA_Security_Informationsmodell#accessToken|accessToken-Object]]) an den Resource Manager des EFA-Providers.  
+
## 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.
## Der EFA-Provider extrahiert aus dem Berechtigungstoken die ''[[cdaefa:EFA_Business_Informationsmodell#ecrRef|ecrRef]]'', mittels der die Fallakte eindeutig identifizierbar ist, für die ein Berechtigungstoken eingelöst werden soll.
+
## 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.
## 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 ([[cdaefa:EFA_Security_Informationsmodell#subjectAccessPolicy|subjectAccessPolicy-Objekt]]) zu.
 
  
Die Berechtigungspolicy kann von dem Teilnehmer über das [[cdaefa:Gruppierung_von_Anwendungs-_und_Sicherheitsdiensten#Client_Policy_Push|Client-Policy-Push]] Verfahren unmittelbar zum Zugriff auf die Akte genutzt werden.
+
=== Speichern und Registrieren von Dokumenten ===
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eouns.01.12}</tt>
  
=== Querverweise und Referenzen ===
+
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.
 +
 +
 +
 +
 +
----
 +
 +
 +
{{NoteBox|'''Referenzen und Querverweise'''
 
* [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]
 
* [[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.