Bilaga 3: RIV-SHS förstudie, Mina intyg

Transkript

1 Bilaga 3 RIV-SHS förstudie, Mina intyg

2 Innehållsförteckning 1. Inledning Bakgrund Historik Problembeskrivning Nulägesbeskrivning Börlägesbeskrivning Effektmål Funktionella krav Ickefunktionella krav Lösningsalternativ (S1) Scenario 1 Inköp av SHS-Server i form av färdig produkt (S2) Scenario 2 Utveckling av SHS-Adapter till befintlig integrationslösning (NTJP) (S3) Scenario 3 Utveckling av SHS-Server (Axel) för integration med befintlig integrationslösning (NTJP) (S4) Scenario 4 Inköp av tjänsten i form av Software as a Service (SaaS - molntjänst) Lösningsförslag Konceptuell arkitektur Uppdragsbeskrivning Sid 1/12

3 1. Inledning Detta dokument är en förstudie som analyserar och diskuterar olika angreppssätt för att tillföra SHS funktionalitet till Landstingets RIV-baserade kommunikationslösning. I dokumentet ges en kortfattad beskrivning av olika protokollstandarder samt ett antal lösningsscenarier. Dokumentet innehåller också en högnivåarkitektur av förelagen lösning samt ett förslag till uppdragsbeskrivning med tillhörande kostnadsestimat. Samtliga tekniska beskrivningar hålls på en övergripande nivå. Mottagare för detta dokument är lämpligen personer i beslutsfattande ställning och/eller tekniskt/verksamhetsmässigt berörda personer. 2. Bakgrund Sveriges alla Landsting och därtill hörande organisationer är anslutna till ett informationsnätverk för överföring av elektronisk information. Nätverket använder den egna protokollstandarden RIV för att säkerställa korrekt och tillförlitlig överföring. Från detta nätverk finns behov att kunna kommunicera med statliga myndigheter och verk. Sveriges myndigheter och därtill anslutna organisationer har beslutat att använda protokollet SHS (Spridnings- och HämtningsSystem) för att lösa sina kommunikationsbehov, vilket innebär att den kommunikation som sker med RIV måste kunna översättas till SHS. Projektet har fått i uppdrag att analysera olika möjligheter att ansluta NTJP till SHS-nätverket. Analysen ska ge ett antal olika lösningsalternativ som presenteras i form av scenarier. Det mest gynnsamma scenariot specificeras med en kortfattad teknisk och affärsmässig beskrivning. 3. Historik SHS utvecklades under slutet av 90-talet som en enhetlig protokollstandard för utbyte av information mellan myndigheter och därtill relaterade organisationer. Upphandlande myndighet var vid den tiden Statskontoret med Kammarkollegiet som slutlig mottagare. Skatteverket (dåvarande RSV) och Försäkringskassan (dåvarande RFV) var huvudsakliga intressenter och starkt pådrivande. Fyra företag fick tilldelning och uppdrag att utveckla var sin lösning. Av dessa finns endast ett alternativ kvar som erbjudande till marknaden. Idag används SHS för allt elektroniskt informationsutbyte med statliga myndigheter och verk. Under de senaste åren har uppdraget att förvalta och underhålla SHS-Specifikationen övergått till Försäkringskassan. Försäkringskassan utför också drift och förvaltning av den globala SHSkatalogen som används för adressuppslag. 4. Problembeskrivning Sid 2/12

4 Informationsöverföring mellan Landsting och Myndigheter sker över tillfälliga och ickestandardiserade protokoll. Myndigheter kräver överföring över SHS, stöd för detta saknas i nuvarande version av NTJP. 5. Nulägesbeskrivning SHS är ett nätverk för myndigheter och vissa organisationer som specificerats av Kammarkollegiet. RIV fyller samma syften för vård och landsting och är specificerad av Centrum för e-hälsa. Dessa två specifikationer är inkompatibla med varandra och information kan därför inte flöda från det ena nätverket till det andra på ett enhetligt och standardiserat sätt. SHS och RIV skiljer sig åt på flera kritiska punkter, de har exempelvis skilda standarder för e-id och certifikathantering, adressering, tjänstekataloger, kommunikationsformat och säkerhet. 6. Börlägesbeskrivning 6.1. Effektmål Att möjliggöra sömlös informationsöverföring över ett standardiserat protokoll mellan RIV- och SHS-anslutna organisationer. Att skapa en öppen lösning som finansieras en gång och kan återanvändas av alla som behöver, utan licenskostnad och leverantörsberoenden. Att skapa en lösning som inte är knuten till någon teknisk implementation och därför inte innebär inlåsningseffekter Funktionella krav Lösningen ska i alla relevanta sammanhang vara specifikationskomplett i enlighet med SHS Specifikation version (eller senare version). Lösningen ska vara sömlöst integrerbar med NTJP. Lösningen ska fungera för både synkron och asynkron kommunikation. Stöd ska finnas för samtliga överföringsmetoder som specificeras i SHS Specifikation version (In-Out, In-only w/wo ack, Publish-subscribe, etc). Lösningen ska kunna anpassas för transport av samtliga förekommande och framtida meddelandeformat i RIV. Lösningen ska uppfylla samtliga krav på integritet och säkerhet som ställs i SHS Specifikation version Detta gäller transportsäkerhet, meddelandesäkerhet, meddelandeintegritet, leveranssäkerhet, och avsändar- och mottagarautentisering. Sid 3/12

5 Lösningen ska uppfylla samtliga krav för händelseloggning, övervakning och spårbarhet som anges i SHS Specifikation version Dessa funktioner ska kunna integreras och styras från NTJP. Lösningen ska tillhandahålla ett webb-baserat administrationsgränssnitt för konfiguration. Lösningen bör vara utförd i en komponentbaserad arkitektur. Protokolladaptrar ska kunna användas tillsammans med befintliga integrationsplattformar (NTJP) Ickefunktionella krav Lösningen får inte inkräkta på eller påverka nuvarande kommunikationsplattform (NTJP) eller dess protokoll RIV. Lösningen skall vara horisontellt och vertikalt skalbar för att teoretiskt kunna hantera arbiträr storlek på last. Lösningen ska inte ha några teoretiska övre begränsningar i meddelandestorlek, praktiska begränsningar får förekomma. Lösningen ska inte begränsa Landstingens kommunikationsprotokoll (RIV) i existerande eller i kommande användningsfall. Lösning ska vara utförd i öppen licensmodell och alla ingående komponenter ska vara baserade på en öppen modell med fri användnings- och redistributionsrätt. 7. Lösningsalternativ Utifrån ovan beskrivna problemdefinition och kravbild har vi tagit fram fyra olika realistiska lösningsalternativ (S1) Scenario 1 Inköp av SHS-Server i form av färdig produkt. En mjukvara som låter organisationer kommunicera över SHS finns för inköp på den öppna marknaden. Produkten produceras och distribueras av företaget Ida Infront och är i sig själv en hel integrationslösning med många tillhörande moduler och väl utbyggd funktionalitet utöver SHS-kommunikation. Fördelar Allt i ett lösning. Beprövad lösning. Specifikationskomplett. Innehåller RIV/SHS brygga. Sid 4/12

6 Nackdelar Dyr (licenskostnader). Fyller inte skall-krav på öppen och fri källkod (proprietär programvara). Leverantörsinlåsning avseende support, förvaltning och vidareutveckling. Monolit, ingående komponenter kan ej återanvändas i andra integrationsplattformar. Kommentar Ida Infronts produkt heter iipax och är en lösning för en organisations totala integrationsbehov. Den innehåller moduler för att lösa allt från att bygga e-tjänster till dokument-, arkiv- och ärendehantering. Iipax är specifikationskomplett enligt SHS-specifikationen och är en beprövad lösning i sammanhanget. Iipax är en monolitisk integrationsplattform, delar av plattformen, exempelvis protokolladaptern för SHS, kan inte användas separat (S2) Scenario 2 Utveckling av SHS-Adapter till befintlig integrationslösning (NTJP). För att tillse SHS-kommunikation utifrån enkla behov kan funktionen erhållas genom att utveckla en protokolladapter till den befintliga integrationsplattformen. Fördelar Enkel att använda i existerande integrationsflöden. Ingen ytterligare server-mjukvara behövs för SHS-kommunikation. Kan göras specifikationskomplett, vi kontrollerar ingående krav (fyller kravspecifikationen) Reducerar komplexitet genom att använda befintlig infrastruktur. Open Source. Nackdelar Invasiv på existerande integrationslösning. Förändringar kommer att behöva utföras. Kostnad och komplexitet är i samma härad som för Scenario 3. Kommentar En SHS-adapter för användning direkt i befintlig integrationsplattform är på många sätt det mest optimala lösningsalternativet. Det reducerar komplexitet och kostnad över tid eftersom förvaltning och underhåll ej behöver utföras på två parallella plattformar. Det förenklar också användning eftersom SHS-kommunikation kommer att finnas tillgängligt direkt i alla integrationsrutter. Det skiljer dock inte mycket i kostnad mellan detta alternativ och att utveckla en hel SHS- Server, alla tidskrävande och komplicerade delar ingår i detta scenario också. Implementation av adaptern i NTJP är också komplicerad, tidskrävande och riskfylld. Sid 5/12

7 7.3. (S3) Scenario 3 Utveckling av SHS-Server (Axel) för integration med befintlig integrationslösning (NTJP). För att erhålla en fullt specifikationskomplett lösning som bygger på modern teknik och är skalbar kan en SHS-Server utvecklas och användas tillsammans med NTJP via ett särskilt integrationsinterface. Fördelar Hög prestanda och modern arkitektur, anpassningsbar. Framtidssäker, nya standarder implementeras enkelt. Enkel att integrera mot från NTJP. Kontroll över utveckling ger total uppfyllnad av krav, specifikationskomplett. Tämligen låga utvecklingskostnader, mycket för pengarna. Open Source, ingen leverantörsinlåsning. Nackdelar Ökad komplexitet, förvaltnings- och driftkostnader p.g.a. parallell server-lösning. Kommentar En SHS-Server är vid första anblick det mest kraftfulla alternativet och dessutom det som skalar bäst både gällande funktion och prestanda. Den ytterligare komplexitet som lösningens täta integration med NTJP skapar ska däremot inte förbises (S4) Scenario 4 Inköp av tjänsten i form av Software as a Service (SaaS - molntjänst). SHS-kommunikation finns också att köpa som tjänst på nätet. Flera stora molnleverantörer tillhandahåller SHS i form av SaaS. Fördelar Billigt, kostnad skalar efter användande. Nackdelar Kan finnas säkerhetsproblem med känslig data hos extern aktör. Proprietär lösning, fyller ej krav på öppen och fri källkod. Leverantörsinlåsning, SaaS-leverantörens SHS-adapter måste integreras med NTJP. Prestanda och driftsäkerhet påverkas och är utom systemägarens kontroll. Kommentar SaaS är en väldigt kostnadseffektiv lösning för små aktörer utan udda eller avancerade krav. Den är enkel att sätta upp och fungerar för de vanligaste användarfallen direkt ut ur kartongen. SaaS-lösningar är dock svåra att anpassa för större och mer komplicerade integrationsbehov och skalar inte väl i lösningar med förändringsbehov. Att blanda in ytterligare en aktör i Sid 6/12

8 integrationsscenarion leder också till större säkerhetsrisker, skyddsvärd data kan komma att lagras på platser utom producentens kontroll (S5) Scenario 5 Sammanslagning av S2 och S3 För att kombinera fördelarna med båda dessa scenarior har vi beslutat oss för att förorda ett alternativt scenario, S5, som är en kombination av S2 och S3, se punkt 8 Lösningsförslag. 8. Lösningsförslag Givet analys och utvärdering av scenarier finner vi att den mest hållbara och kostnadseffektiva lösningen är att implementera S3. Utöver detta och ur ett rent funktionellt perspektiv är S2 en bättre lösning. För att kombinera fördelarna med båda dessa scenarior har vi beslutat oss för att förorda ett alternativt scenario, S5, som är en kombination av S2 och S3. Förslaget är att utveckla en serverlösning enligt S3 men där alla ingående komponenter hålls helt generiska och utbytbara. Detta ger oss möjlighet att koppla loss, byta ut och återanvända samtliga ingående komponenter i lösningen. Valda komponenter kan då användas tillsammans med NTJP, enligt S2 eller i vilka kombinationer som helst. Genom detta angreppssätt mitigerar vi de flesta negativa aspekter med S2 och S3 samtidigt som vi skapar en lösning med alla positiva aspekter kombinerat. Utvecklingskostnaden för detta scenario bedöms vara något högre än för S2 eller S3 som båda har ungefär samma kostnad, men lägre än för S1. Förvaltnings och driftskostnad är samma som för S2 alt. S3 beroende på hur lösningen används Konceptuell arkitektur Den arkitekturella beskrivningen nedan utgår ifrån Scenario 5, som är en kombination av Scenario 2 och Scenario 3. Användningsfall och beskrivning (Bild 1) Sid 7/12

9 Vi har valt att förenkla detta avsnitt genom att endast belysa två användningsfall Send och Receive. Bild 1 belyser dessa två fall. BILD 1 KONCEPTUELL ARKITEKTURSKISS ÖVER RIV OCH SHS INTEROPERABILITET. Send från RIV till SHS-aktör Ett meddelande som skapats hos en RIV-aktör inkommer till NTJP som vet att den efterfrågade tjänsten tillhandahålls av en SHS-Aktör. Tjänsteplattformen kompletterar meddelandet med all nödvändig information för att kunna utföra överföring via SHS. (ex vis mottagarens org. nr). Meddelandet skickas till SHS-Servern (Axel) som SHS-paketerar meddelandet (adresserar, signerar, krypterar, etc.) och överför det till mottagaren. Receive från SHS-aktör till RIV Ett meddelande som skapats hos en SHS-Aktör inkommer till Axel. Axel packar upp det inkomna meddelandet och skickar innehållet till RIV-plattformen NTJP. Sid 8/12

10 Komponentdiagram, teknisk beskrivning (Bild 2) Bild 2 beskriver samma flöden som bild 1 men med mer ingående komponentinteraktion. BILD 2 KOMPONENTDIAGRAM, SYSTEMNIVÅ. NTJP OCH AXEL Sid 9/12

11 Detaljerat komponentdiagram (Bild 3) För att kunna genomföra Scenario 5 (S2 + S3) har vi identifierat ett antal komponenter som måste realiseras (Bild 3) i referensbrokern. Dessa komponenter kommer att byggas på ett sådant sätt att de även går att återanvända i andra integrationsplattformar. BILD 3 KOMPONENTDIAGRAM PÅ FUNKTIONSNIVÅ. SHS-ADAPTER MED STÖDFUNKTIONER FRÅN AXEL. Sid 10/12

12 9. Uppdragsbeskrivning Uppdraget är att skapa en lösning enligt scenario 5 och beskriven arkitektur där resultatet är en PoC som inkluderar de användningsfall vilka är beskrivna i lösningsförslaget. PoC levereras till projektet "Mina intyg" från en delad lagringsplats. Utveckling och leverans av PoC sker av ett specifikt projekt i nära samarbete och täta avstämningar med Försäkringskassan. Projektet bemannas i sin helhet av resurser med SHS - kompetens såsom arkitekt, utvecklare och projektledare från en specialistleverantör för att säkerställa att mål uppnås med hög kvalitet. I projektet ingår komponenttester och systemtester i leverantörens domän. Avgränsning Acceptanstester efter leverans ingår inte i detta PoC utvecklingsprojekt. Sid 11/12