...

Databasefunktionerne implementeres ved hjælp af Hibernate.

Interceptors

A number of interceptors are used in the implementation of the specific service for performing SLA-logging, error handling and security validation. These interceptors make use of the interceptor-pattern and prevents the EJB container from calling the specific service implementation directly, as the call hits a proxy that calls the annotated interceptors sequentially.

Each interceptor then wraps the ensuing call and can perform error handling and logging.

Et antal interceptors bruges til implementering af SLA-logning, fejlhåndtering og sikkerhedsvalidering. Disse interceptors gør brug af interceptor-mønsteret og forhindrer EJB-containeren i at kalde den specifikke serviceimplementering direkte, da kald rammer en proxy, der kalder de annoterede interceptors sekventielt.

Hver interceptor indpakker derefter det efterfølgende kald og kan udføre fejlhåndtering og logning.

Alle interceptorer er annonteret med @AroundInvoke, hvilket betyder, at de kaldes op, før servicemetoderne eksekveresEvery interceptor is annotated with @AroundInvoke, which means that they are called before the service methods are invoked.

SLA logging

SLA-log-interceptor is responsible er ansvarlig for SLA logging of all service calls-logning af alle servicekald.

Error handlingFejlhåndtering

Consent Administration and Consent Verification handles errors differently. See the subsections "Error Handling" in the following two sections.

Service Logic for Consent Administration

The service logic is implemented directly in the bean implementation as the logic primarily consist of forwarding calls to the DAO. Additionally, overall validation of the HSUID header is performed in addition to validating that health professionals are only allowed to call the ‘ConsentAdd’ method.

MinSpærring Administration og MinSpærring Verifikation håndterer fejl forskelligt. Se underafsnittene "Fejlhåndtering" i de følgende to sektioner.

Service Logik MinSpærring Administration

Servicelogikken implementeres direkte i bønneimplementeringen, da logikken primært består i videresendelse af opkald til DAO'en. Derudover udføres samlet validering af HSUID-overskriften ud over validering af, at sundhedspersonale kun har tilladelse til at kalde 'ConsentAdd' -metoden.

Hvis brugeren adskiller sig fra den borger, der er omfattet af samtykke, foretages der desuden et opkald til Min-log-servicen for at logge dette til MinLogIf the user differs from the citizen that is subject of the consent, a call is additionally made to the Min-log service to log this change in the citizen’s ’Min Log’.

The consent service make use of the Min Log service client (see section 5.4).

Samtykketjenesten gør brug af Min Log-serviceklienten (se afsnit 5.4).

Error handling

The error handling intercept performs general error handling of all service calls and wraps and ensures that it is only SOAP faults that are returned to the calling systems.

It additionally ensures that potential errors are logged in the error log and performs debug logging of flow ID.

Service Logic for Consent Verification

The service logic comply with the decision graph that has been made for consent verification (see section 2.2) and it is implemented in the class ConsentVerificationServiceLogic.

Consent verification

The verification consists of three different operations: user verification, data verification and verification of foreign health professionals.

The foreign health professionals are persons who attempt to access a citizen’s data through epSos. It is possible for a citizen to register positive consent for this (see section 2.2).

User verification is used to obtain an indication of whether a user can access a citizen’s data. It is possible for a system to call this service and thus avoiding examination of each individual data element.

If ’Positiv’ is returned, then the calling system do not need to validate consent for possible data as the citizen has provided consent for the calling user for all data.

If ’Negativ’ is returned, then the calling system do not need to lookup data, as negative consent is provided for the calling user for all data.

Only on a ’Dataspecifik’ returnvalue will it be necessary for the calling system to make a request to the other verification method.

Data verification is used to examine which data in a sequence of specific data elements the user has consent too view.

This method is only necessary to call if user verification has returned a data specific result.

The method accepts a list of possible data elements and returns a list of those data elements (from the received list) that the user has consent to view.

Consent for persons and data

The service logic class retrieves all the citizen’s consents from the database and filter these using the class ConsentTypeFilterer.

In this class, consents are filtered in relevant units corresponding to the various steps in the decision graph (e.g. positive consent for the user’, ‘negative consent for all’, ’positive consent for the users organization’ etc.). The filtration is performed on the consents and possible associated ’who’ element. The ‘what’ element is not examined in the filtration.

...

Fejlhåndtering

Fejlhånterings-interceptoreren udfører generel fejlhåndtering af alle servicekald og sikrer, at det kun er SOAP-fejl, der returneres til opkaldssystemerne.

Det sikrer desuden, at potentielle fejl er logget i fejlloggen og udfører fejllogning af flow-id.

Service Logik for MinSpærring Verifikation

Servicelogikken overholder beslutningsgrafen, der er lavet til godkendelsesbekræftelse (se tidligere afsnit), og den implementeres i klassen ConsentVerificationServiceLogic.

MinSpærring Verifikation

Verifikationen består af tre forskellige operationer: brugerverifikation, dataverifikation og verifikation af udenlandske sundhedspersonale.

Det udenlandske sundhedspersonale er personer, der forsøger at få adgang til en borgeres data gennem epSos. Det er muligt for en borger at registrere positivt samtykke til dette (se tidligere afsnit).

Brugerverfikation bruges til at få en verifikation af, om en bruger kan få adgang til en borgeres data. Det er muligt for et system at kalde til denne service og dermed undgå at lave verifikation af hvert enkelt dataelement.

Hvis 'Positiv' returneres, behøver anvendersystemet ikke at validere samtykke til mulige data, da borgeren har givet samtykke til den kalende bruger til alle data.

Hvis 'Negativ' returneres, behøver det kaldende system ikke at slå op data, da der er oprettet en spærring til den kalende bruger for alle data.

Kun på et 'Dataspecifik'  er det nødvendigt for det kaldende system at at kalde 'dataverifikation'.

Dataverifikation bruges til at undersøge, hvilke data i en sekvens af specifikke dataelementer, som brugeren har samtykke eller spærring til at få vist.

Denne metode er kun nødvendig at kalde hvis der er returneret dataspecifik.

Metoden accepterer en liste over mulige dataelementer og returnerer en liste over de dataelementer (fra den modtagne liste), som brugeren har samtykke til at få vist.

Samtykke/Spærring for personer og data

Serviceklassen henter alle borgerens samtykker og spærringer fra databasen og filtrerer disse ved hjælp af klassen ConsentTypeFilterer.

I denne klasse filtreres samtykker og spærringer i relevante enheder svarende til de forskellige trin i beslutningsgrafen (f.eks. spærringeer til brugeren ',' spærring til alle ',' samtykke til brugerorganisationen 'osv.). Filtreringen udføres på registreringerne og mulig tilknyttet 'hvem' element. 'Hvad' elementet undersøges ikke i filtreringen.

Opslag foretages i SORES-tjenesten for at sortere organisationsspecifikke samtykke korrekt.

If user or data verification is performed, then the general consent verification logic will subsequently be performed in the abstract class ServiceLogicHandler that has been implemented by two concrete classes: a class for user verification and a class for data verification. Filtration of consents, order of consent verification, and handling of positive/negative/data specific consents, are identical for both the concrete classes.

Image Removed

General service verification

The general verification algorithm is as follows, where the parenthesized text indicates if the individual step results in a positive, negative or data-specific handling.

In each step, it is examined whether the filtration has found consents that belong to the current category whereupon the stated handling is performed.

For instance, a positive handling is performed if a positive consent is found for the current user in step 2.

’On behalf of’ (step 1) is used when a health professional is working on behalf of another health professional. This could be a medicine student working on behalf of his senior physician or a secretary making lookups for a health professional.

In this case, the algorithm is swiftly executed if positive consent exists towards both users. Otherwise, it is required that if negative consent exists towards only one of the users, no access is allowed to the user’s data.

1. On behalf of (positive/negative/data-specific)

2. Positive personal consent for all (positive)

3. Positive personal consent for specific data (data-specific)

4. Negative personal consent for all (negative)

5. Positive consent towards the user’s organization for all (positive)

6. Positive consent towards the user’s organization for specific data (data-specific)

7. Negative consent towards anybody for specific data (data-specific)

8. Negative consent towards anybody for all (negative)

9. No more consents / no consents registered (positive)

Handling of the individual steps varies between user and data-verification.

User verification

The logic for user verification is simple and will result in either a positive, negative or data-specific answer.

The value for the first handling, where consents are found in the database, is returned to the calling system.

...

Hvis der udføres bruger- eller dataverifikation, udføres den generelle tilladelsesverifikationslogik derefter i den abstrakte klasse ServiceLogicHandler, der er implementeret af to konkrete klasser: en klasse til brugerverifikation og en klasse til dataforifikation. Filtrering af samtykke, bekræftelse af samtykkeordre og håndtering af positive / negative / dataspecifikke samtykke er identiske for begge de konkrete klasser.

Image Added

Generel service verifikation

Den generelle verifikationsalgoritme er som følger, hvor parentessteksten angiver, om det enkelte trin resulterer i en positiv, negativ eller dataspecifik håndtering.

I hvert trin undersøges det, om filtreringen har fundet samtykke eller spærring, der hører til den aktuelle kategori, hvorpå den angivne håndtering udføres.

For eksempel udføres en positiv håndtering, hvis der findes et  samtykke til den nuværende bruger i trin 2.

'På vegne af' (trin 1) bruges, når en sundhedsprofessionel arbejder på vegne af en anden sundhedsperson. Dette kan være en medicinstudent, der arbejder på vegne af hans overlæge eller en sekretær, der søger efter en sundhedsperson.

I dette tilfælde udføres algoritmen hurtigt, hvis der findes samtykke til begge brugere. Ellers kræves det, at hvis der kun findes spærring over for en af ​​brugerne, er der ikke adgang til brugerens data.

1. På vegne af (positiv / negativ / dataspecifik)
2. Personligt samtykke for alle (positive)
3. Personligt samtykke til specifikke data (dataspecifikke)
4. Personlig spærring for alle (negativt)
5. Samtykke over for brugerens organisation for alle (positive)
6. Samtykke over for brugerens organisation for specifikke data (dataspecifikke)
7. Spærring over for nogen til specifikke data (dataspecifik)
8. Spærring over for enhver for alle (negativt)
9. Ikke flere registreringer elller ingen registreringer (positivt)
10. Håndteringen af ​​de enkelte trin varierer mellem bruger og data-verifikation.

Bruger verifikation

Logikken til brugerbekræftelse er enkel og vil resultere i enten et positivt, negativt eller dataspecifikt svar.

Værdien for den første håndtering, hvor samtykke eller spærring findes i databasen, returneres til det kaldende system.

'Positiv' returneres, når samtykke findes trin (2, 5), 'Negativt' i de tring hvor der er spærring trin (4,8) og 'Dataspecifikt' i de dataspecifikke trin (3,6,7) .

In step 1, a value is returned that depends on the citizen’s consents towards the person that work is performed on behalf of, and the user calling the service.

Data verification
Consent verification for data sorts the data, where there is negative consent, from the total list of possible data elements. The verification is performed once for each data element.
If positive handling is performed, the element is added to the return list. If negative handling is performed, the element is removed from the list of possible data elements

On a data-specific handling, iteration is performed over the remaining possible data elements and the ’what’-elements of the consents are examined. Comparison is made with the creating organization of the data element and the ’what’-organization provided in the consent:

• If no ’what’-element is provided or the ’what’-organization is subject of a positive consent, the element is added to the return list.

• If it is the subject of a negative consent, it is removed from the list of possible data elements.

• Handling by precautionary principle:

• If the creating organization of the data element is of type unknown or other, it is removed when there is negative consent or one or more negative data specific consents with overlapping referral period, unless there is also a positive data specific consent (with overlapping referral period) which applies to any origin (‘what’-organization).

• If the creating organization of the data element is of type SHAK or DEA (Danish: ydernummer) and the identifier cannot be looked up as a SOR code, it is treated similarly to the unknown or other organization type described above.

• Otherwise, verification continues.

This proceeds until all steps of the verification has been passed or the list of possible data-elements is empty.

The return list (with all the data elements without negative consent) is returned to the calling system.

The handling by precautionary principle is simply, that if a data element is of type unknown or type other, it might represent data from the same organization (‘what’-organization) as that of a negative data specific negative consent. The data element, therefore is eligible for being removed from list. The same does not apply for the positive data specific consent. Although the data element might represent the same organization, the opposite might as well be true. Therefore, positive data specific consent applies only when defined for any origin (any ‘what’-organization).

Error handling

The error handling intercept performs general error handling of all service calls and wraps and ensures that it is only DGWS faults that are returned to the calling systems.

It additionally ensures that potential errors are logged in the error log and performs debug logging of flow ID.

DGWS and security

The DGWS-interceptor performs validation of the security and Medcom headers. It ensures that only authenticated user systems can access the service by authorizing them in a whitelist.

Consent for foreign health professionals

On verification of foreign health professionals, iteration occurs over all the citizen’s consents to examine if one exists towards foreign health professionals (epSos).

If so, the type of the consent is returned (positive/negative). Otherwise, negative is returned, as the citizen specifically must allow access for foreign health professionals.

Min-log Service Client

All calls to the Min-log service is performed through the Min-log service client, based on the loaded configuration (see section 3.2.2).

Call is forwarded to the Min Log service with the same Medcom and security headers, as received by the calling system.

The interface for the Min-log service can be seen in [Min-log].

Integration and Test

Integration Strategy

There is no specific sequence in which the two components must be integrated. However, the Min Log service-client must be available before the consent administration service can be integrated.

For a description of the build process and external/internal depencies for the service, see [UdviklerGuide].

Test Specifications

To be able to test the consent administration service, the Min Log-service must be available. It is also possible to test consentadministrationsservicen with a stub for Min Log.

Min Spærring administration

The following three integration test classes exists for the administration service:

1. ConsentAdministrationServiceIT
2. ConsentAdministrationSecurityIT
3. ConsentAdministrationServiceMinLogLoggingIT

The security-class ensures that the service validates and verifies those security tokens that are included in the service request.

The service-class contains those integration tests that verify that the service requirements have been met, in addition to ensuring that OIO-IDWS 1.1 and SLA-logging is implemented correctly.

The MinLog-class ensures that the service logging mechanism using MinLog is implemented correctly.

Consent verification

Two unit test classes exists for the verification service:

ConsentVerificationLogicTest and ConsentForForeignersTest

The verificationLogic-test ensures that the service logic classes has been implemented correctly.

The foreigners-test ensures that the logic that checks for consents for foreign health professionals has been implemented correctly.

Additionally, two integration test classes exists for the verification service:

ConsentVerificationServiceIT and ConsentVerificationSecurityIT

The security-class ensures that the service validates and verifies the security tokens that are included in the service request.

The service class contains those integration tests that verify that the service requirements have been met, in addition to ensuring that DGWS 1.0.1 and SLA-logging is implemented correctly

Common

I trin 1 returneres en værdi, der afhænger af borgerens samtykke til den person, som arbejdet udføres på vegne af, og den bruger, der kalder tjenesten.

Data verifikation

Samtykkeverifikation returnerer, fra den samlede liste af dataelementer, de elementer der er samtykke til at tilgå. Verifikationen udføres én gang for hvert dataelement.
Hvis der udføres positiv håndtering, tilføjes elementet til returlisten. Hvis der udføres negativ håndtering, fjernes elementet fra listen over mulige dataelementer

På en dataspecifik håndtering udføres iteration over de resterende mulige dataelementer og 'hvad'-elementerne i registreringen undersøges. Sammenligning foretages med oprettelsen af ​​dataelementet og den 'what'-organisation, der er givet i samtykke:

• Hvis der ikke gives noget 'what'-element, eller' what'-organisationen er underlagt et samtykke, føjes elementet til returlisten.
• Hvis det er genstand for en spærring fjernes det fra listen over mulige dataelementer.
• Håndtering efter forsigtighedsprincip:
  • Hvis den oprettende organisation af dataelementet er af ukendt eller anden type, fjernes det, når der er rale om en spærring eller en eller flere dataspecifikke spærringer med overlappende henvisningsperiode, medmindre der også er et positivt  samtykke (med overlappende henvisningsperiode ), der gælder for enhver oprindelse ('hvad'-organisation).
  • Hvis den oprettende organisation af dataelementet er af typen SHAK eller ydernummer, og identifikatoren ikke kan ses som en SOR-kode, behandles den på samme måde som den ukendte eller anden organisationstype beskrevet ovenfor.
• Ellers fortsætter verifikationen.

Dette fortsætter, indtil alle trin i verifikationen er gennmemført, eller listen over mulige dataelementer er tom.

Returlisten (med alle dataelementerne uden spærring) returneres til det kaldende system.

Håndteringen af ​​forsigtighedsprincippet er, at hvis et dataelement er af en ukendt type eller en anden type, kan det repræsentere data fra den samme organisation ('hvad'-organisation) som for en dataspecifikt spærring. Dataelementet er derfor berettiget til at blive fjernet fra listen. Det samme gælder ikke for det  dataspecifikke samtykke. Selv om dataelementet muligvis repræsenterer den samme organisation, kan det modsatte lige så godt være tilfældet. Derfor gælder dataspecifikt samtykke kun, når det er defineret for enhver oprindelse (enhver 'hvad'-organisation).

Fejlhåndtering

Fejlhåndterings-interceptoret udfører generel fejlhåndtering af alle servicekald og sikrer, at det kun er DGWS-fejl, der returneres til opkaldssystemerne.

Det sikrer desuden, at potentielle fejl er logget i fejlloggen og udfører fejllogning af flow-id.

DGWS og sikkerhed

DGWS-interceptoren udfører validering af sikkerheds- og Medcom-headere. Det sikrer, at kun godkendte brugersystemer kan få adgang til tjenesten ved at godkende dem i sin whiteliste.

Samtykke til udenlandskesundhedspersonale

Ved verifikation af udenlandske sundhedspersonale itereres der over alle borgerens registreringer for at undersøge om der eksieterer en for udenlandsk sundhedspersonale (epSos).

I så fald returneres typen af registrering (positiv / negativ). Ellers returneres negativt, da borgeren specifikt skal tillade udenlandsk sundhedspersonale adgang.

Min-log Service Klient

Alle kald til Min-log-servicen udføres via Min-log-serviceklienten, baseret på den indlæste konfiguration.

Kald videresendes til Min Log-tjenesten med de samme Medcom- og sikkerhedsoverskrifter som modtaget af det kaldende system.

Snitfladen til Min-log-tjenesten kan ses i MinLog dokumentationen..

Integration og Test

Integrationsstrategi

Der er ingen specifik rækkefølge, hvor de to komponenter skal integreres. Min Log-serviceklienten skal dog være tilgængelig, før servicen samtykkeadministrationstjeneste kan kaldes.

For en beskrivelse af byggeprocessen og eksterne / interne afhængigheder for servicen se MinSpærring - Guide til Udviklere.

Testspecifikationer

To be able to test the consent administration service, the Min Log-service must be available. It is also possible to test consentadministrationsservicen with a stub for Min Log.

Min Log-tjenesten skal være tilgængelig for at kunne teste MinSpærring Administration. Det er også muligt at teste MinSpærring Administration med en stub til Min Log.

Min Spærring administration

Der findes en række klasse med  MinSpærring Administration integrationstest. De findes alle i modulet consent-administration-integrationtest.

De klasser der er navngivet med "Security" sikrer, at tjenesten validerer og verificerer de sikkerhedstokener, der er inkluderet i request.

De kalsser der er navngivet med "Service" indeholder de integrationstests, der tester, at servicekravene er opfyldt, ud over at sikre, at OIO-IDWS 1.1 og SLA-logning implementeres korrekt.

MinLog-klassen sikrer, at serviceloggingsmekanismen ved hjælp af MinLog implementeres korrekt.

MinSpærring Verifikation

Der findes en række unit tests til MinSpærring Verifikation. Disse findes alle i modulet consent-verification-app.

Yderlige findes der en række integrationstests. Disse findes i projektet. consent-verification-integrationtest.

De har alle til formål at teste at applikationen fungerer efter hensigten.

Fælles

Yderlige findes der ekstar unit tests i consentservices-common der har til formål at verificere at intercepter og DAO er implementeret korrektFurthermore, there exists a number of unit tests that ensure that the different interceptor-validations and DAOs has been implemented correctly.