NEF - PIRR anrop av webbtjänster

 

HTTP-headers: {Authorization=[Basic cGl…], SOAPAction=[""], Accept=[*]}

2.3.2 Indata detaljerat (Namnen härrör från XML-schema i WSDL)

2.3.2.1 ServiceRequestWrapper

2.3.2.2 ServiceRequest

2.3.2.3 RequestHeader

2.3.2.4 RequestBody

2.3.2.5 SecurityDescriptor

2.3.2.6 Checksum

2.3.2.7 ServiceDescriptor

2.3.2.8 ArrayOfRequestDocument

2.3.2.9 RequestDocument

2.4 Utdata

Svarsmeddelandet som skickas från PIRR i soap:body består att ett header- och ett body-element. I headerelementet finns information som möjliggör att avgöra hur anropet gick. Beroende på status för anropet levereras en applikationskvittens (APERAK) i serviceResponse.responseBody.responseDocuments.ResponseDocument.data. Innehållet i data-elementet signeras inte men är base64-encodat. Applikationskvittensen finns definierad i respektive tjänsts XML-schema (Aperak.xsd, AperakAnimal.xsd, AperakCancellation.xsd och AperalCancellationAnimal.xsd samt de generella Common.xsd, Types.xsd och Header.xsd). Samtliga scheman kan erhållas från E-hälsomyndighetens kundytor.

2.4.1 Exempel på ett svar från NewPrescription:

Encoding: UTF-8

HTTP-headers: {content-type=[text/xml;charset=UTF-8], Date=[Wed, 02 Apr 2014 08:25:39 GMT], Content-Length=[3542]}

2.4.2 Utdata detaljerat

2.4.2.1 ServiceResponseWrapper

2.4.2.2 ServiceResponse

2.4.2.3 ReponseHeader

2.4.2.4 ResultDescriptor

För koderna 0, 1 och 2 returneras en applikationskvittens (aperak) i serviceResponse.responseBody.responseDocuments.ResponseDocument.data. Beroende på typ av fel kan aperak returneras för koderna 1000-1999 samt 3000-3999. För koderna 2000-2999 returneras ingen aperak.

För ytterligare information om svarskoder och applikationskvittenser hänvisas till dokumentet NEF – Riktlinjer kvittenshantering som kan hämtas från E-hälsomyndighetens kundyta.

2.4.2.5 ResponseBody

2.4.2.6 ArrayOfResponseDocument

2.4.2.7 ResponseDocument

2.5 Elementvärden vid utdata

3. Innehåll i data-elementet

3.1 Indata

I dataelementet levereras e-recept/makuleringsbegäran. Formatet på dokumentet ska följa S/MIME version 3-standarden (Ref. 5). Dokumentet ska signeras och levereras i multipart/signed format. Certifikatet tillsammans med kedjan upp till CA-certifikatet ska finnas i PKCS-7-delen av dokumentet (Ref. 6). Vidare måste CA-certifikatet finnas installerat hos E-hälsomyndigheten. Detta för att verifiering av inskickat certifikat ska kunna utföras.

Bilden nedan visar strukturen på meddelandet.

S/MIME-header

      Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1;
      boundary="----=_Part_1_655641627.1394783459289"

      ​OBS. Ovanstående värde på boundary är bara ett exempel.

​

Part 1-header

      Content-Type: application/xml
      Content-Transfer-Encoding: binary
      ​charset: utf-8

Part 2-header

      Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data
      Content-Transfer-Encoding: base64
      Content-Disposition: attachment; filename="smime.p7s"
      ​Content-Description: S/MIME Cryptographic Signature

3.1.1 Exempel

3.2 Utdata

I dataelementet kan en applikationskvittens returneras. Innehållet i applikationskvittensen definieras av resp. tjänsts schema. Ingen signering görs på applikationskvittensen (kvittensen returneras inte i S/MIME-format).

3.2.1 Exempel

Versionshistorik