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 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
• foretage logninger i MinLog2
• foretage auditlogning

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 NSP libraries:

• audit-api
• security-api

Løsningens opbygning

Nedenstående diagram viser opbygningen af SFSK.

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

Ovenstående diagram viser, hvorledes en DROS ITI-X service er opbygget.

Selve service interface og implementation er placeret i pakkerne dk.nsp.dros.service(.impl). Klasserne i disse pakker er ansvarlige for at modtage requests fra anvenderne på de for DROS definerede snitflader. Ved at anvende klasser i pakken dk.nsp.dros.security valideres det, at den indkommende sikkerhedsbillet er valid og overholder de for DROS definerede krav (se evt. DROS - Driftsvejledning for muligheder for opsætning).

Klasserne i pakkerne dk.nsp.dros.service.validation(.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 videre validering (se afsnit nedenfor vedr. validering).

Hvis valideringerne i DROS ikke er overholdt, så returnerer DROS passende fejlbesked til den kaldende anvender.

Hvis valideringerne er overholdt, så anvender DROS klasser i pakkerne dk.nsp.dros.backend(.impl) til at kalde den bagvedliggende XDS infrastruktur.

2.3. Validering i DROS

DROS validerer de indkommende request.

I skrivende stund er der tale om en simpel validering, der tjekker, om det indkommende request er lovligt i henhold til standarden IHE XDS.

Valideringspakkerne er struktureret, så disse senere kan udvides med NSP specifikke valideringer.