Page History

...

...

Definitioner og referencer

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

...

...

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

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

...

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

Allows registration and maintenance of submitted consents for the citizen. The service expose the following operations

Tillader registrering og vedligeholdelse af spærringer og samtykker for en borger. Serivcen tilbyder nedenstående funktionalitet.

• ConsentRegistrationsGet – Returnerer alle registreringer for en borger.
  

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

  • Type (samtykke eller spærring)

  • 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 spærring eller samtykke på borgerens vegne.

Operationen understøtter desuden oprettelse af samtykke til udenlandsk sundhedspersonales adgang til data.

• 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 spærring 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.

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, Samtykkeservicen Administration opbevarer i sin database information om samtykke og spærring, som angivet af ConsentAdd ovenfor, ud over oplysninger om, hvem og hvornår samtykke henholdsvis oprettes og ændres.

...

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

• ConsentForUserCheck – Returnerer det generelle samtykkeforhold (samtykke eller spærringeller 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 samtykkeforhold (samtykke eller spærringeller 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.
  

• ConsentForForeignersCheck – Returnerer, om udenlandske sundhedsfaglige kan få adgang til patientoversigt og elektronisk recept til borgeren gennem epSos (Bemærk: denne operation udgår)

•  

Det er kun systembrugere der må kalde verifikationssnitfladen.

...

Figur 1 Tilstandsdiagram for den oprindelige beslutning om at give adgang til sundhedsoplysninger om borgerne.

For en borger verificeres det kun at borgeren er godkendt og egne data kan tilgås.

For sundhedsfaglige er det nedenstående beslutningstræ der anvendes til at lave Samtykkeservicen Verifikation:

Figur 2 Tilstandsdiagram for trin til bekræftelse af samtykke eller spærring, når en sundhedsfaglig forsøger at tilgå sundhedsoplysninger om en birger. Henvisninger i parentes henviser til [Sundhedsloven].

Bemyndigelse er en tilstand hvor en sundhedsfaglig arbejder på vegne af en anden. Den sundhedsfaglige der arbejdes på vegne er typisk ansvarlig for de handlinger der udføres.

Fælles for MinSpærring

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

Fælles for Samtykkeservicen

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

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

• At anvender er whitelisted i servicen
  

...

Belslutning angående logning

Fejlr 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 SLALOgning i NSPUtil 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.

...

I Samtykkeservicen Administraition bruges indholdet af HSUID-headeren til at autentificere og validere autorisationen for den kalende 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 spærringfrabedelse/samtykke samt for at vurdere om det skal logges at en registrering er oprettet/rettet af en anden borger end den registreringen berører.

...

Hver service implementeres som en stateless Java EE-sessionbønne, der implementerer en grænseflade, der definerer de metoder, servucen 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.

...

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 spærringerfrabedelser.

ConsentAdministrationDAO

...

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 spærringerog frabedelser.

Databasefunktionerne implementeres ved hjælp af Hibernate.

...

Samtykkeservicen 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).

to forskellige operationer: brugerverifikation og dataverifikation.

Bruger verifikation 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 anvender-systemet ikke at validere samtykke til mulige data, da borgeren har givet samtykke til den kalende 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 kalende 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 spærring frabedelser til at få vist.

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

...

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

I denne klasse filtreres samtykker og spærringer frabedelser i relevante enheder svarende til de forskellige trin i beslutningsgrafen (f.eks. spærringeer spærringer til brugeren ',' spærring 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.

Image Removed

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.

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

Image Added

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.

...

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 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 spærring frabedelse 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 Frabedelse over for nogen til specifikke data (dataspecifik)
8. Spærring over Frabedelse over for enhver for alle (negativt)
9. Ikke flere registreringer elller eller ingen registreringer (positivt)
10. Håndteringen af ​​de enkelte trin varierer mellem bruger og data-verifikation.

Bruger verifikation

Logikken til brugerbekræftelse 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 spærring frabedelse findes i databasen, returneres til det kaldende system.

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

...

• 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 regler om en spærring frabedelse eller en eller flere dataspecifikke spærringer 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 gennmemførtgennemført, eller listen over mulige dataelementer er tom.

Returlisten (med alle dataelementerne uden spærring 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 spærringfrabedelse. 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).

...

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

...

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.

...

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:

For en beskrivelse af byggeprocessen og eksterne / interne afhængigheder for servicen se Samtykkeservicen - 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 Samtykkeservicen Administration. Det er også muligt at teste Samtykkeservicen Administration med en stub til Min Log.

...

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

...