EFA Anwendungsdienste (logische Spezifikation)

Aus Hl7wiki
Implementierungsleitfaden
Wechseln zu: Navigation, Suche
Zeile 15: Zeile 15:
 
}}
 
}}
  
−
Eine Fallakten-Infrastruktur besteht im einfachsten Fall aus drei Klassen von Akteuren:
 
−
* Ein EFA-Register (eCR Registry) stellt die Verzeichnisse zur Verwaltung von Fallakten und darin enthaltenen Dokumenten bereit. In einem regionalen Gesundheitsnetz kann ein einzelner EFA-Teilnehmer das EFA-Register für das gesamte Netzwerk anbieten.
 
−
* Ein EFA-Speichersystem (eCR Repository) hält die registrierten Dokumente vor und stellt sie für berechtigte Nutzer zum Abruf bereit. Jeder EFA-Teilnehmer kann ein eigenes EFA-Speichersystem bereitstellen und an das EFA-Register anbinden.
 
−
* Ein EFA-Teilnehmersystem (eCR Consumer) bildet eine Nutzerschnittstelle ab, über die ein Arzt Behandlungsdaten anderer Ärzte aus an einem EFA-Register registrierten Speichersystemen abrufen kann bzw. in einem Speichersystem verwaltete Behandlungsdaten am EFA-Register registrieren kann.
 
  
−
Im einfachsten Fall sind die EFA-Speichersysteme über bestehende Datenspeicher bei den EFA-Teilnehmern realisiert, d. h. das EFA-Register vermittelt den EFA-Teilnehmern lediglich einen gegenseitigen, stark reglementierten und geschützten Zugang zu bestehenden IT-Systemen.
+
== Operationen des EFA Ressource Manager ==
  
−
Niedergelassene Ärzte verfügen jedoch in den meisten Fällen nicht über die technischen Möglichkeiten, um ein EFA-Speichersystem sicher und wirtschaftlich in eigener Regie und innerhalb der eigenen IT-Infrastruktur zu betreiben. Aus diesem Grund verfügt die EFA über die Möglichkeit, dass ein EFA-Teilnehmer im Rahmen der Registrierung von Daten an einem EFA-Register diese Daten auch gleichzeitig in das EFA-Speichersystem des Register-Betreibers kopieren kann.  
+
Die nachfolgende Tabelle listet die vom EFA Ressource Manager (''ECR Resource Manager'') bereit gestellten Operationen sowie die damit realisierbaren [[cdaefa:EFA_Kommunikationsmuster|Kommunikationsmuster]].
  
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!Operation
 +
!Kommunikationsmuster
 +
|-
 +
|createECR
 +
|[[cdaefa:EFA_Kommunikationsmuster#Anlegen_einer_Fallakte|Anlegen einer Fallakte]]
 +
|-
 +
|createPartition
 +
|[[cdaefa:EFA_Kommunikationsmuster#Anlegen_einer_Partition_zu_einer_bestehenden_Fallakte|Anlegen einer Partition zu einer bestehenden Fallakte]]
 +
|-
 +
|closeECR
 +
|[[cdaefa:EFA_Kommunikationsmuster#Schließen_einer_Fallakte|Schließen einer Fallakte]]
 +
|-
 +
|listPartitions
 +
|[[cdaefa:EFA_Kommunikationsmuster#Auflisten_von_Partitionen|Auflisten von Partitionen]]
 +
|-
 +
|registerConsent
 +
|[[cdaefa:EFA_Kommunikationsmuster#Registrierung_einer_neuen_Einwilligung|Registrierung einer neuen Einwilligung]]
 +
|}
  
−
----
+
In den folgenden Abschnitten werden diese Operationen plattform-unabhängig über das ''Service Functional Model'' des EFA Ressource Managers spezifiziert.
  
−
* zurück zur [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]
+
== ''createECR'' ==
 +
 
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!Operation
 +
! colspan="2"|createECR
 +
|-
 +
|Funktionalität
 +
| 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 und die neu hinzu kommenden Behandlungsteilnehmer erweitert.
 +
|-
 +
| rowspan="6"|Eingabe
 +
|[[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.
 +
|-
 +
|[[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.
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#ecrInfo|ecrInfo]]
 +
|Beschreibende Daten zur anzulegenden Fallakte bzw. der für die Fallakte angelegten initialen Partition (falls das genutzte ''Binding'' keine expliziten Akten-Objekte erlaubt, werden diese Metadaten an die initial für die Akte angelegte Partition gebunden).
 +
|-
 +
|[[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.
 +
|-
 +
|[[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.
 +
|-
 +
| rowspan="2"|Rückgabe
 +
|statusInfo
 +
|Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#partitionID|partitionID]]
 +
|Eindeutige ID der Partition, die entweder als initiale Partition für einen neue Fallakte angelegt wurde oder zu einer bereits bestehenden Fallakte hinzugefügt wurde.
 +
|-
 +
|Vorbedingungen
 +
| colspan="2"|
 +
* prec1
 +
* prec2
 +
|-
 +
|Ablaufsequenz
 +
| colspan="2"|
 +
# seq1
 +
# seq2
 +
|-
 +
|Mögliche Fehler
 +
|name
 +
|descr
 +
|}
 +
 
 +
== ''createPartition'' ==
 +
 
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!Operation
 +
! colspan="2"|createPartition
 +
|-
 +
|Funktionalität
 +
| colspan="2"|Anlegen einer neuen Partition zu einer bestehenden Fallakte.
 +
|-
 +
| rowspan="4"|Eingabe
 +
|[[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.
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#ecrRef|ecrRef]]
 +
|Eindeutige Identifizierung der Fallakte, zu der die Partition hinzugefügt werden soll.
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#partitionInfo|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.
 +
|-
 +
| rowspan="2"|Rückgabe
 +
|statusInfo
 +
|Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#partitionID|partitionID]]
 +
|Eindeutige ID der neu angelegten Partition.
 +
|-
 +
|Vorbedingungen
 +
| colspan="2"|
 +
* prec1
 +
* prec2
 +
|-
 +
|Ablaufsequenz
 +
| colspan="2"|
 +
# seq1
 +
# seq2
 +
|-
 +
|Mögliche Fehler
 +
|name
 +
|descr
 +
|}
 +
 
 +
== ''closeECR'' ==
 +
 
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!Operation
 +
! colspan="2"|closeECR
 +
|-
 +
|Funktionalität
 +
| colspan="2"|Schließen einer bestehenden Fallakte. Die Fallakte geht damit in den "Grace"-Status über.
 +
|-
 +
| rowspan="4"|Eingabe
 +
|[[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.
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#ecrRef|ecrRef]]
 +
|Eindeutige Identifizierung der Fallakte, die geschlossen werden soll.
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#consentInfo|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
 +
| colspan="2"|
 +
* prec1
 +
* prec2
 +
|-
 +
|Ablaufsequenz
 +
| colspan="2"|
 +
# seq1
 +
# seq2
 +
|-
 +
|Mögliche Fehler
 +
|name
 +
|descr
 +
|}
 +
 
 +
== ''listPartitions'' ==
 +
 
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!Operation
 +
! colspan="2"|listPartitions
 +
|-
 +
|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.
 +
|-
 +
| rowspan="3"|Eingabe
 +
|[[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.
 +
|-
 +
|[[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).
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#purpose|purpose]] (optional)
 +
|Einschränkung der Suche auf Akten und Partitionen, die zu einem bestimmten Zweck angelegt wurden.
 +
|-
 +
| rowspan="2"|Rückgabe
 +
|statusInfo
 +
|Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#partitionList|partitionList]]
 +
|Liste von nach übergeordneten Fallakten strukturierten Partitionen des Patienten, die im Ergebnis der Suchanfrage gefunden wurden.
 +
|-
 +
|Vorbedingungen
 +
| colspan="2"|
 +
* prec1
 +
* prec2
 +
|-
 +
|Ablaufsequenz
 +
| colspan="2"|
 +
# seq1
 +
# seq2
 +
|-
 +
|Mögliche Fehler
 +
|name
 +
|descr
 +
|}
 +
 
 +
== ''registerConsent'' ==
 +
 
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!Operation
 +
! colspan="2"|registerConsent
 +
|-
 +
|Funktionalität
 +
| 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.
 +
|-
 +
| rowspan="4"|Eingabe
 +
|[[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.
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#ecrRef|ecrRef]]
 +
|Eindeutige Identifizierung der Fallakte, zu der eine neue Einwilligung vorliegt.
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#consentInfo|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
 +
| colspan="2"|
 +
* prec1
 +
* prec2
 +
|-
 +
|Ablaufsequenz
 +
| colspan="2"|
 +
# seq1
 +
# seq2
 +
|-
 +
|Mögliche Fehler
 +
|name
 +
|descr
 +
|}
 +
 
 +
 
 +
== Operationen des EFA Document Registry==
 +
 
 +
Die nachfolgende Tabelle listet die vom EFA Document Registry (''ECR Document Registry'') bereit gestellten Operationen sowie die damit realisierbaren [[cdaefa:EFA_Kommunikationsmuster|Kommunikationsmuster]].
 +
 
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!Operation
 +
!Kommunikationsmuster
 +
|-
 +
|registerData
 +
|[[cdaefa:EFA_Kommunikationsmuster#Einstellen_von_Dokumenten|Einstellen von Dokumenten]]
 +
|-
 +
|listData
 +
|[[cdaefa:EFA_Kommunikationsmuster#Auflisten_von_Dokumenten|Auflisten von Dokumenten]]
 +
|}
 +
 
 +
In den folgenden Abschnitten werden diese Operationen plattform-unabhängig über das ''Service Functional Model'' des EFA Document Registry spezifiziert.
 +
 
 +
== ''registerData'' ==
 +
 
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!Operation
 +
! colspan="2"|registerData
 +
|-
 +
|Funktionalität
 +
| 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.'' 
 +
|-
 +
| rowspan="4"|Eingabe
 +
|[[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.
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#partitionID|partitionID]]
 +
|Eindeutige Identifizierung der Partition, an der die Daten registriert werden sollen.
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#docMatadata|docMetadata]][1..*]
 +
|Metadaten der bereits im Document Repository abgelegten Daten, die am Document Registry registriert werden sollen.
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#docRelationship|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
 +
| colspan="2"|
 +
* prec1
 +
* prec2
 +
|-
 +
|Ablaufsequenz
 +
| colspan="2"|
 +
# seq1
 +
# seq2
 +
|-
 +
|Mögliche Fehler
 +
|name
 +
|descr
 +
|}
 +
 
 +
== ''listData'' ==
 +
 
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!Operation
 +
! colspan="2"|listData
 +
|-
 +
|Funktionalität
 +
| colspan="2"|Abruf der Metadaten zu den an einer Partition einer Fallakte registrierten Dokumenten. 
 +
|-
 +
| rowspan="2"|Eingabe
 +
|[[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.
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#partitionID|partitionID]]
 +
|Eindeutige Identifizierung der Partition, deren Inhalte ausgelesen werden sollen.
 +
|-
 +
| rowspan="2"|Rückgabe
 +
|[[cdaefa:EFA_Business_Informationsmodell#docMetadata|docMetadata]][0..*]
 +
|Metadaten der an der ausgewählten Partition registrierten Dokumente
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#docRelationship|docRelationship]][0..*]
 +
|Beziehungen zwischen den  Dokumenten der zu listenden Partition und Dokumenten dieser und anderer Partitionen.
 +
|-
 +
|Vorbedingungen
 +
| colspan="2"|
 +
* prec1
 +
* prec2
 +
|-
 +
|Ablaufsequenz
 +
| colspan="2"|
 +
# seq1
 +
# seq2
 +
|-
 +
|Mögliche Fehler
 +
|name
 +
|descr
 +
|}
 +
 
 +
== Operationen des EFA Document Repository ==
 +
 
 +
Die nachfolgende Tabelle listet die vom EFA Document Repository (''ECR Document Repository'') bereit gestellten Operationen sowie die damit realisierbaren [[cdaefa:EFA_Kommunikationsmuster|Kommunikationsmuster]].
 +
 
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!Operation
 +
!Kommunikationsmuster
 +
|-
 +
|provideData
 +
|[[cdaefa:EFA_Kommunikationsmuster#Einstellen_von_Dokumenten|Einstellen von Dokumenten]]
 +
|-
 +
|retrieveData
 +
|[[cdaefa:EFA_Kommunikationsmuster#Abrufen_von_Dokumenten|Abrufen von Dokumenten]]
 +
|}
 +
 
 +
In den folgenden Abschnitten werden diese Operationen plattform-unabhängig über das ''Service Functional Model'' des EFA Document Repository spezifiziert.
 +
 
 +
== ''provideData'' ==
 +
 
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!Operation
 +
! colspan="2"|provideData
 +
|-
 +
|Funktionalität
 +
| colspan="2"|Einstellen von Daten in eine bestehende Partition einer Fallakte.
 +
|-
 +
| rowspan="4"|Eingabe
 +
|[[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.
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#partitionID|partitionID]]
 +
|Eindeutige Identifizierung der Partition, in die die Daten eingestellt werden sollen.
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#document|document]][1..*]
 +
|In die Partition einzustellende Dokumente mitsamt ihrer Metadaten.
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#docRelationship|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
 +
| colspan="2"|
 +
* Der Sicherheitskontext ist gültig und vollständig. Die Angaben zur Nutzeridentität sind authentisch.
 +
* Die Ziel-Partition ist einer Fallakte zugeordnet.
 +
* Für die mit der Ziel-Partition verbundene Akte (Zweckbindung) sind zum Aktenzugang berechtigte Teilnehmer und deren Rollen definiert. Der Nutzer ist berechtigter Teilnehmer. Die Teilnehmerrolle berechtigt zum Einstellen von Daten in die Akte.
 +
* Der Nutzer ist berechtigt, bei dem EFA-Provider, der die Partition verwaltet, Daten einzustellen.
 +
* Die Metadaten der einzustellenden Dokumente sind vollständig und valide.
 +
* Sofern bestehende Dokumente aktualisiert oder ergänzt werden: Die Ziele der Dokumentbeziehungen sind valide.
 +
|-
 +
|Ablaufsequenz
 +
| colspan="2"|
 +
# Das Document Repository stellt sicher, dass die Vorbedingungen erfüllt sind.
 +
# Das Document Repository legt alle übergebenen Dokumente in einem sicheren Dokumentenspeicher ab.
 +
# Das Document Repository initiert die [[cdaefa:EFA_Document_Registry_SFM|registerData]] Operation mit den übergebenen Metadaten und Beziehungen beim Document Registry.
 +
# Das Document Repository schreibt einen Audit Trail Eintrag über die Ausführung der Operation.
 +
# Das Document Repository sendet eine Information zum Ausführungsstatus der Operation an den Nutzer zurück.
 +
|-
 +
| rowspan="4"|Mögliche, für diese Operation spezifische Fehler
 +
|unbekannte Partition
 +
|Die angegebene Ziel-Partition ist nicht existent, keine EFA-Partition oder für den Nutzer nicht zugreifbar.
 +
|-
 +
|Unvollständige Metadaten
 +
|Die übergebenen Metadaten sind nicht vollständig (z.B. weil ein verpflichtendes Datenfeld nicht belegt ist). In der Fehlermeldung sollen die Dokumente benannte werden, deren Metadaten unvollständig sind.
 +
|-
 +
|Invalide Metadaten
 +
|In den Metadaten werden Vorgaben zu den zu verwendenden Codesystemen verletzt. In der Fehlermeldung sollen die Dokumente benannte werden, deren Metadaten falsch kodiert sind.
 +
|-
 +
|Invalide Objektreferenzen
 +
|In Dokumentenbeziehungen referenzierte Dokumente existieren nicht oder sind nicht Bestandteil der Fallakte.
 +
|}
 +
 
 +
== ''retrieveData'' ==
 +
 
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!Operation
 +
! colspan="2"|retrieveData
 +
|-
 +
|Funktionalität
 +
| colspan="2"|Abrufen von Daten aus einer Fallakte.
 +
|-
 +
| rowspan="2"|Eingabe
 +
|[[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.
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#documentID|documentID]]
 +
|Eindeutige Identifizierung der abzurufenden Dokumente
 +
|-
 +
| rowspan="2"|Rückgabe
 +
|statusInfo
 +
|Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#docData|docData]][0..n]
 +
|angeforderte Dokumente
 +
|-
 +
|Vorbedingungen
 +
| colspan="2"|
 +
* prec1
 +
* prec2
 +
|-
 +
|Ablaufsequenz
 +
| colspan="2"|
 +
# seq1
 +
# seq2
 +
|-
 +
|Mögliche Fehler
 +
|name
 +
|descr
 +
|}
 +
=== Querverweise und Referenzen ===
 +
 
 +
* [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]

Version vom 21. April 2013, 09:53 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


Operationen des EFA Ressource Manager

Die nachfolgende Tabelle listet die vom EFA Ressource Manager (ECR Resource Manager) bereit gestellten Operationen sowie die damit realisierbaren Kommunikationsmuster.

Operation Kommunikationsmuster
createECR Anlegen einer Fallakte
createPartition Anlegen einer Partition zu einer bestehenden Fallakte
closeECR Schließen einer Fallakte
listPartitions Auflisten von Partitionen
registerConsent Registrierung einer neuen Einwilligung

In den folgenden Abschnitten werden diese Operationen plattform-unabhängig über das Service Functional Model des EFA Ressource Managers spezifiziert.

createECR

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 und die neu hinzu kommenden Behandlungsteilnehmer erweitert.
Eingabe 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.
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).
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.
ecrInfo Beschreibende Daten zur anzulegenden Fallakte bzw. der für die Fallakte angelegten initialen Partition (falls das genutzte Binding keine expliziten Akten-Objekte erlaubt, werden diese Metadaten an die initial für die Akte angelegte Partition gebunden).
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.
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 Partition, die entweder als initiale Partition für einen neue Fallakte angelegt wurde oder zu einer bereits bestehenden Fallakte hinzugefügt wurde.
Vorbedingungen
  • prec1
  • prec2
Ablaufsequenz
  1. seq1
  2. seq2
Mögliche Fehler name descr

createPartition

Operation createPartition
Funktionalität Anlegen einer neuen Partition zu einer bestehenden Fallakte.
Eingabe 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.
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.
Vorbedingungen
  • prec1
  • prec2
Ablaufsequenz
  1. seq1
  2. seq2
Mögliche Fehler name descr

closeECR

Operation closeECR
Funktionalität Schließen einer bestehenden Fallakte. Die Fallakte geht damit in den "Grace"-Status über.
Eingabe 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.
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
  • prec1
  • prec2
Ablaufsequenz
  1. seq1
  2. seq2
Mögliche Fehler name descr

listPartitions

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 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.
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).
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
  • prec1
  • prec2
Ablaufsequenz
  1. seq1
  2. seq2
Mögliche Fehler name descr

registerConsent

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 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.
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
  • prec1
  • prec2
Ablaufsequenz
  1. seq1
  2. seq2
Mögliche Fehler name descr


Operationen des EFA Document Registry

Die nachfolgende Tabelle listet die vom EFA Document Registry (ECR Document Registry) bereit gestellten Operationen sowie die damit realisierbaren Kommunikationsmuster.

Operation Kommunikationsmuster
registerData Einstellen von Dokumenten
listData Auflisten von Dokumenten

In den folgenden Abschnitten werden diese Operationen plattform-unabhängig über das Service Functional Model des EFA Document Registry spezifiziert.

registerData

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 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.
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
  • prec1
  • prec2
Ablaufsequenz
  1. seq1
  2. seq2
Mögliche Fehler name descr

listData

Operation listData
Funktionalität Abruf der Metadaten zu den an einer Partition einer Fallakte registrierten Dokumenten.
Eingabe 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.
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
  • prec1
  • prec2
Ablaufsequenz
  1. seq1
  2. seq2
Mögliche Fehler name descr

Operationen des EFA Document Repository

Die nachfolgende Tabelle listet die vom EFA Document Repository (ECR Document Repository) bereit gestellten Operationen sowie die damit realisierbaren Kommunikationsmuster.

Operation Kommunikationsmuster
provideData Einstellen von Dokumenten
retrieveData Abrufen von Dokumenten

In den folgenden Abschnitten werden diese Operationen plattform-unabhängig über das Service Functional Model des EFA Document Repository spezifiziert.

provideData

Operation provideData
Funktionalität Einstellen von Daten in eine bestehende Partition einer Fallakte.
Eingabe 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.
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
  • Der Sicherheitskontext ist gültig und vollständig. Die Angaben zur Nutzeridentität sind authentisch.
  • Die Ziel-Partition ist einer Fallakte zugeordnet.
  • Für die mit der Ziel-Partition verbundene Akte (Zweckbindung) sind zum Aktenzugang berechtigte Teilnehmer und deren Rollen definiert. Der Nutzer ist berechtigter Teilnehmer. Die Teilnehmerrolle berechtigt zum Einstellen von Daten in die Akte.
  • Der Nutzer ist berechtigt, bei dem EFA-Provider, der die Partition verwaltet, Daten einzustellen.
  • Die Metadaten der einzustellenden Dokumente sind vollständig und valide.
  • Sofern bestehende Dokumente aktualisiert oder ergänzt werden: Die Ziele der Dokumentbeziehungen sind valide.
Ablaufsequenz
  1. Das Document Repository stellt sicher, dass die Vorbedingungen erfüllt sind.
  2. Das Document Repository legt alle übergebenen Dokumente in einem sicheren Dokumentenspeicher ab.
  3. Das Document Repository initiert die registerData Operation mit den übergebenen Metadaten und Beziehungen beim Document Registry.
  4. Das Document Repository schreibt einen Audit Trail Eintrag über die Ausführung der Operation.
  5. Das Document Repository sendet eine Information zum Ausführungsstatus der Operation an den Nutzer zurück.
Mögliche, für diese Operation spezifische Fehler unbekannte Partition Die angegebene Ziel-Partition ist nicht existent, keine EFA-Partition oder für den Nutzer nicht zugreifbar.
Unvollständige Metadaten Die übergebenen Metadaten sind nicht vollständig (z.B. weil ein verpflichtendes Datenfeld nicht belegt ist). In der Fehlermeldung sollen die Dokumente benannte werden, deren Metadaten unvollständig sind.
Invalide Metadaten In den Metadaten werden Vorgaben zu den zu verwendenden Codesystemen verletzt. In der Fehlermeldung sollen die Dokumente benannte werden, deren Metadaten falsch kodiert sind.
Invalide Objektreferenzen In Dokumentenbeziehungen referenzierte Dokumente existieren nicht oder sind nicht Bestandteil der Fallakte.

retrieveData

Operation retrieveData
Funktionalität Abrufen von Daten aus einer Fallakte.
Eingabe 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.
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
  • prec1
  • prec2
Ablaufsequenz
  1. seq1
  2. seq2
Mögliche Fehler name descr

Querverweise und Referenzen

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