Att digitalisera verksamhetsprocesser som spänner över organisationsgränser är högt prioriterat. Behovet av informationsutbyte mellan myndigheter, regioner och kommuner är enormt stor. En utmaning är att det saknas en gemensam infrastruktur som stödjer detta på ett bra sätt. På grund av avsaknad av en gemensam infrastruktur tvingas man till punktinsatser som riskerar öka förvaltningskostnader och skapar ett bromsande tekniskt arv.
Denna blogg tittar närmare på några generiska infrastrukturer som skulle kunna utgöra den generiska infrastrukturen som efterfrågas. Dessa infrastrukturer är förhållandevis komplicerade men bloggen har som ambition att beskriva dessa på en övergripande nivå och vid behov gå ner i detaljer som anses särskiljande och intressanta.
En gemensam säker infrastruktur där många organisationer kan utbyta information av olika dokumenttyper.
En infrastruktur för digitalisering skulle kunna beskrivas som ett “säkert rör” som används för utbyte av information mellan organisationer. Varje organisation ansluter till stamnätet och kan därmed skicka och ta emot meddelanden andra ansluta organistioner.
Organisationer identifieras på ett garanterat säkert sätt.
När överföring mellan organisationer kan garanteras kan andra stödfunktioner som t.ex. en adressbok stödja identifiering av funktioner och personer.
Överföringen kvitteras av avsändare och mottagare.
Information överförs på ett sätt så att endast avsändare och mottagare kan ta del av informationen.
Infrastrukturen lägger sig inte i vilken information som skickas utan ansvarar endast för att informationen överförs på ett garanterat säkert sätt.
Infrastrukturer för digitalisering
Informationsplats för Spridnings- och HämtningsSystem - SHS
SHS är en stor informationsväxel och ett koncept för att via Internet säkert och pålitligt utbyta information mellan offentliga organisationer. Dokument (business documents) transporteras som attachments.
Bilaterala avtal tecknas mellan parter som utbyter information.
Rättsväsendets InformationsFörsörjning - RIF
Arkitektur och infrastruktur för att stödja myndigheters gemensam ärendehantering och informationsutbyte under förundersökningen (FU), stöd för hantering och dokumentation av straffprocessuella tvångsmedel och elektronisk dom och uppgift om laga kraft (e-dom).
Strukturerad information överförs.
SHS infrastrukturen används.
Bilaterala avtal tecknas mellan parter som utbyter information.
Nationella tjänsteplattformen - NTjP
Plattform som ursprungligen togs fram för att stödja sammanhållen journal i enlighet med Patientdatalagen (PDL). Plattformen har dock utvecklats för att stödja betydligt fler områden inom häls- och sjukvården.
Strukturerad information (tjänstedomäner, tjänstekontrakt).
En central hub används för kommunikation mellan konsument och producent.
Bilaterala avtal tecknas mellan parter som utbyter information.
PEPPOL
Infrastruktur för e-handel inom EU. PEPPOL står för Pan-European Public Procurement On-Line. Infrastrukturen är baserat på CEF eDelivery (ebMS3 and AS4 OASIS specifikation)
Varje organisation tecknar ett sk operatörsavtal.
Säker digital kommunikation (SDK)
Säker digital kommunikation(SDK) är en infrastruktur för ostrukturerat informationsutbyte för information av betydande konsekvensnivå(enligt klassifikationsmodellen av MSB) Exempel på information av betydande konsekvensnivå är framtaget av SKL’s informationsklassificeringsverktyg SKL KLASSA:
Patientuppgifter
Känsliga personuppgifter
Uppgifter som omfattas av sekretess
Federationsanslutning
Informationsplats för Spridnings- och HämtningsSystem - SHS
SHS är ett kommunikations- och överföringsprotokoll som syftar till ökad säkerhet i kommunikationen över internet.
skicka elektroniska dokument (asynkront)
hämta information från andra myndigheters system (synkront)
prenumerera på information från andra myndigheter
ställa frågor till en annan myndighet(asynkron)
Informationsmängder definieras av parter som använder infrastrukturen och benämns som produkter (product type) t.ex. ett xml schema. Ett exempel på detta är RIF.
Typa av infrastruktur
Öppet protokoll där varje ansluten nod ansluter direkt (punkt till punkt). Den centrala komponenten för att möjliggöra informationsutbyte är SHS Directory.
SHS Directory innehåller nödvändig metadata för att möjliggöra informationsutbyte mellan aktörer inom SHS-nätverket t.ex. informationsmängd(t.ex. xml schema), teknisk adress till ändpunkt (URL), avtal som stödjer överföring mellan parter etc.
En utpekad Certificate authority (CA, aktör som utfärdar digitala certifikat) används för certifikathantering.
Det finns ett regelverk för hur informationsmängder tekniskt skall definieras men ingen central organisation som ansvarar för dessa.
Överföring mellan organisationer förutsätter ett tekniskt avtal (agreement). Det tekniska avtalet definierar vilken typ av information(product) som kan överföras mellan parterna.
Säkerhetslösning
SHS transmission security (End-to-end signering och kryptering)
Transport security (Transportkryptering (SSL enligt dokumentation, sannolikt TLS)
Kammarkollegiet agerar CA och ställer ut certifikat till anslutna organisationer.
Övergripande arkitektur
Överföring mellan organisationer förutsätter ett tekniskt avtal (agreement). Det tekniska avtalet definierar vilken typ av information(product) som kan överföras mellan parterna.
SHS är en etablerad infrastruktur med 184 ansluta* organisationer. Värt att notera är att endast 3 region (fd landsting) är ansluten till SHS.Infrastrukturen. Att regioner inte är representerade skulle kunna förklaras med att Inera AB har en anslutning och agerar “brygga”. T.ex. så är alla regioner anslutna till via Ineras SHS brygga för att leverera sjukintyg till Försäkringskassan.
SHS är en Svenska paketering med ett ekosystem av leverantörer som erbjuder SHS tjänster.
Mer informartion: https://www.forsakringskassan.se/myndigheter/e-tjanster/shs
*Siffror baserade på registerutdraget “Anslutna organisationer” från försäkringskassan.
Rättsväsendets Informationsförsörjning - RIF
RIF är framtaget för att stödja följande områden:
Gemensam ärendehantering och informationsutbyte under förundersökningen (FU).
Stöd för hantering och dokumentation av straffprocessuella tvångsmedel.
Elektronisk dom och uppgift om laga kraft (e-dom).
Användare av RIF är aktörer som Rikspolisstyrelsen, Åklagarmyndigheten, Domstolsverket, Kriminalvården, Tullverket, Skatteverket, Brottsförebyggande rådet, Brottsoffermyndigheten, Rättsmedicinalverket, Ekobrottsmyndigheten, Kustbevakningen och kommuner.
RIF är ingen självständig infrastruktur utan är ett bra exempel på hur SHS infrastrukturen användas.
Nationella tjänsteplattformen - NTjP
Nationella tjänsteplattformen är en teknisk plattform som förenklar, säkrar och effektiviserar informationsutbytet mellan olika it-system inom vård och omsorg.
Informationsutbyte sker i huvudsak inom ramen för sammanhållen journal i enlighet med Patientdatalagen (PDL). Information som utbyts är strukturerad (tjänstedomäner, tjänstekontrakt).
Typa av infrastruktur
Öppet protokoll som implementeras i en sluten infrastruktur. En central integrationspunkt används för att ansluta till respektive ansluten organisation.
Infrastrukturens TAK(tjänsteadresserings katalog) används för att adressera meddelanden vid informationsutbyte.
Säkerhetslösning
Transportsäkerhet tillämpas.
Transportkryptering (TLS)
Certifikat utställda av SITHS CA krävs.
Bilden illustrerar hur SKL/Inera arkitekturen använder en central hubb för informationsutbyte. Tjänstekontrakt är RIV-TA arkitekturens “dokumenttyper”. RTjP är anslutande parts integrationsmotor (Regional tjänsteplattform)
Sammanfattning NTjP
Tjänsteplattformen är en infrastruktur för strukturerat informationsutbyte inom ramen för sammanhållen journal. Infrastrukturen är dedikerad för hälso- och sjukvårdssektorn.
Allt informationsutbyte sker genom en central punkt vilket förutsätter omfattande administration. Bilaterala avtal upprättas mellan konsument och producent.
Det finns 571 anslutna system som konsumerar information från 246 anslutna producerande system.
Vid informationsutbyte kan 316 definierade informationsmängder (tjänstekontrakt/integrationsprofiler) användas.
Mer information:
eDelivery
eDelivery är en arkitektur för kommunikation mellan distribuerade noder(organisationer) i ett säkert definierat nätverk. eDelivery har berörts i en tidigare blogg här:
eDelivery är framtaget för att stödja “cross-border” lösningar inom EU. Utöver de eDelivery initiativ som beskrivs nedan finns många andra lösningar baserade på eDelivery.
Bilden illustrerar andra lösningar baserade på eDelivery. Läs mer här.
Typ av infrastruktur
Öppet protokoll som implementeras i en sluten infrastruktur. Alla noder kommunicera direkt med andra noder (peer-to-peer). eDelivery är en implementation av OASIS ebMS3, AS4 OASIS specifikation.
Det som gör eDelivery intressant är hur nya dokumenttyper (som är av valfritt format t.ex. xml, JSON, EDIFACT etc) definieras och överförs. Olika dokumenttyper kan överföras utan att någon förändring behöver göras i infrastrukturen (accesspunkterna).
Varje ansluten organisation registrerar vilka dokumenttyper som kan tas emot. Registreringen görs i SMP komponenten (via klient eller API).
Accesspunkterna brys sig inom om vad som skickas så länge dokumenttypen är registrerad.
Denna typ av arkitektur skapar en flexibel “transport” infrastruktur som kan överföra olika typer av information utan att infrastrukturen behöver förändras.
Bilden illustrerar komponenter inom eDelivery arkitekturen. En ansluten accesspunkt kontrolleras via SMP att mottagaren finns och stödjer dokumenttypen skall skickas.
Central komponenter:
Service Metadata Locator (SML) service (Uppdaterar DNS).
Service Metadata Publisher (SMP). Vilka dokumenttyper respektive ansluten organisation stödjer samt vilken teknisk adress (URL). Ett nätverk kan välja att ha en eller flera SMP komponenter.
Accesspunkt. Standardiserad komponent som stödjer protokollet eDelivery (ebMS3 och AS4). Det finns paketerade “out-of-box” accesspunkt både som öppenkällkod och licensierade produkter (installera, konfigurera och kör). Ett asynkront mönster tillämpas.
Dokumenttyper. Dokumenttyper är den information som överförs mellan noder i eDelivery nätverket (varje organisation registrerar vilka dokumenttyper som kan hanteras i SMP). Dokumenttyper (t.ex. XML schema, JSON etc) definieras och förvaltas centralt eller lokalt.
Backend (ingår ej i eDelivery) Internt gränssnitt för att hämta/lämna information i nätverket. T.ex. en integrationsmotor som ansluter ett verksamhetssystem
openPEPPOL (eDelivery)
Pan-European Public Procurement On-Line (PEPPOL) är en infrastruktur framtagen för att stödja e-handel (inköp, order och fakturering) inom EU. openPEPPOL är baserad på eDelivery. PEPPOL använder idag AS2 protokollet men är på väg mot AS4.
openPEPPOL har definierat ett antal områden inom e-handel. Varje område har definierat dokumenttyper(t.ex. XML schema) och processbeskrivningar för dess hantering så som validering och kvittering.
Från och med april 2019 är det e-fakturor(BIS Billing 3) som gäller för alla som skickar fakturor till offentliga sektorn. Den nya lagen beslutades i riksdagen i juni 2018.
Den 1 november 2018 måste alla statliga myndigheter vara anslutna till PEPPOL:s infrastruktur för att skicka och ta emot meddelanden.
Den 1 april 2019 måste alla statliga myndigheter ha kapacitet för att kunna hantera PEPPOL BIS Billing 3.
Som ett resultat av detta lagkrav har infrastrukturen PEPPOL etablerats för alla offentliga verksamheter i Sverige.
Implementation av eDelivery:
Service Metadata Publisher (SMP). I PEPPOL kan det finnas flera SMP.
Accesspunkt. Egen infrastruktur eller via tjänsteleverantör
Dokumenttyper (ingår ej i eDelivery). Det finns en mängd (33st) olika dokumenttyper definierad för att stödja e-handel, se http://www.sfti.se/standarder/rekommenderadestandarder
Backend. Ett backen kan avropas via Kammarkollegiet “E-handeltjänst”.
Säkerhetslösning
Transportsäkerhet tillämpas. Transportkryptering (TLS)
Certifikat utställda av PEPPOL CA krävs.
Till skillnad från Säker Digital Kommunikation (SDK) så finns inget stöd för att att hantera känslig sekretessbelagda uppgifter så som person eller patientuppgifter.
Leverantörsmarknad
PEPPOL är en etablerad infrastruktur som kan avropas via Kammarkollegiet “E-handeltjänst” (Se https://www.avropa.se/ramavtal/ramavtalsomraden/it-och-telekom/administrativa-system/e-handelstjanst/).
Upphandlingen är en paketering där PEPPOL tillsammans med komponenter som behövs för att fullfölja e-handel. Exempel på komponenter som ingår:
Produktkatalog
Beställningsfunktion
Leverans och faktura funktion
Leverantörsportal
Pris- och produkthantering
Operatörstjänst (eDelivery komponenter som SMP och accesspunkt)
Upphandlingsunderlaget är omfattande och ställer en del krav som påverka hur infrastrukturen kan användas på ett generiskt sätt. Några exempel:
Transportprotokollet SFTP skall användas (B-5.6.12, I-2.1.3)
Detta krav torde gäller “backend” integration. Det är inget modernt protokoll som sällan tillåts i brandväggar. Det finns betydligt modernare protokoll som SOAP eller REST som borde användas. Kravet gör det väldigt svårt att t.ex. följa status på en överföring.
SFTP är ett filöverföringsprotokoll som kräver nyckelhantering för att överföring skall vara möjlig.
SFTI specifikationerna som skall stödjas (B-2.4.1, B-3.6.4)
Det är br att det finns central förvaltning av dokumenttyper. Samtidigt begränsas infrastrukturen till att endast användas för dessa informationsmängder (33st).
Förvaltningsgemensamma specifikationer (FGS) skall stödjas (I-2.1.4)
Det finns idag 3 st FGS’er (FGS Personal, FGS Ärendehantering, FGS Arkivredovisning).
Ingen av dessa har någon koppling till SFTI specifikationerna.
Ingen av dessa verkar har någon direkt koppling till e-handel.
Säker digital kommunikation (eDelivery)
Säker digital kommunikation(SDK) är en infrastruktur framtagen för ostrukturerat informationsutbyte(fritext, bifogade filer). SDK kan hantera information av betydande konsekvensnivå(enligt klassifikationsmodellen av MSB) Exempel på information av betydande konsekvensnivå är framtaget av SKL’s informationsklassificeringsverktyg SKL KLASSA:
Patientuppgifter
Känsliga personuppgifter
Uppgifter som omfattas av sekretess
SDK är en standardiserad infrastruktur för kommunikation mellan offentliga aktörer och privata utförare av offentlig finansierad verksamhet. Alla anslutna organisationer kan skicka meddelanden alla anslutnas organisationer och dess funktioner.
Implementation av eDelivery:
Service Metadata Publisher (SMP). I SDK finns endast en SMP (tillhandahålls av DIGG).
Accesspunkt. Egen infrastruktur eller via tjänsteleverantör
Dokumenttyper. SDK har definierat två dokumenttyper
-Meddelande (e-post liknande meddelande för text och bifogade filer)
-Kvittens (kvittering av meddelanden)
Backend. Denna komponent är en integrationskomponent för det system som hämtar och lämnar meddelanden till accesspunkten. Hur respektive organisation ansluter till verksamhetssystem via “backend” förväntas lösas av organisationen och dess leverantörer.
Utöver eDelivery “standard” har SDK tagit fram en Adressbok. Adressboken innehåller alla anslutna organisationer samt dess adresserbara funktioner t.ex. Socialtjänsten orosanmälan. Respektive ansluten organisation administrerar information i adressboken.
Säkerhetslösning
Transportsäkerhet tillämpas. Transportkryptering (TLS)
Certifikat utställda av olika CA kan användas.
Leverantörsmarknad
Det finns idag ingen etablerad leverantörsmarknad. Det finns dock leverantörer som börjar erbjuda lösningar för att ansluta till SDK.
Har vi en generisk infrastruktur?
Till att börja med behöver Sverige ett ledarskap som ansvarar för denna typ av infrastruktur. Sedan september 2018 har vi en ny myndighet, DIGG, som kommer ansvara för detta. Stabilitet och en tydlig riktning är en förutsättning för att leverantörsmarknaden skall komma igång.
I skrivande stund har vi bara en etablerad generisk infrastruktur. Det är Informationsplats för Spridnings- och HämtningsSystem (SHS). SHS lever upp till de krav man kan ställa på en generisk infrastruktur. SHS har dock ett rykte om sig att vara kostsam och ha få paketerade out-of-the-box produkter. Varje part som skall kommunicera behöver också teckna bilaterala avtal.
En kandidat är SKL/Inera Nationella tjänsteplattformen(NTjP) arkitekturen är tekniskt generisk men är inriktad på vård- och omsorgsområdet. SKL/Inera arkitekturen har ett etablerat regelverk (RIV-TA) för framtagande av tjänstekontrakt (tjänstekontrakt är jämförbara med dokumenttyper).
En annan kandidat skulle kunna vara en infrastruktur baserad på eDelivery, standarden är dock inte etablerad som en generisk infrastruktur i Sverige. En fördel med eDelivery är det är en etablerad EU standard och paketerade lösningar finns tillgängliga. En begränsning är dock att eDelivery endast stödjer asynkrona integrationsmönster.
Om vi tittar på två eDelivery initiativ som finns så skulle PEPPOL eller SDK kunna utökas för att bli en mer generisk infrastruktur.
PEPPOL
Är ett europeiskt nätverk för elektroniska inköp. Framtagna ramavtal begränsar även möjligheten att generalisera PEPPOL för ett bredare användningsområde.
Har ett koncept för framtagande och etablering av nya dokumenttyper men är begränsat till området elektroniska inköp.
Saknar ett koncept för hantering av sekretessbelagda känsliga uppgifter.
SDK
SDK är framtagen för att stödja offentlig verksamhet eller aktörer med offentligt uppdrag.
SDK adresserar behovet av sekretessbelagd känslig ostrukturerad information (text och PDF).
SDK är idag begränsad till att stödja ostrukturerad information (dokumenttyper).
SDK har baserat dokumenttyper på RIV-TA.
Vad behöver vi göra nu?
Vi har goda kandidater för en generisk infrastruktur. Man kan vidareutveckla befintliga lösningar eller ta fram ytterligaren en ny? Aktörer som DIGG bör vägleda och samordna offentliga aktörer om vi skall få fram en gemensam infrastruktur.
Viktiga egenskaper:
Infrastruktur bör baseras på öppna standarder. Leverantörsmarknaden måste kunna ta fram och erbjuda produkter och tjänster. Det måste vara enkelt för organisationer att införskaffa produkter för att ansluta till infrastrukturen.
En infrastruktur som stödjer olika nivåer av sekretess. Detta kan lösas genom t.ex. meddelandekryptering eller separering av infrastruktur.
Möjliggöra för alla organisationer som deltar i informationsflöden att ansluta. Idag utestängs många aktörer baserat på organisationsform.
Infrastrukturen skall kunna överföra olika typer av information. Centralt och lokalt förvaltade dokumenttyper. Dokumenttyper skall stödja olika tekniska format baserat på behov.
Sammantaget kan man säga att det inte är ett “tekniskt” problem att etablera en gemensam infrastruktur, det handlar mer om ledning/styrning, informationssäkerhet och definition av regelverk för nyttjande.