...

Det antages at læseren har general forståelse for SOAP-basterede Web Services. Derfor er tekniske termer som SOAP, WSDL osv. ikke beskrevet. It is assumed that the reader understands the general use of SOAP-based Web services, why technical terms such as SOAP, WSDL etc. are not clarified.Kendskab til  Den Gode Webservice (DGWS) 1.0.1beskrevet i  [DGWS 1.0] og [DGWS 1.0.1] vil gøre forståelsen nemmere.

...

Dette afviger fra  DGWS 1.0.1 i forhold til håndtering af genfremsendelse.

...

Tildeling og genbrug af flow-ID

If the request contains a flow ID, it is reused in the reply. Handling of flow ID complies with Hvis request indeholder et flow-ID bliver det genbrugt i svaret. Håndtering af flow-ID sker i henhold til DGWS 1.0.1.

...

Behandling af anmodning om Non-Repudiation

Digital signing of replies is not supported. On request for non-repudiation, a fault-error message is returned as described in [DGWS 1.0].

Error Handling

SOAP errors

SOAP errors are returned with the components as described hereinafter.  A structure has been chosen wherein both standard error codes as described in Digital signering af svar understøttes ikke. På anmodning om Non-Repudiation returneres en fejlfejlmeddelelse som beskrevet i [DGWS 1.0] and service specific error codes can be returned.

Fejlhåndtering

SOAP fejl

SOAP-fejl returneres som beskrevet nedenfor. Der er valgt en struktur, hvor både standardfejlkoder som beskrevet i [DGWS 1.0] og servicespecifikke fejlkoder kan returneres.

<soap:Body>
      <soap:Fault>
         <faultcode>soap:Server</faultcode>
         <faultstring>Description of the error</faultstring>
         <detail>
            <FaultInfo xsi:type="ns2:dgwsInfo" xmlns="urn:dk:nsi:consent:verification:service:1" xmlns:ns2="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
               <ns2:FaultCode>expired_idcard</ns2:FaultCode>
            </FaultInfo>
         </detail>
      </soap:Fault>
   </soap:Body>

Code listing 1 Structure of SOAP faults returned from Web service operation. The example shows FaultCode used when the ID card has expiredKodeliste 1 Struktur af SOAP-fejl returneret fra Web Service Operation. Eksemplet viser FaultCode, der bruges, når ID-kortet er udløbet.

SOAP Fault Status

...

Koder

For all alle web service operations described in section 3 will be used SOAP Fault with FaultCode-values as listed in Table 2, originating from operationer, der er beskrevet i afsnit 3, anvendes SOAP-fejl med FaultCode-værdier som anført i tabel 2, der stammer fra DGWS 1.0.1.

Tabel 2 Anvendte Faultcode værdier stammende fra Table 2 Applied FaultCode-values originating from DGWS 1.0.1

Additionally, service specific FaultCode values as listed in Table 3 are usedDerudover anvendes tjenestespecifikke FaultCode værdier som anført i tabel 3.

Table 3 Applied service-specific FaultCode-values

Tabel 3 Anvendte servicespecifikke FaultCode værdier

WSDL'en tilhørende servicen specificerer ikke SOAP fejlkoder for hver The WSDL that describes the Web service described in this document does not specify the SOAP Fault status codes for every operation.

Web Service Input

...

Validering

Nedenstående valideresIt is validated that:

• Properly formatted Korrekt formateret HSUID header is included in the SOAP header, including the attributes that respectively may and must be present for a given user type as described in section -header er inkluderet i SOAP-headeren, inklusive de attributter, der henholdsvis kan og skal være til stede for en given brugertype som beskrevet i afsnit 4.1.1. Furthermore, it is validated that attribute values belong to established value sets and is not null or simply whitespaces

• ID card in security header is valid and signed by STS and that the additional conditions described in section 4.2 are met

• Social security numbers are valid and found in the National Board of Health authorization register.
• Organization identifiers are valid. Validity means that the identifier is a valid SOR-, SHAK- or Yder identifier.

There will be performed:

• No XML schema validation

• No validation that stated authorization numbers are valid and found in National Board of Health authorization register

• No validation that there is consistency between the health professional’s organization ID's when multiple ID and classification systems are provided.

• No validation that a health care professional is affiliated with stated organization

• No validation that the user is acting under responsibility of stated health professional

Standarder

• Desuden valideres det, at attributværdier hører til etablerede værdisæt og ikke er null eller simpelthen mellemrum

• ID kort i security header er valid og signeret af STS'en og yderlige krav i sektion 4.2 er opfyldt.

• CPR numre er valid og findes i autorisationsregistret.
  
• Organisations ID'er er valide. Valid betyder at det er en valid SOR, SHAK eller Yder nummer.
  

Nedenstående udføres IKKE:

• XML skema validering.
  

• Validering af, at de angivne autorisationsnumre er gyldige og findes i autorisationsregisteret
  

• Validering af, at der er konsistens mellem sundhedspersonens organisations-id'er, når der gives flere ID- og klassificeringssystemer.

• Validering af, at en sundhedsperson er tilknyttet den angivne organisation

• Validering af, at brugeren handler på vegne af den erklærede sundhedsperson

Standarder

MinSpærring Verifikation er baseret på nedenstående standarder. Consent verification service is based on the following standards:

1. SOAP version 1.1

2. Soap Fault version 1.1

3. WS-I Basic Profile 1.1

4. OIO namegivningsnavngivnings- og designregler

5. DGWS 1.0.1, with the exception of requirements regarding retransmission and control of reuse of messageID as described in section 4.5, and with the exception of structure used on errors as described in section med undtagelse af krav til videresendelse og kontrol af genbrug af meddelelses-ID som beskrevet i afsnit 4.5, og med undtagelse af struktur anvendt på fejl som beskrevet i afsnit 4.7.1.

MinSpærring Verifikation Web Service Skemaer

This section provides a general description of the key elements in the XML schemas, which together with WSDL files define the Web service operations described in Dette afsnit giver en generel beskrivelse af nøgleelementerne i XML-skemaerne, som sammen med WSDL-filer definerer de webservicefunktioner, der er beskrevet i 3.2. Additionally, cardinality is provided when an element is not compulsoryDerudover gives kardinalitet, når et element ikke er obligatorisk.

HealthcareProfessionalIdentifierOnBehalfOf

ConsentForDataRegistrations

ConsentDataRegistration

ConsentIndication

ConsentForDataResponse

ConsentForForeigners

Styring

Dokumentation

For the consent verification, the interface between the actor systems and consent verification is versioned.

The interface specification constitutes the contract that defines how the systems involved must act.

The interface specification consists of:

Til MinSpærring Verifikation er grænsefladen mellem anvendersystemerne og verifikation versioneret.

Snitfladebeskrivelsen udgør kontrakten, der definerer, hvordan de involverede systemer skal handle.

Snitfladebeksrivelsen består af:

• den tekniske specifikation af skemaer og servicebeskrivelser (dokumenteret som en WSDL-fil, se afsnit 7)

• dokumentation for den semantiske og funktionelle betydning af data, der udveksles (dokumenteret i dette dokument

• the technical specification of schemas and service descriptions (documented as a WSDL file, see section 7)

• documentation of the semantic and functional meaning of data that is exchanged (documented in this document).

Versionering

As part of the WSDL for ConsentVerification figures headers that are defined and versioned elsewhere. The body is specific for ConsentVerification and follows the naming

Som en del af WSDL for ConsentVerification er der headers der er definereret i andre standarder. Selve request til ConsentVerification følger nedenstående navngivning.

”urn:dk:nsi:consentservices:verification:service:<version>”

where the version changes on redefinition of the ConsentVerification interface.

WSDL

:service:<version>”

Bemærk dog at hvis der laves nye versioner af snitfladen skal versioneringen ske ved hjælp af en datoangivelse som det kan ses i nyeste version af MinSpærring Aministration snitfladen.

WSDL

WSDL til servicen kan tilgås ved at tilgå det endpoint servicen udstiller WSDL på. I test2 miljøet er det http://test2-cnsp.ekstern-test.nspop.dk:8080/consent-verification/service?wsdl. Hvis tjenesten på NSP miljøet ikke er tilgængeligt kan servicen startes op ved hjælp af de leverede docker-compose filer og WSDL kan tilgås derWSDL for the service can be obtained by runtime WSDL-generation towards a deployed service. If the service in NSP test environment cannot be accessed with a view to runtime WSDL-generation, then a locally built and deployed service can be used.