Introduktion

Formål

Formålet med dette dokument er at beskrive systemarkitekturen for SFSK.

Læsevejledning

Nærværende dokument er tiltænkt udviklere og IT-arkitekter med interesse i SFSK og dens opbygning.

Definitioner og referencer

Overblik over SFSK

SFSK er en service til at gøre det muligt at fremsøge og hente Fælles Stamkort via snitflader, som de kendes fra Dokumentdelingsservice Registry og Repository (se DDS - Design- og Arkitekturbeskrivelse (Registry) og DDS - Design- og Arkitekturbeskrivelse (Repository)).

I modsætning til DDS, så er SFSK målrettet systembrugere og dækker det behov, der kan være for synkronisering af Fælles Stamkort i anvendernes fagsystemer.

I de følgende afsnit kigger vi på SFSK og dens afhængigheder til andre NSP services og i form af tredjepartsbiblioteker.

Løsningens afhængigheder

SFSK i samspil med andre NSP Services

SFSK kan opfattes som en alternativ DDS, som har til formål at udstille data for anvenderne i forbindelse med Fælles Stamkort.

SFKS har til ansvar at:

• sikkerhedsvalidere kald fra anvendersystemer
• hente data i de bagvedliggende registre FSK Registry og FSK
• foretage de nødvendige tjek i forhold til dataspærringer i MinSpærring i forbindelse med fremsøgning af stamkort (da SFSK kun skal anvendes af systembrugere giver filtrering i forhold til spærringer mod enkeltpersoner) ikke mening i SFSK
• foretage logninger i MinLog2 ved fremsøgning og afhentning af stamkort
• foretage auditlogning

SFSK indgår i samspil med de øvrige NSP services på følgende måde:

Relevante tredjepartsbiblioteker

SFSK betjener sig af tredjeparts biblioteker fra IPF Open eHealth Integration Platform til implementations- og hjælpeklasser, der har med XDS IHE at gøre.

SFSK anvender følgende NSP libraries:

• audit-api
• security-api
• minlog-producer

Løsningens opbygning

Nedenstående diagram viser den interne opbygningen af SFSK.

I designet er der lagt vægt på at definere en fornuftig struktur, hvor begge SFSK services er opbygget på en ensartet måde.

Ovenstående diagram viser, hvorledes en SFSK ITI-18 og ITI-43 services er opbygget.

Selve service interface og implementation er placeret i pakkerne dk.nsp.sfsk.ws(.impl). Klasserne i disse pakker er ansvarlige for at modtage requests fra anvenderne på de for SFKS definerede snitflader. Ved at anvende klasser i pakken dk.nsp.sfsk.security valideres det, at den indkommende sikkerhedsbillet er valid og overholder de, for SFKS, definerede krav (se sikkerhedshåndtering i SFSK nedenfor).

Klasserne i pakkerne dk.nsp.sfsk.ws(.impl) indeholder funktionalitet der har til formål at:

• Validere det indkommende request (se afsnit nedenfor vedr. validering)
• Konvertere de indkommende requests til domæneklasser (som defineret i biblioteket openehealth) til brug for selve forretningsservices i SFSK.

Hvis sikkerhedsvalideringen eller konverteringen i SFSK ikke er succesfuld, så returnerer SFSK passende fejlbesked til den kaldende anvender.

Ellers sendes kaldet videre til SFSKs forretningslag.

Klasserne i pakkerne dk.nsp.sfsk.serivce(.impl) indeholder forretningsfunktionaliteten (se de to afsnit ved Forretningsregler nedenfor)

Integrationerne til hhv MinLog2 og MinSpærring er implementeret i separate moduler og anvendelsen af disse er afkoblet fra forretningslaget ved hjælp af interfaces (se dk.nsp.sfsk.components).

Kaldende fra SFSK proxy'es videre til backends ved implementation i pakken dk.nsp.sfsk.backend(.impl).

Implementationsklasser til kommunikation med backends, MinLog2 og MinSpærring kan alle trække på moduler til håndtering af SFSKs eget SOSI Idkort i pakken dk.nsp.sfks.security.

Sikkerhedshåndtering og forretningsregler i SFSK

I det følgende beskrives sikkerhedshåndteringen og forretningsreglerne i SFKS. Først beskrives sikkerhedsprotokollen.

Dernæst beskrives flowet for de to services til hhv fremsøgning og hentning af dokumenter.

Sikkerhedshåndtering i SFSK

SFSK anvender det på platformen udstillede security-api til at validere de indkommende requests. Alle kald til SFKS skal være lovlige DGWS kald. Det tjekkes at:

• det medsendte SOSI Idkort er validt
• det medsendte SOSI Idkort identificerer et system (og ikke en person) dvs. niveau 3 SOSI Idkort er de eneste, der accepteres
• det pågældnede anvendercertifikat er whitelistet i SFSK

Når SFSK kalder videre til de bagvedliggende services sker dette også vha DGWS. Dog trækker SFSK sit eget niveau 3 SOSI Idkort i den videre kommunikation med de bagvedliggende services. Identiteten af kaldet skifter således til at være et kald udført af SFSK, hvilket betyder at der kan udføres whitelisting i FSK til at tillade niveau 3 idkort fra det CVR nummer, som er identificeret i SFSKs Idkort.

SFSK har sin egen whitelistingtabel, hvor subject serialnumber for det kaldende certifikat skal være whitelistet. Se SFSK - Driftsvejledning for detaljer.

Der skal være mulighed for værdispring i løsningen, hvorved tjek af spærringer omgås. Værdispring aktiveres ved at med sende HTTP header 'consent-override'. (Den første) værdi af denne header fortolkes som en boolsk variable med lovlige værdier (caseinsensitive true/false). Andre eller manglende værdi fortolkes som, at der ikke foretages værdispring (dvs false). Denne oplysning ligger udenfor sikkerhedsvalideringen men opbevares på SystemUserContext til anvendelse af forretningsregler (se nedenfor).

Flow i forbindelse med "Søg dokumenter" i SFSK

Når et kald er blevet sikkerhedsvalideret sker der en validerering af det indkommende request. Der tale om en simpel validering, der tjekker, om det indkommende ITI-18 request er lovligt i henhold til standarden IHE XDS.

Sekvensdiagrammerne nedenfor beskriver flowet i forbindelse med "søg dokumenter". Flowet minder om det tilsvarende flow i Dokumentdelingsservicen, men er simplere, da der ikke tjekkes for spærringer mod enkeltpersoner ligesom kaldet til Behandlingsrelationservice udelades.

Filtrering af data via MinSpærring

De fundne metadata filtreres ved at tjekke i MinSpærring verifikationssnitfladen, om der eksisterer spærringer mod mod et af de fundne dokumenter. Et dokument tjekkes ved at at kigge på alle organisationer (sor-koder), der har redigeret dokumentet, på alle relevante tidspunkter. Disse tidspunkter er ServiceStartTime og ServiceStopTime, hvis de er tilstede, samt CreationTime for dokumenter af typen Stable, og 'nu' (opslagstidspunktet) for dokumenter af typen OnDemand. Hvis der for en eneste af disse kombinationer af sor-kode og tidspunkt er angivet andet end positivt samtykke, så filtreres dokumentet fra.

Flow i forbindelse med "Hent dokumenter" i SFSK

Når et kald er blevet sikkerhedsvalideret sker der en validering af det indkommende request. Der er tale om en simpel validering, der tjekker, om det indkommende ITI-43 request er lovligt i henhold til standarden IHE XDS.

Sekvensdiagrammerne nedenfor beskriver flowet i forbindelse med "hent dokumenter".

Afklaringer

• Ingen HSUID dvs ingen mulighed for værdispring. Beslutning: Der skal være mulighed for værdispring, men HSUID er overkill. Der skal anvendes en HTTP header til at angive "consent-override" (anvenderdokumenteres). Det skal tilføjes til auditlogging, om der er consent override eller ej.
• MinSpærring kræver et cpr på den sundhedsfaglige bruger i datatjek. Vi antager, at det er ok at medsende 'USPECIFICERET'.
• Hvilket tidspunkt skal bruges til at tjekke for i MinSpærring? Det er et ondemand dokument uden service start eller service endtime. Beslutning: Hvis det er obligatorisk at sende dato med i spærringstjek, så bruges "Nu".
• Lige en hovsa....Vi kan ikke kalde MinLog fra "Hent Dokumenter", da vi ikke kender patientid. Beslutning: Det droppes som en del af dokumenthenting og laves stadig ved dokumentsøgning.