Page History
Navitabs | ||||
---|---|---|---|---|
| ||||
Table of Contents |
---|
Introduktion
Formål
MinSpærring 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 MinSpærring servicenSamtykkeservicen.
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
Version | Date | Responsible | Description |
---|---|---|---|
1.0 | 29.06.2012 | Systematic | First edition |
1.1 | 28.11.2014 | Systematic | References to National Patient Index (NPI) removed |
1.2 | 25.11.2016 | Systematic | MinLog now reuses SOSI ID-card and no longer requires HSUID (5.4) |
1.3 | 7.2.2017 | Systematic | Added handling of data specific consent by precautionary principle to section 5.3.1. |
1.4 | 13.06.2018 | Systematic | Migrated to NSPOP SVN |
23.10.2018 | KIT | Document moved from Word to Confluence. Original document name was: SDD0011 Consent Services Architecture and Design.docx | |
14.05.2020 | KIT | SDS-3883 Etablering af IDWS snitflade | |
09.11.2020 | KIT | SDS-3685 Min Spærring skal anvende SORES til SOR-SHAK opslag | |
12.11.2020 | KIT | Oversættelse til dansk | |
06.05.2021 | KIT | [SDS-2416] MinSpærring Samtykkeservicen skal ændres til at kalde minlog2 |
Definitiner og referencer
Formålet med dette afsnit er at give en oversigt over definitioner og dokumentreferencer, der bruges i dette dokument.
...
Reference | Beskrivelse |
---|---|
Behov | National consentservice, v1.1 (behovsbeskrivelse for Min Spærring Service) |
Data Model | MinSpærring Samtykkeservicen- Data Model |
Administra Service Interface Beskrivelse | MinSpærring Samtykkeservicen- Administration Service Interface Description |
Verifikation Service Interface Beskrivelse | MinSpærring Samtykkeservicen- Verifikation Service Interface Beskrivelse |
Driftsvejledning | MinSpærring Samtykkeservicen- Driftsvejledning |
MinLog | |
UdviklerGuide | |
HSUID-Header | MinSpærring Samtykkeservicen- Healthcare Service User Identification Header Interface Description |
Sundhedsloven | LBK nr 913 af 13/07/2010 (Sundhedsloven) https://www.retsinformation.dk/forms/r0710.aspx?id=130455 |
Ændring af sundhedsloven | LOV nr 605 af 14/06/2011 (Lov om ændring af sundhedsloven) |
...
Samtykkeservicen
Baggrund
Grundlaget for samtykke service er som følger::
...
Web Service for registration and lookup / control of consent information.”
Kravene, som MinSpærring skal Samtykkeservicenskal 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 Samtykkeservicen udstiller to services. Det er MinSpærring Samtykkeservicen Administration og MinSpærring Samtykkeservicen Verifikation.
MinSpærring Administration
Allows registration and maintenance of submitted consents for the citizen. The service expose the following operations
HTML |
---|
<iframe src="https://archi.nspop.dk/NSP/570928ca/views/ba962f9c-58fb-40ba-92cc-a7d065936542.html" name="test" height="570" width="800">You need a Frames Capable browser to view this content.</iframe> |
* 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
- 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.
Brugertypen: Borger | Verifikation | Mapning til Samtykkeservicen ServiceActor | ||
SecurityContext | Ticket | Audience | Matche audience som findes som konfiguration i Minspærring | |
Validity | Er valid | |||
Message | Verificeres ikke - må gerne være der | |||
ActingUser | UserType | Skal være Citizen | Brugertypen: Borger | |
IdentifierFormat | Skal være CPR | |||
Identifier | Skal være sat | actionUserCpr | ||
GivenName | Verificeres ikke - må gerne være der | |||
SurName | Verificeres ikke - må gerne være der | |||
Credentials | Verificeres ikke - må gerne være der | |||
PersistentUniqueKey | Verificeres ikke - må gerne være der | |||
PrincipalUser | Må ikke være der | |||
Organisation | Må ikke være der | |||
Client | Name | Verificeres ikke - må gerne være der | systemName |
Brugertypen: Sundhedsfaglig | Verifikation | Mapning til Samtykkeservicen ServiceActor | ||
SecurityContext | Ticket | Audience | Verificeres ikke - må gerne være der | |
Validity | Er valid | |||
Message | Verificeres ikke - må gerne være der | |||
ActingUser | UserType | Skal være HealthCareProfessional | Brugertypen: Sundhedsfaglig | |
IdentifierFormat | Skal være CPR | |||
Identifier | Skal være sat | actionUserCpr | ||
GivenName | Verificeres ikke - må gerne være der | |||
SurName | Verificeres ikke - må gerne være der | |||
Credentials.NationalRole | Må ikke være der | |||
PersistentUniqueKey | Verificeres ikke - må gerne være der | |||
PrincipalUser | Må ikke være der | |||
Organisation | Identifier | Skal være der | organisationIdentifier | |
identifierFormat | Skal være der og skal være CVR | |||
Client | Name | Verificeres ikke - må gerne være der | systemName |
Brugertypen: Administrativ | Verifikation | Mapning til Samtykkeservicen ServiceActor | ||
SecurityContext | Ticket | Audience | Verificeres ikke - må gerne være der | |
Validity | Er valid | |||
Message | Verificeres ikke - må gerne være der | |||
ActingUser | UserType | Skal være HealthCareProfessional | Brugertypen: Administrativ | |
IdentifierFormat | Skal være CPR | |||
Identifier | Skal være sat | actionUserCpr | ||
GivenName | Verificeres ikke - må gerne være der | |||
SurName | Verificeres ikke - må gerne være der | |||
Credentials.NationalRole | Skal være der - og skal matche config variable i MinSpaerring | |||
PersistentUniqueKey | Verificeres ikke - må gerne være der | |||
PrincipalUser | Må ikke være der | |||
Organisation | Identifier | Skal være der | organisationIdentifier | |
identifierFormat | Skal være der og skal være CVR | |||
Client | Verificeres ikke - må gerne være der | systemName |
Brugertypen: System | Verifikation | Mapning til Samtykkeservicen ServiceActor | ||
SecurityContext | Ticket | Audience | Verificeres ikke - må gerne være der | |
Message | Verificeres ikke - må gerne være der | |||
ActingUser | Må ikke være der | Brugertypen: System | ||
PrincipalUser | Må ikke være der | |||
Organisation | Identifier | Skal være der | organisationIdentifier | |
identifierFormat | Skal være der og skal være CVR | |||
Client | Verificeres ikke - må gerne være der | systemName |
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 Samtykkeservicen og ved hjælp af en medsendt HSUID header kan opnå status som een af brugertyperne Borger eller Sundhedsfaglig.
Brugertypen Borger (sundhed.dk) | Verifikation | Mapning til Samtykkeservicen ServiceActor | ||
HSUID Header | userType | Skal være der og skal være CITIZEN | Brugertypen: Borger | |
actingUserCivilRegistrationNumber | Skal være sat | actionUserCpr | ||
responsibleUserCpr | Må ikke være sat eller være anderledes end actingUserCivilRegistrationNumber | |||
systemName | Verificeres ikke - må gerne være der | systemName (prefix) | ||
systemVersion | Verificeres ikke - må gerne være der | systemName (postfix) |
Brugertypen Sundhedsfaglig (sundhed.dk) | Verifikation | Mapning til Samtykkeservicen ServiceActor | ||
HSUID Header | userType | Skal være der og være HEALTHCAREPROFESSIONAL | Brugertypen: Sundhedsfaglig | |
actingUserCivilRegistrationNumber | Skal være sat | actionUserCpr | ||
responsibleUserCpr | Må ikke være sat eller være anderledes end actingUserCivilRegistrationNumber | |||
orgUsingIDType | Verificeres ikke - må gerne være der | healthcareOrgType | ||
orgUsingIDName | Verificeres ikke - må gerne være der | healthCareOrg | ||
systemName | Verificeres ikke - må gerne være der | systemName (prefix) | ||
systemVersion | Verificeres ikke - må gerne være der | systemName (postfix) |
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. 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 MinSpærring Samtykkeservicen - Data Model og indeholder:
Type (samtykke eller spærring)
Hvad det gælder
Hvem det gælder for
Gyldighedsperiode
...
Nogle operationer tillader at bruger og borger ikke er den samme person. Hvis de ikke er den samme person logges handling til borgerens MinLog.
MinSpærring 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.
...
Samtykkeservicen Verifkation
Servicen anvendes til at verificere spærringer og samtykker mellem border og sundhedsfaglig. Service udstiller nedenstående operationer:
...
For sundhedsfaglige er det nedenstående beslutningstræ der anvendes til at lave MinSpærring Samtykkeservicen Verifikation:
Gliffy Diagram macroId d54356ae-900b-4792-b5d3-dd7011d9e504 name Verifikation pagePin 1
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:
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
Som afbildet i figur 3 lagres MinSpærring data i en central database, der replikeres til de forskellige NSP instanser.
d54356ae-900b-4792-b5d3-dd7011d9e504 name Verifikation pagePin 1
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:
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.
HTML |
---|
<iframe src="https://archi.nspop.dk/NSP/570928ca/views/id-0d9123b8-1e2f-41eb-b393-5d9b50963a60.html" name="test" height="340" width="800">You need a Frames Capable browser to view this content.</iframe> |
* Hver kasse i ovenstående diagram har en kort forklaring, som kommer frem i et nyt browservindue, når der klikkes på kassen.
Samtykkeservicen MinSpærring Administration installeres på en central server og eksponeres på NSP-forekomster gennem afkoblingskomponenten DCC. Proxyen for MinSpærring 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.
MinSpærring Samtykkeservicen Verifikation er kun installeret på cNSP og forespærger 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 Samtykkeservicen Administration) forskellige property filer, der leveres som en del af docker setup.
...
For beskrivelse af konfigurationen se MinSpærring Samtykkeservicen - Driftsvejledning.
Applikations konfiguration
...
Service klient konfiguration
MinSpærring 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.
...
Database konfiguration
Begge MinSpærring Samtykkeservicen services skal forsynes med en datasource med navnet 'ConsentServiceDS', der har adgang til den database der er beskrevet i MinSpærring 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 MinSpærring 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 ofreseksisterende 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 MinSpærring Samtykkeservicen - Healthcare Service User Identification Header Interface Description og et body-element.
I MinSpærring Samtykkeservicen Administraition bruges indholdet af HSUID-headeren til at autentificere og validere autorisationen for den kalende 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ærring/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 MinSpærring Samtykkeservicen Verifikation er kun gyldigheden af HSUID-headeren valideret.
...
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 Samtykkeservicen - Administration Service Interface Description og MinSpærring 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, 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 Samtykkeservicen databasen implementeres gennem Hibernate, hvilket gør det muligt at afkoble databashåndteringen fra koden. Datasource til MinSpærring Samtykkeservicen 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 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.
...
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.
...
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
MinSpærring Samtykkeservicen Administration og MinSpærring 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.
...
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.
MinSpærring Samtykkeservicen Verifikation
Verifikationen består af tre forskellige operationer: brugerverifikation, dataverifikation og verifikation af udenlandske sundhedspersonale.
...
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 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 MinSpærring Samtykkeservicen Administration. Det er også muligt at teste MinSpærring Samtykkeservicen Administration med en stub til Min Log.
...
Der findes en række klasse med MinSpærring med Samtykkeservicen Administration integrationstest. De findes alle i modulet consent-administration-integrationtest.
...
MinLog-klassen sikrer, at serviceloggingsmekanismen ved hjælp af MinLog implementeres korrekt.
MinSpærring Samtykkeservicen Verifikation
Der findes en række unit tests til MinSpærring Samtykkeservicen Verifikation. Disse findes alle i modulet consent-verification-app.
...
Yderlige findes der ekstar unit tests i consentservices-common der har til formål at verificere at intercepter og DAO er implementeret korrekt.