EFA Anwendungsdienste (logische Spezifikation)

Aus Hl7wiki
(Teildokument von CDA für die elektronische Fallakte)
Wechseln zu: Navigation, Suche
(→‎registerConsent: Vorbedingung aus Kommunikationsmuster "Registrieren einer Einwilligung" in die Beschreibung der Operation verschoben.)
(→‎listPartitionContent)
 
(29 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
−
{{Infobox Dokument
+
{{DocumentPart
−
|Title    = EFA Anwendungsdienste (logische Spezifikation)
 
−
|Short    = EFA Anwendungsdienste (logische Spezifikation)
 
−
|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 47: Zeile 32:
 
|[[cdaefa:EFA_Kommunikationsmuster#Registrierung_einer_neuen_Einwilligung|Registrierung einer neuen Einwilligung]]
 
|[[cdaefa:EFA_Kommunikationsmuster#Registrierung_einer_neuen_Einwilligung|Registrierung einer neuen Einwilligung]]
 
|registerConsent
 
|registerConsent
 +
|EFA Ressource Manager
 +
|-
 +
|[[cdaefa:EFA_Kommunikationsmuster#Verteilen_einer_Einwilligung_im_EFA-Verbund|Verteilen einer Einwilligung im EFA-Verbund]]
 +
|notifyOfConsent
 
|EFA Ressource Manager
 
|EFA Ressource Manager
 
|-
 
|-
Zeile 53: Zeile 42:
 
|EFA Ressource Manager
 
|EFA Ressource Manager
 
|-
 
|-
−
|[[cdaefa:EFA_Kommunikationsmuster#Einl.C3.B6sen_eines_Berechtigungstoken|Einlösen eines Berechtigungstoken]]
+
| rowspan="3"| [[cdaefa:EFA_Kommunikationsmuster#Einl.C3.B6sen_eines_Berechtigungstoken|Einlösen eines Berechtigungstoken]]
 
|redeemAccessToken
 
|redeemAccessToken
 +
|EFA Ressource Manager
 +
|-
 +
|listRecordLocations
 +
|EFA Ressource Manager
 +
|-
 +
|registerRecordLocation
 
|EFA Ressource Manager
 
|EFA Ressource Manager
 
|-
 
|-
Zeile 71: Zeile 66:
 
|retrieveData
 
|retrieveData
 
|EFA Document Repository
 
|EFA Document Repository
 +
|-
 +
|[[cdaefa:EFA_Kommunikationsmuster#Invalidieren_eines_Dokuments|Invalidieren eines Dokuments]]
 +
|invalidateData
 +
|EFA Document Registry
 
|}
 
|}
  
 
Das Zusammenspiel von Diensten und Operationen ist in der folgenden Darstellung noch einmal im Überblick dargestellt.
 
Das Zusammenspiel von Diensten und Operationen ist in der folgenden Darstellung noch einmal im Überblick dargestellt.
  
−
[[Datei:EFA_AppArch_Transaktionen.png|640px]]
+
[[Datei:cdaefa_SFM_Operationen.png|639px]]
  
 
Die gestrichelt dargestellten internen Operationsaufrufe vom Ressource Manager zu den anderen Diensten sind optional in dem Sinne als dass die geforderte Funktionalität der Speicherung und Registrierung von Einwilligungen und Einwilligungsdokumenten auch über interne Mechanismen des EFA-Providers erfolgen kann.
 
Die gestrichelt dargestellten internen Operationsaufrufe vom Ressource Manager zu den anderen Diensten sind optional in dem Sinne als dass die geforderte Funktionalität der Speicherung und Registrierung von Einwilligungen und Einwilligungsdokumenten auch über interne Mechanismen des EFA-Providers erfolgen kann.
 +
 +
Für alle Operationen gilt:
 +
* Der vom Teilnehmersystem übermittelte Sicherheitskontext muss gültig, vollständig, authentisch und von einer vertrauenswürdigen Stelle für den Aufrufer ausgestellt worden sein.
 +
* Der EFA-Dienst muss den Aufrufer anhand des Eingabeparameters [[cdaefa:EFA_Security_Informationsmodell#context|context]] authentifizieren können.
 +
* Die beteiligten Systeme schreiben einen [[cdaefa:EFA_Sicherheitsanforderungen#Nicht-Abstreitbarkeit.2C_Dokumentation_und_Audit-Trail|Audit-Trail]].
  
 
=== Operationen des EFA Ressource Manager ===
 
=== Operationen des EFA Ressource Manager ===
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Enndn.01.01}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Enndn.01.01}</tt>
  
−
In den folgenden Abschnitten werden die Operationen des EFA Ressource Managers plattform-unabhängig als ''Service Functional Model'' spezifiziert. Die folgenden Vorbedingungen müssen für alle Aufrufe an den Ressource Manager erfüllt sein und werden:
+
Der EFA Ressource Manager muss die in diesem Abschnitt enthaltenen Operationen implementieren.
−
* Das aufrufende Teilnehmersystem kann den EFA Ressource Manager lokalisieren und sicher authentifiziern. 
 
−
* Der vom Teilnehmersystem übermittelte Sicherheitskontext ist gültig, vollständig, authentisch und wurde von einer vertrauenswürdigen Stelle für Aufrufer ausgestellt.
 
−
* Der Ressource Manager kann den Aufrufer anhand der im [[cdaefa:EFA_Security_Informationsmodell#context|context]] übermittelten Daten sicher identifizieren und authentifizieren.
 
−
* Der Ressource Manager ist technisch in der Lage, einen Audit Trail Eintrag zu schreiben
 
−
* Der Ressource Manager verfügt über eine Möglichkeit, mit dem Operationsaufruf ggf. übergebene Daten im Document Repository abzulegen und im Document Registry zu registrieren.
 
−
 
 
  
 
==== ''createECR'' ====
 
==== ''createECR'' ====
Zeile 95: Zeile 93:
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
!Operation
 
!Operation
−
! colspan="2"|createECR
+
|colspan="2"|createECR
 +
|-
 +
!Funktionalität
 +
| colspan="2"|Diese Operation erzeugt eine [[cdaefa:EFA_Business_Informationsmodell#Fallakte|Fallakte]]. Wenn die Fallakte für den Patienten und für den Zweck bereits besteht, werden die bestehende und die neue Fallakte fusioniert. Die Einwilligung der bestehenden Fallakte wird invalidiert und mit der neuen Einwilligung ersetzt.
 
|-
 
|-
−
|Funktionalität
+
!Aufrufer
−
| colspan="2"|Mit der Operation ''createECR'' wird eine neue Fallakte für einen Patienten angelegt. Sofern bereits eine Fallakte zu dem benannten Zweck existiert, wird keine neue Akte angelegt, sondern stattdessen die bestehende Akte um eine Partition erweitert. In diesem Fall wird die bestehende Einwilligung invalidiert und durch die übergebene Einwilligung ersetzt.
+
| colspan="2"|EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne
 
|-
 
|-
−
| rowspan="4"|Eingabe
+
!rowspan="5"|Eingabe
 
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
 
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
−
|Die Anlage einer Fallakte muss innerhalb eines Sicherheitskontextes erfolgen, in dem der die EFA-Neuanlage initierende Arzt identifizierbar und in seiner Authentizität überprüfbar ist. Mit dem Parameter ''context'' wird der vorab über die Operation ''openContext'' des EFA Kontext Managers erstellte Sicherheitskontext so an den EFA-Provider übergeben, dass dieser den Kontext provider-seitig zur Prüfung der Berechtigungen des Aufrufers innerhalb des Aufrufkontextes rekonstruieren kann.
+
|Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager [[cdaefa:EFA_Context_Manager_SFM#Operation:_OpenContext|''openContext'']].
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#patientID|patientID]]
 +
|Die ID des Patienten, für den die Fallakte angelegt werden soll.
 
|-
 
|-
−
|[[cdaefa:EFA_Business_Informationsmodell#ecrInfo|ecrInfo]]
+
|[[cdaefa:EFA_Business_Informationsmodell#purpose|purpose]]
−
|Identifizierende und beschreibende Daten zur anzulegenden Fallakte.
+
|Der Zweck für den die Fallakte angelegt werden soll. Er muss mit dem Zweck übereinstimmen, der im Eingabe-Parameter consentInfo angegeben ist.  
−
;[[cdaefa:EFA_Business_Informationsmodell#patientID|patientID]]
 
−
:Eindeutige Identifizierung des Patienten für den eine Fallakte angelegt werden soll. Hierzu muss eine ID verwendet werden, die bereits beim EFA-Provider für den Patienten registriert ist. Ggf. muss eine Abfrage an einen MPI dieser Operation vorgeschaltet werden, um diese ID anhand demografischer Daten des Patienten zu ermitteln (siehe IHE Cookbook für die Abfrage einer XAD-PID).
 
−
;[[cdaefa:EFA_Business_Informationsmodell#purpose|purpose]]
 
−
:Festlegung des Zwecks zu dem die Fallakte angelegt werden soll. Bei einem EFA-Provider kann für jeden Patienten  zu einem Zweck nur eine Fallakte existieren.
 
−
;ecrStatus
 
−
:muss bei der Neuanlage einer EFA immer "offen" sein.  
 
 
|-
 
|-
 
|[[cdaefa:EFA_Business_Informationsmodell#consentInfo|consentInfo]]
 
|[[cdaefa:EFA_Business_Informationsmodell#consentInfo|consentInfo]]
−
|Informationen zu der vom Patienten gegebenen Einwilligung einschließlich der Gültigkeitsdauer der Akte und der Angabe der als EFA-Teilnehmer zum Zugriff auf die Akte zu berechtigenden Personen und Organisationen.
+
|Das strukturierte Dokument, das die Einwilligung des Patienten für die Anlage der Fallakte abbildet.
 
|-
 
|-
 
|[[cdaefa:EFA_Business_Informationsmodell#consentDoc|consentDoc]] (optional)
 
|[[cdaefa:EFA_Business_Informationsmodell#consentDoc|consentDoc]] (optional)
 
|Sofern die Einwilligungserklärung des Patienten als (gescanntes) elektronisches Dokument vorliegt, kann diese bei der Anlage der Akte direkt in die Akte eingestellt werden.
 
|Sofern die Einwilligungserklärung des Patienten als (gescanntes) elektronisches Dokument vorliegt, kann diese bei der Anlage der Akte direkt in die Akte eingestellt werden.
 
|-
 
|-
−
| rowspan="2"|Rückgabe
+
!rowspan="2"|Rückgabe
 
|statusInfo
 
|statusInfo
 
|Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
 
|Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
Zeile 126: Zeile 124:
 
|Eindeutige ID der initial zu der neuen Akte angelegten Partition. Mit Hilfe dieser ID kann der EFA-Teilnehmer weitere Operationen, wie z.B. das Einstellen von Dokumenten in die Fallakte, durchführen.  
 
|Eindeutige ID der initial zu der neuen Akte angelegten Partition. Mit Hilfe dieser ID kann der EFA-Teilnehmer weitere Operationen, wie z.B. das Einstellen von Dokumenten in die Fallakte, durchführen.  
 
|-
 
|-
−
|Vorbedingungen
+
!Vorbedingungen
 
| colspan="2"|
 
| colspan="2"|
−
* Der Aufrufer ist berechtigt, beim angesprochenen EFA-Provider neue Fallakten anzulegen.
 
−
* Die übergebene Patienten-ID ist gültig und mit einer natürlichen Person verknüpft.
 
−
* Die übergebene Zweckbenennung ist gültig und als EFA-Zweck gemäß der Regularien des Providers zulässig.
 
 
* Das übergebene [[cdaefa:EFA_Business_Informationsmodell#consentInfo|consentInfo]] Dokument ist konsistent:
 
* Das übergebene [[cdaefa:EFA_Business_Informationsmodell#consentInfo|consentInfo]] Dokument ist konsistent:
−
** Die Angaben zum betroffenen Patient stimmen mit den verfügbaren Informationen zum Besitzer der übergebenen Patienten-ID überein.
+
** Die Angaben zum betroffenen Patient MÜSSEN mit den verfügbaren Informationen zum Besitzer der übergebenen Patienten-ID übereinstimmen.
−
** Sofern ein Zweck benannt ist, stimmt dieser mit dem bei der EFA-Anlage benannten Zweck überein.
+
** Es MUSS ein Zweck benannt sein, der mit dem bei der EFA-Anlage benannten Zweck überein stimmen MUSS.
−
** Es ist ein Gültigkeitsdatum benannt und dieses ist gemäß der Vorgaben des EFA-Providers zulässig.
+
** Es ist ein Gültigkeitsdatum benannt.
−
** Die EFA Teilnehmer sind benannt. Die Angaben zur Identität der Teilnehmer ermöglichen eine sichere Identifizierung der Teilnehmer.
+
** Zumindest ein autorisierter EFA Teilnehmer MUSS benannt und anhand der angegebenen Daten eindeutig identifizierbar sein. Dies KANN die Einrichtung/Person sein, die die Fallakte anlegt.
−
** Sofern im ''consentInfo'' ein Fallaktenmanager identifiziert ist, stimmt dieser mit der im EFA-Netzwerk für diese Rolle benannten Person überein (die Festlegung des Fallaktenmanagers erfolgt nicht durch den Patienten und muss daher nicht zwingend in den kodierten Informationen zur Einwilligung enthalten sein).
+
** Sofern im ''consentInfo'' ein Fallaktenmanager identifiziert ist, MUSS dieser mit der im EFA-Netzwerk für diese Rolle benannten Person übereinstimmen (die Festlegung des Fallaktenmanagers erfolgt nicht durch den Patienten und muss daher nicht zwingend in den kodierten Informationen zur Einwilligung enthalten sein).  
 
|-
 
|-
−
|Ablaufsequenz (logisch)
+
!Ablauf
 
| colspan="2"|
 
| colspan="2"|
−
Der Ressource Manager ...
+
# Übersetze das consentInfo-Dokument in eine EFA-Berechtigungsregel.
−
# ... verifiziert, dass die Vorbedingungen zur Ausführung der Operation erfüllt sind.
+
# Registriere die EFA-Berechtigungsregel beim Policy Provider.
−
# ... erzeugt aus Patientenidentifikation und Zweckbenennung ein [[cdaefa:EFA_Business_Informationsmodell#ecrRef|ecrRef]]-Objekt für die neu anzulegende Fallakte
+
# Erzeuge eine Partition. Verknüpfe sie mit ecrRef.
−
# ... prüft, ob ein identisches ecrRef-Objekt bereits existiert und mit Partitionen und Berechtigungen verknüpft ist. Sollte dies der Fall sein, prüft der Ressource Manager, ob die bestehende und die neu übergebene Einwilligung eine Überführung der bestehenden Akte in die neue anzulegende Akte erlauben. Ist dies nicht der Fall, wird die Operation mit einer Fehlermeldung abgebrochen.
+
# Konfiguriere die Metadaten der Partition (partitionInfo).
−
# ... legt eine neue Partition an und verknüpft diese mit dem ecrRef-Objekt.
+
# Verknüpfe consentInfo und consentDoc mit der Partition (partitionID).
−
# ... bildet den Inhalt der Einwilligung auf ein Berechtigungsregelwerk ab und verknüpft dieses mit dem ecrRef-Objekt.
+
# Wenn eine Fallakte für patientID und purpose (ecrRef) existiert:
−
# ... stellt die Angaben zur Einwilligung und ein ggf. übergebenes Einwilligungsformular als Dokumente in die neu erzeugte Partition ein.
+
## Beachte die [[cdaefa:EFA_Fehlermeldungen_und_Warnungen|Fehlersituation]] Prohibited Merge.
−
# bei Überführung einer bestehenden Akte: ... lokalisiert die Partitionen der zu überführenden Akte und verknüpft diese mit dem neuen ecrRef-Objekt.  
+
## Ersetze (docRelationship) das bestehende consentInfo und consentDoc mit dem neuen consentInfo und consentDoc.
−
# bei Überführung einer bestehenden Akte: ... erzeugt eine "Ersetzt"-Verknüpfung zwischen der neuen Einwilligung und der für die bestehende Akte zuletzt gültigen Einwilligung.
+
# Speichre und registriere consentInfo und consentDoc bei Document Repository und Document Registry.
−
# ... schreibt einen Audit Trail Eintrag über die erfolgreiche Durchführung der Operation
+
# Gib die Kennung der neuen Partition (partitionID) und den Status dem Aufrufer.
−
# ... liefert einen Statuscode zur erfolgreichen Ausführung der Operation sowie eine Referenz auf die neu angelegte Partition an das aufrufende System zurück
 
 
|-
 
|-
−
|Fehler und Warnungen
+
!Fehler und Warnungen
 
| colspan="2"|
 
| colspan="2"|
−
Über die in [[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]] definierten Ausnahmesituationen hinaus, sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:
+
Folgende Fehler müssen erkannt und rückgemeldet werden:
−
* Der Aufrufer hat keine für die Anlage von Fallakten ausreichende vertragliche Vereinbarung mit dem EFA-Provider.
+
* [[cdaefa:EFA Fehlermeldungen und Warnungen|Gemeinsame Fehlermeldungen und Warnungen]]
−
* Eine neue Akte kann nicht angelegt werden, da bereits eine Akte zum angegebenen Patienten und Zweck besteht.
+
* Der angegebene Fallaktenmanager ist in dem EFA-Netzwerk nicht autorisiert, diese Rolle auszufüllen (Fehler).
−
* Die angegeben Patienten-ID kann nicht aufgelöst werden.
 
−
* Eine oder mehrere der in der consentInfo angegebenen Identitäten zu berechtigender Teilnehmer kann nicht aufgelöst werden.
 
−
* Die übergebene consentInfo ist nicht konsistent zu anderen Angaben.
 
−
Darüber hinaus sind die folgenden Warnungen definiert:
 
−
* Eine bestehende Fallakte wurde in die neu angelegte Akte überführt. Der Aufrufer sollte ggf. verifizieren, dass die damit übernommenen Dokumente noch dem Zweck der Akte dienen. Veraltete Dokumente sollten invalidiert werden.
 
 
|}
 
|}
  
Zeile 169: Zeile 158:
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
!Operation
 
!Operation
−
! colspan="2"|createPartition
+
| colspan="2"|createPartition
 +
|-
 +
!Funktionalität
 +
| colspan="2"|Diese Operation erzeugt eine Partition für eine bestehende Fallakte.
 
|-
 
|-
−
|Funktionalität
+
!Aufrufer
−
| colspan="2"|Anlegen einer neuen Partition zu einer bestehenden Fallakte.
+
| colspan="2"|EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne
 
|-
 
|-
−
| rowspan="4"|Eingabe
+
! rowspan="4"|Eingabe
 
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
 
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
−
|Die Anlage einer Partition muss innerhalb eines Sicherheitskontextes erfolgen, in dem der die Anlage der Partition initierende Arzt identifizierbar und in seiner Authentizität überprüfbar ist. Mit dem Parameter context wird der vorab über die Operation ''openContext'' des ''EFA Kontext Managers'' erstellte Sicherheitskontext so an den EFA-Provider übergeben, dass dieser den Kontext provider-seitig zur Prüfung der Berechtigungen des Aufrufers innerhalb des Aufrufkontextes rekonstruieren kann.
+
|Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager [[cdaefa:EFA_Context_Manager_SFM#Operation:_OpenContext|''openContext'']].
 
|-
 
|-
 
|[[cdaefa:EFA_Business_Informationsmodell#ecrRef|ecrRef]]
 
|[[cdaefa:EFA_Business_Informationsmodell#ecrRef|ecrRef]]
Zeile 187: Zeile 179:
 
|Bei der Anlage einer Partition können initial in diese Partition einzustellende Dokumente mit übergeben werden.
 
|Bei der Anlage einer Partition können initial in diese Partition einzustellende Dokumente mit übergeben werden.
 
|-
 
|-
−
| rowspan="2"|Rückgabe
+
! rowspan="2"|Rückgabe
 
|statusInfo
 
|statusInfo
 
|Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
 
|Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
Zeile 194: Zeile 186:
 
|Eindeutige ID der neu angelegten Partition. Mit Hilfe dieser ID kann der EFA-Teilnehmer weitere Operationen, wie z.B. das Einstellen von Dokumenten in diese Partition, durchführen.
 
|Eindeutige ID der neu angelegten Partition. Mit Hilfe dieser ID kann der EFA-Teilnehmer weitere Operationen, wie z.B. das Einstellen von Dokumenten in diese Partition, durchführen.
 
|-
 
|-
−
|Vorbedingungen
+
!Vorbedingungen
 
| colspan="2"|
 
| colspan="2"|
−
* Der Aufrufer ist berechtigt, beim angesprochenen EFA-Provider Partitionen zu bestehenden Fallakten anzulegen.
 
−
* Die übergebene [[cdaefa:EFA_Business_Informationsmodell#ecrRef|EFA-Referenz]] ist valide und der Aufrufer hat  die erforderlichen Zugriffsrechte auf dieser Akte, um die angeforderte Aktion durchzuführen.
 
 
* Die übergebenen Metadaten der anzulegenden Partition sind vollständig und valide.
 
* Die übergebenen Metadaten der anzulegenden Partition sind vollständig und valide.
−
* Die Konfiguration der angesprochenen Akte erlaubt das Einstellen der ggf. übergebenen Dokumente.
 
 
|-
 
|-
−
|Ablaufsequenz (logisch)
+
!Ablauf
 
| colspan="2"|
 
| colspan="2"|
−
Der Ressource Manager ...
+
# Erzeuge eine Partition. Verknüpfe sie mit dem Eingabeparametern ecrRef und partitionInfo.
−
# ... verifiziert, dass die Vorbedingungen zur Ausführung der Operation erfüllt sind.
+
# Verknüpfe initialDoc mit der Partition (partitionID).
−
# ... legt eine neue Partition an und verknüpft diese mit dem übergebenen ecrRef-Objekt.
+
# Speichre und registriere initialDoc bei Document Repository und Document Registry.
−
# ... stellt die ggf. übergebenen Dokumente in die neu erzeugte Partition ein.
+
# Gib die Kennung der neuen Partition (partitionID) und den Status dem Aufrufer.
−
# ... schreibt einen Audit Trail Eintrag über die erfolgreiche Durchführung der Operation
 
−
# ... liefert einen Statuscode zur erfolgreichen Ausführung der Operation sowie eine Referenz auf die neu angelegte Partition an das aufrufende System zurück
 
 
|-
 
|-
−
|Fehler und Warnungen
+
!Fehler und Warnungen
 
| colspan="2"|
 
| colspan="2"|
−
Über die in [[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]] definierten Ausnahmesituationen hinaus sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:
+
Folgende Fehler müssen erkannt und rückgemeldet werden:
−
* Der Aufrufer hat keine für die Anlage von Partitionen ausreichende vertragliche Vereinbarung mit dem EFA-Provider.
+
* [[cdaefa:EFA Fehlermeldungen und Warnungen|Gemeinsame Fehlermeldungen und Warnungen]]
−
* Die angegeben Fallakten-Referenz kann nicht aufgelöst werden bzw. der Aufrufer hat keine (ausreichenden) Berechtigungen, die angeforderte Operation auf dieser Akte auszuführen.
+
* Die übergebene partitionInfo ist nicht vollständig oder nicht konsistent zu anderen Angaben. (Fehler)
−
* Die übergebene partitionInfo ist nicht vollständig oder nicht konsistent zu anderen Angaben.
 
−
Darüber hinaus sind die folgenden Warnungen definiert:
 
−
* Eines oder mehrere der übergebenen Dokumente konnte nicht in der Partition abgelegt werden.
 
 
|}
 
|}
−
 
  
 
==== ''closeECR'' ====
 
==== ''closeECR'' ====
Zeile 226: Zeile 209:
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
!Operation
 
!Operation
−
! colspan="2"|closeECR
+
| colspan="2"|closeECR
 
|-
 
|-
−
|Funktionalität
+
!Funktionalität
−
| colspan="2"|Schließen einer bestehenden Fallakte. Die Fallakte geht damit in den "Grace"-Status über.
+
| colspan="2"|Schließt eine Fallakte. Sie wechselt in den Status "Gesperrt" und ist nur für Fallaktenmanager verfügbar.
 
|-
 
|-
−
| rowspan="4"|Eingabe
+
!Aufrufer
 +
| colspan="2"|EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne
 +
|-
 +
! rowspan="4"|Eingabe
 
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
 
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
−
|Das Schließen einer Fallakte muss innerhalb eines Sicherheitskontextes erfolgen, in dem der diese Operation initierende Arzt identifizierbar und in seiner Authentizität überprüfbar ist. Mit dem Parameter context wird der vorab über die Operation ''openContext'' des ''EFA Kontext Managers'' erstellte Sicherheitskontext so an den EFA-Provider übergeben, dass dieser den Kontext provider-seitig zur Prüfung der Berechtigungen des Aufrufers innerhalb des Aufrufkontextes rekonstruieren kann.
+
|Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager [[cdaefa:EFA_Context_Manager_SFM#Operation:_OpenContext|''openContext'']].
 
|-
 
|-
 
|[[cdaefa:EFA_Business_Informationsmodell#ecrRef|ecrRef]]
 
|[[cdaefa:EFA_Business_Informationsmodell#ecrRef|ecrRef]]
Zeile 244: Zeile 230:
 
|Sofern die Schließung der Akte auf eine Änderung der Einwilligung zurückzuführen ist, kann eine elektronische Version des entsprechenden Dokuments mit übergeben werden. Hierdurch ist auch nach dem Schließen der Akte der Grund für diese Operation noch nachvollziehbar.
 
|Sofern die Schließung der Akte auf eine Änderung der Einwilligung zurückzuführen ist, kann eine elektronische Version des entsprechenden Dokuments mit übergeben werden. Hierdurch ist auch nach dem Schließen der Akte der Grund für diese Operation noch nachvollziehbar.
 
|-
 
|-
−
|Rückgabe
+
!Rückgabe
 
|statusInfo
 
|statusInfo
 
|Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
 
|Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
 
|-
 
|-
−
|Vorbedingungen
+
!Vorbedingungen
 
| colspan="2"|
 
| colspan="2"|
−
* Die übergebene [[cdaefa:EFA_Business_Informationsmodell#ecrRef|EFA-Referenz]] ist valide und der Aufrufer hat  die erforderlichen Zugriffsrechte auf dieser Akte, um die angeforderte Aktion durchzuführen.
 
−
* Das übergebene [[cdaefa:EFA_Business_Informationsmodell#consentInfo|consentInfo]] Dokument ist konsistent:
 
−
** Die Angaben zum benannten Patient stimmen mit den verfügbaren Informationen zum Betroffenen der Akte überein.
 
 
|-
 
|-
−
|Ablaufsequenz
+
!Ablauf
 
| colspan="2"|
 
| colspan="2"|
−
Der Ressource Manager ...
+
# Ändere den Status der Fallakte (ecrStatus) auf "[[cdaefa:EFA_Business_Lebenszyklus#Lebenszyklus_einer_Fallakte|Gesperrt]]".
−
# ... verifiziert, dass die Vorbedingungen zur Ausführung der Operation erfüllt sind.
+
# Übersetze das consentInfo-Dokument in eine EFA-Berechtigungsregel.
−
# ... ändert die auf der Akte definierten Zugriffsrechte sowie den internen Status der Akte entsprechend der Vorgaben in der Rücknahme der Einwilligung und unter Berücksichtigung des definierten EFA-Lebenszyklus
+
# Registriere die EFA-Berechtigungsregel beim Policy Provider.
−
# ... stellt die Angaben zur Einwilligungsrücknahme und ein ggf. übergebenes Einwilligungsformular als Dokumente in eine Partition der Akte ein.  
+
# Verknüpfe consentInfo und consentDoc mit einer Partition (partitionID) der Fallakte.
−
# ... schreibt einen Audit Trail Eintrag über die erfolgreiche Durchführung der Operation
+
# Ersetze (docRelationship) das bestehende consentInfo und consentDoc mit dem neuen consentInfo und consentDoc.
−
# ... liefert einen Statuscode zur erfolgreichen Ausführung der Operation an das aufrufende System zurück
+
# Speichre und registriere consentInfo und consentDoc bei Document Repository und Document Registry.
 +
# Gib statusInfo dem Aufrufer.
 
|-
 
|-
−
|Fehler und Warnungen
+
!Fehler und Warnungen
 
| colspan="2"|
 
| colspan="2"|
−
Über die in [[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]] definierten Ausnahmesituationen hinaus sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:
+
Folgende Fehler müssen erkannt und rückgemeldet werden:
−
* Die angegeben Fallakten-Referenz kann nicht aufgelöst werden bzw. der Aufrufer hat keine (ausreichenden) Berechtigungen, die angeforderte Operation auf dieser Akte auszuführen.
+
* [[cdaefa:EFA Fehlermeldungen und Warnungen|Gemeinsame Fehlermeldungen und Warnungen]]
−
* Die übergebene consentInfo ist nicht vollständig oder nicht konsistent zu anderen Angaben.
 
−
* Eines oder mehrere der übergebenen Dokumente konnten nicht in der Akte abgelegt werden.
 
 
|}
 
|}
  
Zeile 276: Zeile 258:
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
!Operation
 
!Operation
−
! colspan="2"|listPartitions
+
| colspan="2"|listPartitions
 
|-
 
|-
−
|Funktionalität
+
!Funktionalität
−
| colspan="2"|Mit der Operation ''listPartitions'' werden Informationen zu allen Partitionen (und deren übergeordneten Fallakte) aufgelistet, zu denen der Aufrufer über die vom betroffenen Patienten gegebenen Einwilligungen zugangsberechtigt ist.
+
| colspan="2"|Diese Operation listet die Informationen aller Partitionen (und deren übergeordneten Fallakte) auf, zu denen der Aufrufer über die vom betroffenen Patienten gegebenen Einwilligungen zugangsberechtigt ist.
 
|-
 
|-
−
| rowspan="3"|Eingabe
+
!Aufrufer
 +
| colspan="2"|
 +
*EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne,
 +
*Ressource Manager einer benachbarten EFA-Provider-Domäne
 +
|-
 +
! rowspan="3"|Eingabe
 
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
 
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
−
|Die Suche nach Fallakten und Partitionen muss innerhalb eines Sicherheitskontextes erfolgen, in dem der die Anfrage initierende Arzt identifizierbar und in seiner Authentizität überprüfbar ist. Mit dem Parameter ''context'' wird der vorab über die Operation ''openContext'' des EFA Kontext Managers erstellte Sicherheitskontext so an den EFA-Provider übergeben, dass dieser den Kontext provider-seitig zur Prüfung der Berechtigungen des Aufrufers innerhalb des Aufrufkontextes rekonstruieren kann.
+
|Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager [[cdaefa:EFA_Context_Manager_SFM#Operation:_OpenContext|''openContext'']].
 
|-
 
|-
 
|[[cdaefa:EFA_Business_Informationsmodell#patientID|patientID]]
 
|[[cdaefa:EFA_Business_Informationsmodell#patientID|patientID]]
−
|Eindeutige Identifizierung des Patienten nach dessen Fallakten und Partitionen gesucht werden soll. Hierzu muss eine ID angegeben werden, die bereits beim EFA-Provider für den Patienten registriert ist und die bei der Anlage der EFA verwendet wurde. Ggf. muss eine Abfrage an einen MPI dieser Operation vorgeschaltet werden, um diese ID anhand demografischer Daten des Patienten zu ermitteln (siehe IHE Cookbook für die Abfrage einer XAD-PID).
+
|Die ID des betroffenen Patienten.
 
|-
 
|-
−
|[[cdaefa:EFA_Business_Informationsmodell#purpose|purpose]] (optional)
+
|[[cdaefa:EFA_Business_Informationsmodell#purpose|purpose]]
 
|Einschränkung der Suche auf Akten und Partitionen, die zu einem bestimmten Zweck angelegt wurden.
 
|Einschränkung der Suche auf Akten und Partitionen, die zu einem bestimmten Zweck angelegt wurden.
 
|-
 
|-
−
| rowspan="2"|Rückgabe
+
! rowspan="2"|Rückgabe
 
|statusInfo
 
|statusInfo
 
|Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
 
|Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
Zeile 298: Zeile 285:
 
|Liste von nach übergeordneten Fallakten strukturierten Partitionen des Patienten, die im Ergebnis der Suchanfrage gefunden wurden.
 
|Liste von nach übergeordneten Fallakten strukturierten Partitionen des Patienten, die im Ergebnis der Suchanfrage gefunden wurden.
 
|-
 
|-
−
|Vorbedingungen
+
!Vorbedingungen
 
| colspan="2"|
 
| colspan="2"|
−
* Die übergebene Patienten-ID ist gültig und mit einer natürlichen Person verknüpft.
 
−
* Eine ggf. übergebene Zweckbenennung ist gültig und als EFA-Zweck gemäß der Regularien des Providers zulässig.
 
 
|-
 
|-
−
|Ablaufsequenz (logisch)
+
!Ablauf
 
| colspan="2"|
 
| colspan="2"|
−
Der Ressource Manager ...
+
# Identifiziere alle Partitionen,
−
# ... verifiziert, dass die Vorbedingungen zur Ausführung der Operation erfüllt sind.
+
## die mit den Eingabeparametern patientID und purpose verknüpft sind und
−
# ... lokalisiert alle Partitionen, die mit dem angegebenen Patienten verknüpft sind und identifiziert die jeweils übergeordneten Fallakten.
+
## für welche der Aufrufer (context) zugriffsberechtigt ist.
−
# ... prüft für jede der gefundenen Fallakten, ob der Aufrufer ein berechtigter Teilnehmer der Akte ist.  
+
# Erstelle das partitionList-Objekt für diese Partitionen.
−
# ... stellt die Metadaten der Partitionen dieser Akten zur Ergebnisstruktur dieser Operation zusammen.
+
# Gib partitionList und statusInfo dem Aufrufer.
−
# ... schreibt einen Audit Trail Eintrag über die erfolgreiche Durchführung der Operation
 
−
# ... liefert einen Statuscode zur erfolgreichen Ausführung der Operation sowie die Metadaten der gefundenen Partitionen an das aufrufende System zurück
 
 
|-
 
|-
−
|Fehler und Warnungen
+
!Fehler und Warnungen
 
| colspan="2"|
 
| colspan="2"|
−
Über die in [[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]] definierten Ausnahmesituationen hinaus sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:
+
Folgende Fehler müssen erkannt und rückgemeldet werden:
−
* Die angegeben Patienten-ID kann nicht aufgelöst werden.
+
* [[cdaefa:EFA Fehlermeldungen und Warnungen|Gemeinsame Fehlermeldungen und Warnungen]]
 
|}
 
|}
  
Zeile 323: Zeile 306:
  
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
−
!Operation
 
−
! colspan="2"|registerConsent
 
 
|-
 
|-
−
|Funktionalität
+
!Operation
−
| colspan="2"|Registrierung einer neuen Patienteneinwilligung zu einer bestehenden Fallakte. Zweck, Gültigkeitsdauer und Teilnehmerkreis der Akte werden gemäß der neuen Einwilligung festgesetzt. Alle vorher gegebenen Einwilligungen verlieren damit ihre Gültigkeit, sind aber nach wie vor über die Akte nachvollziehbar.  
+
|colspan="2"|registerConsent
 +
|-
 +
!Funktionalität
 +
|colspan="2"|Registriert eine neue Patienteneinwilligung für eine bestehende Fallakte. Zweck, Gültigkeitsdauer und Teilnehmerkreis der Akte werden gemäß der neuen Einwilligung festgesetzt. Die zuvor gültige Einwilligung wird invalidiert.
 +
|-
 +
!Aufrufer
 +
|colspan="2"|EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne
 
|-
 
|-
−
| rowspan="4"|Eingabe
+
!rowspan="4"|Eingabe
 
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
 
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
−
|Das Registrieren einer neuen Einwilligung muss innerhalb eines Sicherheitskontextes erfolgen, in dem der diese Operation initierende Arzt identifizierbar und in seiner Authentizität überprüfbar ist. Mit dem Parameter context wird der vorab über die Operation ''openContext'' des ''EFA Kontext Managers'' erstellte Sicherheitskontext so an den EFA-Provider übergeben, dass dieser den Kontext provider-seitig zur Prüfung der Berechtigungen des Aufrufers innerhalb des Aufrufkontextes rekonstruieren kann.
+
|Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager ''[[cdaefa:EFA_Context_Manager_SFM#Operation:_OpenContext|openContext]]''.
 
|-
 
|-
−
|[[cdaefa:EFA_Business_Informationsmodell#ecrRef|ecrRef]]
+
|[[cdaefa:EFA_Business_Informationsmodell#ecrRef|ecrRef]]
 
|Eindeutige Identifizierung der Fallakte, zu der eine neue Einwilligung vorliegt.
 
|Eindeutige Identifizierung der Fallakte, zu der eine neue Einwilligung vorliegt.
 
|-
 
|-
−
|[[cdaefa:EFA_Business_Informationsmodell#consentInfo|consentInfo]]
+
|[[cdaefa:EFA_Business_Informationsmodell#consentInfo|consentInfo]]
 +
 
 +
docRelationship
 
|Angaben zur neuen Einwilligung auf deren Basis Zweck, Gültigkeitsdauer und Teilnehmerkreis der Akte an Änderungen in der Behandlungsorganisation oder der Behandlungssituation angepasst werden sollen.
 
|Angaben zur neuen Einwilligung auf deren Basis Zweck, Gültigkeitsdauer und Teilnehmerkreis der Akte an Änderungen in der Behandlungsorganisation oder der Behandlungssituation angepasst werden sollen.
 +
 +
consentInfo MUSS über docRelationship (Wert "ersetzt") mit dem gültigen consentInfo-Dokument in der Fallakte assoziiert werden.
 
|-
 
|-
−
|consentDoc (optional)
+
|consentDoc (optional)
−
|Eine ggf. verfügbare elektronische Version des Einwilligungsdokuments kann im Rahmen dieser Operation zur Ablage in der Akte übergeben werden.  
+
 
 +
docRelationship
 +
|Eine ggf. verfügbare elektronische Version des Einwilligungsdokuments kann im Rahmen dieser Operation zur Ablage in der Akte übergeben werden.
 +
 
 +
Wenn consentDoc gegeben ist, dann MUSS consentDoc über docRelationship (Wert "ersetzt") mit dem gültigen consentDoc-Dokument in der Fallakte assoziiert werden.
 
|-
 
|-
−
|Rückgabe
+
!Rückgabe
−
|statusInfo
+
|statusInfo
 
|Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
 
|Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
 
|-
 
|-
−
|Vorbedingungen
+
!Vorbedingungen
−
| colspan="2"|
+
|colspan="2"|
−
* Das übergebene [[cdaefa:EFA_Business_Informationsmodell#consentInfo|consentInfo]] Dokument ist konsistent:
+
*Das übergebene [[cdaefa:EFA_Business_Informationsmodell#consentInfo|consentInfo]] Dokument ist konsistent:
−
** Die Angaben zum betroffenen Patient stimmen mit den verfügbaren Informationen zum Betroffenen der angegeben Akte überein.
+
**Es ist ein Gültigkeitsdatum benannt.
−
** Sofern ein Zweck benannt ist, ist dieser valide und zulässig.
+
**Die EFA Teilnehmer sind benannt.
−
** Es ist ein Gültigkeitsdatum benannt und dieses ist gemäß der Vorgaben des EFA-Providers zulässig.
+
**Die Angaben zu den Rollen der Teilnehmer ermöglichen eine Zuordnung der Teilnehmer zu mit konkreten Zugriffsrechten hinterlegten EFA-Rollen.
−
** Die EFA Teilnehmer sind benannt. 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.
 
 
|-
 
|-
−
|Ablaufsequenz (logisch)
+
!Ablauf
−
| colspan="2"|
+
|colspan="2"|
−
Der Ressource Manager ...
+
#Passe ecrRef.purpose der Partitionen der Fallakte an den Zweck der neuen Einwilligung an.
−
# ... verifiziert, dass die Vorbedingungen zur Ausführung der Operation erfüllt sind.
+
#Übersetze das consentInfo-Dokument in eine EFA-Berechtigungsregel.
−
# ... bildet den Inhalt der Einwilligung auf ein Berechtigungsregelwerk ab und verknüpft dieses mit dem ecrRef-Objekt.
+
#Registriere die EFA-Berechtigungsregel beim Policy Provider.
−
# ... lokalisiert die Partitionen der referenzierten Akte
+
#Verknüpfe consentInfo und consentDoc mit einer Partition (partitionID) der Fallakte.
−
# ... prüft ob die Zweckbenennung über die neue Einwilligung verändert wird. Falls dies der Fall ist, prüft der Ressource Manager, ob bereits eine Akte des Patienten zu dem neuen Zweck besteht. Existiert eine solche Akte, wird die Operation mit einer Fehlermeldung abgebrochen. Ansonsten wird die neue Zweckbindung im ecrRef-Objekt vermerkt.
+
#Ersetze (docRelationship) das bestehende consentInfo und consentDoc mit dem neuen consentInfo und consentDoc.
−
# ... stellt die Angaben zur Einwilligung und ein ggf. übergebenes Einwilligungsformular als Dokumente in eine Partition der referenzierten Akte ein.
+
#Speichre und registriere consentInfo und consentDoc bei Document Repository und Document Registry.
−
# ... erzeugt eine "Ersetzt"-Verknüpfung zwischen der neuen Einwilligung und der für die bestehende Akte zuletzt gültigen Einwilligung.
+
#Gib statusInfo an den Aufrufer.
−
# ... schreibt einen Audit Trail Eintrag über die erfolgreiche Durchführung der Operation
 
−
# ... liefert einen Statuscode zur erfolgreichen Ausführung der Operation an das aufrufende System zurück
 
 
|-
 
|-
−
|Fehler und Warnungen
+
!Fehler und Warnungen
−
| colspan="2"|
+
|colspan="2"|
−
Über die in [[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]] definierten Ausnahmesituationen hinaus, sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:
+
Folgende Fehler müssen erkannt und rückgemeldet werden:
−
* Der Aufrufer hat keine für die Anpassung von Fallakten ausreichende vertragliche Vereinbarung mit dem EFA-Provider.
+
 
−
* Die angegeben Fallakten-Referenz kann nicht aufgelöst werden bzw. der Aufrufer hat keine (ausreichenden) Berechtigungen, die angeforderte Operation auf dieser Akte auszuführen.
+
*[[cdaefa:EFA Fehlermeldungen und Warnungen|Gemeinsame Fehlermeldungen und Warnungen]]
−
* Der Zweck der Akte kann nicht geändert werden, da bereits eine Akte zum angegebenen Patienten und Zweck besteht.
 
−
* Eine oder mehrere der in der consentInfo angegebenen Identitäten zu berechtigender Teilnehmer kann nicht aufgelöst werden.
 
−
* Die übergebene consentInfo ist nicht konsistent zu anderen Angaben.
 
 
|}
 
|}
−
 
+
==== ''notifyOfConsent'' ====
−
==== ''issueAccessToken'' ====
+
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Enndn.01.01.08}</tt>
−
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Enndn.01.01.06}</tt>
 
  
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
!Operation
 
!Operation
−
! colspan="2"|issueAccessToken
+
| colspan="2"|notifyOfConsent
 +
|-
 +
!Funktionalität
 +
| colspan="2"|Benachrichtigt den EFA Ressource Manager über ein consentInfo-Dokument, das bei einem benachbarten EFA-Provider registriert wurde.
 
|-
 
|-
−
|Funktionalität
+
!Aufrufer
−
| colspan="2"|Abrufen eines Berechtigungstoken, über das ein Patient einen weiteren Arzt als Teilnehmer zur Nutzung einer bestehenden Fallakte berechtigen kann. Erteilte Einwilligung, Zweck und Gültigkeit der Akte werden von dieser Operation nicht berührt.
+
| colspan="2"| Ressource Manager einer benachbarten EFA-Provider-Domäne
 
|-
 
|-
−
| rowspan="2"|Eingabe
+
! rowspan="3"|Eingabe
 
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
 
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
−
|Das Abrufen eines Berechtigungstoken muss innerhalb eines Sicherheitskontextes erfolgen, in dem der diese Operation initierende Arzt identifizierbar und in seiner Authentizität überprüfbar ist. Mit dem Parameter context wird der vorab über die Operation ''openContext'' des ''EFA Kontext Managers'' erstellte Sicherheitskontext so an den EFA-Provider übergeben, dass dieser den Kontext provider-seitig zur Prüfung der Berechtigungen des Aufrufers innerhalb des Aufrufkontextes rekonstruieren kann.
+
|Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager [[cdaefa:EFA_Context_Manager_SFM#Operation:_OpenContext|''openContext'']].
 
|-
 
|-
 
|[[cdaefa:EFA_Business_Informationsmodell#ecrRef|ecrRef]]
 
|[[cdaefa:EFA_Business_Informationsmodell#ecrRef|ecrRef]]
−
|Eindeutige Identifizierung der Fallakte, zu der ein Berechtigungstoken abgerufen werden soll.
+
|Eindeutige Identifizierung der Fallakte, zu der eine neue Einwilligung vorliegt.
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#documentID|documentID]]
 +
|Die Referenz des consentInfo-Dokuments.
 
|-
 
|-
−
|Rückgabe
+
!Rückgabe
−
|[[cdaefa:EFA_Security_Informationsmodell#accessToken|accessToken]]
+
|colspan="2"|
−
|Berechtigungstoken, dessen Einlösung den einlösenden Leistungserbringer zum Zugriff auf eine Fallakte berechtigt.
 
 
|-
 
|-
−
|Vorbedingungen
+
!Vorbedingungen
 
| colspan="2"|
 
| colspan="2"|
−
* Der Aufrufer ist berechtigter Teilnehmer der Fallakte und zum Abruf von Berechtigungstoken berechtigt.
 
−
* Die bestehende Einwilligung der Fallakte lässt die Nutzung von Berechtigungstoken zu.
 
−
* Der Aufrufer kann vom EFA Ressource Manager identifiziert und in seiner Authentizität verifiziert werden.
 
 
|-
 
|-
−
|Ablaufsequenz (logisch)
+
!Ablauf
 
| colspan="2"|
 
| colspan="2"|
−
Der Ressource Manager ...
+
# Rufe die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#retrieveData|''retrieveData'']] des Document Repository auf, das im Eingabe-Parameter documentID referenziert ist.
−
# ... verifiziert, dass die Vorbedingungen zur Ausführung der Operation erfüllt sind.
+
# Identifiziere die Fallakte, die das abgerufene consentInfo-Dokument referenziert.
−
# ... generiert einen Proof-Schlüssel (Geheimnis, etc.) anhand dessen beim Einreichen des Berechtigungstoken die Authentizität des Token validiert werden kann
+
# Übersetze das consentInfo-Dokument in eine EFA-Berechtigungsregel.
−
# ... erzeugt ggf. eine Token-Redeem-Policy, die definiert, wer (Rolle, Fachbereich, etc.) das Token einreichen darf
+
# Passe die bestehende EFA-Berechtigungsregel beim Policy Provider an.
−
# ... erzeugt eine Token-Access-Policy, die definiert, welche Berechtigungen an den Einreicher des Tokens vergeben werden
 
−
# ... kapselt Informationen zur Fallakte und Proof-Schlüssel in einem Berechtigungstoken ([[cdaefa:EFA_Security_Informationsmodell#accessToken|accessToken]]-Objekt)
 
−
# ... registriert das erzeugte accessToken mitsamt Proof-Schlüssel und zugehörigen Poicies (z.B. im Policy Provider)
 
−
# ... schreibt einen Audit Trail Eintrag über die erfolgreiche Durchführung der Operation
 
−
# ... liefert ein Berechtigungstoken an das aufrufende System zurück
 
 
|-
 
|-
−
|Fehler und Warnungen
+
!Fehler und Warnungen
 
| colspan="2"|
 
| colspan="2"|
−
Über die in [[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]] definierten Ausnahmesituationen hinaus, sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:
+
Folgende Fehler müssen erkannt und zurückgemeldet werden:
−
* Die angegeben Fallakten-Referenz kann nicht aufgelöst werden bzw. der Aufrufer hat keine (ausreichenden) Berechtigungen, die angeforderte Operation auf dieser Akte auszuführen.  
+
* Gemeinsame [[cdaefa:EFA Fehlermeldungen und Warnungen|Fehler und Warnungen]].
−
* Die Einwilligung zu der Fallakte lässt keine Ad-Hoc-Autorisierungen über Berechtigungstoken zu.
+
* Der Eingabe-Parameter documentID referenziert kein consentInfo-Dokument.
 +
* Die im consentInfo-Dokument referenzierte Fallakte existiert nicht.
 
|}
 
|}
  
−
==== ''redeemAccessToken'' ====
+
==== ''listRecordLocations'' ====
−
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Enndn.01.01.07}</tt>
+
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Enndn.01.01.09}</tt>
  
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
−
!Operation
 
−
! colspan="2"|redeemAccessToken
 
 
|-
 
|-
−
|Funktionalität
+
!Operation
−
| colspan="2"|Einlösen eines Berechtigungstoken, über das ein Patient einen weiteren Arzt als Teilnehmer zur Nutzung einer bestehenden Fallakte berechtigen kann. Erteilte Einwilligung, Zweck und Gültigkeit der Akte werden von dieser Operation nicht berührt.  
+
|colspan="2"|listRecordLocations
 +
|-
 +
!Funktionalität
 +
|colspan="2"|Listet die an einer Fallakte beteiligten EFA-Provider-Domänen auf.
 +
|-
 +
!Aufrufer
 +
|colspan="2"|Ressource Manager einer benachbarten EFA-Provider-Domäne
 +
|-
 +
!rowspan="2"|Eingabe
 +
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
 +
|Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager ''[[cdaefa:EFA_Context_Manager_SFM#Operation:_OpenContext|openContext]]''.
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#ecrRef|ecrRef]]
 +
|Referenziert die Fallakte, deren EFA-Provider-Domänen aufgelistet werden sollen.
 +
|-
 +
!Rückgabe
 +
|[[cdaefa:EFA_Business_Informationsmodell#communityID|MountPoint]]*
 +
|Liste der Mount-Points
 +
|-
 +
!Vorbedingungen
 +
|colspan="2"|
 +
|-
 +
!Ablauf
 +
|colspan="2"|
 +
#Gib die Liste der Mount-Points dem Aufrufer.
 +
|-
 +
!Fehler und Warnungen
 +
|colspan="2"|
 +
Folgende Fehler müssen erkannt und zurückgemeldet werden:
 +
 
 +
*Gemeinsame [[cdaefa:EFA Fehlermeldungen und Warnungen|Fehler und Warnungen]].
 +
*Der Sicherheitskontext enthält kein Access Policy Token, das von diesem EFA-Provider ausgestellt wurde.
 +
|}
 +
==== ''registerRecordLocation'' ====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Enndn.01.01.10}</tt>
 +
 
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
|-
 +
!Operation
 +
|colspan="2"|registerRecordLocation
 +
|-
 +
!Funktionalität
 +
|colspan="2"|Registriert eine EFA-Provider-Domäne als weiteren Speicherort für Partitionen einer Fallakte. Beim Aufrufer wurde ein Offline-Token eingereicht, das vom aufgerufenen EFA-Provider ausgestellten worden ist.
 +
|-
 +
!Aufrufer
 +
|colspan="2"|Ressource Manager der EFA-Provider-Domäne, in der das Offline-Token eingereicht wurde.
 
|-
 
|-
−
| rowspan="3"|Eingabe
+
!rowspan="3"|Eingabe
 
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
 
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
−
|Das Einlösen eines Berechtigungstoken muss innerhalb eines Sicherheitskontextes erfolgen, in dem der diese Operation initierende Arzt identifizierbar und in seiner Authentizität überprüfbar ist. Mit dem Parameter context wird der vorab über die Operation ''openContext'' des ''EFA Kontext Managers'' erstellte Sicherheitskontext so an den EFA-Provider übergeben, dass dieser den Kontext provider-seitig zur Prüfung der Berechtigungen des Aufrufers innerhalb des Aufrufkontextes rekonstruieren kann.
+
|Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager ''[[cdaefa:EFA_Context_Manager_SFM#Operation:_OpenContext|openContext]]''.
 
|-
 
|-
−
|[[cdaefa:EFA_Business_Informationsmodell#patientID|patientID]]
+
|[[cdaefa:EFA_Business_Informationsmodell#ecrRef|MountPoint.sourcePatientId]]
−
|ID des Patienten in der Affinity Domain des Arztes, der das Token einreicht.
+
 
 +
MountPoint.patientId
 +
 
 +
MountPoint.purpose
 +
|Referenziert die Fallakte bei dem Peer, bei dem das Offline-Token eingereicht wurde. sourcePatientId ist die lokal gültige Patienten-ID. patientId ist die Patienten-ID, die in der Ziel-Provider-Domäne gültig ist.
 
|-
 
|-
−
|[[cdaefa:EFA_Business_Informationsmodell#accessToken|accessToken]]
+
|[[cdaefa:EFA_Business_Informationsmodell#communityID|MountPoint.communityID]]
−
|Über die Operation [[#issueAccessToken|issueAccessToken]] ausgestelltes Berechtigungstoken, mit dem der Einreicher als Teilnehmer an der im Token kodierten Fallakte registriert werden soll.  
+
|Kennung der lokalen EFA-Provider-Domäne, bei der das Offline-Token eingereicht wurde.
 
|-
 
|-
−
|Rückgabe
+
!Rückgabe
−
|[[cdaefa:EFA_Security_Informationsmodell#subjectAccessPolicy|subjectAccessPolicy]]
+
|statusInfo
−
|Berechtigungspolicy für den neuen EFA-Teilnehmer. 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.
+
|Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
 
|-
 
|-
−
|Vorbedingungen
+
!Vorbedingungen
−
| colspan="2"|
+
|colspan="2"|
−
* Der Aufrufer kann vom EFA Ressource Manager identifiziert und in seiner Authentizität verifiziert werden.
 
−
* Die Fallakte ist im Zustand "offen".
 
−
* Der Aufrufer verfügt über ein gültiges [[cdaefa:EFA_Business_Informationsmodell#accessToken|accessToken]]
 
−
* Der Patient wurde in der Affinity Domain des Arztes eindeutig identifiziert und die in der Affinity Domain bekannte [[cdaefa:EFA_Business_Informationsmodell#patientID|patientID]] des Patienten liegt vor.
 
 
|-
 
|-
−
|Ablaufsequenz (logisch)
+
!Ablauf
−
| colspan="2"|
+
|colspan="2"|
−
Der Ressource Manager ...
+
#Verknüpfe und speichre den Eingabeparameter ecrRef mit der ecrRef-Instanz des accessPolicyToken.
−
# ... verifiziert, dass die Vorbedingungen zur Ausführung der Operation erfüllt sind.
 
−
# ... validiert den im Token kodierten Proof-Schlüssel (Geheimnis, etc.) um die Authentizität des Tokens sicherzustellen
 
−
# ... validiert die Identitätsdaten des Einreichers gegen eine ggf. erzeugte Redeem-Policy, um sicherzustellen, dass der Einreicher dieses Token einlösen darf
 
−
# ... verknüpft Fallakte und ID des Einreichers mit der hinterlegten Token-Access-Policy, die definiert, welche Berechtigungen an den Einreicher des Tokens vergeben werden
 
−
# ... registriert die erzeugte Policy am Policy Provider
 
−
# ... ruft vom Policy Provider die gültige [[cdaefa:EFA_Security_Informationsmodell#subjectAccessPolicy|subjectAccessPolicy]] des Einreichers ab
 
−
# ... schreibt einen Audit Trail Eintrag über die erfolgreiche Durchführung der Operation
 
−
# ... liefert die subjectAccessPolicy an das aufrufende System zurück
 
 
|-
 
|-
−
|Fehler und Warnungen
+
!Fehler und Warnungen
−
| colspan="2"|
+
|colspan="2"|
−
Über die in [[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]] definierten Ausnahmesituationen hinaus, sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:
+
Folgende Fehler müssen erkannt und zurückgemeldet werden:
−
* Die im Token kodierte Fallakten-Referenz kann nicht aufgelöst werden bzw. der Aufrufer hat keine (ausreichenden) Berechtigungen, die angeforderte Operation auf dieser Akte auszuführen.
+
 
−
* Die Einwilligung zu der Fallakte lässt keine Ad-Hoc-Autorisierungen über Berechtigungstoken zu.
+
*Gemeinsame [[cdaefa:EFA Fehlermeldungen und Warnungen|Fehler und Warnungen]].
−
* Die Redeem-Policy schließt den Einreicher von der Einlösung des Berechtigungstoken aus.
+
*Der Sicherheitskontext enthält kein Access Policy Token, das von diesem EFA-Provider ausgestellt wurde.
 
|}
 
|}
  
Zeile 477: Zeile 497:
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Enndn.01.02}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Enndn.01.02}</tt>
  
−
In den folgenden Abschnitten werden die Operationen des EFA Document Registry plattform-unabhängig als ''Service Functional Model'' spezifiziert. Die folgenden Vorbedingungen müssen für alle Aufrufe an das Document Registry erfüllt sein und werden:
+
Die EFA Document Registry muss die in diesem Abschnitt enthaltenen Operationen implementieren.  
−
* Das aufrufende Teilnehmersystem kann das EFA Document Registry lokalisieren und sicher authentifizieren. 
 
−
* Ein aufrufendes Document Repository kann das EFA Document Registry lokalisieren und sicher authentifizieren. 
 
−
* Der vom Teilnehmersystem übermittelte Sicherheitskontext ist gültig, vollständig, authentisch und wurde von einer vertrauenswürdigen Stelle für den Aufrufer ausgestellt.
 
−
* Das Document Registry kann den Aufrufer anhand der im [[cdaefa:EFA_Security_Informationsmodell#context|context]] übermittelten Daten sicher identifizieren und authentifizieren.
 
−
* Das Document Registry ist technisch in der Lage, einen Audit Trail Eintrag zu schreiben.
 
  
 
==== ''registerData'' ====
 
==== ''registerData'' ====
Zeile 489: Zeile 504:
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
!Operation
 
!Operation
−
! colspan="2"|registerData
+
| colspan="2"|registerData
 +
|-
 +
!Funktionalität
 +
| colspan="2"|Diese Operation registriert von Daten an einer bestehenden Partition einer Fallakte.
 
|-
 
|-
−
|Funktionalität
+
!Aufrufer
−
| colspan="2"|Registrieren von Daten an einer bestehenden Partition einer Fallakte.<br>''Dies ist eine EFA-Provider interne Funktion, die ausschließlich vom EFA Document Repository aufgerufen wird. Die Absicherung der Kommunikation durch einen zwischen beiden Diensten gespannten Sicherheitskontext ist Aufgabe des EFA-Providers und kann mit EFA-unabhängigen Mechanismen realisiert werden.'' 
+
| colspan="2"|Document Repository der gleichen EFA-Provider-Domäne. Die Absicherung der Kommunikation durch einen zwischen beiden Diensten gespannten Sicherheitskontext ist Aufgabe des EFA-Providers und kann mit EFA-unabhängigen Mechanismen realisiert werden.
 
|-
 
|-
−
| rowspan="4"|Eingabe
+
! rowspan="4"|Eingabe
 
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
 
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
−
|Das Einstellen von Daten in eine Partition muss innerhalb eines Sicherheitskontextes erfolgen, in dem der die Anlage der Partition initierende Arzt identifizierbar und in seiner Authentizität überprüfbar ist. Mit dem Parameter context wird der vorab über die Operation ''openContext'' des ''EFA Kontext Managers'' erstellte Sicherheitskontext so an den EFA-Provider übergeben, dass dieser den Kontext provider-seitig zur Prüfung der Berechtigungen des Aufrufers innerhalb des Aufrufkontextes rekonstruieren kann.
+
|Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager [[cdaefa:EFA_Context_Manager_SFM#Operation:_OpenContext|''openContext'']].
 
|-
 
|-
 
|[[cdaefa:EFA_Business_Informationsmodell#partitionID|partitionID]]
 
|[[cdaefa:EFA_Business_Informationsmodell#partitionID|partitionID]]
Zeile 507: Zeile 525:
 
|Beziehungen der neu zu registrierenden Daten zu bestehenden Dokumenten. Diese müssen so registriert werden, dass sie bei der Auflistung von Dokumenten mit bereit gestellt werden können.
 
|Beziehungen der neu zu registrierenden Daten zu bestehenden Dokumenten. Diese müssen so registriert werden, dass sie bei der Auflistung von Dokumenten mit bereit gestellt werden können.
 
|-
 
|-
−
|Rückgabe
+
!Rückgabe
 
|statusInfo
 
|statusInfo
 
|Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
 
|Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
 
|-
 
|-
−
|Vorbedingungen
+
!Vorbedingungen
 
| colspan="2"|
 
| colspan="2"|
−
* Der Aufrufer ist berechtigt, beim angesprochenen EFA-Provider Daten zu bestehenden Fallakten anzulegen.
 
−
* Die übergebene Partitons-Referenz ist valide und der Aufrufer hat die erforderlichen Zugriffsrechte auf der übergeordneten Akte, um die angeforderte Aktion durchzuführen.
 
 
* Die übergebenen Metadaten der einzustellenden Daten sind vollständig und valide.
 
* Die übergebenen Metadaten der einzustellenden Daten sind vollständig und valide.
 
* Die Konfiguration der angesprochenen Akte erlaubt das Einstellen der übergebenen Dokumente.  
 
* Die Konfiguration der angesprochenen Akte erlaubt das Einstellen der übergebenen Dokumente.  
−
* Die angegebenen Dokumentbeziehungen sind valide und referenzieren ausschließlich zu der selben Akte gehörige Dokumente.
 
 
|-
 
|-
−
|Ablaufsequenz
+
!Ablauf
 
| colspan="2"|
 
| colspan="2"|
−
Das Document Registry ...
+
# Speichre docMetadata, docRelationship und den Bezug zu partitionID.
−
# ... verifiziert, dass die Vorbedingungen zur Ausführung der Operation erfüllt sind.
+
# Gib das statusInfo-Objekt dem Aufrufer.
−
# ... registriert die Metadaten und Dokumentbeziehungen an der angegebenen Partition.
 
−
# ... schreibt einen Audit Trail Eintrag über die erfolgreiche Durchführung der Operation
 
−
# ... liefert einen Statuscode zur erfolgreichen Ausführung der Operation zurück
 
 
|-
 
|-
−
|Fehler und Warnungen
+
!Fehler und Warnungen
 
| colspan="2"|
 
| colspan="2"|
−
Über die in [[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]] definierten Ausnahmesituationen hinaus, sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:
+
Folgende Fehler müssen erkannt und rückgemeldet werden:
−
* Der Aufrufer hat keine für das Einstellen von Daten in Fallakten ausreichende vertragliche Vereinbarung mit dem EFA-Provider.
+
* [[cdaefa:EFA Fehlermeldungen und Warnungen|Gemeinsame Fehlermeldungen und Warnungen]]
−
* Die angegeben Partitions-Referenz kann nicht aufgelöst werden bzw. der Aufrufer hat keine (ausreichenden) Berechtigungen, die angeforderte Operation auf der übergeordneten Akte auszuführen.
 
−
Zusätzlich sind die folgenden Warnungen definiert:
 
−
* Eine oder mehrere der übergebenen Dokument-Beziehungen konnte nicht aufgelöst werden oder ist nicht zulässig.
 
 
|}
 
|}
  
Zeile 541: Zeile 550:
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
!Operation
 
!Operation
−
! colspan="2"|listPartitionContent
+
| colspan="2"|listPartitionContent
 
|-
 
|-
−
|Funktionalität
+
!Funktionalität
−
| colspan="2"|Abruf der Metadaten zu den an einer Partition einer Fallakte registrierten Dokumenten.
+
| colspan="2"|Diese Operation gibt die Liste der Dokumente, die in einer Partition enthalten sind, zurück. Die Liste enthält die Dokument-Metadaten und Dokument-Beziehungen.
 
|-
 
|-
−
| rowspan="2"|Eingabe
+
!Aufrufer
 +
| colspan="2"|
 +
*EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne,
 +
*Document Registry einer benachbarten EFA-Provider-Domäne
 +
|-
 +
! rowspan="2"|Eingabe
 
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
 
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
−
|Das Auflisten von Daten einer Partition muss innerhalb eines Sicherheitskontextes erfolgen, in dem der die Anlage der Partition initierende Arzt identifizierbar und in seiner Authentizität überprüfbar ist. Mit dem Parameter context wird der vorab über die Operation ''openContext'' des ''EFA Kontext Managers'' erstellte Sicherheitskontext so an den EFA-Provider übergeben, dass dieser den Kontext provider-seitig zur Prüfung der Berechtigungen des Aufrufers innerhalb des Aufrufkontextes rekonstruieren kann.
+
|Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager [[cdaefa:EFA_Context_Manager_SFM#Operation:_OpenContext|''openContext'']].
 
|-
 
|-
 
|[[cdaefa:EFA_Business_Informationsmodell#partitionID|partitionID]]
 
|[[cdaefa:EFA_Business_Informationsmodell#partitionID|partitionID]]
 
|Eindeutige Identifizierung der Partition, deren Inhalte ausgelesen werden sollen.
 
|Eindeutige Identifizierung der Partition, deren Inhalte ausgelesen werden sollen.
 
|-
 
|-
−
| rowspan="2"|Rückgabe
+
! rowspan="2"|Rückgabe
 
|[[cdaefa:EFA_Business_Informationsmodell#docMetadata|docMetadata]][0..*]
 
|[[cdaefa:EFA_Business_Informationsmodell#docMetadata|docMetadata]][0..*]
 
|Metadaten der an der ausgewählten Partition registrierten Dokumente
 
|Metadaten der an der ausgewählten Partition registrierten Dokumente
Zeile 560: Zeile 574:
 
|Beziehungen zwischen den  Dokumenten der zu listenden Partition und Dokumenten dieser und anderer Partitionen.  
 
|Beziehungen zwischen den  Dokumenten der zu listenden Partition und Dokumenten dieser und anderer Partitionen.  
 
|-
 
|-
−
|Vorbedingungen
+
!Vorbedingungen
 
| colspan="2"|
 
| colspan="2"|
−
* Die übergebene Partitons-Referenz ist valide und der Aufrufer hat die erforderlichen Zugriffsrechte auf der übergeordneten Akte, um die angeforderte Aktion durchzuführen.
 
 
|-
 
|-
−
|Ablaufsequenz
+
!Ablauf
 
| colspan="2"|
 
| colspan="2"|
−
Das Document Registry ...
+
# Identifiziere alle Dokumente,
−
# ... verifiziert, dass die Vorbedingungen zur Ausführung der Operation erfüllt sind.
+
## die mit partitionID verknüpft sind und
−
# ... überführt die Metadaten der an der angegebenen Partition registrierten Dokumente in das im Binding dieser Operation definierte Format. Hierbei werden nur Dokumente berücksichtigt, die für den Aufrufer gemäß seiner Rolle zugreifbar sind (siehe insbesondere die mäglichen [[cdaefa:Akteure_und_Rollen_der_EFA#EFA-Teilnehmer|Sonderrollen von EFA-Teilnehmern]])
+
## für welche der Aufrufer (context) zugriffsberechtigt ist.
−
# ... schreibt einen Audit Trail Eintrag über die erfolgreiche Durchführung der Operation
+
# Identifiziere alle Dokument-Beziehungen dieser Dokumente.
−
# ... liefert einen Statuscode zur erfolgreichen Ausführung der Operation sowie die Metadaten der an der Partition registrierten Dokumente zurück
+
# Gib die Metadaten der Dokumente und deren Dokument-Beziehungen dem Aufrufer.
 
|-
 
|-
−
|Fehler und Warnungen
+
!Fehler und Warnungen
 
| colspan="2"|
 
| colspan="2"|
−
Über die in [[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]] definierten Ausnahmesituationen hinaus, sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:
+
Folgende Fehler müssen erkannt und rückgemeldet werden:
−
* Die angegeben Partitions-Referenz kann nicht aufgelöst werden bzw. der Aufrufer hat keine (ausreichenden) Berechtigungen, die angeforderte Operation auf der übergeordneten Akte auszuführen.  
+
* [[cdaefa:EFA Fehlermeldungen und Warnungen|Gemeinsame Fehlermeldungen und Warnungen]]
 +
|}
 +
 
 +
==== ''invalidateData'' ====
 +
 
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!Operation
 +
| colspan="2"|invalidateData
 +
|-
 +
!Funktionalität
 +
| colspan="2"|Invalidieren eines Dokuments in einer Fallakte.
 +
|-
 +
!Aufrufer
 +
| colspan="2"|
 +
*EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne,
 +
|-
 +
! rowspan="2"|Eingabe
 +
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
 +
|Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager [[cdaefa:EFA_Context_Manager_SFM#Operation:_OpenContext|''openContext'']].
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#documentID|documentID]]
 +
|Eindeutige Identifizierung des zu invalidierenden Dokuments. Das zu invalidierende Dokument DARF NICHT vom Typ [[cdaefa:EFA_Business_Informationsmodell#consentInfo|consentInfo]] oder [[cdaefa:EFA_Business_Informationsmodell#consentDoc|consentDoc]] sein.
 +
|-
 +
! rowspan="1"|Rückgabe
 +
|statusInfo
 +
|Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
 +
|-
 +
!Vorbedingungen
 +
| colspan="2"|
 +
|-
 +
!Ablauf
 +
| colspan="2"|
 +
Das Document Registry
 +
# ... ändert den Wert des Attributs ''[[cdaefa:EFA_Business_Informationsmodell#docMetadata|Status]]'' des Dokuments auf ''ungültig''.
 +
# ... sendet eine Information zum Ausführungsstatus der Operation an den Nutzer zurück.
 +
|-
 +
!Fehler und Warnungen
 +
| colspan="2"|
 +
Folgende Fehler müssen erkannt und rückgemeldet werden:
 +
* [[cdaefa:EFA Fehlermeldungen und Warnungen|Gemeinsame Fehlermeldungen und Warnungen]]
 
|}
 
|}
  
Zeile 581: Zeile 633:
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Enndn.01.03}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Enndn.01.03}</tt>
  
−
In den folgenden Abschnitten werden die Operationen des EFA Document Repository plattform-unabhängig als ''Service Functional Model'' spezifiziert. Die folgenden Vorbedingungen müssen für alle Aufrufe an das Document Repository erfüllt sein und werden:
+
Das EFA Document Repository muss die in diesem Abschnitt enthaltenen Operationen implementieren.  
−
* Das aufrufende Teilnehmersystem kann das EFA Document Repository lokalisieren und sicher authentifizieren.
 
−
* Der Document Repository ist ein Document Registry zugeordnet. Das Document Repository kann dieses Document Registry lokalisieren und sicher authentifizieren. 
 
−
* Der vom Teilnehmersystem übermittelte Sicherheitskontext ist gültig, vollständig, authentisch und wurde von einer vertrauenswürdigen Stelle für den Aufrufer ausgestellt.
 
−
* Das Document Repository kann den Aufrufer anhand der im [[cdaefa:EFA_Security_Informationsmodell#context|context]] übermittelten Daten sicher identifizieren und authentifizieren.
 
−
* Das Document Repository ist technisch in der Lage, einen Audit Trail Eintrag zu schreiben
 
  
 
==== ''provideData'' ====
 
==== ''provideData'' ====
Zeile 593: Zeile 640:
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
!Operation
 
!Operation
−
! colspan="2"|provideData
+
| colspan="2"|provideData
 
|-
 
|-
−
|Funktionalität
+
!Funktionalität
−
| colspan="2"|Einstellen von Daten in eine bestehende Partition einer Fallakte.
+
| colspan="2"|Diese Operation stellt Daten in eine Partition einer Fallakte ein.
 
|-
 
|-
−
| rowspan="4"|Eingabe
+
!Aufrufer
 +
| colspan="2"|EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne
 +
|-
 +
! rowspan="4"|Eingabe
 
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
 
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
−
|Das Einstellen von Daten in eine Partition muss innerhalb eines Sicherheitskontextes erfolgen, in dem der die Anlage der Partition initierende Arzt identifizierbar und in seiner Authentizität überprüfbar ist. Mit dem Parameter context wird der vorab über die Operation ''openContext'' des ''EFA Kontext Managers'' erstellte Sicherheitskontext so an den EFA-Provider übergeben, dass dieser den Kontext provider-seitig zur Prüfung der Berechtigungen des Aufrufers innerhalb des Aufrufkontextes rekonstruieren kann.
+
|Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager [[cdaefa:EFA_Context_Manager_SFM#Operation:_OpenContext|''openContext'']].
 
|-
 
|-
 
|[[cdaefa:EFA_Business_Informationsmodell#partitionID|partitionID]]
 
|[[cdaefa:EFA_Business_Informationsmodell#partitionID|partitionID]]
Zeile 611: Zeile 661:
 
|Beziehungen der neu zu registrierenden Daten zu bestehenden Dokumenten.  
 
|Beziehungen der neu zu registrierenden Daten zu bestehenden Dokumenten.  
 
|-
 
|-
−
|Rückgabe
+
!Rückgabe
 
|statusInfo
 
|statusInfo
 
|Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
 
|Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
 
|-
 
|-
−
|Vorbedingungen
+
!Vorbedingungen
 
| colspan="2"|
 
| colspan="2"|
−
* Die übergebene Partitons-Referenz ist valide und der Aufrufer hat die erforderlichen Zugriffsrechte auf der übergeordneten Akte, um die angeforderte Aktion durchzuführen.
 
 
* Die übergebenen Metadaten der einzustellenden Daten sind vollständig und valide.
 
* Die übergebenen Metadaten der einzustellenden Daten sind vollständig und valide.
−
* Die Konfiguration der angesprochenen Akte erlaubt das Einstellen der übergebenen Dokumente.
 
−
* Die angegebenen Dokumentbeziehungen sind valide und referenzieren ausschließlich zu der selben Akte gehörige Dokumente.
 
 
|-
 
|-
−
|Ablaufsequenz
+
!Ablauf
 
| colspan="2"|
 
| colspan="2"|
−
Das Document Repository
+
# Speichre die Dokument-Daten.
−
# ... stellt sicher, dass die Vorbedingungen erfüllt sind.
+
# Rufe die Operation [[cdaefa:EFA_Document_Registry_SFM|registerData]] Operation des Document Registry der gleichen Community auf. Übergebe die Eingabeparameter dieser Operation.
−
# ... legt alle übergebenen Dokumente in einem sicheren Dokumentenspeicher ab.
+
# Gib das statusInfo-Objekt dem Aufrufer.  
−
# ... initiert die [[cdaefa:EFA_Document_Registry_SFM|registerData]] Operation mit den übergebenen Metadaten und Beziehungen beim Document Registry.
 
−
# ... schreibt einen Audit Trail Eintrag über die Ausführung der Operation.
 
−
# ... sendet eine Information zum Ausführungsstatus der Operation an den Nutzer zurück.
 
 
|-
 
|-
−
|Fehler und Warnungen
+
!Fehler und Warnungen
 
| colspan="2"|
 
| colspan="2"|
−
Über die in [[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]] definierten Ausnahmesituationen hinaus, sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:
+
Folgende Fehler müssen erkannt und rückgemeldet werden:
−
* Der Aufrufer hat keine für das Einstellen von Daten in Fallakten ausreichende vertragliche Vereinbarung mit dem EFA-Provider.
+
* [[cdaefa:EFA Fehlermeldungen und Warnungen|Gemeinsame Fehlermeldungen und Warnungen]]
−
* Die angegeben Partitions-Referenz kann nicht aufgelöst werden bzw. der Aufrufer hat keine (ausreichenden) Berechtigungen, die angeforderte Operation auf der übergeordneten Akte auszuführen.
 
−
Zusätzlich sind die folgenden Warnungen definiert:
 
−
* Eine oder mehrere der übergebenen Dokument-Beziehungen konnte nicht aufgelöst werden oder ist nicht zulässig.
 
 
|}
 
|}
  
Zeile 645: Zeile 686:
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
!Operation
 
!Operation
−
! colspan="2"|retrieveData
+
| colspan="2"|retrieveData
 
|-
 
|-
−
|Funktionalität
+
!Funktionalität
 
| colspan="2"|Abrufen von Daten aus einer Fallakte.
 
| colspan="2"|Abrufen von Daten aus einer Fallakte.
 
|-
 
|-
−
| rowspan="2"|Eingabe
+
!Aufrufer
 +
| colspan="2"|
 +
*EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne,
 +
*Ressource Manager einer benachbarten EFA-Provider-Domäne
 +
|-
 +
! rowspan="2"|Eingabe
 
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
 
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
−
|Das Abrufen von Daten muss innerhalb eines Sicherheitskontextes erfolgen, in dem der die Anlage der Partition initierende Arzt identifizierbar und in seiner Authentizität überprüfbar ist. Mit dem Parameter context wird der vorab über die Operation ''openContext'' des ''EFA Kontext Managers'' erstellte Sicherheitskontext so an den EFA-Provider übergeben, dass dieser den Kontext provider-seitig zur Prüfung der Berechtigungen des Aufrufers innerhalb des Aufrufkontextes rekonstruieren kann.
+
|Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager [[cdaefa:EFA_Context_Manager_SFM#Operation:_OpenContext|''openContext'']].
 
|-
 
|-
 
|[[cdaefa:EFA_Business_Informationsmodell#documentID|documentID]]
 
|[[cdaefa:EFA_Business_Informationsmodell#documentID|documentID]]
 
|Eindeutige Identifizierung der abzurufenden Dokumente
 
|Eindeutige Identifizierung der abzurufenden Dokumente
 
|-
 
|-
−
| rowspan="2"|Rückgabe
+
! rowspan="2"|Rückgabe
 
|statusInfo
 
|statusInfo
 
|Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
 
|Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
Zeile 664: Zeile 710:
 
|angeforderte Dokumente
 
|angeforderte Dokumente
 
|-
 
|-
−
|Vorbedingungen
+
!Vorbedingungen
 
| colspan="2"|
 
| colspan="2"|
−
* Die übergebenen Dokument-Referenzen sind valide und der Aufrufer hat die erforderlichen Zugriffsrechte auf der übergeordneten Akte, um die angeforderte Aktion durchzuführen.
 
−
* Die angefragten Dokumente sind der selben Fallakte zugeordnet.
 
 
|-
 
|-
−
|Ablaufsequenz
+
!Ablauf
 
| colspan="2"|
 
| colspan="2"|
 
Das Document Repository  
 
Das Document Repository  
−
# ... stellt sicher, dass die Vorbedingungen erfüllt sind.
 
 
# ... ruft die angefragten Dokumente aus dem sicheren Dokumentenspeicher ab.
 
# ... ruft die angefragten Dokumente aus dem sicheren Dokumentenspeicher ab.
−
# ... schreibt einen Audit Trail Eintrag über die Ausführung der Operation.
 
 
# ... sendet eine Information zum Ausführungsstatus der Operation sie wie die angefragten Dokumente an den Nutzer zurück.
 
# ... sendet eine Information zum Ausführungsstatus der Operation sie wie die angefragten Dokumente an den Nutzer zurück.
 
|-
 
|-
−
|Fehler und Warnungen
+
!Fehler und Warnungen
 
| colspan="2"|
 
| colspan="2"|
−
Über die in [[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]] definierten Ausnahmesituationen hinaus, sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:
+
Folgende Fehler müssen erkannt und rückgemeldet werden:
−
* Der Aufrufer hat keine (ausreichenden) Berechtigungen, die angeforderte Operation auf der übergeordneten Akte auszuführen.
+
* [[cdaefa:EFA Fehlermeldungen und Warnungen|Gemeinsame Fehlermeldungen und Warnungen]]
−
Zusätzlich sind die folgenden Warnungen definiert:
 
−
* Eine oder mehrere der übergebenen Dokument-Referenzen konnten nicht aufgelöst werden.
 
 
|}
 
|}
  
−
=== Querverweise und Referenzen ===
 
  
 +
 +
----
 +
 +
 +
{{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:50 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".

EFA Anwendungsarchitektur: Service Functional Model

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

Die nachfolgende Tabelle listet zu den EFA-Kommunikationsmustern die zu deren Umsetzung benötigten Operationen auf. Die Gesamtheit dieser Operationen bildet das Service Functional Model der EFA-Anwendungsarchitektur, d.h. liefert eine vollständige plattformunabhängige Beschreibung der technisch umzusetzenden EFA-Funktionalität.

Kommunikationsmuster Operation (logisch) Umsetzender Dienst (logisch)
Anlegen einer Fallakte createECR EFA Ressource Manager
Anlegen einer Partition zu einer bestehenden Fallakte createPartition EFA Ressource Manager
Schließen einer Fallakte closeECR EFA Ressource Manager
Auflisten von Partitionen listPartitions EFA Ressource Manager
Registrierung einer neuen Einwilligung registerConsent EFA Ressource Manager
Verteilen einer Einwilligung im EFA-Verbund notifyOfConsent EFA Ressource Manager
Anfordern eines Berechtigungstoken issueAccessToken EFA Ressource Manager
Einlösen eines Berechtigungstoken redeemAccessToken EFA Ressource Manager
listRecordLocations EFA Ressource Manager
registerRecordLocation EFA Ressource Manager
Einstellen von Dokumenten provideData EFA Document Repository
registerData EFA Document Registry
Auflisten von Dokumenten (einer Partition) listPartitionContent EFA Document Registry
Abrufen von Dokumenten retrieveData EFA Document Repository
Invalidieren eines Dokuments invalidateData EFA Document Registry

Das Zusammenspiel von Diensten und Operationen ist in der folgenden Darstellung noch einmal im Überblick dargestellt.

Cdaefa SFM Operationen.png

Die gestrichelt dargestellten internen Operationsaufrufe vom Ressource Manager zu den anderen Diensten sind optional in dem Sinne als dass die geforderte Funktionalität der Speicherung und Registrierung von Einwilligungen und Einwilligungsdokumenten auch über interne Mechanismen des EFA-Providers erfolgen kann.

Für alle Operationen gilt:

  • Der vom Teilnehmersystem übermittelte Sicherheitskontext muss gültig, vollständig, authentisch und von einer vertrauenswürdigen Stelle für den Aufrufer ausgestellt worden sein.
  • Der EFA-Dienst muss den Aufrufer anhand des Eingabeparameters context authentifizieren können.
  • Die beteiligten Systeme schreiben einen Audit-Trail.

Operationen des EFA Ressource Manager

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Enndn.01.01}

Der EFA Ressource Manager muss die in diesem Abschnitt enthaltenen Operationen implementieren.

createECR

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Enndn.01.01.01}

Operation createECR
Funktionalität Diese Operation erzeugt eine Fallakte. Wenn die Fallakte für den Patienten und für den Zweck bereits besteht, werden die bestehende und die neue Fallakte fusioniert. Die Einwilligung der bestehenden Fallakte wird invalidiert und mit der neuen Einwilligung ersetzt.
Aufrufer EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne
Eingabe context Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext.
patientID Die ID des Patienten, für den die Fallakte angelegt werden soll.
purpose Der Zweck für den die Fallakte angelegt werden soll. Er muss mit dem Zweck übereinstimmen, der im Eingabe-Parameter consentInfo angegeben ist.
consentInfo Das strukturierte Dokument, das die Einwilligung des Patienten für die Anlage der Fallakte abbildet.
consentDoc (optional) Sofern die Einwilligungserklärung des Patienten als (gescanntes) elektronisches Dokument vorliegt, kann diese bei der Anlage der Akte direkt in die Akte eingestellt werden.
Rückgabe statusInfo Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
partitionID Eindeutige ID der initial zu der neuen Akte angelegten Partition. Mit Hilfe dieser ID kann der EFA-Teilnehmer weitere Operationen, wie z.B. das Einstellen von Dokumenten in die Fallakte, durchführen.
Vorbedingungen
  • Das übergebene consentInfo Dokument ist konsistent:
    • Die Angaben zum betroffenen Patient MÜSSEN mit den verfügbaren Informationen zum Besitzer der übergebenen Patienten-ID übereinstimmen.
    • Es MUSS ein Zweck benannt sein, der mit dem bei der EFA-Anlage benannten Zweck überein stimmen MUSS.
    • Es ist ein Gültigkeitsdatum benannt.
    • Zumindest ein autorisierter EFA Teilnehmer MUSS benannt und anhand der angegebenen Daten eindeutig identifizierbar sein. Dies KANN die Einrichtung/Person sein, die die Fallakte anlegt.
    • Sofern im consentInfo ein Fallaktenmanager identifiziert ist, MUSS dieser mit der im EFA-Netzwerk für diese Rolle benannten Person übereinstimmen (die Festlegung des Fallaktenmanagers erfolgt nicht durch den Patienten und muss daher nicht zwingend in den kodierten Informationen zur Einwilligung enthalten sein).
Ablauf
  1. Übersetze das consentInfo-Dokument in eine EFA-Berechtigungsregel.
  2. Registriere die EFA-Berechtigungsregel beim Policy Provider.
  3. Erzeuge eine Partition. Verknüpfe sie mit ecrRef.
  4. Konfiguriere die Metadaten der Partition (partitionInfo).
  5. Verknüpfe consentInfo und consentDoc mit der Partition (partitionID).
  6. Wenn eine Fallakte für patientID und purpose (ecrRef) existiert:
    1. Beachte die Fehlersituation Prohibited Merge.
    2. Ersetze (docRelationship) das bestehende consentInfo und consentDoc mit dem neuen consentInfo und consentDoc.
  7. Speichre und registriere consentInfo und consentDoc bei Document Repository und Document Registry.
  8. Gib die Kennung der neuen Partition (partitionID) und den Status dem Aufrufer.
Fehler und Warnungen

Folgende Fehler müssen erkannt und rückgemeldet werden:

createPartition

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Enndn.01.01.02}

Operation createPartition
Funktionalität Diese Operation erzeugt eine Partition für eine bestehende Fallakte.
Aufrufer EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne
Eingabe context Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext.
ecrRef Eindeutige Identifizierung der Fallakte, zu der die Partition hinzugefügt werden soll.
partitionInfo Metadaten zu der neu anzulegenden Partition (Titel, etc.)
initialDoc (optional) Bei der Anlage einer Partition können initial in diese Partition einzustellende Dokumente mit übergeben werden.
Rückgabe statusInfo Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
partitionID Eindeutige ID der neu angelegten Partition. Mit Hilfe dieser ID kann der EFA-Teilnehmer weitere Operationen, wie z.B. das Einstellen von Dokumenten in diese Partition, durchführen.
Vorbedingungen
  • Die übergebenen Metadaten der anzulegenden Partition sind vollständig und valide.
Ablauf
  1. Erzeuge eine Partition. Verknüpfe sie mit dem Eingabeparametern ecrRef und partitionInfo.
  2. Verknüpfe initialDoc mit der Partition (partitionID).
  3. Speichre und registriere initialDoc bei Document Repository und Document Registry.
  4. Gib die Kennung der neuen Partition (partitionID) und den Status dem Aufrufer.
Fehler und Warnungen

Folgende Fehler müssen erkannt und rückgemeldet werden:

closeECR

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Enndn.01.01.03}

Operation closeECR
Funktionalität Schließt eine Fallakte. Sie wechselt in den Status "Gesperrt" und ist nur für Fallaktenmanager verfügbar.
Aufrufer EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne
Eingabe context Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext.
ecrRef Eindeutige Identifizierung der Fallakte, die geschlossen werden soll.
consentInfo Angaben zum Grund für das Schließen der Fallakte (z.B. Rücknahme der Einwilligung durch den Patienten).
consentDoc (optional) Sofern die Schließung der Akte auf eine Änderung der Einwilligung zurückzuführen ist, kann eine elektronische Version des entsprechenden Dokuments mit übergeben werden. Hierdurch ist auch nach dem Schließen der Akte der Grund für diese Operation noch nachvollziehbar.
Rückgabe statusInfo Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
Vorbedingungen
Ablauf
  1. Ändere den Status der Fallakte (ecrStatus) auf "Gesperrt".
  2. Übersetze das consentInfo-Dokument in eine EFA-Berechtigungsregel.
  3. Registriere die EFA-Berechtigungsregel beim Policy Provider.
  4. Verknüpfe consentInfo und consentDoc mit einer Partition (partitionID) der Fallakte.
  5. Ersetze (docRelationship) das bestehende consentInfo und consentDoc mit dem neuen consentInfo und consentDoc.
  6. Speichre und registriere consentInfo und consentDoc bei Document Repository und Document Registry.
  7. Gib statusInfo dem Aufrufer.
Fehler und Warnungen

Folgende Fehler müssen erkannt und rückgemeldet werden:

listPartitions

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Enndn.01.01.04}

Operation listPartitions
Funktionalität Diese Operation listet die Informationen aller Partitionen (und deren übergeordneten Fallakte) auf, zu denen der Aufrufer über die vom betroffenen Patienten gegebenen Einwilligungen zugangsberechtigt ist.
Aufrufer
  • EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne,
  • Ressource Manager einer benachbarten EFA-Provider-Domäne
Eingabe context Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext.
patientID Die ID des betroffenen Patienten.
purpose Einschränkung der Suche auf Akten und Partitionen, die zu einem bestimmten Zweck angelegt wurden.
Rückgabe statusInfo Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
partitionList Liste von nach übergeordneten Fallakten strukturierten Partitionen des Patienten, die im Ergebnis der Suchanfrage gefunden wurden.
Vorbedingungen
Ablauf
  1. Identifiziere alle Partitionen,
    1. die mit den Eingabeparametern patientID und purpose verknüpft sind und
    2. für welche der Aufrufer (context) zugriffsberechtigt ist.
  2. Erstelle das partitionList-Objekt für diese Partitionen.
  3. Gib partitionList und statusInfo dem Aufrufer.
Fehler und Warnungen

Folgende Fehler müssen erkannt und rückgemeldet werden:

registerConsent

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Enndn.01.01.05}

Operation registerConsent
Funktionalität Registriert eine neue Patienteneinwilligung für eine bestehende Fallakte. Zweck, Gültigkeitsdauer und Teilnehmerkreis der Akte werden gemäß der neuen Einwilligung festgesetzt. Die zuvor gültige Einwilligung wird invalidiert.
Aufrufer EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne
Eingabe context Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext.
ecrRef Eindeutige Identifizierung der Fallakte, zu der eine neue Einwilligung vorliegt.
consentInfo

docRelationship

Angaben zur neuen Einwilligung auf deren Basis Zweck, Gültigkeitsdauer und Teilnehmerkreis der Akte an Änderungen in der Behandlungsorganisation oder der Behandlungssituation angepasst werden sollen.

consentInfo MUSS über docRelationship (Wert "ersetzt") mit dem gültigen consentInfo-Dokument in der Fallakte assoziiert werden.

consentDoc (optional)

docRelationship

Eine ggf. verfügbare elektronische Version des Einwilligungsdokuments kann im Rahmen dieser Operation zur Ablage in der Akte übergeben werden.

Wenn consentDoc gegeben ist, dann MUSS consentDoc über docRelationship (Wert "ersetzt") mit dem gültigen consentDoc-Dokument in der Fallakte assoziiert werden.

Rückgabe statusInfo Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
Vorbedingungen
  • Das übergebene consentInfo Dokument ist konsistent:
    • Es ist ein Gültigkeitsdatum benannt.
    • Die EFA Teilnehmer sind benannt.
    • Die Angaben zu den Rollen der Teilnehmer ermöglichen eine Zuordnung der Teilnehmer zu mit konkreten Zugriffsrechten hinterlegten EFA-Rollen.
Ablauf
  1. Passe ecrRef.purpose der Partitionen der Fallakte an den Zweck der neuen Einwilligung an.
  2. Übersetze das consentInfo-Dokument in eine EFA-Berechtigungsregel.
  3. Registriere die EFA-Berechtigungsregel beim Policy Provider.
  4. Verknüpfe consentInfo und consentDoc mit einer Partition (partitionID) der Fallakte.
  5. Ersetze (docRelationship) das bestehende consentInfo und consentDoc mit dem neuen consentInfo und consentDoc.
  6. Speichre und registriere consentInfo und consentDoc bei Document Repository und Document Registry.
  7. Gib statusInfo an den Aufrufer.
Fehler und Warnungen

Folgende Fehler müssen erkannt und rückgemeldet werden:

notifyOfConsent

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Enndn.01.01.08}

Operation notifyOfConsent
Funktionalität Benachrichtigt den EFA Ressource Manager über ein consentInfo-Dokument, das bei einem benachbarten EFA-Provider registriert wurde.
Aufrufer Ressource Manager einer benachbarten EFA-Provider-Domäne
Eingabe context Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext.
ecrRef Eindeutige Identifizierung der Fallakte, zu der eine neue Einwilligung vorliegt.
documentID Die Referenz des consentInfo-Dokuments.
Rückgabe
Vorbedingungen
Ablauf
  1. Rufe die Operation retrieveData des Document Repository auf, das im Eingabe-Parameter documentID referenziert ist.
  2. Identifiziere die Fallakte, die das abgerufene consentInfo-Dokument referenziert.
  3. Übersetze das consentInfo-Dokument in eine EFA-Berechtigungsregel.
  4. Passe die bestehende EFA-Berechtigungsregel beim Policy Provider an.
Fehler und Warnungen

Folgende Fehler müssen erkannt und zurückgemeldet werden:

  • Gemeinsame Fehler und Warnungen.
  • Der Eingabe-Parameter documentID referenziert kein consentInfo-Dokument.
  • Die im consentInfo-Dokument referenzierte Fallakte existiert nicht.

listRecordLocations

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Enndn.01.01.09}

Operation listRecordLocations
Funktionalität Listet die an einer Fallakte beteiligten EFA-Provider-Domänen auf.
Aufrufer Ressource Manager einer benachbarten EFA-Provider-Domäne
Eingabe context Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext.
ecrRef Referenziert die Fallakte, deren EFA-Provider-Domänen aufgelistet werden sollen.
Rückgabe MountPoint* Liste der Mount-Points
Vorbedingungen
Ablauf
  1. Gib die Liste der Mount-Points dem Aufrufer.
Fehler und Warnungen

Folgende Fehler müssen erkannt und zurückgemeldet werden:

  • Gemeinsame Fehler und Warnungen.
  • Der Sicherheitskontext enthält kein Access Policy Token, das von diesem EFA-Provider ausgestellt wurde.

registerRecordLocation

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Enndn.01.01.10}

Operation registerRecordLocation
Funktionalität Registriert eine EFA-Provider-Domäne als weiteren Speicherort für Partitionen einer Fallakte. Beim Aufrufer wurde ein Offline-Token eingereicht, das vom aufgerufenen EFA-Provider ausgestellten worden ist.
Aufrufer Ressource Manager der EFA-Provider-Domäne, in der das Offline-Token eingereicht wurde.
Eingabe context Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext.
MountPoint.sourcePatientId

MountPoint.patientId

MountPoint.purpose

Referenziert die Fallakte bei dem Peer, bei dem das Offline-Token eingereicht wurde. sourcePatientId ist die lokal gültige Patienten-ID. patientId ist die Patienten-ID, die in der Ziel-Provider-Domäne gültig ist.
MountPoint.communityID Kennung der lokalen EFA-Provider-Domäne, bei der das Offline-Token eingereicht wurde.
Rückgabe statusInfo Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
Vorbedingungen
Ablauf
  1. Verknüpfe und speichre den Eingabeparameter ecrRef mit der ecrRef-Instanz des accessPolicyToken.
Fehler und Warnungen

Folgende Fehler müssen erkannt und zurückgemeldet werden:

  • Gemeinsame Fehler und Warnungen.
  • Der Sicherheitskontext enthält kein Access Policy Token, das von diesem EFA-Provider ausgestellt wurde.

Operationen des EFA Document Registry

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Enndn.01.02}

Die EFA Document Registry muss die in diesem Abschnitt enthaltenen Operationen implementieren.

registerData

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Enndn.01.02.01}

Operation registerData
Funktionalität Diese Operation registriert von Daten an einer bestehenden Partition einer Fallakte.
Aufrufer Document Repository der gleichen EFA-Provider-Domäne. Die Absicherung der Kommunikation durch einen zwischen beiden Diensten gespannten Sicherheitskontext ist Aufgabe des EFA-Providers und kann mit EFA-unabhängigen Mechanismen realisiert werden.
Eingabe context Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext.
partitionID Eindeutige Identifizierung der Partition, an der die Daten registriert werden sollen.
docMetadata[1..*] Metadaten der bereits im Document Repository abgelegten Daten, die am Document Registry registriert werden sollen.
docRelationship[0..*] Beziehungen der neu zu registrierenden Daten zu bestehenden Dokumenten. Diese müssen so registriert werden, dass sie bei der Auflistung von Dokumenten mit bereit gestellt werden können.
Rückgabe statusInfo Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
Vorbedingungen
  • Die übergebenen Metadaten der einzustellenden Daten sind vollständig und valide.
  • Die Konfiguration der angesprochenen Akte erlaubt das Einstellen der übergebenen Dokumente.
Ablauf
  1. Speichre docMetadata, docRelationship und den Bezug zu partitionID.
  2. Gib das statusInfo-Objekt dem Aufrufer.
Fehler und Warnungen

Folgende Fehler müssen erkannt und rückgemeldet werden:

listPartitionContent

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Enndn.01.02.02}

Operation listPartitionContent
Funktionalität Diese Operation gibt die Liste der Dokumente, die in einer Partition enthalten sind, zurück. Die Liste enthält die Dokument-Metadaten und Dokument-Beziehungen.
Aufrufer
  • EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne,
  • Document Registry einer benachbarten EFA-Provider-Domäne
Eingabe context Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext.
partitionID Eindeutige Identifizierung der Partition, deren Inhalte ausgelesen werden sollen.
Rückgabe docMetadata[0..*] Metadaten der an der ausgewählten Partition registrierten Dokumente
docRelationship[0..*] Beziehungen zwischen den Dokumenten der zu listenden Partition und Dokumenten dieser und anderer Partitionen.
Vorbedingungen
Ablauf
  1. Identifiziere alle Dokumente,
    1. die mit partitionID verknüpft sind und
    2. für welche der Aufrufer (context) zugriffsberechtigt ist.
  2. Identifiziere alle Dokument-Beziehungen dieser Dokumente.
  3. Gib die Metadaten der Dokumente und deren Dokument-Beziehungen dem Aufrufer.
Fehler und Warnungen

Folgende Fehler müssen erkannt und rückgemeldet werden:

invalidateData

Operation invalidateData
Funktionalität Invalidieren eines Dokuments in einer Fallakte.
Aufrufer
  • EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne,
Eingabe context Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext.
documentID Eindeutige Identifizierung des zu invalidierenden Dokuments. Das zu invalidierende Dokument DARF NICHT vom Typ consentInfo oder consentDoc sein.
Rückgabe statusInfo Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
Vorbedingungen
Ablauf

Das Document Registry

  1. ... ändert den Wert des Attributs Status des Dokuments auf ungültig.
  2. ... sendet eine Information zum Ausführungsstatus der Operation an den Nutzer zurück.
Fehler und Warnungen

Folgende Fehler müssen erkannt und rückgemeldet werden:

Operationen des EFA Document Repository

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

Das EFA Document Repository muss die in diesem Abschnitt enthaltenen Operationen implementieren.

provideData

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Enndn.01.03.01}

Operation provideData
Funktionalität Diese Operation stellt Daten in eine Partition einer Fallakte ein.
Aufrufer EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne
Eingabe context Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext.
partitionID Eindeutige Identifizierung der Partition, in die die Daten eingestellt werden sollen.
document[1..*] In die Partition einzustellende Dokumente mitsamt ihrer Metadaten.
docRelationship[0..*] Beziehungen der neu zu registrierenden Daten zu bestehenden Dokumenten.
Rückgabe statusInfo Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
Vorbedingungen
  • Die übergebenen Metadaten der einzustellenden Daten sind vollständig und valide.
Ablauf
  1. Speichre die Dokument-Daten.
  2. Rufe die Operation registerData Operation des Document Registry der gleichen Community auf. Übergebe die Eingabeparameter dieser Operation.
  3. Gib das statusInfo-Objekt dem Aufrufer.
Fehler und Warnungen

Folgende Fehler müssen erkannt und rückgemeldet werden:

retrieveData

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Enndn.01.03.02}

Operation retrieveData
Funktionalität Abrufen von Daten aus einer Fallakte.
Aufrufer
  • EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne,
  • Ressource Manager einer benachbarten EFA-Provider-Domäne
Eingabe context Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext.
documentID Eindeutige Identifizierung der abzurufenden Dokumente
Rückgabe statusInfo Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
docData[0..n] angeforderte Dokumente
Vorbedingungen
Ablauf

Das Document Repository

  1. ... ruft die angefragten Dokumente aus dem sicheren Dokumentenspeicher ab.
  2. ... sendet eine Information zum Ausführungsstatus der Operation sie wie die angefragten Dokumente an den Nutzer zurück.
Fehler und Warnungen

Folgende Fehler müssen erkannt und rückgemeldet werden:



Information icon.svg Referenzen und Querverweise
Abgerufen von „https://wiki.hl7.de/index.php?title=cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)&oldid=28812“