Introduktion

Formål

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

...

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

Læsevejledning

I dokumentet bruges begreberne autorisation og autoriseret primært i en sikkerhedskontekst, det vil sige i forståelsen af, at en person eller et system er autoriseret til at bruge en given ressource. Hvis begreberne anvendes om en sundhedsfaglig med dansk autorisation, der er anført i Sundhedsstyrelsens autorisationsregister, vil det blive udtrykkeligt angivet.

Dokument historik

Definitiner og referencer

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

...

MinSpærring Services

Baggrund

Grundlaget for samtykke service er som følger::

...

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

Overblik over løsningen

MinSpærring udstiller to services. Det er MinSpærring Administration og MinSpærring Verifikation.

...

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

MinSpærring Brugertyper

Der findes følgende brugertyper i Minspærring:

• Borger
• Systembruger
• Sundhedsfaglig
• 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 således at systemer (i praksis sundhed.dk) kan anvende MinSpærring og ved hjælp af en medsendt HSUID header kan opnå status som een af brugertyperne Borger eller Sundhedsfaglig. 

...

MinSpærring Administration

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

...

MinSpærring 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.

MinSpærring Verifkation

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

...

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:

...

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

MinSpærring data lagres i en central database, der replikeres til de forskellige NSP instanser.

...

MinSpærring 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

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

...

• 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 MinSpærring Administration) forskellige property filer, der leveres som en del af docker setup.

...

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

Beslutninger angående Web Services

De to MinSpærring 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.

...

Alle andre parametre for kald til servicen er indeholdt i SOAP body elementetm for hvilket indhold varierer med hensyn til den enkelte operation (se MinSpærring - Administration Service Interface Description og MinSpærring - 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, servucen 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

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

...

Å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 MinSpærring - 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.

...

Tjenesten kører på en applikationsserver, der er ansvarlig for generering af en Web Interface (og WSDL), 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.

...

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.

...

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

...

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.

...

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.

...

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

...