Introduktion

Formål

This document describes the usage of the web services that are made available by consent services, which consists of two independent services: consent administration and consent verification.

The document provides an introduction to the general Web service interface for both services, in addition to examples on how they can be used in a specific user system.

Where the services overlap, common functionality is only described once.

Læsevejledning

This document is directed towards developers and architects that will be using consent service on NSP. It is assumed that the reader is familiar with Web services and the additional components on the NSP such as STS, in addition to knowing about Den Gode Web service (DGWS).

Dokument historik

Definitioner og referencer

Interface Beskrivelse

Snitfladerne for de to services er beskrevet i detaljer i dokumenterne MinSpærring - Verifikation Service Interface Beskrivelse og MinSpærring - Administration Service Interface Description.

I dette afsnit er kun de enkelte komponenter, der er nødvendige for at beskrive brugen af de to tjenester beskrevet.

Fælles

Security header

To call consent services, a user system must obtain a certificate and an ID card of level 3, issued by STS, and add these to the security header.

For at kalde de to MinSpærring services  skal der anvendes et niveau 3 ID-kort udstedt af STS'en.

It should furthermore be ensured that one has a stated company registration number and that it is on the whitelist of authorized system. The two services use different whitelists, so the company registration number must be added to one or both, depending on which service one wants to call.

Det skal desuden sikres, at man har et angivet CVR-nummer og at dette er whitelisted i servicen. De to services bruger forskellige whitelisting tabeller, så CVR-nummer skal føjes til den ene eller begge, afhængigt af hvilken tjeneste man vil tilgå.

Medcom header

I Medcom-headeren skal det sikres, at Flow-ID er sat korrekt. Hvis servicene kaldes fra et andet system der også anvender DGWS skal Flow-ID bevares fra dette opkald.

Medcom-headeren returneres fra alle operationer da den er indstillet som en ind / ud-parameter med flowstatus opdateret til 'afsluttet med succes'.

HSUID header

Endelig skal HSUID-headeren udfyldes med identifikation af den bruger, der udfører en given operation. Nogle af disse oplysninger genbruges muligvis i selve meddelelsen, og disse skal naturligvis være konsistente (jf. MinSpærring - Verifikation Service Interface Beskrivelse og MinSpærring - Administration Service Interface Description).

MinSpærring Verifikation

MinSpærring Verifikation har to operationer til at verificere samtykke fra en sundhedsfaglig: ConsentForUserCheck og ConsentForDataCheck.

Formålet med ConsentForUserCheck-operationen er, at gøre det muligt for et brugersystem hurtigt at kontrollere, om en bruger har generelt samtykke eller generel spærring.

Hvis operationen vender tilbage positiv eller negativ, er det ikke nødvendigt at kalde yderlige for at afgøre om en sundhedsfaglig har lov til at tilgå data.

På et positivt svar antager brugersystemet, at brugeren har samtykke til at se sundhedsdata vedrørende den borger, som MinSpærring databasen er ansvarlig for. Omvendt antages det på et negativt svar, at borgeren har oprettet en spærring vedrørende adgang til data.

Operationen ConsentForDataCheck accepterer en liste over metadataelementer og filtrerer dem baseret på borgerens samtykke eller spærring.

Hvis ID'erne er en SHAK-kode eller et Ydernummer forsøger verifikations servicen at slå de relaterede SOR koder op som vil blive anvendt i forbindelse med brugeresn spærring eller samtykke.

Derudover, hvis der er angivet en dataspecifikt spærring til en organisation, inkluderes de hierarkiske forældre til den organisation i dette samtykke. Medmindre der er givet et specifikt samtykke.

Dette illustreres i de følgende eksempler. Figur 1 viser borger, der har et generelt samtykke, men som har givet en dataspecifikt spærring til organisationen "Org". Hvis organisations id'er fra alle fire organisationer sendes til MinSpærring Verifikation viser diagrammet svaret hvor rød er spærring og grøn er samtykke.

Figur 1: Spærring på ”Org” der har indflydelse på den overliggende organisation.

På den anden side, hvis borgeren har oprettet en general spærring og givet et specifikt samtykke til data fra "Org" for en given bruger, påvirkes overliggende organisation ikke. Se figur 2.

Figur 2: Specikt samtykke på  ”Org” påvirker ikke overliggende organisation.

Those metadata whose IDs are returned from the service are the metadata the user has a positive consent to view.

De metadata, hvis id'er returneres fra tjenesten, er de metadata, som brugeren har et positivt samtykke til at få vist.

It is the user systems responsibility to ensure that the used IDs are unique so that they can be distinguished in the returned list. The service does not use the IDs for anything else than the return list.

Consent administration

Create- edit- and delete-methods all accept consent-objects (Consent) as parameters. The contents of a consent-object, in addition to which options are allowed, are shown in [Data Model] section 2.

All methods in the consent administration allows the citizen who creates a consent (or deletes/modifies) to be different from the citizen that the consent concerns.

This means that a citizen can create/edit/delete consents on behalf of another citizen as long as the citizen is authorized to do so.

Likewise, it is possible for a health professional to create a consent (but not edit or delete) on behalf of a citizen.

It is the user system’s responsibility that the user is authenticated and authorized to perform an action on behalf of another.

Examples of Calling Services

In this section, examples are provided on how one can use a Java-based user system to call the two services.

The code example is taken from the integration tests for the service and both method calls, variables and parameters come from this context.

The code might possibly not be able to compile or run its current form, as it is only intended as a guide on how to construct a call to the service.

Service Clients

A service client has been developed for each service which can be found as Maven-components:

<dependency> 
	<groupId>dk.nsi.consentservices.verification</groupId> 
	<artifactId>consent-verification-client</artifactId> 
	<version><desired client version></version>
</dependency>

and:

<dependency> 
	<groupId>dk.nsi.consentservices.administration</groupId> 
	<artifactId>consent-administration-client</artifactId> 
	<version><desired client version></version>
</dependency>

Creation of service client

These service clients are configured using a property file, and the client takes care of obtaining a valid STS-token, creating proper headers etc.

Properties for the client are set up through the ClientConfig-class that accepts the name of the properties file in which the configuration is found. The properties-file must be found on classpath.

The code below creates a port for the verification service:

Config config = new ClientConfig("VerificationClient").
     addRequiredKeys(ConsentVerificationService.CONFIG_KEY, ConsentVerificationService.CONFIG_ENDPOINT);
URL wsdl =
   new URL(config.getProperty(ConsentVerificationService.CONFIG_KEY));
String wsendpoint = config.getProperty(ConsentVerificationService.CONFIG_ENDPOINT);
ConsentVerificationServiceservice =
   new ConsentVerificationService (config, wsdl);
service.initialise();
ConsentVerification port = service.getConsentVerificationPort(wsendpoint);

This presupposes that a VerificationClient.properties-file can be found on classpath.

Similar code create a client for the administration service, the client is just the class ConsentAdministrationService instead and the call results in a port defined in the class ConsentAdministration.

Properties

The properties file provided for the service client, must define a number of properties that the client uses to communicate with the service (the values must be adjusted so that they are relevant to the user system):

administration.wsdl.location = http://localhost:8080/consent-administration/service?wsdl
administration.service.url = http://localhost:8080/consent-administration/service
verification.wsdl.location = http://localhost:8080/consent-verification/service?wsdl
verification.service.url = http://localhost:9090/consent-verification/service
idcard.level = 3
idcard.system.name = TESTSTS
idcard.subject.id.type = medcom:cvrnumber
idcard.subject.id = 19343634
idcard.subject.name = JERNALDERBYENS VENNER
sts.test.mode = false
sts.endpoint = http://test1.ekstern-test.nspop.dk:8080/sts/services/NewSecurityTokenService
sts.token.expiry.threshold = 60
sts.keystore = jks/validVocesVault.jks
sts.keystore.password = !234Qwer
cert.expires.in.warning = 30

(the values are taken from the integration tests and must possibly be changed to function in another context).

The values for the security certificate must be corrected to the certificate one is using.

It is only necessary to provide one wsdl-location for each service.

Headers

Subsequently, service and port can be used to create the necessary headers, so the service can be called.

A flowID is provided with the headers, see section 2.1.

DGWSHeaderWrapper signedHeaders = service.getSignedHeaders(flowID);
Holder<Header> medcomHeader =
   new Holder<Header>(signedHeaders.getMedcomHeader());
HsuidHeader hsuidHeader = createHsuidHeader();

The values in the HSUID-header must be set manually by calling a method that creates the object (see [HSUID-header] for a description of the header contents).

The Medcom header is wrapped in a holder-object as it is an In/Out parameter.

Example of Call to Consent Verification

An example of call to ConsentForDataCheck on the verification service is shown here.

List<ConsentDataRegistration> consentData; // the list must be populated elsewhere

ConsentForDataCheck consentForDataCheck =
new ConsentForDataCheck(citizen, healthcareProfessional, onBehalfOf,
organization, consentData);

ConsentForDataResponse consentForDataCheckResponse =
PORT.ConsentForDataCheck(consentForDataCheck, medcomHeader,
signedHeaders.getSecurityHeader(), hsuidHeader);

The element consentData has to be a list of ConsentDataRegistration-objects, see [Consent Administration Interface Description] and [Consent Verification Interface Description]:

The return value contains the IDs of the data elements that the user healthcareProfessional has consent from the citizen citizen to view.

Example of Call to Consent Administration

Shown here is an example of a call to ConsentAdd on the administration service (the contents of the actual consent-object is not shown here):

Consent consentItem = new Consent();
consentItem.setCitizenCPR(citizen);
consentItem.setPositiveConsent(positive);
consentItem.setValidFromDate(validFrom);
consentItem.setValidToDate(validTo);
consentItem.setWho(who);
consentItem.setWhat(what);

PORT.ConsentAdd(Arrays.<Consent>asList(consentItem), medcomHeader,
signedHeaders.getSecurityHeader(), hsuidHeader);

Client Generation from WSDL

It is of course also possible to use runtime WSDL-generation against a deployed service as a starting point.