NSP - en robust distribueret arkitektur

Robusthed, tilgængelighed og fejltolerance er nogle af de mest centrale principper i designet af NSP arkitekturen. NSP er helt fra begyndelsen designet, så parterne på sundhedsområdet skal kunne regne med, at NSP-services er tilgængelige selvom der skulle være alvorlige udfald i forskellige dele af den nationale infrastruktur. Så når vi på nogle af de andre sider i denne introduktion skriver "NSP platformen", så taler vi om NSP på et abstrakt plan. På det fysiske plan er der nemlig ikke tale om én platform, men om flere forskellige NSP'er i mange forskellige driftscentre rundt omkring i Danmark. Her mener vi ikke bare redundans, flerserver-setup, clusters og 'disaster-tolerance', men om faktiske uafhængige platforme, der er i stand til at køre alene i 'ø-drift' i en længere periode, hvor de for mange af NSP'ens services vil fortsætte med at levere service, samle data op og - hvis de opsamlede data skal videresendes - sende dem videre, når alle forbindelser er retableret.

En logisk NSP platform består af en "NSP frontoffice", hvor services og deres nødvendige data mv. ligger i en platform.

For nogle services vedkommende, skal der samles data op, foretages periodiske beregninger eller lignende, som i nogle tilfælde også skal distribueres ud til de øvrige NSP'er. Opsamling, beregning og datadistribution foregår normalt i "NSP backoffice". NSP "frontoffice" er ikke direkte afhængig af NSP "backoffice". Alle services, der er rettet mod sundhedsfaglige, er som udgangspunkt asynkront afkoblet. Det giver en ekstra kompleksitet, men også en reel uafhængighed, så en NSP i tilfælde af nedbrud andre steder i infrastrukturen kan køre videre i et stykke tid, indtil infrastrukturen igen er fuldt fungerende.

Typer af NSP

Der er grundlæggende to typer af NSP. De centraliserede og de distribuerede.

De to centraliserede NSP-platforme:

  • cNSP (den centrale NSP), som alle parter, der ikke har sin egen NSP stående i eget driftscenter, kan anvende.
  • NSP-GW (eller bare NGW) er en slags gateway-udgave af en NSP, som i første omgang var tiltænkt kommunerne.

I skrivende stund afvikles begge disse NSP-instancer og NSP backoffice i driftscentre i Ålborg.

Derudover er der de distribuerede NSP'er, dNSP'erne. Der er pt. sådan en platform i hver region i Danmark. Alle disse platforme kan køre i 'ø-drift', så hvis der skulle være et lokalt problem i en region, så kører alle de andre regioners NSP'er videre. NSP-typerne og deres nuværende fysiske landsdelsplacering ses af nedenstående figurer:

Bemærk: cNSP, NSP-GW og NSP backoffice afvikles ikke i Region Nordjyllands driftscentre. Det gør Region Nordjyllands dNSP imidlertid.

Ovenstående afspejler i store træk virkeligheden. Der er nogle nuancer (flere dNSP'er i Reg. H / Reg. Sj.) osv., som ikke er taget med her.

Afkoblingskomponenten

Alle services på NSP skal tilgås udefra gennem afkoblingskomponenten (DeCouplingComponent = DCC). Du skal betragte DCC'en som den alleryderste skal på en NSP frontoffice instans. Så man skal aldrig bruge et endpoint til en bestemt "Service X", men bruge DCC-komponentens endpoint og angive, at det er "Service X", man gerne vil kalde. Dette giver nemlig fleksibilitet på NSP til at ændre endpointet for en given "Service X", uden at det påvirker anvenderne. Du kan læse mere om DCC'en på DCC'ens leverancebeskrivelsesside. 

Adgangsbilletter og service-kald

Som skrevet andetsteds er der efterhånden rigtig mange forskellige services tilgængelig på NSP. Nogle retter sig direkte mod sundhedsfaglige slutbrugere (forretningsservices), andre er støtteservices til de sundhedsfagliges fagsystemer, og andre igen retter sig mod borgere, der får vist data i apps eller på Sundhed.dk / Sundhedsjournalen eller andre steder.

Adgangen, og det flow, der skal følges, afhænger af, hvilken type slutbruger, der kalder:

  1. Sundhedsfaglig person: Skal følge flowet Den Gode Web Service for sundhedsfaglige,  DGWS → Bruger-ID-Kort flowet
  2. Sundhedsfagligt fagsystem: Skal følge flowet Den Gode Web Service for systemer, DGWS → System-ID-Kort flowet
  3. Borger/Patient: Skal følge Identitetsbaseret Web Service flowet, IDWS

Både DGWS og IDWS er egentlig eksempler på "Identitetsbaserede Web Services". Hvis du ikke helt ved, hvad det er, eller hvorfor det er smart, så læs de indledende afsnit i gennemgangen af IDWS beskrivelsen her. 

Den gode web service - Overordnet

Det overordnede flow for et DGWS-kald til en service på en NSP ser sådan her ud:



Så først skal man have en adgangsbillet. Den kan man få ved at have gennemført en passende sikker autentifikationshandling. Adgangsbilletter udstedes af STS-servicen på NSP, så det kan du læse meget mere om i STS'ens anvenderguide. 

Bemærk: STS’en skal betragtes som endnu en DGWS service på NSP, så den skal jeres system også whitelistes til at anvende!

IDWS og OIOIDWS - et lidt mere kompliceret flow

Nu bliver det lidt mere indviklet, fordi flowet både involverer de fællesoffentlige autentifikations- og trust-services (MitID og NemLogin eller SEB IdP'en) og flere forskellige omvekslinger. Selve OIOIDWS-kaldet sker i skridt 3 i figuren nedenfor, men forinden er borgeren/patienten logget ind gennem NemLogin eller SEB IdP'en, og der er rekvireret en adgangsbillet til NSP'ens Organdonorregistreringsservice ved NSP'ens STS service.

Læs meget mere om IDWS/OIOIDWS her. De fællesoffentlige profiler finder du her hos Digitaliseringsstyrelsen.

Opbygning af service-kald

De data, der sendes og returneres fra en service på NSP overholder en standardiseret struktur:

Ovenstående er et eksempel på strukturen i en DGWS service. En hel del af det, der kan findes her på NSPOP, handler om, hvordan Header oplysningerne og adgangsbilletter er opbygget. Der er lidt forskel på, hvordan et DGWS og et IDWS kald ser ud, men den overordnede struktur er nogenlunde ens.

  • I DGWS kald er adgangsbilletten et såkaldt 'SOSI ID-kort' og header- og body-strukturen skal følge "Den Gode Web Service" profilen. I DGWS kald kan adgangsbilletten typisk caches lidt længere og bruges mere på tværs af services end i IDWS kald. Det op til servicen at afgøre, om den medsendte adgangsbillet er "frisk" og stærk nok til at få adgang til servicen. Hvis adgangsbilletten (i forhold til den pågældende service) ikke er god nok, returneres der en fejl, men servicen kan kaldes efter der er rekvireret en ny adgangsbillet.
  • I IDWS kald er adgangsbilletten et såkaldt "identity token" og er bundet til et bestemt 'audience'. Typisk kan et identity token kun anvendes i få minutter og kun mod en bestemt service, så der skal veksles lidt oftere. Den overordnede struktur af header og body på IDWS kald følger OIOIDWS SOAP profilen. Den overordnede struktur for IDWS adgangsbilletter (identity tokens) følger OIO Identity Token Profile.

Borgeres adgang til services med fuldmagt

Når en borger ønsker at hjælpe eller støtte en pårørende eller en nærtstående, så kan de få adgang til NSP services med fuldmagt. Fuldmagten afgives i den fællesoffentlige fuldmagtsløsning på Borger.dk.

Når den, der har fået fuldmagt (fuldmagtshaveren), logger ind på f.eks. Sundhedsjournalen/Sundhed.dk, så vælger fuldmagtshaveren, hvem vedkommende gerne vil se eller ændre data for (fuldmagtsgiveren). 'Beviset' for at fuldmagtshaver har en gyldig fuldmagt til at kunne tilgå en bestemt service, indbygges i adgangsbilletten. Det sker i omvekslingen (step 2 ovenfor), hvor Sundhedsjournalen/Sundhed.dk vedlægger et såkaldt "claim" om, at brugeren har fuldmagt. Det efterprøver STS-servicen, og hvis det er korrekt, så indlejres beviset i adgangsbilletten (identity token).

OIO Identity Token Profile er udformet så smart, at der kan indlejres mange forskellige beviser, der kan overholde flere forskellige profiler.

Lige netop for den slags særligt basale privilegier, som en fuldmagt jo er, har Digitaliseringsstyrelsen udarbejdet en rammeprofil, der hedder OIO Basic Privilege Profile. Den regulerer hvordan sådan nogle basale privilegier skal udformes i IdentityToken for IDWS kald. Når OIOBPP ikke længere slår til, kan man lokalt i domænet udvikle andre profiler, hvor der kan opnås bedre standardisering og udtrykskraft. Det benyttede vi os af i 2023-2024, hvor de to nederste profiler på figuren ovenfor (Blurring Instructions Profile og Subject Relations Profile) blev udarbejdet og taget i brug (se evt. mere i ID Sløring projektområdet) - førstnævnte anvendes til at udtrykke sløring, og sidstnævnte anvendes til at udtrykke potentielt adgangsgivende relationer mellem personer, som f.eks. forældremyndighed.

Helt konkrete eksempler på, hvordan sådan nogle profilerede "beviser" ser ud i indlejrede IdentityTokens finder du her:


  • No labels