EFA Anwendungsdienste (logische Spezifikation)

Aus Hl7wiki
Implementierungsleitfaden
Wechseln zu: Navigation, Suche
(Redundanz in der Beschreibung der Eingabe-Parameter entfernt.)
(Vorbedingungen, Fehler und Warnungen wurden entfernt, die bereits auf der Seite cdaefa:EFA_Fehlermeldungen_und_Warnungen definiert sind.)
Zeile 83: Zeile 83:
  
 
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:
 
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:
−
* 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 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 128: Zeile 123:
 
|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 stimmen mit den verfügbaren Informationen zum Besitzer der übergebenen Patienten-ID überein.
 
** Sofern ein Zweck benannt ist, stimmt dieser mit dem bei der EFA-Anlage benannten Zweck überein.
 
** Sofern ein Zweck benannt ist, stimmt dieser mit dem bei der EFA-Anlage benannten Zweck überein.
−
** 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.
+
** Die EFA Teilnehmer sind benannt.
 
** 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, 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).
 
|-
 
|-
Zeile 141: Zeile 133:
 
| colspan="2"|
 
| colspan="2"|
 
Der Ressource Manager ...
 
Der Ressource Manager ...
−
# ... verifiziert, dass die Vorbedingungen zur Ausführung der Operation erfüllt sind.
 
 
# ... erzeugt aus Patientenidentifikation und Zweckbenennung ein [[cdaefa:EFA_Business_Informationsmodell#ecrRef|ecrRef]]-Objekt für die neu anzulegende Fallakte
 
# ... erzeugt aus Patientenidentifikation und Zweckbenennung ein [[cdaefa:EFA_Business_Informationsmodell#ecrRef|ecrRef]]-Objekt für die neu anzulegende Fallakte
 
# ... 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.
 
# ... 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.
Zeile 155: Zeile 146:
 
| 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:
 
Über die in [[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]] definierten Ausnahmesituationen hinaus, sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:
−
* Der Aufrufer hat keine für die Anlage von Fallakten ausreichende vertragliche Vereinbarung mit dem EFA-Provider.
 
 
* Eine neue Akte kann nicht angelegt werden, da bereits eine Akte zum angegebenen Patienten und Zweck besteht.  
 
* Eine neue Akte kann nicht angelegt werden, da bereits eine Akte zum angegebenen Patienten und Zweck besteht.  
−
* 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:
 
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.
 
* 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 196: Zeile 183:
 
|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.
 
* Die Konfiguration der angesprochenen Akte erlaubt das Einstellen der ggf. übergebenen Dokumente.
Zeile 204: Zeile 189:
 
| colspan="2"|
 
| colspan="2"|
 
Der Ressource Manager ...
 
Der Ressource Manager ...
−
# ... verifiziert, dass die Vorbedingungen zur Ausführung der Operation erfüllt sind.
 
 
# ... legt eine neue Partition an und verknüpft diese mit dem übergebenen ecrRef-Objekt.
 
# ... legt eine neue Partition an und verknüpft diese mit dem übergebenen ecrRef-Objekt.
 
# ... stellt die ggf. übergebenen Dokumente in die neu erzeugte Partition ein.
 
# ... stellt die ggf. übergebenen Dokumente in die neu erzeugte Partition ein.
Zeile 213: Zeile 197:
 
| 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:
 
Über die in [[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]] definierten Ausnahmesituationen hinaus sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:
−
* Der Aufrufer hat keine für die Anlage von Partitionen 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.
 
 
* Die übergebene partitionInfo ist nicht vollständig oder nicht konsistent zu anderen Angaben.
 
* Die übergebene partitionInfo ist nicht vollständig oder nicht konsistent zu anderen Angaben.
 
Darüber hinaus sind die folgenden Warnungen definiert:
 
Darüber hinaus sind die folgenden Warnungen definiert:
 
* Eines oder mehrere der übergebenen Dokumente konnte nicht in der Partition abgelegt werden.
 
* Eines oder mehrere der übergebenen Dokumente konnte nicht in der Partition abgelegt werden.
 
|}
 
|}
−
 
  
 
==== ''closeECR'' ====
 
==== ''closeECR'' ====
Zeile 250: Zeile 231:
 
|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
 
|Ablaufsequenz
 
| colspan="2"|
 
| colspan="2"|
 
Der Ressource Manager ...
 
Der Ressource Manager ...
−
# ... verifiziert, dass die Vorbedingungen zur Ausführung der Operation erfüllt sind.
 
 
# ... ä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
 
# ... ä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
 
# ... stellt die Angaben zur Einwilligungsrücknahme und ein ggf. übergebenes Einwilligungsformular als Dokumente in eine Partition der Akte ein.  
 
# ... stellt die Angaben zur Einwilligungsrücknahme und ein ggf. übergebenes Einwilligungsformular als Dokumente in eine Partition der Akte ein.  
Zeile 266: Zeile 243:
 
| 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:
 
Über die in [[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]] definierten Ausnahmesituationen hinaus sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:
−
* 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 consentInfo ist nicht vollständig oder nicht konsistent zu anderen Angaben.
 
 
* Eines oder mehrere der übergebenen Dokumente konnten nicht in der Akte abgelegt werden.
 
* Eines oder mehrere der übergebenen Dokumente konnten nicht in der Akte abgelegt werden.
 
|}
 
|}
Zeile 300: Zeile 275:
 
|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)
 
|Ablaufsequenz (logisch)
 
| colspan="2"|
 
| colspan="2"|
 
Der Ressource Manager ...
 
Der Ressource Manager ...
−
# ... verifiziert, dass die Vorbedingungen zur Ausführung der Operation erfüllt sind.
 
 
# ... lokalisiert alle Partitionen, die mit dem angegebenen Patienten verknüpft sind und identifiziert die jeweils übergeordneten Fallakten.
 
# ... lokalisiert alle Partitionen, die mit dem angegebenen Patienten verknüpft sind und identifiziert die jeweils übergeordneten Fallakten.
 
# ... prüft für jede der gefundenen Fallakten, ob der Aufrufer ein berechtigter Teilnehmer der Akte ist.  
 
# ... prüft für jede der gefundenen Fallakten, ob der Aufrufer ein berechtigter Teilnehmer der Akte ist.  
Zeile 316: Zeile 288:
 
| 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:
 
Über die in [[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]] definierten Ausnahmesituationen hinaus sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:
−
* Die angegeben Patienten-ID kann nicht aufgelöst werden.
 
 
|}
 
|}
  
Zeile 349: Zeile 320:
 
| 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 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.
 
** Die Angaben zu den Rollen der Teilnehmer ermöglichen eine Zuordnung der Teilnehmer zu mit konkreten Zugriffsrechten hinterlegten EFA-Rollen.
 
|-
 
|-
Zeile 358: Zeile 327:
 
| colspan="2"|
 
| colspan="2"|
 
Der Ressource Manager ...
 
Der Ressource Manager ...
−
# ... verifiziert, dass die Vorbedingungen zur Ausführung der Operation erfüllt sind.
 
 
# ... bildet den Inhalt der Einwilligung auf ein Berechtigungsregelwerk ab und verknüpft dieses mit dem ecrRef-Objekt.
 
# ... bildet den Inhalt der Einwilligung auf ein Berechtigungsregelwerk ab und verknüpft dieses mit dem ecrRef-Objekt.
 
# ... lokalisiert die Partitionen der referenzierten Akte  
 
# ... lokalisiert die Partitionen der referenzierten Akte  
Zeile 370: Zeile 338:
 
| 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:
 
Über die in [[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]] definierten Ausnahmesituationen hinaus, sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:
−
* Der Aufrufer hat keine für die Anpassung von Fallakten ausreichende vertragliche Vereinbarung mit dem EFA-Provider.
+
* Der Zweck der Akte kann nicht geändert werden, da bereits eine Akte zum angegebenen Patienten und Zweck besteht.
−
* Die angegeben Fallakten-Referenz kann nicht aufgelöst werden bzw. der Aufrufer hat keine (ausreichenden) Berechtigungen, die angeforderte Operation auf dieser Akte auszuführen.
 
−
* 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.
 
 
|}
 
|}
  
Zeile 400: Zeile 364:
 
|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.
 
* 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)
 
|Ablaufsequenz (logisch)
 
| colspan="2"|
 
| colspan="2"|
 
Der Ressource Manager ...
 
Der Ressource Manager ...
−
# ... verifiziert, dass die Vorbedingungen zur Ausführung der Operation erfüllt sind.
 
 
# ... generiert einen Proof-Schlüssel (Geheimnis, etc.) anhand dessen beim Einreichen des Berechtigungstoken die Authentizität des Token validiert werden kann
 
# ... generiert einen Proof-Schlüssel (Geheimnis, etc.) anhand dessen beim Einreichen des Berechtigungstoken die Authentizität des Token validiert werden kann
 
# ... erzeugt ggf. eine Token-Redeem-Policy, die definiert, wer (Rolle, Fachbereich, etc.) das Token einreichen darf
 
# ... erzeugt ggf. eine Token-Redeem-Policy, die definiert, wer (Rolle, Fachbereich, etc.) das Token einreichen darf
Zeile 419: Zeile 380:
 
| 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:
 
Über die in [[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]] definierten Ausnahmesituationen hinaus, sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:
−
* 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 Einwilligung zu der Fallakte lässt keine Ad-Hoc-Autorisierungen über Berechtigungstoken zu.
 
* Die Einwilligung zu der Fallakte lässt keine Ad-Hoc-Autorisierungen über Berechtigungstoken zu.
 
|}
 
|}
Zeile 449: Zeile 409:
 
|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".
 
* Die Fallakte ist im Zustand "offen".
 
* Der Aufrufer verfügt über ein gültiges [[cdaefa:EFA_Business_Informationsmodell#accessToken|accessToken]]
 
* 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)
 
|Ablaufsequenz (logisch)
 
| colspan="2"|
 
| colspan="2"|
 
Der Ressource Manager ...
 
Der Ressource Manager ...
−
# ... 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 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
 
# ... validiert die Identitätsdaten des Einreichers gegen eine ggf. erzeugte Redeem-Policy, um sicherzustellen, dass der Einreicher dieses Token einlösen darf
Zeile 469: Zeile 426:
 
| 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:
 
Über die in [[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]] definierten Ausnahmesituationen hinaus, sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:
−
* 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.
 
* Die Einwilligung zu der Fallakte lässt keine Ad-Hoc-Autorisierungen über Berechtigungstoken zu.
 
* Die Redeem-Policy schließt den Einreicher von der Einlösung des Berechtigungstoken aus.
 
* Die Redeem-Policy schließt den Einreicher von der Einlösung des Berechtigungstoken aus.
Zeile 478: Zeile 434:
  
 
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:
 
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:
−
* 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.
 
* 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 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 513: Zeile 466:
 
|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
 
|Ablaufsequenz
 
| colspan="2"|
 
| colspan="2"|
 
Das Document Registry ...
 
Das Document Registry ...
−
# ... verifiziert, dass die Vorbedingungen zur Ausführung der Operation erfüllt sind.
 
 
# ... registriert die Metadaten und Dokumentbeziehungen an der angegebenen Partition.
 
# ... registriert die Metadaten und Dokumentbeziehungen an der angegebenen Partition.
 
# ... schreibt einen Audit Trail Eintrag über die erfolgreiche Durchführung der Operation
 
# ... schreibt einen Audit Trail Eintrag über die erfolgreiche Durchführung der Operation
Zeile 530: Zeile 479:
 
| 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:
 
Über die in [[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]] definierten Ausnahmesituationen hinaus, sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:
−
* Der Aufrufer hat keine für das Einstellen von Daten in Fallakten ausreichende vertragliche Vereinbarung mit dem EFA-Provider.
 
−
* 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 562: Zeile 507:
 
|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
 
|Ablaufsequenz
 
| colspan="2"|
 
| colspan="2"|
 
Das Document Registry ...
 
Das Document Registry ...
−
# ... verifiziert, dass die Vorbedingungen zur Ausführung der Operation erfüllt sind.
 
 
# ... ü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]])
 
# ... ü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]])
 
# ... schreibt einen Audit Trail Eintrag über die erfolgreiche Durchführung der Operation
 
# ... schreibt einen Audit Trail Eintrag über die erfolgreiche Durchführung der Operation
Zeile 575: Zeile 518:
 
| 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:
 
Über die in [[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]] definierten Ausnahmesituationen hinaus, sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:
−
* 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.
 
 
|}
 
|}
  
Zeile 582: Zeile 524:
  
 
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:
 
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 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.
 
* 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 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 617: Zeile 556:
 
|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
 
|Ablaufsequenz
 
| colspan="2"|
 
| colspan="2"|
 
Das Document Repository  
 
Das Document Repository  
−
# ... stellt sicher, dass die Vorbedingungen erfüllt sind.
 
 
# ... legt alle übergebenen Dokumente in einem sicheren Dokumentenspeicher ab.
 
# ... legt alle übergebenen Dokumente in einem sicheren Dokumentenspeicher ab.
 
# ... initiert die [[cdaefa:EFA_Document_Registry_SFM|registerData]] Operation mit den übergebenen Metadaten und Beziehungen beim Document Registry.
 
# ... initiert die [[cdaefa:EFA_Document_Registry_SFM|registerData]] Operation mit den übergebenen Metadaten und Beziehungen beim Document Registry.
Zeile 634: Zeile 569:
 
| 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:
 
Über die in [[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]] definierten Ausnahmesituationen hinaus, sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:
−
* Der Aufrufer hat keine für das Einstellen von Daten in Fallakten ausreichende vertragliche Vereinbarung mit dem EFA-Provider.
+
 
−
* 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 666: Zeile 598:
 
|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
 
|Ablaufsequenz
 
| 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.
 
# ... schreibt einen Audit Trail Eintrag über die Ausführung der Operation.
Zeile 680: Zeile 609:
 
| 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:
 
Über die in [[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]] definierten Ausnahmesituationen hinaus, sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:
−
* 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-Referenzen konnten nicht aufgelöst werden.
 
 
|}
 
|}
  

Version vom 5. März 2014, 19:45 Uhr

Logo-hl720.jpg
EFA Anwendungsdienste (logische Spezifikation)
EFA Anwendungsdienste (logische Spezifikation)
Implementierungsleitfaden
vorgelegt von:
February 2013
Jörg Caumanns, Raik Kuhlisch
Draft
Version: 0.9
Datum: March 2013
Status: xxx
Verfahren: {{{Verfahren}}}
Realm: Flag de.svg Deutschland
Copyright © 2012-2013: HL7 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.
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
Anfordern eines Berechtigungstoken issueAccessToken EFA Ressource Manager
Einlösen eines Berechtigungstoken redeemAccessToken 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

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

EFA AppArch Transaktionen.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.

Operationen des EFA Ressource Manager

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

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 vom Teilnehmersystem übermittelte Sicherheitskontext ist gültig, vollständig, authentisch und wurde von einer vertrauenswürdigen Stelle für Aufrufer ausgestellt.

createECR

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

Operation createECR
Funktionalität 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.
Eingabe context Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext.
ecrInfo Identifizierende und beschreibende Daten zur anzulegenden Fallakte.
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.
ecrStatus
muss bei der Neuanlage einer EFA immer "offen" sein.
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 stimmen mit den verfügbaren Informationen zum Besitzer der übergebenen Patienten-ID überein.
    • Sofern ein Zweck benannt ist, stimmt dieser mit dem bei der EFA-Anlage benannten Zweck überein.
    • Es ist ein Gültigkeitsdatum benannt.
    • Die EFA Teilnehmer sind benannt.
    • 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).
Ablaufsequenz (logisch)

Der Ressource Manager ...

  1. ... erzeugt aus Patientenidentifikation und Zweckbenennung ein ecrRef-Objekt für die neu anzulegende Fallakte
  2. ... 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.
  3. ... legt eine neue Partition an und verknüpft diese mit dem ecrRef-Objekt.
  4. ... bildet den Inhalt der Einwilligung auf ein Berechtigungsregelwerk ab und verknüpft dieses mit dem ecrRef-Objekt.
  5. ... stellt die Angaben zur Einwilligung und ein ggf. übergebenes Einwilligungsformular als Dokumente in die neu erzeugte Partition ein.
  6. bei Überführung einer bestehenden Akte: ... lokalisiert die Partitionen der zu überführenden Akte und verknüpft diese mit dem neuen ecrRef-Objekt.
  7. 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.
  8. ... schreibt einen Audit Trail Eintrag über die erfolgreiche Durchführung der Operation
  9. ... 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

Über die in Fehlermeldungen und Warnungen definierten Ausnahmesituationen hinaus, sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:

  • Eine neue Akte kann nicht angelegt werden, da bereits eine Akte zum angegebenen Patienten und Zweck besteht.

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.

createPartition

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

Operation createPartition
Funktionalität Anlegen einer neuen Partition zu einer bestehenden Fallakte.
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.
  • Die Konfiguration der angesprochenen Akte erlaubt das Einstellen der ggf. übergebenen Dokumente.
Ablaufsequenz (logisch)

Der Ressource Manager ...

  1. ... legt eine neue Partition an und verknüpft diese mit dem übergebenen ecrRef-Objekt.
  2. ... stellt die ggf. übergebenen Dokumente in die neu erzeugte Partition ein.
  3. ... schreibt einen Audit Trail Eintrag über die erfolgreiche Durchführung der Operation
  4. ... 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

Über die in Fehlermeldungen und Warnungen definierten Ausnahmesituationen hinaus sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:

  • 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

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

Operation closeECR
Funktionalität Schließen einer bestehenden Fallakte. Die Fallakte geht damit in den "Grace"-Status über.
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
Ablaufsequenz

Der Ressource Manager ...

  1. ... ä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
  2. ... stellt die Angaben zur Einwilligungsrücknahme und ein ggf. übergebenes Einwilligungsformular als Dokumente in eine Partition der Akte ein.
  3. ... schreibt einen Audit Trail Eintrag über die erfolgreiche Durchführung der Operation
  4. ... liefert einen Statuscode zur erfolgreichen Ausführung der Operation an das aufrufende System zurück
Fehler und Warnungen

Über die in Fehlermeldungen und Warnungen definierten Ausnahmesituationen hinaus sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:

  • Eines oder mehrere der übergebenen Dokumente konnten nicht in der Akte abgelegt werden.

listPartitions

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

Operation listPartitions
Funktionalität 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.
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 (optional) 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
Ablaufsequenz (logisch)

Der Ressource Manager ...

  1. ... lokalisiert alle Partitionen, die mit dem angegebenen Patienten verknüpft sind und identifiziert die jeweils übergeordneten Fallakten.
  2. ... prüft für jede der gefundenen Fallakten, ob der Aufrufer ein berechtigter Teilnehmer der Akte ist.
  3. ... stellt die Metadaten der Partitionen dieser Akten zur Ergebnisstruktur dieser Operation zusammen.
  4. ... schreibt einen Audit Trail Eintrag über die erfolgreiche Durchführung der Operation
  5. ... liefert einen Statuscode zur erfolgreichen Ausführung der Operation sowie die Metadaten der gefundenen Partitionen an das aufrufende System zurück
Fehler und Warnungen

Über die in Fehlermeldungen und Warnungen definierten Ausnahmesituationen hinaus sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:

registerConsent

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

Operation registerConsent
Funktionalität 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.
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 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.
consentDoc (optional) Eine ggf. verfügbare elektronische Version des Einwilligungsdokuments kann im Rahmen dieser Operation zur Ablage in der Akte ü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)
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.
Ablaufsequenz (logisch)

Der Ressource Manager ...

  1. ... bildet den Inhalt der Einwilligung auf ein Berechtigungsregelwerk ab und verknüpft dieses mit dem ecrRef-Objekt.
  2. ... lokalisiert die Partitionen der referenzierten Akte
  3. ... 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.
  4. ... stellt die Angaben zur Einwilligung und ein ggf. übergebenes Einwilligungsformular als Dokumente in eine Partition der referenzierten Akte ein.
  5. ... erzeugt eine "Ersetzt"-Verknüpfung zwischen der neuen Einwilligung und der für die bestehende Akte zuletzt gültigen Einwilligung.
  6. ... schreibt einen Audit Trail Eintrag über die erfolgreiche Durchführung der Operation
  7. ... liefert einen Statuscode zur erfolgreichen Ausführung der Operation an das aufrufende System zurück
Fehler und Warnungen

Über die in Fehlermeldungen und Warnungen definierten Ausnahmesituationen hinaus, sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:

  • Der Zweck der Akte kann nicht geändert werden, da bereits eine Akte zum angegebenen Patienten und Zweck besteht.

issueAccessToken

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

Operation issueAccessToken
Funktionalität 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.
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 ein Berechtigungstoken abgerufen werden soll.
Rückgabe accessToken Berechtigungstoken, dessen Einlösung den einlösenden Leistungserbringer zum Zugriff auf eine Fallakte berechtigt.
Vorbedingungen
  • Die bestehende Einwilligung der Fallakte lässt die Nutzung von Berechtigungstoken zu.
Ablaufsequenz (logisch)

Der Ressource Manager ...

  1. ... generiert einen Proof-Schlüssel (Geheimnis, etc.) anhand dessen beim Einreichen des Berechtigungstoken die Authentizität des Token validiert werden kann
  2. ... erzeugt ggf. eine Token-Redeem-Policy, die definiert, wer (Rolle, Fachbereich, etc.) das Token einreichen darf
  3. ... erzeugt eine Token-Access-Policy, die definiert, welche Berechtigungen an den Einreicher des Tokens vergeben werden
  4. ... kapselt Informationen zur Fallakte und Proof-Schlüssel in einem Berechtigungstoken (accessToken-Objekt)
  5. ... registriert das erzeugte accessToken mitsamt Proof-Schlüssel und zugehörigen Poicies (z.B. im Policy Provider)
  6. ... schreibt einen Audit Trail Eintrag über die erfolgreiche Durchführung der Operation
  7. ... liefert ein Berechtigungstoken an das aufrufende System zurück
Fehler und Warnungen

Über die in Fehlermeldungen und Warnungen definierten Ausnahmesituationen hinaus, sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:

  • Die Einwilligung zu der Fallakte lässt keine Ad-Hoc-Autorisierungen über Berechtigungstoken zu.

redeemAccessToken

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

Operation redeemAccessToken
Funktionalität 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.
Eingabe context Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext.
patientID Die ID des Patienten in der Affinity Domain des Arztes, der das Token einreicht.
accessToken Über die Operation issueAccessToken ausgestelltes Berechtigungstoken, mit dem der Einreicher als Teilnehmer an der im Token kodierten Fallakte registriert werden soll.
Rückgabe subjectAccessPolicy Berechtigungspolicy für den neuen EFA-Teilnehmer. Die Berechtigungspolicy kann von dem Teilnehmer über das Client-Policy-Push Verfahren unmittelbar zum Zugriff auf die Akte genutzt werden.
Vorbedingungen
  • Die Fallakte ist im Zustand "offen".
  • Der Aufrufer verfügt über ein gültiges accessToken
Ablaufsequenz (logisch)

Der Ressource Manager ...

  1. ... validiert den im Token kodierten Proof-Schlüssel (Geheimnis, etc.) um die Authentizität des Tokens sicherzustellen
  2. ... validiert die Identitätsdaten des Einreichers gegen eine ggf. erzeugte Redeem-Policy, um sicherzustellen, dass der Einreicher dieses Token einlösen darf
  3. ... verknüpft Fallakte und ID des Einreichers mit der hinterlegten Token-Access-Policy, die definiert, welche Berechtigungen an den Einreicher des Tokens vergeben werden
  4. ... registriert die erzeugte Policy am Policy Provider
  5. ... ruft vom Policy Provider die gültige subjectAccessPolicy des Einreichers ab
  6. ... schreibt einen Audit Trail Eintrag über die erfolgreiche Durchführung der Operation
  7. ... liefert die subjectAccessPolicy an das aufrufende System zurück
Fehler und Warnungen

Über die in Fehlermeldungen und Warnungen definierten Ausnahmesituationen hinaus, sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:

  • Die Einwilligung zu der Fallakte lässt keine Ad-Hoc-Autorisierungen über Berechtigungstoken zu.
  • Die Redeem-Policy schließt den Einreicher von der Einlösung des Berechtigungstoken aus.

Operationen des EFA Document Registry

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

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:

  • 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 context übermittelten Daten sicher identifizieren und authentifizieren.

registerData

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

Operation registerData
Funktionalität Registrieren von Daten an einer bestehenden Partition einer Fallakte.
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.
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.
Ablaufsequenz

Das Document Registry ...

  1. ... registriert die Metadaten und Dokumentbeziehungen an der angegebenen Partition.
  2. ... schreibt einen Audit Trail Eintrag über die erfolgreiche Durchführung der Operation
  3. ... liefert einen Statuscode zur erfolgreichen Ausführung der Operation zurück
Fehler und Warnungen

Über die in Fehlermeldungen und Warnungen definierten Ausnahmesituationen hinaus, sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:

listPartitionContent

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

Operation listPartitionContent
Funktionalität Abruf der Metadaten zu den an einer Partition einer Fallakte registrierten Dokumenten.
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
Ablaufsequenz

Das Document Registry ...

  1. ... ü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 Sonderrollen von EFA-Teilnehmern)
  2. ... schreibt einen Audit Trail Eintrag über die erfolgreiche Durchführung der Operation
  3. ... liefert einen Statuscode zur erfolgreichen Ausführung der Operation sowie die Metadaten der an der Partition registrierten Dokumente zurück
Fehler und Warnungen

Über die in Fehlermeldungen und Warnungen definierten Ausnahmesituationen hinaus, sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:

Operationen des EFA Document Repository

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

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:

  • 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 context übermittelten Daten sicher identifizieren und authentifizieren.

provideData

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

Operation provideData
Funktionalität Einstellen von Daten in eine bestehende Partition einer Fallakte.
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.
Ablaufsequenz

Das Document Repository

  1. ... legt alle übergebenen Dokumente in einem sicheren Dokumentenspeicher ab.
  2. ... initiert die registerData Operation mit den übergebenen Metadaten und Beziehungen beim Document Registry.
  3. ... schreibt einen Audit Trail Eintrag über die Ausführung der Operation.
  4. ... sendet eine Information zum Ausführungsstatus der Operation an den Nutzer zurück.
Fehler und Warnungen

Über die in Fehlermeldungen und Warnungen definierten Ausnahmesituationen hinaus, sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:

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

Das Document Repository

  1. ... ruft die angefragten Dokumente aus dem sicheren Dokumentenspeicher ab.
  2. ... schreibt einen Audit Trail Eintrag über die Ausführung der Operation.
  3. ... sendet eine Information zum Ausführungsstatus der Operation sie wie die angefragten Dokumente an den Nutzer zurück.
Fehler und Warnungen

Über die in Fehlermeldungen und Warnungen definierten Ausnahmesituationen hinaus, sind für diese Operation die folgenden spezifischen Fehlermeldungen definiert:

Querverweise und Referenzen

Abgerufen von „https://wiki.hl7.de/index.php?title=cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)&oldid=17445“