Page History
...
Definitioner og referencer
NSP | National Service Platform |
SFSK | Synkroniseringsservice til Fælles Stamkort |
DGWS | Den Gode WebService |
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)).
...
SFSK kan opfattes som en alternativ DDS, som har til formål at udstille data for anvenderne i forbindelse med Fælles Stamkort.
...
- 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:
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
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
...
Nedenstående diagram viser den interne opbygningen af SFSK.
I designet er der lagt vægt på at definere en fornuftig struktur, hvor hver af begge SFSK services er opbygget på en ensartet måde.
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
Ovenstående diagram viser, hvorledes en DROS SFSK ITI-18 og ITI-X service 43 services er opbygget.
Selve service interface og implementation er placeret i pakkerne dk.nsp.drossfsk.servicews(.impl). Klasserne i disse pakker er ansvarlige for at modtage requests fra anvenderne på de for DROS SFKS definerede snitflader. Ved at anvende klasser i pakken dk.nsp.drossfsk.security valideres det, at den indkommende sikkerhedsbillet er valid og overholder de for DROS SFKS definerede krav (se evt. DROS - Driftsvejledning for muligheder for opsætning sikkerhedshåndtering i SFSK nedenfor).
Klasserne i pakkerne dk.nsp.drossfsk.service.validationws(.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).selve forretningsservices i SFSK.
Hvis sikkerhedsvalideringen eller konverteringen i SFSK ikke er succesfuldHvis valideringerne i DROS ikke er overholdt, så returnerer DROS 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 seperate 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 Hvis valideringerne er overholdt, så anvender DROS klasser i pakkerne dk.nsp.drossfsk.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 forretningsreglerne for de to services til at kalde den bagvedliggende XDS infrastruktur.
2.3. Validering i DROS
DROS validerer de indkommende request.
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
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.
Forretningsregler i forbindelse med "Søg dokumenter" i SFSK
Når et kald er blevet sikkerhedsvalideret sker der en validerering af det indkommende request. Der I skrivende stund er der tale om en simpel validering, der tjekker, om det indkommende ITI-18 request er lovligt i henhold til standarden IHE XDS.Valideringspakkerne er struktureret, så disse senere kan udvides med NSP specifikke valideringer.
Sekvensdiagrammerne nedenfor beskriver forretningsreglerne 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.
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|