Introduktion

Formål

Samtykkeservicen servicen er en national service til administration og verifikation af en borgers samtykke og spærringer for sundhedsfagliges adgang til data i nationale systemer.

Formålet med dette dokument er beskrive arkitektur og design i Samtykkeservicen.

For et overblik over systemet se afsnittet "Overblik over løsningen".

Dokument historik

Definitioner og referencer

Formålet med dette afsnit er at give en oversigt over definitioner og dokumentreferencer, der bruges i dette dokument.

Samtykkeservicen

Baggrund

Grundlaget for samtykke service er som følger::

”The health act contains stipulations regarding a citizens’ right to decline retrieval or disclosure of information. In regard to electronic retrieval of patient information, the patient must be briefed about his right to decline retrieval, but it is not required that the patient’s consent is requested on the actual retrieval. In the remarks to the law, it is stated that this right must be supported electronically in new IT solutions, i.e. the patient or a health professional acting on behalf of the patient must be able to mark which information to which access is declined.

…

The consent service that is developed in connection with the NPI (National Patient Index) project should be viewed as the first draft. The consent service must be shared between NSP and the Health Journal and should consequently be developed in collaboration with Sundhed.dk and the architecture should support future extension of interface and functionality.

Specifically, the consent functionality in the NPI project must contain the following components:

A database with a simple data model for storage of negative and positive consent

Web Service for registration and lookup / control of consent information.”

Kravene, som Samtykkeservicen skal opfylde, er uddybet i [Behov]. Det juridiske grundlag er beskrevet i [Sundhedsloven] med rettelser givet i [Ændring af sundhedsloven].

Overblik over løsningen

Samtykkeservicen udstiller to services. Det er Samtykkeservicen Administration og Samtykkeservicen Verifikation.

* Hver kasse i ovenstående diagram har en kort forklaring, som kommer frem i et nyt browservindue, når der klikkes på kassen.

Samtykkeservicen Brugertyper

Der findes følgende brugertyper i Minspærring:

• Borger
• Systembruger
• Administrativ

Bestemmelse og mapning til actor

De enkelte brugertyper bestemmes udfra modellen, der udstilles i Security API. Disse regler er opsummeret i tabellerne nedenfor.

Transformation af Systembruger

En systembruger giver ikke mening i sig selv i forhold til de beskrevne brugerhistorier. Systembrugeren er der kun fordi nogle systemer (i praksis sundhed.dk) kan anvende Samtykkeservicen og ved hjælp af en medsendt HSUID header kan opnå status som brugertypen Borger. 

Samtykkeservicen Administration

Tillader registrering og vedligeholdelse af frabedelser og samtykker for en borger. Servicen tilbyder nedenstående funktionalitet.

• ConsentRegistrationsGet – Returnerer alle registreringer for en borger.
  

• ConsentAdd – Opretter en ny frabedelser eller samtykke for en borger. Et registrering er defineret i Samtykkeservicen - Data Model og indeholder:

  • Type (samtykke eller frabedelse)

  • Hvad det gælder

  • Hvem det gælder for

  • Gyldighedsperiode

Operationen kan kaldes af både borgere og af en anden person, som det kaldende system har verificeret, har lov til at oprette en frabedelse eller samtykke på borgerens vegne. Hvis en borger kalder på vegne af en anden borger, skal den kaldende borger have fuldmagt til dette. Fuldmagt er for nuværende deaktiveret.

• ConsentModify - Ændrer et samtykke til en borger. En ændringer er defineret på samme måde som hvis der oprettes en ny registrering.

• ConsentRevoke - Tilbagekalder et samtykke eller frabedelse så det ikke længere er gyldigt.

Nogle operationer tillader at bruger og borger ikke er den samme person. Hvis de ikke er den samme person logges handling til borgerens MinLog.

Samtykkeservicen Administration opbevarer i sin database information om samtykke og frabedelse, som angivet af ConsentAdd ovenfor, ud over oplysninger om, hvem og hvornår samtykke henholdsvis oprettes og ændres.

Samtykkeservicen Verifkation

Servicen anvendes til at verificere frabedelser og samtykker mellem borger og sundhedsfaglig. Service udstiller nedenstående operationer:

• ConsentForUserCheck – Returnerer det generelle samtykkeforhold (samtykke eller frabedelse) for en bruger med hensyn til en borger; hvis brugeren har lov til at se alt eller intet om borgeren.

• ConsentForDataCheck – Returnerer det specifikke samtykkeforhold (samtykke eller frabedelse ) for en bruger og konkrete oplysninger om en borger; hvis brugeren har lov til at se disse konkrete oplysninger om borgeren. De konkrete oplysninger / dokumenter returneres i form af en liste af ID'er. ID'erne der ønskes undersøgt er en del af forespørgslen til servicen. 

Det er kun systembrugere der må kalde verifikationssnitfladen.

Sammen med det kaldende anvendersystem følger Samtykkeservicen Verifikation følgende beslutningsgraf for at bestemme en borgeres / sundhedspersonale adgang til data:

Fælles for Samtykkeservicen

Begge services overholder Den Gode Web Service 1.0.1 og kræver:

• At anvendersystem er godkendt af STS på NSP med mindst sikkerhedsniveau 3

• At anvender er whitelisted i servicen
  

Det er anvendersystemets ansvar It is the responsibility of the calling system to ensure that the user is authenticated and authorized.

Database og service deployment overblik

Samtykkeservicen data lagres i en central database, der replikeres til de forskellige NSP instanser.

* Hver kasse i ovenstående diagram har en kort forklaring, som kommer frem i et nyt browservindue, når der klikkes på kassen.

Samtykkeservicen Administration installeres på en central server og eksponeres på NSP-forekomster gennem afkoblingskomponenten DCC. Proxyen for Samtykkeservicen Administration, der bruges i en NSP-instans, implementeres ikke som en del af denne service. Proxyen oprettes på NSP i form af en konfiguration af DCC.

Samtykkeservicen Verifikation er kun installeret på cNSP og forespørger på den lokale database.

Design mål og beslutninger

Design mål

Systemet skal designes i overensstemmelse med de mål og prioriteter, der er angivet i tabel 1. Prioriteten for hvert mål er angivet med en score på 1 til 5, hvor 5 angiver den højeste prioritet.

Tabel 1: Design mål og deres indbyrdes prioritering

Design beslutninger

Dette afsnit indeholder vigtige designbeslutninger og deres begrundelse. Hvis det er relevant, præsenteres afviste designs også med begrundelsen for deres afvisning.

Belslutning angående logning

Fejl og debug logging er implementeret via log4j der er konfigureret for hvert service. Der laves en logfil pr. service.
I denne log registreres exceptions og stacktraces. Hvis konfigurationen er indstillet til 'debug'-niveau, logges der også  flowID ved ind- / udgang af servicemetoderne.
Debuglog er blevet implementeret for at lette fejlfinding, således at flowID (og følgelig en besked) kan spores mellem serviceopkald.

Service Level Agreement (SLA) logning håndteres via SLA-logning i NSPU til biblioteket. 

SLA-logging logger alle kald til de to service og består blandt andet af:
Tidspunkt, navn på den kaldte metode, eksekveringstids samt message ID.

Audit logging sker også via log4j via kategorien ”audit”. Audit logging skal logge

• Tid (zulu time)

• Bruger ID

• Metodekald

• borgeren

• Anvender systems CVR nummer

• SessionID fra IDWS sikkerhedskontekst (messageID)

Beslutning angående konfiguration

Servicekonfigurationen udføres i to (tre for Samtykkeservicen Administration) forskellige property filer, der leveres som en del af docker setup.

Ændringer i konfigurationen skal medføre en genstart af den container som servicen den kører i da konfiguration indlæses ved opstart.

For beskrivelse af konfigurationen se Samtykkeservicen - Driftsvejledning.

Applikations konfiguration

Applikationen er konfigureret i filerne ConsentAdministration.properties og ConsentVerification.properties.
Al konfiguration af sikkerhed og serviceopsætning findes i disse filer.

Derudover angives placeringen af logkonfigurationsfilen og serviceklientkonfigurationen.

På denne måde er det muligt at konfigurere logning og klientopsætning uafhængigt af tjenesten, f.eks. om genbrug af logkonfigurationen mellem services.

Service klient konfiguration

Samtykkeservicen Administration service skal være i stand til at kommunikere med Min Log'-tjenesten, og konfigurationen af den anvendte serviceklient skal også udføres i en konfigurationsfil.

Placeringen af denne fil findes i applikationskonfigurationen.

Log konfiguration

I logkonfigurationsfilen leveres konfiguration af error og debug ved at angive en log4j-logger property med navnet log4j.logger.dk.nsi.

Database konfiguration

Begge Samtykkeservicen services skal forsynes med en datasource med navnet 'ConsentServiceDS', der har adgang til den database der er beskrevet i Samtykkeservicen - Data Model.

Begge tjenester skal have adgang til en datasource med navnet 'WhitelistDS', der bruges af whitelist af anvendersystemer.

Beslutninger angående Web Services

De to Samtykkeservicen services er udviklet med en ”Java-first” tilgang, hvor Java-koden er udviklet uafhængigt, og WSDL genereres på tidspunktet for kørsel på webserveren på basis af den implementerede kode.

Java-first-metoden blev valgt for at lette udvikling og vedligeholdelse af tjenesten, da dette gør det muligt at udnytte eksisterende Java-kompetencer. Muligheden for at tilpasse den udsatte WSDL ofres.

Denne beslutning er omgjort med SDS-4222, hvor der er lavet faste WSDL filer, hvorfra der generes java klasser. WSDL filerne udstilles direkte via en servlet og på servicens endpoints (?wsdl).

Indhold af Web Service kald

Web Service operationerne består af: en Medcom-header, en sikkerheds-header, en HSUID-header Samtykkeservicen - Healthcare Service User Identification Header Interface Description og et body-element.

I Samtykkeservicen Administraition bruges indholdet af HSUID-headeren til at autentificere og validere autorisationen for den kaldene bruger ud over at validere, at brugeren har lov til at kalde metoden med de inkluderede parametre i body elementet.
Desuden bruges det 'fungerende bruger'-felt i HSUID-headeren til at indstille felterne' oprettet af' og' modificeret af' på en frabedelse/samtykke samt for at vurdere om det skal logges at en registrering er oprettet/rettet af en anden borger end den registreringen berører.

Ved Samtykkeservicen Verifikation er kun gyldigheden af ​​HSUID-headeren valideret.

Medcom-headeren bruges til at validere sikkerhedsniveauet og signaturen.

Security Headeren bruges til at validere, om den vedhæftede signatur og STS-sikkerhedstoken er gyldig, jf. den konfiguration, der er brugt til at konfigurere tjenesten.

Alle andre parametre for kald til servicen er indeholdt i SOAP body elementetm for hvilket indhold varierer med hensyn til den enkelte operation (se Samtykkeservicen - Administration Service Interface Description og Samtykkeservicen - Verifikation Service Interface Beskrivelse).

Beslutninger vedrørende service arkitektur

Hver service implementeres som en stateless Java EE-sessionbønne, der implementerer en grænseflade, der definerer de metoder, servicen udstiller. Både implementeringen af bønne og webservicen håndteres via Java EE-kommentarer.
Ved at implementere tjenesten som en Java EE-bønne er det muligt for applikationsserveren at håndtere datasource injection, transaktioner og systemressourcer i stedet for at håndtere dette manuelt i koden.

Hvert aspekt af overholdelse af DGWS, IDWS, sikkerhedshåndtering og logning håndteres af Java EE-interceptorer, der automatisk kaldes af den omgivende EJB-container.

Beslutninger vedrørende data sources

Samtykkeservicen databasen implementeres gennem Hibernate, hvilket gør det muligt at afkoble databashåndteringen fra koden. Datasource til Samtykkeservicen håndteres gennem injektion fra EJB-containeren i applikationsserveren.

DataSournce til whitelisting (der bruges til at kontrollere, om anvendersystemer har adgang til tjenesten), håndteres af et kontekstopslag i koden og injiceres således ikke fra EJB-containeren.

Årsagen til dette er, at whitelist ikke håndteres direkte af bønnen, men af en interceptor, der kan konfigureres uafhængigt af bønneimplementeringen. Interceptoren leveres af et fælles kodemodul og bruges af flere tjenester for at sikre, at DGWS overholdes ud over validering af sikkerhed. For at undgå en afhængighed fra whitelist til bønnen finder datasource opslag sted i det delte modul.

Data Model

Datamodelen er dokumenteret i Samtykkeservicen - Data Model.

Arkitektur

Dette afsnit beskriver både statiske og dynamiske aspekter af systemarkitekturen, herunder grundlaget for de individuelle designvalg.

Statisk struktur

Overblik

Den generelle servicestruktur er, at tjenesten implementeres som en statsløs sessionbønne, der implementerer en Web Service, der er en Java Web Service.

Denne bønne håndterer derefter servicelogikken, DAO'er og anden forretningslogik.

Sikkerhedsvalidering, logning og fejlhåndtering håndteres af et antal Java EE-interceptors.

Tjenesten kører på en applikationsserver, der er ansvarlig for generering af en Web Interface, styring af datasource injection og håndtering af systemressourcer.

Database håndtering

Databasekommunikationen håndteres af et antal DAO'er (en pr. Injiceret datasource), der indkapsler databasekommunikationen i et antal objektrelaterede metoder.

Whitelist håndteres ikke via en DAO. I stedet fremsætter hvidlisteimplementeringen en direkte forespørgsel til sin datakilde.

ConsentVerificationDAO
Håndteres af en EntityManager (defineret i persistence.xml-filen i applikationen) med navnet 'ConsentVerificationService', der injiceres gennem Java EE-kommentaren @PersistenceContext i bønnen.

Denne EntityManager gør brug af datasourcen 'ConsentServiceDS'.

DAO udstiller metoder, der svarer til de funktioner, som webservicen udstiller til anvendersystemer. De bruges af bønnen til at læse en borgers samtykker og frabedelser.

ConsentAdministrationDAO

Håndteres af en EntityManager (defineret i persistence.xml-filen i applikationen) med navnet 'ConsentAdmin', der injiceres gennem Java EE-kommentaren @PersistenceContext i bønnen.

Denne EntityManager gør brug af datasourcen 'ConsentServiceDS'.

DAO udstiller metoder, der svarer til de funktioner, som webservicen udstiller til anvendersystemer. De bruges af bønnen til at vedligeholde en borgers samtykker og frabedelser.

Databasefunktionerne implementeres ved hjælp af Hibernate.

Interceptors

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 eksekveres.

SLA logging

SLA-log-interceptor er ansvarlig for SLA-logning af alle servicekald.

Fejlhåndtering

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

Service Logik Samtykkeservicen 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. Det tjekkes ved kald af cprexists-servicen, at det cpr-nummer som forespørgslen indeholder er gyldigt.

Ved oprettelse, ændring og sletning af samtykke sendes adviseringer til National Adviseringsservice (NAS2) med borgerens cpr-nummer som id. Dermed kan anvendere abonnere på ændringer for specifikke borgere. 

Hvis brugeren adskiller sig fra den borger, der er omfattet af samtykke logges ændringen i Min Spærring til MinLog2.

Samtykketjenesten gør brug af Min Log Provider.

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 Samtykkeservicen Verifikation

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

Samtykkeservicen Verifikation

Verifikationen består af to forskellige operationer: brugerverifikation og dataverifikation.

Bruger verifikation 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 anvender-systemet ikke at validere samtykke til mulige data, da borgeren har givet samtykke til den kaldene 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 kaldene 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 frabedelser 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 frabedelser fra databasen og filtrerer disse ved hjælp af klassen ConsentTypeFilterer.

I denne klasse filtreres samtykker og frabedelser i relevante enheder svarende til de forskellige trin i beslutningsgrafen (f.eks. spærringer til brugeren ',' frabedelse 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. Opslag til SORES forsøges så vidt muligt cached i Samtykkeservicen, så vi ikke laver 1000 opslag på de samme 10 SOR-koder, hvis en borger har 1000 aftaler..

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.

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 frabedelse 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 frabedelse for alle (negativt)
5. Samtykke over for brugerens organisation for alle (positive)
6. Samtykke over for brugerens organisation for specifikke data (dataspecifikke)
7. Frabedelse over for nogen til specifikke data (dataspecifik)
8. Frabedelse over for enhver for alle (negativt)
9. Ikke flere registreringer eller ingen registreringer (positivt)
10. Håndteringen af ​​de enkelte trin varierer mellem bruger og data-verifikation.

Bruger verifikation

Logikken til bruger bekræ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 frabedelse findes i databasen, returneres til det kaldende system.

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

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 regler om en frabedelse eller en eller flere dataspecifikke frabedelser 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 gennemført, eller listen over mulige dataelementer er tom.

Returlisten (med alle dataelementerne uden frabedelse) 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 frabedelse. 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.

Min Log Provider

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

National Adviseringsservice (NAS2) modul

Alle kald til NAS2 Notifikation Broker udføres via nas-notification-modulet.

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 Samtykkeservicen - Guide til Udviklere.

Testspecifikationer

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

Min Spærring administration

Integrationstests af den administrative snitflade er defineret i følgende Cucumber feature filer:

Der findes en række klasse med  Samtykkeservicen 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.

Samtykkeservicen Verifikation

Der findes en række unit tests til Samtykkeservicen 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 korrekt.