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 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 vedkommende 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 frontservice", 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 "frontservice" er ikke direkte afhængig af NSP "backoffice". Alle services, der er rettet mod sundhedsfaglige, er som udgangspunkt altid 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.
Der er grundlæggende to typer af NSP. De centraliserede og de distribuerede.
De to centraliserede NSP-platforme:
I skrivende stund afvikles begge disse NSP-instancer og NSP backoffice i nogle driftcentre 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 er sådan i store træk som det er i virkeligheden. Der er nogle nuancer (flere dNSP'er i Reg. H / Reg. Sj.) osv. som ikke er taget med her.
Alle services på NSP skal tilgås udefra gennem afkoblingskomponenten (DeCouplingComponent = DCC). Du skal betragte DCC'en som den alleryderste skal på en NSP frontservice. 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 have fat i. Du kan læse mere om DCC'en på DCC'ens leverancebeskrivelsesside.
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 sunhedsfagliges 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:
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 lige de indledende afsnit i gennemgangen af IDWS beskrivelsen her.
Det overordnede flow for et DGWS-kald til en service på en NSP ser sådan her ud:
@startuml participant Fagsystem #72BEDB participant STS #72BEDB participant NSP #72BEDB Activate Fagsystem #FF4E26 group Rekvirér SOSI ID-kort (kan caches) Fagsystem -> STS: NewSecurityTokenService(OCES signatur ...) Activate STS #FF4E26 return Autentifikationsbevis (SOSI-ID-Kort) Deactivate STS end Fagsystem -> NSP: ServiceX(SOSI ID-kort,CPR-nr,...) Activate NSP #FF4E26 return ok? @enduml |
Så først skal man have en adgangsbillet. Den kan man få ved at have gennemført en passende sikker autentifikationshandling. I DGWS på NSP er det i skrivende stund altid baseret på OCES certifikatinfrastrukturen (MOCES for sundhedsfaglige, Systemcertifikater (FOCES) for systemer). 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!
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 E-journal web servicen ved NSP'ens STS service. (For detaljerytteren: Vi ved godt, at E-journal web servicen ikke er tilgængelig på NSP, men det håber vi du kan abstrahere fra . Der er flere andre OIOIDWS services på NSP).
Læs meget mere om IDWS/OIOIDWS her.
Disposition: