diff --git a/docs/erp_abrufen.adoc b/docs/erp_abrufen.adoc index 604e3e5e..fd0f5a4d 100644 --- a/docs/erp_abrufen.adoc +++ b/docs/erp_abrufen.adoc @@ -156,6 +156,12 @@ Content-Type: application/fhir+xml;charset=utf-8 + + + + + + @@ -174,7 +180,7 @@ Content-Type: application/fhir+xml;charset=utf-8 - + @@ -371,6 +377,176 @@ s|Code s|Type Error [small]#Unerwarteter Serverfehler# |=== +== E-Rezept erneut abrufen + +Beim initialen Abrufen eines E-Rezepts erhält die Apotheke ein eindeutiges Secret, das für alle weiteren Schritte benötigt wird. Es besteht das Risiko, dass dieses Secret bei der Übertragung der Response des E-Rezept-Fachdienstes verloren geht. In diesem Fall kann das E-Rezept erneut abgerufen werden, damit die Apotheke in Besitz des Secrets kommt. + +Hierzu wird der Task mit den Informationen aus dem E-Rezept-Token erneut abgerufen. Der E-Rezept-Fachdienst überträgt daraufhin den Task mit Secret und das QES Verordnungsbundle an die Apotheke. + +Dieser Aufruf ist nur erfolgreich, wenn die gleiche Apotheke den Task erneut abruft, die das E-Rezept ursprünglich abgerufen hat. + +*Request* +[cols="h,a"] +[%autowidth] +|=== +|URI |https://erp.zentral.erp.splitdns.ti-dienste.de/Task/160.123.456.789.123.58?ac=777bea0e13cc9c42ceec14aec3ddee2263325dc2c6c699db115f58fe423607ea +|Method |GET +|HTTP Header | +---- +Content-Type: application/fhir+xml; charset=UTF-8 +Authorization: Bearer eyJraWQ.ewogImL2pA10Qql22ddtutrvx4FsDlz.rHQjEmB1lLmpqn9J +---- + +NOTE: Im http-Header des äußeren http-Requests an die VAU (POST /VAU) sind die Header `X-erp-user: l` und `X-erp-resource: Task` zu setzen. + +|=== + + +*Response* +[source,xml] +---- + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +---- + + +[cols="a,a"] +[%autowidth] +|=== +s|Code s|Type Success +|200 | OK + +[small]#Die Anfrage wurde erfolgreich bearbeitet. Die Response enthält die angefragten Daten.# +s|Code s|Type Error +|400 | Bad Request + +[small]#Die Anfrage-Nachricht war fehlerhaft aufgebaut.# +|401 |Unauthorized + +[small]#Die Anfrage kann nicht ohne gültige Authentifizierung durchgeführt werden. Wie die Authentifizierung durchgeführt werden soll, wird im "WWW-Authenticate"-Header-Feld der Antwort übermittelt.# +|403 |Forbidden + +[small]#Die Anfrage wurde mangels Berechtigung des Clients nicht durchgeführt, bspw. weil der authentifizierte Benutzer nicht berechtigt ist.# +|404 |Not found + +[small]#Die adressierte Ressource wurde nicht gefunden, die übergebene ID ist ungültig.# +|405 |Method Not Allowed + +[small]#Die Anfrage darf nur mit anderen HTTP-Methoden (zum Beispiel GET statt POST) gestellt werden. Gültige Methoden für die betreffende Ressource werden im "Allow"-Header-Feld der Antwort übermittelt.# +|408 |Request Timeout + +[small]#Innerhalb der vom Server erlaubten Zeitspanne wurde keine vollständige Anfrage des Clients empfangen.# +|409 |Conflict + +[small]#Die Anfrage wurde unter falschen Annahmen gestellt. Das E-Rezept hat nicht den Status, dass es durch die Apotheke abgerufen werden kann.# + +[small]#Im OperationOutcome werden weitere Informationen gegeben:# + +[small]#"Task has invalid status completed"# + +[small]#"Task has invalid status in-progress"# + +[small]#"Task has invalid status draft"# +|410 |Gone + +[small]#Die angeforderte Ressource wird nicht länger bereitgestellt und wurde dauerhaft entfernt.# +|412 |Precondition Failed + +[small]#Die angeforderte Ressource wurde nicht von der autorisierten Organisation abgerufen.# +|429 |Too Many Requests + +[small]#Der Client hat zu viele Anfragen in einem bestimmten Zeitraum gesendet.# +|500 |Server Errors + +[small]#Unerwarteter Serverfehler# +|=== + + == Qualifizierte Signatur des E-Rezepts prüfen Im Apothekenverwaltungssystem liegen nach dem Abruf aus dem E-Rezept-Fachdienst der Task des Workflows und der qualifiziert signierte Verordnungsdatensatz vor. Die Rechtmäßigkeit der elektronischen Verordnung wird mittels Prüfung der QES durch den Konnektor verifiziert. Der E-Rezept-Fachdienst prüft die Signatur beim Einstellen des E-Rezepts. Die Apotheke kann sich auf diese Prüfung verlassen, hat aber auch die Möglichkeit die Signatur selbst zu prüfen. Für die Prüfung wird die soeben heruntergeladene PKCS#7-Datei in Base64-codierter Form an die SOAP-Schnittstelle der Signaturprüfung des Konnektors als http-POST-Operation geschickt. diff --git a/docs_sources/erp_abrufen-source.adoc b/docs_sources/erp_abrufen-source.adoc index b12277c4..f2d74eb2 100644 --- a/docs_sources/erp_abrufen-source.adoc +++ b/docs_sources/erp_abrufen-source.adoc @@ -140,6 +140,74 @@ s|Code s|Type Error [small]#Unerwarteter Serverfehler# |=== +== E-Rezept erneut abrufen + +Beim initialen Abrufen eines E-Rezepts erhält die Apotheke ein eindeutiges Secret, das für alle weiteren Schritte benötigt wird. Es besteht das Risiko, dass dieses Secret bei der Übertragung der Response des E-Rezept-Fachdienstes verloren geht. In diesem Fall kann das E-Rezept erneut abgerufen werden, damit die Apotheke in Besitz des Secrets kommt. + +Hierzu wird der Task mit den Informationen aus dem E-Rezept-Token erneut abgerufen. Der E-Rezept-Fachdienst überträgt daraufhin den Task mit Secret und das QES Verordnungsbundle an die Apotheke. + +Dieser Aufruf ist nur erfolgreich, wenn die gleiche Apotheke den Task erneut abruft, die das E-Rezept ursprünglich abgerufen hat. + +*Request* +[cols="h,a"] +[%autowidth] +|=== +|URI |https://erp.zentral.erp.splitdns.ti-dienste.de/Task/160.123.456.789.123.58?ac=777bea0e13cc9c42ceec14aec3ddee2263325dc2c6c699db115f58fe423607ea +|Method |GET +|HTTP Header | +---- +Content-Type: application/fhir+xml; charset=UTF-8 +Authorization: Bearer eyJraWQ.ewogImL2pA10Qql22ddtutrvx4FsDlz.rHQjEmB1lLmpqn9J +---- + +NOTE: Im http-Header des äußeren http-Requests an die VAU (POST /VAU) sind die Header `X-erp-user: l` und `X-erp-resource: Task` zu setzen. + +|=== + + +*Response* +[source,xml] +---- +include::../resources/examples/ti-dienste/task/request_recovery_secret.xml[] +---- + + +[cols="a,a"] +[%autowidth] +|=== +s|Code s|Type Success +|200 | OK + +[small]#Die Anfrage wurde erfolgreich bearbeitet. Die Response enthält die angefragten Daten.# +s|Code s|Type Error +|400 | Bad Request + +[small]#Die Anfrage-Nachricht war fehlerhaft aufgebaut.# +|401 |Unauthorized + +[small]#Die Anfrage kann nicht ohne gültige Authentifizierung durchgeführt werden. Wie die Authentifizierung durchgeführt werden soll, wird im "WWW-Authenticate"-Header-Feld der Antwort übermittelt.# +|403 |Forbidden + +[small]#Die Anfrage wurde mangels Berechtigung des Clients nicht durchgeführt, bspw. weil der authentifizierte Benutzer nicht berechtigt ist.# +|404 |Not found + +[small]#Die adressierte Ressource wurde nicht gefunden, die übergebene ID ist ungültig.# +|405 |Method Not Allowed + +[small]#Die Anfrage darf nur mit anderen HTTP-Methoden (zum Beispiel GET statt POST) gestellt werden. Gültige Methoden für die betreffende Ressource werden im "Allow"-Header-Feld der Antwort übermittelt.# +|408 |Request Timeout + +[small]#Innerhalb der vom Server erlaubten Zeitspanne wurde keine vollständige Anfrage des Clients empfangen.# +|409 |Conflict + +[small]#Die Anfrage wurde unter falschen Annahmen gestellt. Das E-Rezept hat nicht den Status, dass es durch die Apotheke abgerufen werden kann.# + +[small]#Im OperationOutcome werden weitere Informationen gegeben:# + +[small]#"Task has invalid status completed"# + +[small]#"Task has invalid status in-progress"# + +[small]#"Task has invalid status draft"# +|410 |Gone + +[small]#Die angeforderte Ressource wird nicht länger bereitgestellt und wurde dauerhaft entfernt.# +|412 |Precondition Failed + +[small]#Die angeforderte Ressource wurde nicht von der autorisierten Organisation abgerufen.# +|429 |Too Many Requests + +[small]#Der Client hat zu viele Anfragen in einem bestimmten Zeitraum gesendet.# +|500 |Server Errors + +[small]#Unerwarteter Serverfehler# +|=== + + == Qualifizierte Signatur des E-Rezepts prüfen Im Apothekenverwaltungssystem liegen nach dem Abruf aus dem E-Rezept-Fachdienst der Task des Workflows und der qualifiziert signierte Verordnungsdatensatz vor. Die Rechtmäßigkeit der elektronischen Verordnung wird mittels Prüfung der QES durch den Konnektor verifiziert. Der E-Rezept-Fachdienst prüft die Signatur beim Einstellen des E-Rezepts. Die Apotheke kann sich auf diese Prüfung verlassen, hat aber auch die Möglichkeit die Signatur selbst zu prüfen. Für die Prüfung wird die soeben heruntergeladene PKCS#7-Datei in Base64-codierter Form an die SOAP-Schnittstelle der Signaturprüfung des Konnektors als http-POST-Operation geschickt. diff --git a/resources/examples/ti-dienste/task/request_recovery_secret.xml b/resources/examples/ti-dienste/task/request_recovery_secret.xml new file mode 100644 index 00000000..afd82a64 --- /dev/null +++ b/resources/examples/ti-dienste/task/request_recovery_secret.xml @@ -0,0 +1,103 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/resources/examples/ti-dienste/task/response_taskAccept.xml b/resources/examples/ti-dienste/task/response_taskAccept.xml index f84ab999..d320052c 100644 --- a/resources/examples/ti-dienste/task/response_taskAccept.xml +++ b/resources/examples/ti-dienste/task/response_taskAccept.xml @@ -62,6 +62,12 @@ Content-Type: application/fhir+xml;charset=utf-8 + + + + + + @@ -80,7 +86,7 @@ Content-Type: application/fhir+xml;charset=utf-8 - +