Page History
Navitabs | ||||
---|---|---|---|---|
| ||||
Table of Contents |
---|
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.
...
Reference | Beskrivelse |
---|---|
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 | Guide for udvikling og anvendelse af 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
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. Kendskab til 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 1beskrevet i [DGWS 1.0] and og [DGWS 1.0.1] will facilitate comprehension considerablyvil gøre forståelsen nemmere.
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 | |
10.11.2020 | KIT | Oversættelse til Dansk samt ajourføring |
MinSpærring Verifikation Bruger Scenarier
The following section describes the usage scenarios that the Web service for consent verification supportsNedenstående beskriver brugerscenarier som service MinSpærring Verifikation understøtter.
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.
NavnName: <operation header> | |||
---|---|---|---|
Beskrivelse | Beskriver operationens formål | Description: | Description of the functions purpose. |
InputForespørgsel: | Input parametersParameter til input. | ||
OutputSvar: | Output parametersParametre i svar. | ||
Error handling: | Description of error handling, typically refers to the general description of error handling in (section 4.7). | ||
Roles: | Description of necessary roles. | ||
Fejlhåndtering: | Beskriver fejlhåndtering. Refererer typisk til den generelle beskrivelse af fejlhåndtering. | ||
Roller: | Beskriver krævede roller. | ||
Forudsætninger: | Beskriver forudsætninger der skal være opfyldt for at operationen kan udføres | 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 serviceNedenstående operationer udstullet af MinSpærring Verifikation.
Operation – ConsentForUserCheck
NameNavn: 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. | ||
Beskrivelse: | Undersøger om en borger har oprettet generelt samtykke, spærring eller data specifik spærring for en bruger. | ||
Forespørgsel: | ConsentForUserCheckRequest består af: PatientPersonCivilRegistrationIdentifier Identifkation af den borger samtykke/spærring ønskes undersøgt. HealthcareProfessionalIdentifier HealthcareProfessionalIdentifierOnBehalfOf HealthcareProfessionalOrganization | ||
Svar: | ConsentForUserCheckResponse består af: ConsentIndication Samtykke, spærring eller dataspecifkt samtykke i nedenstående form: Positive – betyder at den sundhedsaglige har adgang til data. Negative – betyder at den sundhedsfaglige, eller dennes tilknyttede organisation, ikke har adgang til borgerens data. DataSpecificConsent - betyder at der er registreret dataspecikt samtykke eller spærring. Derfor er det ikke muligt at afgøre om den sundhedsfaglige har adgang til data. Derfor skal der laves opfølgende kald til operationen ConsentForDataCheck. | ||
Error handling: | Se afsnit | Error handling: | See section 4.7. |
Roles: | Health professionalSundhedsffaglig. | ||
Prerequisites: | Both user system and user must be authenticated and authorized as described in section 4.2.1.Både bruger og brugersystem skal godkendt som beskrevet i afsnitet Web Service Sikkerhed. |
Operation – ConsentForDataCheck
Navn: 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
Identification of a health professional.
HealthcareProfessionalIdentifierOnBehalfOf
Identification of a health professional, on whose behalf action is taken (is only populated if the performing person is a health professional who acts on behalf of a health professional with authorization in Danish Health Authority’s authorization register).
HealthcareProfessionalOrganization
Identification of the health professional’s organization using a SOR-code.
ConsentForDataRegistrations
Collection of descriptions of data elements that must be verified for consent.
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
Beskrivelse: | Undersøger om en borger har oprettet data specifikke spærringer eller samtykker. |
---|---|
Forespørgsel: | ConsentForDataCheckRequest består af: PatientPersonCivilRegistrationIdentifier Identifkation af den borger samtykke/spærring ønskes undersøgt. HealthcareProfessionalIdentifier HealthcareProfessionalIdentifierOnBehalfOf HealthcareProfessionalOrganization ConsentForDataRegistrations |
Svar: | ConsentForDataCheckResponse består af: PositiveConsentDataRegistrations Liste af dokument ID fra forespørgsel som den sundhedsfaglige har lov til at se. professional. |
Fejlhåndtering: | Se afsnit 4.7. |
Roller: | Sundhedsfaglig. |
Forudsætninger: | Både bruger og brugersystem skal godkendt som beskrevet i afsnitet Web Service Sikkerhed. |
Operation – ConsentForForeignersCheck
Navn: ConsentForForeignersCheck | |
---|---|
Beskrivelse: | Undersøger om en borger har givet samtykke til at en sundhedsfaglig i et andet land må tilgå borgerens data. |
Forespørgsel: | ConsentForForeignersCheckRequest består: PatientPersonCivilRegistrationIdentifier Identifkation af den borger samtykke/spærring ønskes undersøgt. |
Svar: | ConsentForForeignerCheckResponse består af: ConsentForForeigners om der er adgang til data. Positive – betyder at der er oprettet samtykke så den sundhedsfaglige må tilgå borgerens data. Negative - betyder at der ikke er adgang til borgerens data. |
Fejlhåndtering: | Se afsnit 4.7. |
Roller: | Sundhedsfaglig person |
Forudsætninger: | Både bruger og brugersystem skal godkendt som beskrevet i afsnit |
Name: ConsentForForeignersCheck | |
Description: | Examines if the citizen has given positive consent for foreign health professionals to access the citizens’ health information. | Input: | Output: |
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 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 beskrevet 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 [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.
.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.
Element attribut | Underelement Attributværdi | |||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Attributnavn | AttributNavn format | |||||||||||||
The element Attribute | Subelement AttributeValue | |||||||||||||
Name-attribute | NameFormat-attribute | - | ||||||||||||
nsi:UserType | nsi:HealthcareProfessional | |||||||||||||
nsi:ActingUserCivilRegistrationNumberThe health professional’s social security number | Den sundhedsfaglige CPR nummer. | |||||||||||||
nsi:OrgUsingID | nsi:soror nsi:skskode or nsi:ynumber | Identification of the organization that the health professional is affiliated with as user. The attribute must be present at least once and may occur twice. With two occurrences, the organization can be identified by SOR-code and for instance SHAK-code. | nsi:ResponsibleUserCivilRegistrationNumber | Social security number of the health professional under whose responsibility the user acts. If this is the same person as the user, the same social security number is given. | nsi:ResponsibleUserAuthorizationCode | Authorization number listed in the National Board of Health authorization register for the health professional under whose responsibility the user acts. If the user is a health professional without authorization number listed in the National Board of Health authorization register not working under the responsibility of a designated health person, e.g., a paramedic with special competence, the value "-" is indicated. | nsi:SystemOwnerName | Name of the system owner of the user system | nsi:SystemName | Name of the user system | nsi:SystemVersion | Version of the user system | nsi:OrgResponsibleName | Name of the organization responsible for operation of the user system. |
Table 1 Attributes in the HSUID-header applied for user who is a health professional.
or nsi:skskode or nsi:ynumber | Identifikation af den organisation som den sundhedsfaglige er tilknyttet. Attributten skal være der mindst én gang og må maksimalt være angivet to tange. Hvis den er angivet to gange kan organisationen være identificeret ved en SOR kode og f.eks. en SHAK kode. | |
nsi:ResponsibleUserCivilRegistrationNumber | CPR nummer på den sundhedsfaglige som brugeren agerer på vegne aaf. Hvis det er den samme person som brugeren er det samme CPR nummer angivet. | |
nsi:ResponsibleUserAuthorizationCode | Autorisationsnummer på den sundhedsfaglige som brugeren agerer på vegne af. Hvis brugeren er en sundhedsfaglig uden autorisationskode, arbejder på vegne af en sundhedsfaglig uden autorisationskode anvendes specialværdien '-'. | |
nsi:SystemOwnerName | Navn på systemejer af anvendersystemet. | |
nsi:SystemName | Navn på anvendersystem. | |
nsi:SystemVersion | Version af anvendersystem. | |
nsi:OrgResponsibleName | Navn på organisation ansvarlig for anvendersystem. |
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:
Code Block | ||
---|---|---|
| ||
<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:
Code Block | ||
---|---|---|
| ||
<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> |
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 systemsBemærk at det er anvendersystemets ansvar at sikre konsistes mellem de angive organisationer.
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 retransmission.
Assignment and reuse respectively of flow ID
i forhold til håndtering af genfremsendelse.
Tildeling og genbrug af flow-ID
Hvis request indeholder et flow-ID bliver det genbrugt i svaret. Håndtering af flow-ID sker i henhold til If the request contains a flow ID, it is reused in the reply. Handling of flow ID complies with 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 non-repudiation, a fault-error message is returned as described in [DGWS 1.0].
Digital signering af svar understøttes ikke. På anmodning om Non-Repudiation returneres en fejlfejlmeddelelse som beskrevet i [DGWS 1.0].
...
Fejlhåndtering
SOAP
...
fejl
SOAP-fejl returneres som beskrevet nedenfor. Der er valgt en struktur, hvor både standardfejlkoder som beskrevet i 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 returnedog servicespecifikke fejlkoder kan returneres.
Code Block | ||
---|---|---|
| ||
<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.
FaultCode | DescriptionBeskrivelse | |
---|---|---|
missing_required_header | One or more mandatory DGWS headers are missing in the enclosed message, e.g. ID card, which always must be providedEn eller flere krævede DGWS headers mangler i request. F.eks. skal ID-kort altid være angivet. | |
security_level_failed | Authentication or authorization error. Invalid choice of security level Godkendelses fejl. Forkert id-kort niveau. | |
invalid_idcard | Authentication or authorization error. Error in Godkendelses fejl. Fejl i SOSI ID cardkort. | |
invalid_certificate | Authentication or authorization error. Certificate is not OCES or expiredGodkendelses fejl.. Certifikat er ikke OCES certifikat eller også er det udløbet. | |
expired_idcard | Authentication or authorization error. SOSI ID expired or too old for this Web service providerGodkendelses fejl. SOSI ID kort er udløbet eller for gammel i forhold til kravet i servicen. | |
not_authorized | User has insufficient rights to perform the Web service operation call. E.g., company registration number is not on whitelistBruger har ikke ret til at anvende Web Service operationen. F.eks. cvr nummer der ikke er whitetlisted. | |
nonrepudiation_not_supported | Web service provider system cannot perform a digital signature on the reply. | Service kan ikke signere svar da dette ikke er understøttet. |
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.
FaultCode | DescriptionBeskrivelse |
---|---|
consent_service.ConsentDatabaseAn internal server error has occurred in connection with consent database communication | En intern fejl i servicen i forbindelse med adgang til databasen. |
consent_service.SORLookup | An internal server error has occurred in connection with lookup in the SOR-tableEn intern fejl i servicen i forbindelse med opslag i SOR data. |
consent_service.ServiceInvocation | The service was called with invalid parameters: |
invalid_date_timezone | An attached date has En dato i request er i invalid format, cf. De skal følge DGWS 1.0.1. |
consent_service.UnknownError | An unknown server error resulted in failed call |
Table 3 Applied service-specific FaultCode-values
Ukendt fejl i servicen. |
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:
SOAP version 1.1
Soap Fault version 1.1
WS-I Basic Profile 1.1
OIO namegivningsnavngivnings- 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 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
Element-namenavn | DescriptionBeskrivelse |
HeathcareProfessionalIdentifierOnBehalfOf | Identification of the health professional who is acted on behalf of. The field is optional and can be provided without contentIdentifikation af den sundhedsfaglige der arbejdes på vegne af. Feltet er optionelt og kan angives uden samtykke. |
ConsentForDataRegistrations
Element-namenavn | DescriptionBeskrivelse |
ConsentDataRegistration[0..n] | Collection of data elements where consent must be verifiedListe af data elementer der skal laves verifikation på. |
ConsentDataRegistration
Element-namenavn | DescriptionBeksirvelse |
Identifier[1] | Unique identification of Unik identifikation af data element (key value) as provided by the calling nøgleværdi) som angivet af kalende system. |
Origin[1] | SOR, SHAK or provider-number which states the origin of the data elementeller yder nummer der angiver hvilken organisation datalementet stammer fra. |
CreationDateTime[1]Time for creation of data element in question | Tidspunkt hvor dataelement blev oprettet. |
ConsentIndication
Element-namenavn | DescriptionBeskrivelse |
ConsentIndication | Positive, negative or applicable to specific data. With value setPositim, negativ eller data specifikt. Nedenstående værdisæt anvendes: Positive, Negative, DataSpecificConsent |
ConsentForDataResponse
Element-namenavn | DescriptionBeskrivelse |
DataIdentifiers[0..n] | Collection of unique identification of Liste af unikke id af data element (key-value) as provided by the calling system nøgleværdi) som angivet af det kalende system. |
ConsentForForeigners
Element-namenavn | DescriptionBeskrivelse |
ConsentForForeigners | Positive or negative with value setPositiv eller negativ med nedenstående værdisæt: Positive, Negative |
Styring
Dokumentation
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
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
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
:verification: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.