Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Navitabs
rootMinSpærring - Leverancebeskrivelse
includeroottrue


Table of Contents

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.

...

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

VersionDatoAnsvarligBeskrivelse

1.0

29.06.2012

Systematic

Initial version

1.1

28.11.2014

Systematic

References to National Patient Index (NPI) removed

1.2

07.09.2016

Systematic

Description of additional conditions for data specific consent check (paragraph 2.2)

1.3

07.12.2016

Systematic

Consent services now support DCC – (paragraph 3.1.1 and 3.1.2)

Changed sts.endpoint to new endpoint in example properties file

1.4

13.06.2018

Systematic

Migrated to NSPOP SVN


22.10.2018KITDocument moved from Word to Confluence. Original document name was: PHB0035 Consent Services Users Guide.docx

12.11.2020KITOversættelse fra engelsk til dansk

Definitioner og referencer

DefinitionBeksrivelse

NSI

National Sundheds IT

NSP

National Service Platform

SHAK

SygeHusAfdelingsKode

SOR

Sundhedsvæsnets Organisationsregister

STS

Security Token Service

ReferenceBeskrivelse

DGWS 1.0

Den Gode Webservice 1.0

DGWS 1.0.1

Den Gode Webservice 1.0.1

HSUID-header

MinSpærring - Healthcare Service User Identification Header Interface Description

MinSpærring - Verifikation Service Interface Beskrivelse

MinSpærring - Verifikation Service Interface Beskrivelse


MinSpærring - Administration Service Interface Beskrivelse

MinSpærring - Administration Service Interface Description

Data Model

MinSpærring - Data Model

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.

...

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.

...

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.

...

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

...

Code Block
languagexml
<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.

...

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

...

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.

...

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.

...

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

...

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.