RequestPsnWorkflow

Zweck

Abfragen bzw. anlegen von Pseudonymen auf Basis eines vorkonfigurierten Pseudonymisierungsablaufs (Workflow) für einen gegebenen Geltungsbereich (Studie und Standort). Rückgabe der generierten standort- und studienspezifischen-Pseudonyme als Params.

Voraussetzung
  • Die spezifizierte Studie muss im Zielsystem bekannt und angelegt sein.
  • Die spezifizierte Quell-Domäne (source) muss im Zielsystem bekannt und angelegt sein.
  • Die standortspezifische Domäne (target) muss im Zielsystem bekannt und angelegt sein.
  • Der spezifizierte API-KEY muss valid sein und über die nötigen Rechte zum Aufruf der Funktion verfügen.
  • Das optional spezifizierte Event muss im Workflow-Manager konfiguriert sein.
Aufruf und Rückgabe

Die bereitgestellte Funktionalität kann per POST-Request aufgerufen werden. Die erforderlichen Angaben werden per POST-BODY in Form von FHIR Parameters übermittelt.

<HOST>:<PORT>/ttp-fhir/fhir/dispatcher/$requestPsnWorkflow

Der Funktionsaufruf liefert eine Parameters-Ressource bestehend aus multiplen Multi-Part-Parametern zurück.

Invocations

URL: [base]/$requestPsnWorkflow

This operation changes content

Parameters (In)

Name Cardinality Type Documentation
original 1..* string Liste studien- und standortspezifischer Originalwerte für die entsprechende Pseudonyme ermittelt bzw. erstellt werden.
study 1..1 string Angabe der Studie
source 1..1 string Angabe der Pseudonymisierungsquell-Domain (Herkunft des Originalwertes)
target 1..1 string Angabe der Pseudonymisierungsziel-Domain
apikey 1..1 string Gültiger API-KEY zur Authentifizierung und Authorisierung des aufrufenden Systems gegenüber dem verarbeitenden Workflow-Manager
event 0..1 string Optionaler Parameter. Auszulösendes, vorkonfiguriertes Pseudonymisierungsevents innerhalb des Workflow-Managers.

Im Erfolgsfall wird jeweils ein pseudonym-Parameter zurückgegeben mit folgenden Teilen:

  1. original = der zu pseudonymisierende Werte (Teil des Requests)
  2. target = die genutzte Pseudonymisierungsdomäne (Teil des Requests)
  3. pseudonym = das fTTP-seitig erzeugte Pseudonym.

Im Einzel-Fehlerfall wird jeweils ein error-Parameter zurückgegeben, ebenfalls mit den Teilen original und target sowie einem error-code anstelle des Pseudonyms.

Im vollständigen Fehlerfall wird einer der folgenden HTTP Statuscodes in Verbindung mit einer OperationOutcome-Ressource zurückgegeben:

  • 400: fehlende oder fehlerhafte Parameter
Beispiele

Beispielhafter Request-Body (orientiert am Beispiel der fTTP-NUM Standort Use Cases): 

<Parameters xmlns="http://hl7.org/fhir">
    <id value="Parameters-RequestPsnWorkflow-request-example-1" />
    <parameter>
        <name value="study" />
        <valueString value="num" />
    </parameter>
    <parameter>
        <name value="original" />
        <valueString value="dic_1H51T" />
    </parameter>
    <parameter>
        <name value="source" />
        <valueString value="dic_erlangen" />
    </parameter>
    <parameter>
        <name value="target" />
        <valueString value="codex" />
    </parameter>
    <parameter>
        <name value="apikey" />
        <valueString value="abcdef12345" />
    </parameter>
</Parameters>

Eine beispielhafte Rückmeldung (orientiert am Beispiel der fTTP-NUM Standort Use Cases) kann wie folgt aussehen: 

<Parameters xmlns="http://hl7.org/fhir">
    <id value="Parameters-RequestPsnWorkflow-response-example-1" />
    <parameter>
        <name value="pseudonym" />
        <part>
            <name value="original" />
            <valueIdentifier>
                <system value="https://ths-greifswald.de/gpas" />
                <value value="dic_1H51T" />
            </valueIdentifier>
        </part>
        <part>
            <name value="target" />
            <valueIdentifier>
                <system value="https://ths-greifswald.de/gpas" />
                <value value="codex" />
            </valueIdentifier>
        </part>
        <part>
            <name value="pseudonym" />
            <valueIdentifier>
                <system value="https://ths-greifswald.de/gpas" />
                <value value="codex_6348Q7" />
            </valueIdentifier>
        </part>
    </parameter>
    <parameter>
        <name value="error" />
        <part>
            <name value="original" />
            <valueIdentifier>
                <system value="https://ths-greifswald.de/gpas" />
                <value value="dic_2Q42E" />
            </valueIdentifier>
        </part>
        <part>
            <name value="target" />
            <valueIdentifier>
                <system value="https://ths-greifswald.de/gpas" />
                <value value="codex" />
            </valueIdentifier>
        </part>
        <part>
            <name value="error-code" />
            <valueCoding>
                <system value="http://hl7.org/fhir/issue-type" />
                <code value="not-found" />
                <display value="Not Found" />
            </valueCoding>
        </part>
    </parameter>
</Parameters>

Beispielhafter Request-Body zur Anforderung von Drittpseudonymen (orientiert am Beispiel der Zentralen Plattform im Vorhaben NUM-RDP):

Command 'xml' could not render: File was not found for Resources/fsh-generated/resources/Parameters-Parameters-RequestPsnWorkflow-request-example-2.json

Eine beispielhafte Rückmeldung (orientiert am Beispiel der Zentralen Plattform im Vorhaben NUM-RDP) kann wie folgt aussehen:

Command 'xml' could not render: File was not found for Resources/fsh-generated/resources/Parameters-Parameters-RequestPsnWorkflow-response-example-2.json