Komponenter og infrastrukturservices

For at gøre det lettere for leverandører af it-systemer at koble disse på Sundhedsvæsenets nationale infrastruktur stiller SDSD hjælp til rådighed i form af:

• Kodebiblioteker, der kan bygges ind i Java og .NET (Microsoft Windows) applikationer.
• Infrastrukturservices, skrevet i Java, der kan installeres lokalt og kommunikere med it systemerne.

I begge tilfælde håndteres sikkerhedsaspekter og kommunikation med nationale services via disse artefakter.

Brugen af artefakterne illustreres via følgende scenarium:

Case: Det Fælles Medicinkort

Det Fælles Medicinkort er et centralt it-system, der indeholder oplysninger om udstedt medicin for alle danske patienter. Systemet får oplysninger fra decentrale parter i primærsektoren (lægepraksis) og sekundærsektoren (sygehusene).

For at kommunikere med FMK kræves det af et decentralt it-system, at det er i stand til at danne et webservice SOAP kald indeholdende en SAML 2.0 assertion med lægens identitet. At få skabt en assertion som FMK vil acceptere kræver desuden at systemet kan kommunikere med SDSDs centrale STS web service, der kan validere og sige god for sundhedsfaglige brugere. Endelig kræver FMK digital signatur og det er derfor nødvendigt at bestille og udrulle et medarbejdercertifikater til læger, samt gøre det muligt at foretage digital signering af data fra it-systemet under pålogning.

Scenarium 1: Lægepraksissystemleverandør

En udbyder af it-systemer til almen praksis har behov for at udvide sit it-system til at kunne kommunikere oplysninger om udleveret medicin med Lægemiddelstyrelsens centrale Fælles Medicinkort server (FMK). Udvidelsen vil give den praktiserende læge mulighed for at få et mere retvisende billede af egne patienters medicinering når disse f.eks. er i ambulant behandling på et sygehus eller netop er blevet udskrevet.

Seal

Systemleverandøren ønsker ikke selv at implementere SAML 2.0 understøttelsen, men henter hjælp hos SDSD. Systemet er skrevet til Microsoft platformen og kan håndtere at kalde .NET biblioteker. SDSD tilbyder .NET biblioteket Seal, der indpakker al håndtering af kald til STS, dannelse og verifikation af digitale signaturer, samt håndtering af de ekstra SOAP headere der forlanges i infrastrukturen. Systemleverandøren henter derfor Seal.NET ned og udvider sit system til at anvende bibliotekets snitflader til kommunikation med STS og FMK.

Figuren nedenfor illustrerer denne case:

Seal findes i både en Java og en .NET udgave.

Scenarium 2: EPJ leverandør

En leverandør af medicinmoduler til sygehusejere har behov for at udvide sit system til at kunne kommunikere oplysninger om udleveret medicin på egne patienter med Lægemiddelstyrelsens centrale Fælles Medicinkort server (FMK). Medicinmodulet er i drift i en region, der foruden dette system også anvender andre produkter i den kliniske hverdag, herunder booking systemer, RIS/PACS, mm. Regionen ønsker at der findes en generel løsning på udfordringen med at kommunikere med det nationale niveau, så der kan opnås følgende fordele:

1. Central håndtering af digital signering og validering udenfor de enkelte systemer.
2. Deling af SAML 2.0 assertions på tværs af systemer, så password til signaturen ikke skal afgives for hvert system.
3. Nemmere opgradering af eksternt kommunikerende it-systemer, da al logikken hertil er ekstern og central.

SDSD udbyder to infrastrukturprodukter til dette formål: SOSI Gateway (SOSI-GW) og SOSI Decoupling Component (SOSI-DCC). Produkterne er udviklet som JEE applikationer, der er beregnet til installation i en applikationsserver. Begge produkter findes i en sampakket version med Apache Tomcat.

SOSI-GW

Et it-system, der benytter SOSI-GW som proxy overfor eksterne webservices i sundhedssektoren skal overordnet kunne håndtere 2 opgaver:

1. At danne en SOAP besked med det forretningsdata som kræves af webservicen, samt indsætte brugernavnet på den person der er logget på it-systemet i en header. SOAP beskeden sendes så til SOSI-GW.
2. At håndtere svar fra SOSI-GW der enten er en viderestilling af svaret fra webservicen (SOAP fault eller forretningsdata) eller en SOSI-GW specifik kommando.

Hvis brugeren ikke tidligere har været logget på føderationen eller det kræves at der på ny logges på (f.eks. ved timeout) vil SOSI-GW returnere en kommando til it-systemet. SOSI-GW kan konfigureres til at håndtere hele signeringsprocessen, men kan også lade dette være op til it-systemet.

Hvis SOSI-GW skal forestå signeringen af data, returneres en URL på en webserver hos SOSI-GW, som it-systemet skal hente f.eks. ved at videregive URL'en til en browser. På SOSI-GW kører en lille web applikation, der vil prompte brugeren for password til dennes digitale signatur, gennemføre signeringen og returnere de signerede data til SOSI-GW. Efterfølgende vil proxyen logge på føderationen for brugeren ved at sende de signerede data til STS'en og gemme svaret i en lokal cache.

Ønsker it-systemet selv at signere data, f.eks. fordi det vurderes at en browserløsning bryder med designet, returnerer SOSI-GW i stedet de data der skal signeres. Det er nu op til it-systemet at danne signaturen med brugerens private nøgle, prompte brugeren for password, mm. De signerede data returneres efterfølgende til SOSI-GW af it-systemet, hvorpå logonprocessen beskrevet ovenfor gennemføres og svaret lages i en lokal cache hos SOSI-GW.

Et cluster af SOSI-GW instanser kan nu dele den samme cache hvilket muliggør single-signon på tværs af forskellige it-applikationer for den samme bruger i en virksomhed.

SOSI-DCC

Webservices er eksterne applikationer, der kan være mere eller mindre pålidelige og have forskellige svartider afhængig af belastning. Et it-system, der kalder webservices er derfor nødt til at være robust overfor denne usikkerhed og sørge for at brugeren generes mindst muligt når noget ikke går som planlagt.

En ofte anvendt mekanisme er at kalde webservices i en selvstændig eksekveringstråd, så hovedprogrammet ikke hænger hvis servicen ikke returnerer med det samme. Det er imidlertid ikke trivielt at implementere en sådan asynkronitet og er man ikke omhyggelig fører det let til at systemressourcer lækkes og it-systemets pålidelighed udfordres.

SOSI-DCC tilbyder to faciliteter:

1. At afkoble it-systemet fra en ekstern webservice ved at kalde denne i en separat tråd. It-systemet kan selv bestemme semantikken af kaldet, så der returneres med det samme og svaret senere kan hentes (asynkron) eller at kaldet til DCC afventer svaret fra webservicen dog med et timeout på f.eks. 20 sekunder (synkron med timout).
2. At udstille lokale udgaver af eksterne webservice snitflader, så det for et it-system ser ud som om det kalder en lokal service. It-systemet er dermed helt afkoblet fra at der i virkeligheden befinder sig en ekstern service bag den lokale DCC.

-- KaareKjelstroem - 21 Nov 2008