...

Læsevejledning

I dokumentet ----

In the document, the concepts of authorization and authorized are used primarily in a security context, that is, in the understanding that a person or a system is authorized to use a given resource. If the concepts are applied towards health professionals with Danish authorization listed in Danish Health Authority’s authorization register, it will be stated explicitly.

A system that uses Web services described in this document is referred to as a user system.

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.

Et system der anvender Web Services

Et system, der bruger webservices beskrevet i dette dokument, referes som et anvendersystem.

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 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. Knowing Kendskab til  Den Gode Webservice (DGWS) 1.0.1 described in 1beskrevet i  [DGWS 1.0] and og [DGWS 1.0.1] will facilitate comprehension considerablyvil gøre forståelsen nemmere.

Dokument historik

MinSpærring Verifikation Bruger Scenarier

MinSpærring Verifikation Bruger Scenarier

Nedenstående beskriver brugerscenarier som service MinSpærring Verifikation understøtterThe following section describes the usage scenarios that the Web service for consent verification supports.

Sundhedsfaglig Tjekker Borgers MinSpærring Registreringer

A health professional can check a citizen’s consent registrations to determine if a consent exist that blocks the health professional’s access to the citizen’s data. This usage scenario is supported by the operation ConsentForUserCheck. The check will typically be performed before retrieving information about the citizen.

The result of the operation is a statement about whether the health professional has consent for the citizen’s information in the form of negative, positive or DataSpecificConsent.

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.

Resultatet af operationen er en erklæring om, hvorvidt der er spærret eller givet samtykke til den sundhedsfaglige. Resultat er enten negative, positive eller DataSpecificConsent.

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 sundhedsfagligeA result in the form of DataSpecificConsent means that one or more consents exists on selected information concerning the citizen. Thus, it is not possible to decide if the health professional has consent for all information concerning the citizen. Consequently, additional consent verification of the individual data elements must be performed before the health professional can be presented with information concerning the citizen. On positive reply, no further verification of data is performed. On negative reply, all information concerning the citizen is unavailable for the health professional.

Sundhedsfaglig Tjekker Borgers Data Specifikke Registreringer

A health professional desires to retrieve a number of informations about a citizen. A previous call of the operation ConsentForUserCheck returned the result DataSpecificConsent. Thus, it is necessary to check each individual data element for citizen’s consent in regard to the health professional. When the user system has obtained the list of data elements concerning the citizen, this usage scenario is supported by the operation ConsentForUserCheck.

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 seThe result of the operation is a list of data elements for which the health professional has consent.

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

A foreign health professional desires to retrieve information concerning a Danish citizen. This happens through a call from another country’s NCP to the Danish NCP. Before the Danish NCP returns the information about the concerned Danish citizen to another country’s NCP, the Danish NCP verifies that the citizen has registered a positive consent for foreign health professionals by calling the operation ConsentForForeignersCheck.

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 dataThe result of the operation is a statement on whether foreign health professionals has positive consent for the citizen’s information.

MinSpærring Verifikation Web Services

Læsevejledning

The template below documents the operations that are offered by the consent verification Web service. The most important elements for input and output are described in section 5.

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

The operations below are available on the verification serviceNedenstående operationer udstullet af MinSpærring Verifikation.

Operation – ConsentForUserCheck

Operation – ConsentForDataCheck

Operation – ConsentForForeignersCheck

MinSpærring Verifikation Web Service Semantiker

Besked format

The Web service expects SOAP messages, where the SOAP header contains security header and Medcom header as required by servicen forventer SOAP beskeder. SOAP headeren indeholder sikkerheds header og Medcom header som krævet i DGWS 1.0.1, in addition to a Healthcare Service User Identification (HSUID) . Udover dette skal der også være en HSUID header.

Figure Figur 1 SOAP message containing security header, Medcom header and HSUID header is used as message format.besked indeholdende sikkerhedsheader, Medcomheader samt HSUID header.

Formatet af sikkederhedsheader og Medcomheader er beskreivet i The format of Security and Medcom headers are described in [DGWS 1.0] and og [DGWS 1.0.1], while the format of the HSUID header is described in. Formatet for HSUID-headeren er beskrevet i  [HSUID-Header].

Attributes in HSUID header applied for user who is a health professional

When the user of the service is a health professional, attributes in Table 1 are applied in the 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.

Table 1 Attributes in the HSUID-header applied for user who is a health professional.

Tabel 1 Attributer i HSUID-header når bruger sundhedsfaglig.

Identifikation af organisationen sundhedsfaglig er tilknyttet kan angives som en enkelt kode i form af f.eks. en SHAK-kodeThe identification of the organization for which the user is associated, may be provided as a single value and a single format, such as SHAK-code:

<hsuid:Attribute Name="nsi:OrgUsingID" NameFormat="nsi:skskode">
	<hsuid:AttributeValue>6620151</hsuid:AttributeValue>
</hsuid:Attribute>

Alternatively, the organization, to which the user is affiliated, can be specified by two values, e.g. as both SOR- and SHAK-codeAlternativt kan organisation angives med to værdier. Det kan f.eks. være en SOR kode og en SHAK kode:

<hsuid:Attribute Name="nsi:OrgUsingID" NameFormat="nsi:sor">
	<hsuid:AttributeValue>440081000016006</hsuid:AttributeValue>
</hsuid:Attribute>
<hsuid:Attribute Name="nsi:OrgUsingID" NameFormat="nsi:skskode">
	<hsuid:AttributeValue>6620151</hsuid:AttributeValue>
</hsuid:Attribute>/hsuid:Attribute>

Bemærk at det er anvendersystemets ansvar at sikre konsistes mellem de angive organisationerNote that it is the consumer system's responsibility to ensure that there is consistency between the given ID across SOR, SHAK and Healthcare Provider Number (Danish: ydernummer) classification systems.

Web Service Sikkerhed

The security of this Web service is based on the SOSI integration pattern in Den Gode Webservice (DGWS). Authentication is carried out by a trusted third party component on NSP (Security Token Service) and based on OCES digital certificates. As a rule, the service requires authentication with the STS component based on employee signature (MOCES). However, highly trusted systems - initially only Health journal - can during a transitional period gain access by level 3 based on company signature (VOCES).

Additional security aspects, including authorization, integrity, confidentiality, availability and privacy considerations are enforced to only some extent by the technical service. The aspects that are not currently handled by the technical service will be handled in the service agreement, as specified by the data-responsible authority (NSI), which consumers of the service must agree to.

Authentication and authorization

Authentication and authorization of consumer systems

When STS’ signature of the ID card has been validated successfully, then the consumer has been authenticated.

Authorization of consumer system is performed using a whitelist in the web service based on information in the system-part of the ID card.

Authentication of user

When the user system is authenticated and authorized, the user is authenticated by the HSUID header attribute nsi: ActingUserCivilRegistrationNumber.

Authorisation of user

Whether the user is health professional or citizen is determined from the HSUID header attribute nsi: UserType.

Web service-operation(s), where the user is health professional

The Web service authorizes all users who are health professionals to use its operations.

Timeout on ID card

A request with ID card is rejected when it has been more than 24 hours since the beginning of the ID card validity period.

Status code and Flow status

As required by DGWS 1.0.1, only HTTP-status codes 200 and 500 are used.

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.

Om det er en borger eller sundhedsfaglig afgøres af HSUID header attributen nsi: UserType.

Web service opetaitoner hvor bruger er sundhedsfaglig

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 On HTTP status code 200 FlowStatus is always 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.

Der forestages ikke check om et MessageId har været anvendt tidligere og der er ikke garanti for at samme svar returenres hvis MessageId anvendes igen.

Dette afviger fra 

Timeout on web service-operations is the same as default timeout on the NSP platform.

Session

Each request is handled in its own session.

No check is performed whether MessageID in request has been received previously and no answer is guaranteed if a request with the same MessageID is received.

This deviates from DGWS 1.0.1 in regard to handling of retransmissioni forhold til håndtering af genfremsendelse.

Assignment and reuse respectively of flow ID

...