Introduktion

Formål

Specifikationen for Web Service interfacet for MinSpærring Verifikation beskriver de web services som MinSpærring Verifikation tilbyder henholdsvis sundhedsfaglige og borgere der vil udføre MinSpærring Verifikation.

Koncepter

En MinSpærring registrering beskrivelse beskriver sammenhængen mellem.A consent describes a relationship between:

en borger,

(what) information om hvad en MinSpærring omhandler.

...

For en detaljeret beskrivelse af datamodellen for MinSpærring og strukturen af MinSpærring elementerne se MinSpærring - Data Model

En spærring betyder at borgeren har afvist at data identificeret via what kan tilgås af personer eller organisationer identificaeret via who.

...

En sundhedsfagligs adgang til følsom data for en specifik borger er ikke påvirket hvis den oprettede spærring eller samtykke er for en anden sundhedsfaglig eller organisation. Dette er f.eks. hvis der er oprettet en spærring for en anden sundhedsfaglig end den der forespørger på data.

Definitioner og referencer

Formålet med denne sektion er at give et overblik over definitioner og referencer anvendt i dette dokument.

...

Læsevejledning

I dokumentet bruges begreberne autorisation og autoriseret primært i en sikkerhedskontekst, det vil sige i forståelsen af, at en person eller et system er autoriseret til at bruge en given ressource. Hvis begreberne anvendes på sundhedspersonale med dansk autorisation, der er anført i Sundhedsstyrelsens autorisationsregister, vil det blive udtrykkeligt angivet.

...

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.

Dokument historik

MinSpærring Verifikation Bruger Scenarier

Nedenstående beskriver brugerscenarier som service MinSpærring Verifikation understøtter.

Sundhedsfaglig Tjekker Borgers MinSpærring Registreringer

En sundhedsperson kan kontrollere en borgeres samtykker og spærringer for at afgøre, om der findes et samtykke eller spærring for adgang til borgerens data. Dette brugsscenarie understøttes af operationen ConsentForUserCheck. Kontrollen udføres typisk inden der hentes oplysninger om borgeren.

...

DataSpecificConsent betyder, at der findes et eller flere samtykker eller spærringer til udvalgte oplysninger om borgeren. Det er således ikke muligt at afgøre, om sundhedspersonalet har ret til al information om borgeren. Derfor skal yderligere verifikation af de enkelte dataelementer udføres, inden den sundhedsfaglige kan få oplysninger om borgeren. Ved positivt svar udføres der ikke yderligere verifikation af data. Ved negativt svar er al information om borgeren utilgængelig for den sundhedsfaglige.

Sundhedsfaglig Tjekker Borgers Data Specifikke Registreringer

En sundhedsfaglig ønsker at hente en række oplysninger om en borger. Et tidligere kald til operationen ConsentForUserCheck returnerede resultatet DataSpecificConsent. Det er således nødvendigt at kontrollere hvert enkelt dataelement for borgerens samtykke eller spærring med hensyn til den sundhedsfaglige persons adgang. Operationen ConsentForDataCheck understøtter dette scenarie. 

Resultatet af operationen er en liste af data elementer som den sundhedsfaglige har lov til at se.

Sundhedsfaglig i Andet Land Tjekker Borgers MinSpærring Registreringer Gennem NCP

En sundhedsfaglig person, i et andet landt, ønsker at hente information om en dansk borger. Dette sker via et kald fra et andet lands NCP til den danske NCP. Før den danske NCP returnerer infomationer om den danske borger tjekkes der at borgeren har registreret et samtykke til den sundhedsfaglige person. Dette sker ved kald til operationen ConsentForForeignersCheck.

Resultatet af operationen er om den sundhedsfaglige har samtykke til a tilgå borgerens data.

MinSpærring Verifikation Web Services

Læsevejledning

Nedenstående skabelon dokumenterer operationenerne der er udstillet af MinSpærring Verifikation. De vigtigste elementer i forespørgsel og svar er beskrevet i sektion 5.

Web Service - ConsentVerification

Nedenstående operationer udstullet af MinSpærring Verifikation.

Operation – ConsentForUserCheck

Operation – ConsentForDataCheck

Operation – ConsentForForeignersCheck

MinSpærring Verifikation Web Service Semantiker

Besked format

Web servicen forventer SOAP beskeder. SOAP headeren indeholder sikkerheds header og Medcom header som krævet i DGWS 1.0.1. Udover dette skal der også være en HSUID header.

...

Formatet af sikkederhedsheader og Medcomheader er beskreivet beskrevet i  [DGWS 1.0] og [DGWS 1.0.1]. Formatet for HSUID-headeren er beskrevet i  [HSUID-Header].

Attributter i HSUID headeren når bruger er sundhedsfaglig

Når brugere er en sundhedsfaglig person er det nedenstående attributter der skal være i HSUID headeren.

...

Bemærk at det er anvendersystemets ansvar at sikre konsistes mellem de angive organisationer.

Web Service Sikkerhed

Sikkerheden er baseret på SOSI-integrationsmønstret i Den Gode WebService (DGWS). Godkendelse sker via STS på NSP'en og er baseret på OCES digitale certifikater. Som udgangspunkt kræves der et medarbejdercertifikat (MOCES). Initielt kan visse systemer, i en overgangsperiode, anvende et VOCES certifikat.

Yderligere sikkerhedsaspekter, herunder autorisation, integritet, fortrolighed, tilgængelighed og fortrolighedshensyn, håndhæves kun i nogen grad af den tekniske service. De aspekter, der i øjeblikket ikke håndteres af den tekniske tjeneste, håndteres i serviceaftalen, som specificeret af den dataansvarlige myndighed (SDS) som forbrugere af tjenesten skal acceptere.

Godkendelse

Godkendelse af anvendersystemer

Når STS'en signatur af ID korter er valideret med succes har anvenderen adgang.

Udover dette skal anvendersystemet være whitelisted baseret på system delen af ID-kortet.

Godkendelse af bruger

Når anvendersytemet er godkendt bliver brugeren godkendt via HSUID header attributen nsi:ActingUserCivilRegistrationNumber.

...

Servicen godkender all brugere der er sundhedsfaglige.

Udløb af ID-kort

En request med et ID-kort der er mere end 24 timer gammelt i forhold til udstedelsestidspunkt afvises.

Status koder og flow status

Som krævet i DGWS 1.0.1 anvendes kun HTTP status kode 200 og 500.

Ved HTTP status kode 200 er FlowStatus altid flow_finalized_succesfully.

Timeout ved web-service operationer

Timeout er det samme som standard timeout på NSP platformen.

Session

Alle kald håndteres i sin egen session.

...

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: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

...

 

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

Versionering

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:

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