EFA Anwendungsdienste (logische Spezifikation)

Aus Hl7wiki
Implementierungsleitfaden
Wechseln zu: Navigation, Suche
K (createECR)
K (closeECR)
Zeile 233: Zeile 233:
 
|Vorbedingungen
 
|Vorbedingungen
 
| colspan="2"|
 
| colspan="2"|
* prec1
+
* 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.
* prec2
+
* 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"|
# seq1
+
Der Ressource Manager ...
# seq2
+
# ... verifiziert, dass die Vorbedingungen zur Ausführung der Operation erfüllt sind.
 +
# ... ändert die auf der Akte definierten Zugriffsrechte sowie den 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.
 +
# ... schreibt einen Audit Trail Eintrag über die erfolgreiche Durchführung der Operation
 +
# ... liefert einen Statuscode zur erfolgreichen Ausführung der Operation an das aufrufende System zurück
 
|-
 
|-
|Mögliche Fehler
+
|Fehler und Warnungen
|name
+
| colspan="2"|
|descr
+
Ü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.
 
|}
 
|}
  

Version vom 21. April 2013, 18:45 Uhr


EFA Anwendungsarchitektur: Service Functional Model

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
Einstellen von Dokumenten provideData EFA Document Repository
registerData EFA Document Registry
Auflisten von Dokumenten listData 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

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 Ressource Manager kann den Aufrufer anhand der im 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

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 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
  • 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 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 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.
Ablaufsequenz (logisch)

Der Ressource Manager ...

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

  • 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.
  • Die angegeben Patienten-ID kann nicht aufgelöst werden.
  • Eine oder mehrere der in der consentInfo angegebenen Identitäten zu berechtigender Teilnehmer kann nicht aufgelöst werden.
  • Die übergebene consentInfo ist nicht konsistent zu anderen Angaben.

Darüber hinaus sind die folgenden Warnungen definiert:

  • Eine bestehende Fallakte wurde in die neu angelegte Akte überführt. Der Aufrufer sollte ggf. verifizieren, dass die damit übernommenen Dokumente noch dem Zweck der Akte dienen. Veraltete Dokumente sollten invalidiert werden.

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. Mit Hilfe dieser ID kann der EFA-Teilnehmer weitere Operationen, wie z.B. das Einstellen von Dokumenten in diese Partition, durchführen.
Vorbedingungen
  • Der Aufrufer ist berechtigt, beim angesprochenen EFA-Provider Partitionen zu bestehenden Fallakten anzulegen.
  • Die übergebene 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 Konfiguration der angesprochenen Akte erlaubt das Einstellen der ggf. übergebenen Dokumente.
Ablaufsequenz (logisch)

Der Ressource Manager ...

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

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

Darüber hinaus sind die folgenden Warnungen definiert:

  • Eines oder mehrere der übergebenen Dokumente konnte nicht in der Partition abgelegt werden.


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
  • Die übergebene EFA-Referenz ist valide und der Aufrufer hat die erforderlichen Zugriffsrechte auf dieser Akte, um die angeforderte Aktion durchzuführen.
  • Das übergebene consentInfo Dokument ist konsistent:
    • Die Angaben zum benannten Patient stimmen mit den verfügbaren Informationen zum Betroffenen der Akte überein.
Ablaufsequenz

Der Ressource Manager ...

  1. ... verifiziert, dass die Vorbedingungen zur Ausführung der Operation erfüllt sind.
  2. ... ändert die auf der Akte definierten Zugriffsrechte sowie den Status der Akte entsprechend der Vorgaben in der Rücknahme der Einwilligung und unter Berücksichtigung des definierten EFA-Lebenszyklus
  3. ... stellt die Angaben zur Einwilligungsrücknahme und ein ggf. übergebenes Einwilligungsformular als Dokumente in eine Partition der Akte ein.
  4. ... schreibt einen Audit Trail Eintrag über die erfolgreiche Durchführung der Operation
  5. ... 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:

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

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

In den folgenden Abschnitten werden die Operationen des EFA Document Registry plattform-unabhängig als Service Functional Model 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

In den folgenden Abschnitten werden die Operationen des EFA Document Repository plattform-unabhängig als Service Functional Model 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