Page History
| Navitabs | ||||
|---|---|---|---|---|
| ||||
| Table of Contents |
|---|
...
Introduktion
Purpose
This specification of the Web service interface for consent verification describes the Web services that consent verification offers health professionals and citizens respectively, who through the user will perform verification of consents.
...
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 sammenhængen mellem.
A consent describes a relationship between:
a citizenen borger,
(what) information about the citizenom hvad en MinSpærring omhandler.
(who) health professional persons or organizations in addition to their entry way to the information
For a detailed description of the data model for consents and the structure of consent elements, see [Datamodel].
A negative consent means that the citizen has declined that retrieval or disclosure of sensitive data (what) can be accomplished by an identified target group (who).
A positive consent selectively allows that an identified target group (who) can retrieve sensitive data (what), despite one or more negative consents for the sensitive data. A positive consent can furthermore be used in external systems to allow identified target group to retrieve sensitive data that has been marked externally as private.
sundhedsfaglig person eller organisation der er oprettet MinSpærring for.
For en detaljeret beskrivelse af datamodellen for MinSpærring og strukturen af MinSpærring elementerne se DATAMODEL // TODO DATAMODEL LINK.
En spærring betyder at borgeren har afvist at data identificeret via what kan tilgås af personer eller organisationer identificaeret via who.
Et samtykke betyder at sundhedsfaglige personer eller organisation, identificeret via. who, kan tilgå data identificeret via what. Dette selvom der er oprettet en eller flere spæringer. Et samtykke kan også bruges i eksterne systemer til at tillade en given gruppe af personer adgang til til følsomme data der ellers er blevet markeret som private.
En registrering er enten aktive eller inaktive. En aktive registrering kan påvirke en sundhedsfagligs adgagn til følsom data om en borger. En inaktiv registrering har ikke nogen påvirkning på nuværende spærringer eller samtykker, men er udelukkende historik for en tidligere aktiv spærring eller samtykke.
-----A consent is either active or inactive. An active consent can affect a health professional’s access to sensitive data about the citizen. An inactive consent has no impact, but is a record of a formerly active consent, that the citizen has nullified.
A consent can be attached with a validity period (when), that states a period for which a health professional’s access to the information may be restricted (on negative consent) or relaxed (on positive consent). The consent’s validity period concerns the time for desired retrieval of information only; it does not concern when the information was created or registered. Positive consents must be attached with a validity period, while negative consents only requires a stated start date.
A health professional’s access to sensitive data concerning a citizen is unaffected by a consent if the health professional is outside the consent’s field of action. This is the case if for instance a negative consent concerns another specific health professional.
...
Definitioner og referencer
The purpose of this section is to provide an overview of the definitions and documents references used in this document.
...
| Reference | Description |
|---|---|
OIO-NDR | OIO Navngivnings- og Designregler, OIO-NDR version 3.2, http://www.itst.dk/it-arkitektur-og-standarder/standardisering/datastandardisering/oioxml-udvikling/regler/ndr-3.2 |
DGWS 1.0 | Den Gode Webservice 1.0 |
DGWS 1.0.1 | Den Gode Webservice 1.0.1 |
HSUID-Header | Healthcare Service User Identification Header (SSE/11734/IFS/0018) |
OIO-WSDL | Guideline for development and use of OIOWSDL, http://www.itst.dk/it-arkitektur-og-standarder/standardisering/standarder-for-serviceorienteret-infrastruktur/standarder-for-webservices/filer-til-standarder-for-webservices/OIOWSDL_english.pdf |
...
Læsevejledning
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.
...
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 Den Gode Webservice (DGWS) 1.0.1 described in [DGWS 1.0] and [DGWS 1.0.1] will facilitate comprehension considerably.
...
Dokument historik
| Version | Date | Responsible | Description |
|---|---|---|---|
0.1 | 24.4.2012 | Systematic | Initial version. |
0.2 | 1.5.2012 | Systematic | Optimization of data elements by verification of consent for data elements. Addition of ConsentForForeignerCheck operation. |
0.9 | 14.5.2012 | Systematic | HSUID-header reference added, reading guide updated, web service semantics updated. |
1.0 | 29.6.2012 | Systematic | ConsentForForeignersCheck, SOAP-faults, table elaboration, general improvements. |
1.1 | 28.11.2014 | Systematic | References to National Patient Index (NPI) removed. |
1.2 | 09.09.2016 | Systematic | Changed nsi:skscode to nsi:skskode and nsi:sorcode to nsi:sor to fit XML schema |
1.3 | 13.06.2018 | Systematic | Migrated to NSPOP SVN |
| 22.10.2018 | KIT | Document moved from Word to Confluence. Original document name was: IFS0014 Consent Verification Service Interface Description.docx |
...
MinSpærring Verifikation Bruger Scenarier
The 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.
...
A 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.
The 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.
The 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.
Name: <operation header> | |
|---|---|
Description: | Description of the functions purpose. |
Input: | Input parameters. |
Output: | Output parameters. |
Error handling: | Description of error handling, typically refers to the general description of error handling in (section 4.7). |
Roles: | Description of necessary roles. |
Prerequisites: | Description of prerequisites that must be met for the function to complete successfully. |
Web Service - ConsentVerification
The operations below are available on the verification service.
Operation – ConsentForUserCheck
Name: ConsentForUserCheck | |
|---|---|
Description: | Examines whether a citizen has expressed general positive, general negative or data specific consent towards the user. |
Input: | ConsentForUserCheckRequest which consists of: PatientPersonCivilRegistrationIdentifier Identification of the citizen for which consent is desired examined. HealthcareProfessionalIdentifier HealthcareProfessionalIdentifierOnBehalfOf HealthcareProfessionalOrganization |
Output: | ConsentForUserCheckResponse which consists of: ConsentIndication the states consent for health professional or organization on the form: Positive – means that specific content has been given by the citizen to the concerned health professional or the organization affiliated with the person in question. Negative – means that the health professional does not have access to the citizen’s data. DataSpecificConsent – means that consent exists for specific data, so that it is not possible to decide from the health professional and affiliated organisation alone whether access is possible. Consequently, it is necessary to check consent on the basis of the data the health professionals desires presented. |
Error handling: | See section 4.7. |
Roles: | Health professional. |
Prerequisites: | Both user system and user must be authenticated and authorized as described in section 4.2.1. |
Operation – ConsentForDataCheck
Name: ConsentForDataCheck | |
|---|---|
Description: | Examines whether a citizen has expressed positive or negative consent in regard to the user towards a number of specific data elements. |
Input: | ConsentForDataCheckRequest which consists of: PatientPersonCivilRegistrationIdentifier Identification of which citizen for which consent is desired examined. HealthcareProfessionalIdentifier HealthcareProfessionalIdentifierOnBehalfOf HealthcareProfessionalOrganization ConsentForDataRegistrations |
Output: | ConsentForDataCheckResponse which consists of: PositiveConsentDataRegistrations Collection of document ID’s from ConsentForDataRegistrations input, where positive consent has been given concerning the health professional. |
Error handling: | See section 4.7. |
Roles: | Health professional |
Prerequisites: | Both user system and user must be authenticated and authorized as described in section 4.2.1. |
Operation – ConsentForForeignersCheck
Name: ConsentForForeignersCheck | |
|---|---|
Description: | Examines if the citizen has given positive consent for foreign health professionals to access the citizens’ health information. |
Input: | ConsentForForeignersCheckRequest which consists of: PatientPersonCivilRegistrationIdentifier Identification of the citizen for which consent is desired examined. |
Output: | ConsentForForeignerCheckResponse which consists of: ConsentForForeigners which state consent for foreign health professionals Positive – means that specific consent has been given for foreign health professionals to access the citizens’ information. Negative - means that foreign health professionals do not have access to the citizen’s information. |
Error handling: | See section 4.7. |
Roles: | Health professional |
Prerequisites: | Both user system and user must be authenticated and authorized as described in section 4.2.1. |
...
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 DGWS 1.0.1, in addition to a Healthcare Service User Identification (HSUID) header.
...
The format of Security and Medcom headers are described in [DGWS 1.0] and [DGWS 1.0.1], while the format of the HSUID header is described in [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.
...
Note 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.
...
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.
On HTTP status code 200 FlowStatus is always flow_finalized_succesfully.
Timeout on Web Service Operation
Timeout on web service-operations is the same as default timeout on the NSP platform.
Session
Each request is handled in its own session.
...
This deviates from DGWS 1.0.1 in regard to handling of retransmission.
Assignment and reuse respectively of flow ID
If the request contains a flow ID, it is reused in the reply. Handling of flow ID complies with DGWS 1.0.1.
Processing of Request for 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 [DGWS 1.0] and service specific error codes can be returned.
...
Code listing 1 Structure of SOAP faults returned from Web service operation. The example shows FaultCode used when the ID card has expired.
SOAP Fault Status Codes
For all web service operations described in section 3 will be used SOAP Fault with FaultCode-values as listed in Table 2, originating from DGWS 1.0.1.
...
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 Validation
It is validated that:
Properly formatted 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 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.
...
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
Consent verification service is based on the following standards:
SOAP version 1.1
Soap Fault version 1.1
WS-I Basic Profile 1.1
OIO namegivnings- og designregler
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 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 3.2. Additionally, cardinality is provided when an element is not compulsory.
HealthcareProfessionalIdentifierOnBehalfOf
Element-name | Description |
HeathcareProfessionalIdentifierOnBehalfOf | Identification of the health professional who is acted on behalf of. The field is optional and can be provided without content. |
ConsentForDataRegistrations
Element-name | Description |
ConsentDataRegistration[0..n] | Collection of data elements where consent must be verified. |
ConsentDataRegistration
Element-name | Description |
Identifier[1] | Unique identification of data element (key value) as provided by the calling system. |
Origin[1] | SOR, SHAK or provider-number which states the origin of the data element |
CreationDateTime[1] | Time for creation of data element in question |
ConsentIndication
Element-name | Description |
ConsentIndication | Positive, negative or applicable to specific data. With value set: Positive, Negative, DataSpecificConsent |
ConsentForDataResponse
Element-name | Description |
DataIdentifiers[0..n] | Collection of unique identification of data element (key-value) as provided by the calling system |
ConsentForForeigners
Element-name | Description |
ConsentForForeigners | Positive or negative with value set: Positive, Negative |
...
Styring
...
Dokumentation
For the consent verification, the interface between the actor systems and consent verification is versioned.
...
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
...
where the version changes on redefinition of the ConsentVerification interface.
WSDL
WSDL 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.
...