Page History
Besked format
Web servicen forventer SOAP beskeder. SOAP headeren indeholder sikkerheds header og Medcom header som krævet i DGWS 1.0.1. Udover dette skal der også være en HSUID header.
| Navitabs | ||||
|---|---|---|---|---|
| ||||
...
I det følgende afsnit beskrives de brugsscenarier, som MinSpærring Administration understøtter.
En ny version af grænsefladen snitfladen er tilføjet. I denne grænseflade er operationerne ConsentAdd og ConsentModify opdelt i to separate operationer - i alt fire operationer: ConsentAddPositiveV2, ConsentAddContraintV2, ConsentModifyPositiveV2, ConsentModifyConstraintV2
The following section describes the usage scenarios that the Web service for consent administration supports.
A new version of the interface has been added. In this interface the operations ConsentAdd and ConsentModify has been splitted into two seperate operations - four operations in total: ConsentAddPositiveV2, ConsentAddContraintV2, ConsentModifyPositiveV2, ConsentModifyConstraintV2
Health Professional Registers Consent in a Citizen’s Consent Registrations
A health professional is able to add positive and negative consent on behalf of the citizen to the citizen’s present consent registrations.
As the change entails an entry in the citizen’s Min-log, the citizen will be able to later learn this.
This usage scenario is supported by the operation ConsentAdd in the original version of the consent administration interface.
This usage scenario is supported by the operation ConsentAddPositiveV2 or ConsentAddConstraintV2 in the new version of the consent administration interface.
Citizen Retrieves an Overview of Present Consent Registrations
A citizen can retrieve a complete overview of the consents, that are registered for the citizen, whether they are registered by the citizen, a person on behalf of the citizen or by a health professional.
Another person than the citizen can, on behalf of the citizen, perform the activity. As the action entails an entry in the citizen’s Min-log, the citizen will later be able to learn of the action performed by the person.
This usage scenario is supported by the operation ConsentRegistrationsGet in the original version of the consent administration interface.
This usage scenario is supported by the operation ConsentRegistrationsGetV2 in the new version of the consent administration interface.
The result of the operation is a complete list of all active and inactive consent registrations for the citizen in question.
Registration of Negative Consent
A citizen can register negative consent covering:
(what) Possibly everything in regard to (who) everybody or a specific (named) person provided by social security number.
Or (what) selected information, originating from organization provided by SOR-code – with or without subordinate organizations - created in a certain period in respect to (who) everybody.
(when) a validity period for the consent provided by start and end date, where end date is not a requirement.
Another person than the citizen can, on behalf of the citizen, perform the activity. As the action entails an entry in the citizen’s Min-log, the citizen will later be able to learn of the action performed by the person.
This usage scenario is supported by the operation ConsentAdd in the original version of the consent administration interface.
This usage scenario is supported by the operation ConsentAddPositiveV2 in the new version of the consent administration interface.
Registration of Positive Consent
A citizen can register positive consent covering:
(what) Possibly everything in regard to (who) for a specific identified person provided by social security number or for an organization provided by SOR-code – with or without subordinate organization – or for foreign health professionals provided by positive marking.
...
(when) a validity period for the consent provided by start and end time. The validity can at most cover one year.
Sundhedsfaglig Registrerer på Vegne af en Borger
En sundhedsfaglig er i stand til at tilføje et samtykke eller en spærring på borgerens vegne til borgerens nuværende registreringer.
Da ændringen medfører en registrering i borgerens Min-log, vil borgeren senere kunne se dette.
Dette brugsscenarie understøttes af operationen ConsentAdd i den originale version af grænsefladen til MinSpærring Administration.
Dette brugsscenarie understøttes af operationen ConsentAddPositiveV2 eller ConsentAddConstraintV2 i den nye version af grænsefladen til administration afregistreringer.
Borger Henter en Oversigt Over Nuværende MinSpærring Registreringer
En borger kan hente et komplet overblik, over de registreringer der er for borgeren i MinSpærring, hvad enten de er registreret af borgeren, en person på vegne af borgeren eller af en sundhedsfaglig.
En anden person end borgeren kan på borgerens vegne udføre aktiviteten. Da handlingen indebærer en registrering i borgerens Min-log, vil borgeren senere være i stand til at se at handlingen er udført af en anden person.
Dette brugsscenarie understøttes af operationen ConsentRegistrationsGet i den oprindelige version af grænsefladen til MinSpærring Administration.
Dette brugsscenario understøttes af operationen ConsentRegistrationsGetV2 i den nye version af grænsefladen til MinSpærring Administration.
Resultatet af operationen er en komplet liste over alle aktive og inaktive registreringer for den pågældende borger.
Registrering af Spærring
En borger kan registrere en spærring, der dækker:
- (hvad) Muligvis alt hvad angår (hvem) alle eller en bestemt (navngivet) person identificeret ved CPR-nummer.
- Eller (hvad) valgte oplysninger, der stammer fra en organisation, der identificeres via en SOR-kode - med eller uden underordnede organisationer - oprettet i en bestemt periode i forhold til (hvem) alle.
- (når) en gyldighedsperiode for samtykke fra start- og slutdato, hvor slutdato ikke er et krav.
En anden person end borgeren kan på borgerens vegne udføre aktiviteten. Da handlingen indebærer en registrering i borgerens Min-log, vil borgeren senere være i stand til at se at handlingen er udført af en anden person.
Dette brugsscenarie understøttes af operationen ConsentAdd i den originale version af grænsefladen til administration af samtykke.
Dette brugsscenarie understøttes af operationen ConsentAddPositiveV2 i den nye version af grænsefladen til MinSpærring Administrtation.
Registrering af Samtykke
En borger kan registrere samtykke, der dækker:
- (hvad) Muligvis alt med hensyn til (hvem) for en bestemt identificeret person identificeret med CPR-nummer eller for en organisation identificeret via en SOR-kode - med eller uden underordnet organisationer - eller for udenlandske sundhedsfaglige.
- Eller (hvilke) valgte oplysninger, der stammer fra en bestemt organisation identificeret via SOR-kode - med eller uden underordnet organisationer - oprettet i en bestemt periode i forhold til (hvem) enten en bestemt navngivet person, der er identificeret via CPR-nummer eller for en bestemt organisation, der er identificeret via SOR-kode - med eller uden underordnede organisationer.
- (hvornår) en gyldighedsperiode for samtykke fra start- og sluttidspunkt. Gyldigheden kan højst dække et år.
Aktiviteten kan udføres af en anden person end borgeren, der har samtykke fra borgeren til at udføre handlingen. . Da handlingen indebærer en registrering i borgerens Min-log, vil borgeren senere være i stand til at se at handlingen er udført af en anden person.
Dette brugsscenarie understøttes af operationen ConsentAdd i den originale version af grænsefladen til MinSpærring Administration.
Dette brugsscenarie understøttes af operationen ConsentAddConstraintV2 i den nye version af grænsefladen til MinSpærring Administration.
Borger Ændrer Registrering
En borger kan ændre en eller flere samtykker eller spærringer.
Aktiviteten kan udføres af en anden person end borgeren, der har samtykke fra borgeren til at udføre handlingen. Da handlingen indebærer en registrering i borgerens Min-log, vil borgeren senere være i stand til at se at handlingen er udført af en anden person.
Dette brugsscenarie understøttes af operationen ConsentModify i den oprindelige version af grænsefladen til MinSpærring Administration.
Dette brugsscenarie understøttes af operationerne ConsentModifyPositiveV2 eller ConsentModifyConstraintV2 i den nye version af grænsefladen til MinSpærring Administration.
Borger Ophæver Spærring/Samtykke
En borger kan ophæve samtykker og spærringer.
Aktiviteten kan udføres af en anden person end borgeren, der har samtykke fra borgeren til at udføre handlingen. Da handlingen indebærer en registrering i borgerens Min-log, vil borgeren senere være i stand til at se at handlingen er udført af en anden person.
Dette brugsscenarie understøttes af operationen ConsentRevoke i den oprindelige version af grænsefladen til MinSpærring Administration.
Dette brugsscenarie understøttes af operationen ConsentRevokeV2 i den nye version af grænsefladen til MinSpærring Administration.
MinSpærring Administration Web Service
Læsevejledning
Skabelonen nedenfor bruges til at dokumentere de operationer, der tilbydes i MinSpærring Administration. De vigtigste elementer til input og output er beskrevet i MinSpærring Administration WebService Skemaer.
Navn: <operation> | |
|---|---|
Beskrivelse: | Beskriver operationens formål. |
Forespørgsel: | Parametre til input. |
Svar: | Parametre i svar. |
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. |
Web Service - ConsentAdministration (Original)
Operation – ConsentRegistrationsGet
Navn: ConsentRegistrationsGet | |
|---|---|
Beskrivelse: | Henter alle registreringer for en given borger. |
| Forespørgsel: | ConsentRegistrationsGetRequest der består af: PatientPersonCivilRegistrationIdentifier Identifikation af borger der forespørges på. |
Svar: | ConsentRegistrationsGetResponse der består af: ConsentRegistrations Liste af alle aktive og inaktive registreringer for borgeren. |
Fejlhåndtering: | Se den generelle beskrivelse af fejlhåndtering. |
Roller: | Borger, person på vegne af borger. |
Forudsætninger: | Både bruger og brugersystem skal godkendes som beskrevet i afsnitet Web Service Sikkerhed. |
Operation – ConsentAdd
Navn: ConsentAdd | |
|---|---|
| Beskrivelse: | Tilføjer en eller flere samtykker eller spærringer for en given borger. |
Forespørgsel: | ConsentAddRequest der består af: ConsentAdds liste af beskrivelser af registreringer af samtykker/spærringer, der skal tilføjes. Bemærk, at borgeren er identificeret i ConsentAdds. |
Svar: | Ingen |
Fejlhåndtering: | Se den generelle beskrivelse af fejlhåndtering. |
Roller: | Borger, sundhedsfaglig, person på vegne af borger. |
Forudsætninger: | Både bruger og brugersystem skal godkendes som beskrevet i afsnitet Web Service Sikkerhed. Gentagne kald med identiske parametre vil der blive oprettet flere identiske spærringer eller samtykker. |
Operation – ConsentModify
Navn: ConsentModify | |
|---|---|
Beskrivelse: | Opdaterer regsitreringer for en borger. |
Forespørgsel: | ConsentModifyRequest der består af: ConsentModifications Liste af beskrivelser af samtykker/spærringer, som ønskes modificeret. Bemærk, at borgeren er identificeret i ConsentModification. |
Svar: | Ingen |
Fejlhåndtering: | Se den generelle beskrivelse af fejlhåndtering. |
Roller: | Borger, person på borgerens vegne |
Forudsætninger: | Både bruger og brugersystem skal godkendes som beskrevet i afsnitet Web Service Sikkerhed. |
Operation – ConsentRevoke
Navn: ConsentRevoke | |
|---|---|
Beskrivelse: | Tilbagekalder en eller flere registreringer i MinSpærring. Dette finder sted ved inaktivering af givne registreringer. |
Forespørgsel: | PatientConsentRevokeRequest der består af: ConsentRevocations Liste af beskrivelser af registreringer, der skal tilbagekaldes. Bemærk, at borgeren er identificeret i ConsentRevocation. |
Svar: | Ingen |
Fejlhåndtering: | Se den generelle beskrivelse af fejlhåndtering. |
Roller: | Borger |
Forudsætninger: | Både bruger og brugersystem skal godkendes som beskrevet i afsnitet Web Service Sikkerhed. |
The activity can be performed by a person other than the citizen, on behalf of the citizen. As the action entails an entry in the citizen’s Min-log, the citizen will be able to later learn of this person’s action.
This usage scenario is supported by the operation ConsentAdd in the original version of the consent administration interface.
This usage scenario is supported by the operation ConsentAddConstraintV2 in the new version of the consent administration interface.
Citizen Modifies Consent
A citizen can change one or more positive or negative consent registrations.
The activity can be performed by another person than the citizen, on behalf of the citizen. As the action entails an entry in the citizen’s Min-log, the citizen will be able to later learn of this person’s action.
This usage scenario is supported by the operation ConsentModify in the original version of the consent administration interface.
This usage scenario is supported by the operations ConsentModifyPositiveV2 or ConsentModifyConstraintV2 in the new version of the consent administration interface.
Citizen Nullifies Consent
A citizen can nullify positive and negative consent registrations.
The activity can be performed by another person than the citizen, on behalf of the citizen. As the action entails an entry in the citizen’s Min-log, the citizen will be able to later learn of this person’s action.
This usage scenario is supported by the operation ConsentRevoke in the original version of the consent administration interface.
This usage scenario is supported by the operation ConsentRevokeV2 in the new version of the consent administration interface.
Consent Administration Web Service
Reading Guide
The template below is used to document the operations that are offered in the Consent Administration Web Service. The most important elements for input and output are described in section 5.
...
Name: <operation header>
...
Description:
...
Description of the function’s purpose.
...
Input:
...
Input parameters.
...
Output:
...
Output parameters.
...
Error handling:
...
Description of error handling; typically refers to the general description of error handling in 4.7.
...
Roles:
...
Description of necessary roles.
...
Prerequisites:
...
Description of prerequisites that must be met for the function to complete successfully.
Web Service - Consent_Administration (Original)
Operation – ConsentRegistrationsGet
...
Name: ConsentRegistrationsGet
...
Description:
...
Retrieves descriptions of all registrations of consents applicable to given citizen.
...
Input:
...
ConsentRegistrationsGetRequest which consists of:
PatientPersonCivilRegistrationIdentifier Identification of the citizen for which consent registrations are desired
...
Output:
...
ConsentRegistrationsGetResponse which consists of:
ConsentRegistrations Collection of all active and inactive consent registrations registered for citizen in question.
...
Error handling:
...
See section 4.7.
...
Roles:
...
Citizen, person (on behalf of citizen)
...
Prerequisites:
...
Both user system and user must be authenticated and authorized as described in section 4.2.1.
Operation – ConsentAdd
...
Name: ConsentAdd
...
Description:
...
Adds active consent/active consents applicable to given citizen.
...
Input:
...
ConsentAddRequest which consists of:
ConsentAdds Collection of descriptions of registrations of consents, that are to be added. Note that the citizen is identified in ConsentAdds.
...
Output:
...
Nothing
...
Error handling:
...
See section 4.7.
...
Roles:
...
Citizen, health professional, person (on behalf of citizen).
...
Prerequisites:
...
Both user system and user must be authenticated and authorized as described in section 4.2.1. The operation is not idempotent and on repeated calls with identical parameters, multiple identical consents will be created (see section 1.6).
Operation – ConsentModify
...
Name: ConsentModify
...
Description:
...
Updates consent(s) from the collection of consents applicable to given citizen.
...
Input:
...
ConsentModifyRequest which consists of:
ConsentModifications Collection of descriptions of consents, that are desired modified. Note that the citizen is identified in ConsentModification.
...
Output:
...
Nothing
...
Error handling:
...
See section 4.7.
...
Roles:
...
Citizen, person (on behalf of the citizen)
...
Prerequisites:
...
Both user system and user must be authenticated and authorized as described in section 4.2.1.
Operation – ConsentRevoke
Name: ConsentRevoke | |
|---|---|
Description: | Revokes given consent(s) from the collection of consents applicable to the provided citizen. This takes place by inactivation of the revoked consents. |
Input: | PatientConsentRevokeRequest which consists of: ConsentRevocations Collection of descriptions of consents, that are to be revoked. Note that the citizen is identified in ConsentRevocation. |
Output: | Nothing |
Error handling: | See section 4.7. |
Roles: | Citizen |
Prerequisites: | Both user system and user must be authenticated and authorized as described in section 4.2.1. |
Web Service - Consent_Administration (V2)
...
Name: ConsentRegistrationsGet | |||
|---|---|---|---|
DescriptionBeskrivelse: | Retrieves descriptions of all registrations of consents applicable to given citizen. | ||
Input: | ConsentRegistrationsGetRequest which consists of: PatientPersonCivilRegistrationIdentifier Identification of the citizen for which consent registrations are desired | ||
Output: | ConsentRegistrationsGetResponse which consists of: ConsentRegistrations Collection of all active and inactive consent registrations registered for citizen in question. | ||
Error handling: | See section 4.7. | ||
Roles: | Citizen, person (on behalf of citizen) | ||
Henter alle registreringer for en given borger. | |||
Forespørgsel: | ConsentRegistrationsGetRequest der består af: PatientPersonCivilRegistrationIdentifier Identifikation af borger der forespørges på. | ||
Svar: | ConsentRegistrationsGetResponse der består af: ConsentRegistrations Liste af alle aktive og inaktive registreringer for borgeren. | ||
Fejlhåndtering: | Se den generelle beskrivelse af fejlhåndtering. | ||
Roller: | Borger, person på vegne af borger. | ||
Forudsætninger: | Både bruger og brugersystem skal godkendes som beskrevet i afsnitet Web Service Sikkerhed | Prerequisites: | Both user system and user must be authenticated and authorized as described in section 4.2.1. |
Operation – ConsentAddPositiveV2
Name: ConsentAddPositiveV2 | |||
|---|---|---|---|
Description: | Adds a positive active consent/active consents applicable to given citizen. | ||
Input: | ConsentAddPositiveV2Request which consists of: ConsentAdds Collection of descriptions of registrations of consents, that are to be added. Note that the citizen is identified in ConsentAdds. | ||
Output: | Nothing | ||
Error handling: | See section 4.7. | ||
Roles: | Citizen, health professional, person (on behalf of citizen). | ||
Beskrivelse: | Tilføjer et eller flere samtykker for den givne borger. | ||
Forespørgsel: | ConsentAddPositiveV2Request der består af: ConsentAdds Liste af samtykker, der skal tilføjes. Bemærk, at borgeren er identificeret i ConsentAdds. | ||
| Svar: | Ingen | ||
Fejlhåndtering: | Se den generelle beskrivelse af fejlhåndtering. | ||
Roller: | Borger, sundhedsfaglig, person på vegne af borger. | ||
Forudsætninger: | Både bruger og brugersystem skal godkendes som beskrevet i afsnitet Web Service Sikkerhed. Gentagne kald med identiske parametre vil der blive oprettet flere identiske spærringer eller samtykker. | Prerequisites: | Both user system and user must be authenticated and authorized as described in section 4.2.1. The operation is not idempotent and on repeated calls with identical parameters, multiple identical consents will be created (see section 1.6). |
Operation – ConsentAddConstraintV2
Name: ConsentAddPositiveV2 | |||
|---|---|---|---|
Description: | Adds a constraining active consent/active consents applicable to given citizen. | ||
Input: | ConsentAddConstraintV2Request which consists of: ConsentAdds Collection of descriptions of registrations of consents, that are to be added. Note that the citizen is identified in ConsentAdds. | ||
Output: | Nothing | ||
Error handling: | See section 4.7. | ||
Roles: | Citizen, health professional, person (on behalf of citizen). | ||
Beskrivelse: | Tilføjer en eller flere spærringer for den givne borger. | ||
Forespørgsel: | ConsentAddConstraintV2Request der består af: ConsentAdds Liste af spærringer, der skal tilføjes. Bemærk, at borgeren er identificeret i ConsentAdds. | ||
Svar: | Ingen | ||
Fejlhåndtering: | Se den generelle beskrivelse af fejlhåndtering. | ||
Roller: | Borger, sundhedsfaglig, person på vegne af borger. | ||
Forudsætninger: | Både bruger og brugersystem skal godkendes som beskrevet i afsnitet Web Service Sikkerhed. Gentagne kald med identiske parametre vil der blive oprettet flere identiske spærringer eller samtykker | Prerequisites: | Both user system and user must be authenticated and authorized as described in section 4.2.1. The operation is not idempotent and on repeated calls with identical parameters, multiple identical consents will be created (see section 1.6). |
Operation – ConsentModifyPositiveV2
Name: ConsentModifyPositiveV2 | |||
|---|---|---|---|
Description: | Updates consent(s) from the collection of consents applicable to given citizen. | ||
Input: | ConsentModifyPositiveV2Request which consists of: ConsentModifications Collection of descriptions of consents, that are desired modified. Note that the citizen is identified in ConsentModification. | ||
Output: | Nothing | ||
Error handling: | See section 4.7. | ||
Roles: | Citizen, person (on behalf of the citizen) | ||
Beskrivelse: | Modificerer et eller flere samtykker for en borger. | ||
Forespørgsel: | ConsentModifyPositiveV2Request der består af: ConsentModifications Liste af samtykker som ønskes rettet. Bemærk, at borgeren er identificeret i ConsentModification. | ||
Svar: | Ingen | ||
Fejlhåndtering: | Se den generelle beskrivelse af fejlhåndtering. | ||
Roller: | Borger eller person på vegne af borger. | ||
Forudsætninger: | Både bruger og brugersystem skal godkendes som beskrevet i afsnitet Web Service Sikkerhed. | Prerequisites: | Both user system and user must be authenticated and authorized as described in section 4.2.1. |
Operation – ConsentModifyConstraintV2
Name: ConsentModifyConstraintV2 | |||
|---|---|---|---|
Description: | Updates consent(s) from the collection of consents applicable to given citizen. | ||
Input: | ConsentModifyConstraintV2Request which consists of: ConsentModifications Collection of descriptions of consents, that are desired modified. Note that the citizen is identified in ConsentModification. | ||
Output: | Nothing | ||
Error handling: | See section 4.7. | ||
Roles: | Citizen, person (on behalf of the citizen) | ||
Beskrivelse: | Opdaterer en eller flere spærringer for en borger. | ||
Forespørgsel: | ConsentModifyConstraintV2Request der består af: ConsentModifications Liste af spærringer som ønskes rettet. Bemærk, at borgeren er identificeret i ConsentModification. | ||
Svar: | Ingen | ||
Fejlhåndtering: | Se den generelle beskrivelse af fejlhåndtering. | ||
Roller: | Borger eller person på vegne af borger. | ||
Forudsætninger: | Både bruger og brugersystem skal godkendes som beskrevet i afsnitet Web Service Sikkerhed. | Prerequisites: | Both user system and user must be authenticated and authorized as described in section 4.2.1. |
Operation – ConsentRevokeV2
Name: ConsentRevoke | |
|---|---|
Description: | Revokes given consent(s) from the collection of consents applicable to the provided citizen. This takes place by inactivation of the revoked consents. |
Input: | PatientConsentRevokeRequest which consists of: ConsentRevocations Collection of descriptions of consents, that are to be revoked. Note that the citizen is identified in ConsentRevocation. |
Output: | Nothing |
Error handling: | See section 4.7. |
Roles: | Citizen |
Prerequisites: | Both user system and user must be authenticated and authorized as described in section 4.2.1. |
Consent Administration Web Service Semantics
Message 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.
Figure 1 SOAP message containing security header, Medcom header and HSUID header is used as message format.
Beskrivelse: | Tilbagekalder en eller flere registreringer i MinSpærring. Dette finder sted ved inaktivering af givne registreringer. |
|---|---|
Forespørgsel: | PatientConsentRevokeRequest der består af: ConsentRevocations Liste af registreringer der skal tilbagekaldes. |
Svar: | Ingen |
Fejlhåndtering: | Se den generelle beskrivelse af fejlhåndtering. |
Roller: | Borger |
Forudsætninger: | Både bruger og brugersystem skal godkendes som beskrevet i afsnitet Web Service Sikkerhed. |
MinSpærring Verifikation Web Service Semantiker
Besked format
Web servicen forventer SOAP beskeder. SOAP headeren indeholder sikkerheds header og Medcom header som krævet i DGWS 1.0.1. Udover dette skal der også være en HSUID header.
Figur 1 SOAP besked indeholdende sikkerhedsheader, Medcomheader samt HSUID header.
Formatet af sikkederhedsheader og Medcomheader er beskrevet i [DGWS 1.0] og 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. Formatet for HSUID-headeren er beskrevet i [HSUID-headerHeader].
Attributes in HSUID-header applied for user who is a citizen
When user of the service is a citizen, then the attributes in Table 1 from the HSUID-header are applied.
Attributter i HSUID headeren når bruger er borger
Når anvenderen af servicen er en borger så er det attributerne i tabel 1 der anvendes.
| Element attribut | Underelement Attributværdi | ||
|---|---|---|---|
Attributnavn | Attributnavn format | ||
| The element Attribute | Subelement AttributeValue | ||
Name-attribute | NameFormat-attribute | - | |
nsi:UserType | nsi:Citizen | ||
nsi:ActingUserCivilRegistrationNumber | Citizen’s social security numberBorgers CPR nummer | ||
nsi:SystemOwnerName | Name of system owner of the user systemNavn på systemejer af anvendersystemet. | ||
nsi:SystemName | Name of the user system Navn på anvendersystem. | ||
nsi:SystemVersion | Version of the user systemaf anvendersystem. | ||
nsi:OrgResponsibleName | Name of organization responsible for operation of the user system | ||
Table 1 Attributes in HSUID-header applied for user who is citizen.
Attributes in HSUID-header applied for user who is a health professional
When the user of the service is a health professional, then the attributes in Table 2 from the HSUID-header are applied.
Navn på organisation ansvarlig for anvendersystem. | ||
Tabel 1 Attributer i HSUID-header når bruger borger.
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 | |
Subelement
AttributeValue
Name-attribute
- | ||
|---|---|---|
nsi:UserType | nsi:HealthcareProfessional | |
nsi:ActingUserCivilRegistrationNumber |
Den sundhedsfaglige CPR nummer. | |
nsi:OrgUsingID | nsi:sor or 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 and not working under the responsibility of 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 2 Attributes in the HSUID-header applied for user who is a health professional.
...
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 2 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-kode:
| Code Block | ||
|---|---|---|
| ||
<hsuid:Attribute Name="nsi:OrgUsingID" NameFormat="nsi:skskode"> <hsuid:AttributeValue>6620151</hsuid:AttributeValue> </hsuid:Attribute> |
Alternatively, the organization of 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
...
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 and a IDWS security context ticket is provided to the service.
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 either the IDWS ticket or 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.
Web service operation(s), where the user is the citizen or a citizen, acting on behalf of another
The Web service authorize all users who are citizens to use its operations.
It is the user’s responsibility to ensure that the person is allowed to act on behalf of the citizen.
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
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.
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
If the request contains a flow ID, it is reused in possible forward calls to Min-log. Handling of flow ID complies with DGWS 1.0.1.
...
Sikkerhed
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.
Web Service Operaioner hvor anvender er borger eller person på vegne af borger
Servicen godkender alle borgere.
Det er anvenders ansvar at sikre at personen må agere på vegne af borger.
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 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 DGWS 1.0.1 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 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 [DGWS 1.0].
Error Handling
SOAP errors
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:adminverification: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-errors returned from the 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 Web service operations described in section 3 will be used SOAP Fault with FaultCode-values as listed in Table 3, originating from alle web service 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 |
|---|
Beskrivelse |
|---|
missing_required_header |
En eller flere krævede DGWS headers mangler i request. F.eks. skal ID-kort altid være angivet. |
security_level_failed |
Godkendelses fejl. Forkert id-kort niveau. |
invalid_idcard |
Godkendelses fejl. Fejl i SOSI ID |
kort. |
invalid_certificate |
Authentication or authorization error. Certificate is not OCES or expired.
Godkendelses fejl.. Certifikat er ikke OCES certifikat eller også er det udløbet. |
expired_idcard |
Godkendelses fejl. SOSI ID |
kort er udløbet eller for gammel i forhold til kravet i servicen. |
not_authorized |
Bruger 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 provide a digital signature on the reply.
Service kan ikke signere svar da dette ikke er understøttet. |
Tabel 3 Anvendte Faultcode værdier stammende fra Table 3 Applied FaultCode-values originating from DGWS 1.0.1
Additionally, Web service specific FaultCode values as listed in Table 4 are usedDerudover anvendes tjenestespecifikke FaultCode værdier som anført i tabel 4.
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.ConsentValidationThe consent contained invalid values or compulsory values were not provided | Rgistreringen indeholdt ugyldige værdier eller obligatoriske værdier blev ikke givet |
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 parametersService blev kaldt med ugyldige parametre: The attached HSUID-header is invalid. Consents for more than one citizen has been attached er ikke valid Registreringer for mere end en borger i input. A health professional attempts to retrieve, modify or delete consentsEn sundhedsfaglig forsøger at hente, rette eller slette registreringer. |
consent_service.MinLogClientA error occurred when trying to log this action in the citizen’s ’Min-log’ | Der opstod en fejl i forbindelse med registrering i borgerens MinLog. |
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 callUkendt fejl i servicen. |
Table 4 Applied service-specific FaultCode values
In WSDL, that describes the Web service described in this document, these SOAP Fault status codes are not specified for every WSDL'en tilhørende servicen specificerer ikke SOAP fejlkoder for hver operation.
Web Service Input
...
Validering
Nedenstående valideres
...
:
- 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 and 4.1.2, are provided. 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 following is not performed:
XML-schema validation
Validation that given authorization numbers are valid and found National Board of Health authorization register
Validation that there is consistency between the health professional’s organization ID's when multiple ID and classification systems are provided.
Validation that a health care professional is affiliated with stated organization
Validation that the user is acting under responsibility of stated health professional
...
- . 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. :
SOAP version 1.1
Soap Fault version 1.1
WS-I Basic Profile 1.1
OIO navngivnings- og designregler
DGWS 1.0.1, 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.
Consent administration service is based on the following standards:
SOAP version 1.1
Soap Fault version 1.1
WS-I Basic Profile 1.1
OIO naming and design rules
DGWS 1.0.1, with the exception of requirements regarding retransmission and control of reuse of message ID as described in section 4.5.1, and with the exception of structure used on errors as described in section 4.7.
Consent Administration Web Service Schemas
and with the exception of structure used on errors as described in section 4.7.
MinSpærring Administration WebService Skemaer
Dette afsnit giver en generel beskrivelse af nøgleelementerne i XML-skemaerne, der sammen med WSDL definerer de services der er beskrevet tidligere Hvor eksisterende OIO-typer identificeres, angives den i parentes efter elementnavnet. Derudover tilvejebringes kardinalitet, når et element ikke er obligatoriskThis section provides a general description of the key elements in the XML schemas that together with WSDL define the Web service operations described in section 3.2. Where existing OIO-type is identified, it is provided in the parenthesis after the element name. Additionally, cardinality is provided when an element is not compulsory.
ConsentItem
Element-namenavnDescription | Beskrivelse |
CitizenCPRThe citizen’s social security number | borgerens CPR nummer. |
ConsentIdUnique identification of consent | Unik ID på registreringen |
PositiveConsentTrue if positive or negative | Sandt hvis der er tale om et samtykke. |
What[0..1] | Description of which sensitive data the consent concernsBeskrivelse af hvilke data registreringen dækker. |
Who [0..1] | Description of which individual health professionals or health organizations the consent coversBeskrivelse afsundhedsfaglig person eller organisation som registreringen dækker. |
ValidFrom | Validity period beginning of consent. This is only a date and not a timestampHvornår registreringen er gyldig. Bemærk at dette kun er en dato. |
ValidTo [0..1] | Validity period end of consent. This is only a date and not a timestampHvornår registreringen ikke længere er gyldt. Bemærk at dette kun er en dato. |
WhatItem
Element-namenavn | DescriptionBeskrivelse |
OrganizationIdentifierIdentification of specific health organization, possibly with subordinate organization, from which data originates | Identifikation af specifik sundhedsorganisation, muligvis med underorganisationer, hvorfra data stammer |
IncludeSuborganizationsWhether data from subordinate departments for the stated organization, are also included in the consent | Om data fra underorganisationer for den angivne organisation også er inkluderet i registreringen. |
ReferralStartDate [0..1] | Start date from when data is applicableStartdato fra hvor data er gældende. |
ReferralEndDate [0..1] | End date from when data is applicableSlutdato fra hvor data er gældende. |
WhoItem
Element-namenavn | DescriptionBeskrivelse |
HealthcareProfessionalIdentifierIdentification of a specific health professional by social security number | Identifikation af en bestemt sundhedsfaglig ved hjælp af CPR-nummer. |
Eller | |
OrganizationIdentifierIdentification of specific health organization, possibly having subordinate organization | Identifikation af specifik sundhedsorganisation, muligvis inkluderende underorganisationer. |
Eller | |
ForeignHealthcareProfessionals | Indicates with value true that the consent covers foreign health professionalsAngiver med værdien sandt, at samtykke dækker udenlandske sundhedspersonale (epSos). |
IncludeSuborganizations | Whether Om data for subordinate departments for the stated organization are also included in the consent. Only relevant if OrganizationIdentifier has been filled-inunderorganisationer for den angivne organisation også er inkluderet i registreringen. Kun relevant, hvis OrganizationIdentifier er udfyldt. |
ConsentAdds
Element-navn | DescriptionBeskrivelse |
ConsentItems | Collection of Liste af ConsentItem. |
ConsentRegistrations
Element-navn | DescriptionBeskrivelse |
ConsentRegistrations | Collection of Liste af ConsentItem. |
ConsentModification
Element-navn | DescriptionBeskrivelse |
ConsentItems | Collection of Liste af ConsentItem |
ConsentRevocation
Element-navn | DescriptionBeskrivelse |
ConsentRevocations | Collection of Liste af ConsentItem. |
...
Styring
Documentation
For consent administration, the interface between the actor systems and consent verification is versioned.
The interface specification constitutes the contract that defines how the involved systems must act.
The interface specification consists of:
the technical specification of schema and service descriptions (documented as WSDL file, see section 7)
documentation of the semantic and functional meaning of data that is exchanged (documented in this document).
Versioning
Dokumentation
Til MinSpærring Administration er grænsefladen mellem anvendersystemerne og administration 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 ConsentAdministration are headers defined and versioned elsewhere. The body is specific for ConsentAdministration and follows the namingSom en del af WSDL for ConsentAdministration er der headers der er definereret i andre standarder. Selve request til ConsentVerification følger nedenstående navngivning.
”urn:dk:nsi:consentservices:administration:service:<version>”
where the version changes on redefinition of the ConsentAdministration interface.
WSDL
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-administration/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.