Målarkitektur för samverkan enligt T2 inom svensk välfärd
| Målarkitektur för samverkan enligt T2 inom svensk välfärd
Revision PA3 ARK_0076 2025-02-03 |
Revisionshistorik | |||
Utgåva | Revision Datum | Beskrivning | Ändringarna gjorda av |
A | 2025-02-03 | Revision A fastställd | Anders Malmros |
1. Inledning
T2 beskriver fyra olika aktörsmönster för samverkan: en-till-en, en-till-många, många-till-en, samt många-till-många. Dessa mönster har olika komplexitet i hur de behöver realiseras skalbart och man kan för de mindre komplexa mönstren och även i mindre sammanhang med få aktörer ta genvägar i sina realiseringar av samverkan. Detta innebär att man inte behöver vara beroende av stödtjänsters existens för alla realiseringar.
T2-arkitekturerna kompletterar T-boken med en ökad frihet i hur man integrerar system med direkta anrop. T-bokens mönster och nomenklatur kommer kunna fortsätta användas och RIV Tekniska Anvisningar kommer förvaltas på ett sådant sätt att eventuella praktiska konflikter i realisering av integrationer ska lösas ut. Till exempel har RIV-TA Översikt och RIV-TA Tjänsteplattform redan uppdaterats för att förtydliga att integrationer inte behöver ske via Nationell tjänsteplattform.
Med “T2” avses i denna målarkitektur de två referensarkitekturerna för interoperabilitet:
1.1 Syfte
Målarkitekturen syftar till att:
Beskriva hur samverkan mellan aktörer inom svensk välfärd ska stödjas genom att detaljera begreppen informationsfederation och interoperabilitetsspecifikation och hur de kan realiseras.
Beskriva hur samverkan fungerar med stöd av teknisk arkitektur och infrastruktur.
Beskriva tänkbara mekanismer för att lösa ut behov inom området tillit och säkerhet idag och i framtiden relaterat till andra nationella och internationella initiativ inom området.
Ge underlag för strategisk planering av realisering av stödtjänster och etablering av samverkan.
1.2 Målgrupp
IT-strateger och IT-arkitekter inom svensk e-hälsa som ska ta fram interoperabla lösningar baserade på T2-arkitekturerna eller stödtjänster för sådana lösningar.
1.3 Avgränsningar
De förflyttningar som analyseras avser främst att kunna bidra till kontexten nationell samverkan över organisationsgränser. Samverkan inom en organisation eller mellan ett begränsat antal aktörer kan ofta realiseras med mindre komplexitet vilket kan ge andra behov och prioritering för realiseringens utformning.
Exakt utformning av interaktioner mellan olika aktörer och komponenter detaljeras inte i målarkitekturen.
2. Samverkan mellan aktörer inom svensk välfärd
För att etablera interoperabel samverkan mellan välfärdsaktörer behövs på konceptuell nivå följande:
Specifikation av den tekniska integrationen, presenterad på ett strukturerat sätt
Specifikationer för semantiken hos den information som delas
Avtal som möjliggör informationsutbyte mellan samverkande parter
Överenskommen tolkning på den legala grunden för samverkan
Överenskommen hantering av tillit, säkerhet och åtkomst
T2 formerar dessa förutsättningsskapande delar av samverkan inom koncepten informationsfederation och interoperabilitetsspecifikation.
2.1 Informationsfederation
Informationsfederation: Ett antal aktörer som i avtalad samverkan delar information i ett gemensamt syfte med hjälp av gemensamt definierade regler för informationsutbytet avseende teknik, semantik, legala tolkningar och organisatoriska regler och policyer.
T2 - Välfärden introducerar begreppet informationsfederation enligt ovan. T2 - vård och omsorg detaljerar beskrivningen som paketering av samverkan inom ett avgränsat kontext och med ett specifikt syfte. Inom en federation för informationsutbyte hanteras affärsmässiga avtal, personuppgiftbiträdesavtal, gemensamma tolkningar om legal grund för samverkan och respektive parts ansvar. Man hanterar också tillitsmodeller och kvalitetssäkringskrav på medlemmar i informationsfederationen. Man definierar processer för anslutning till informationsfederationen, samt hur man säkerställer federationsmedlemmars efterlevnad av överenskommelser.
Det är lämpligt att utse en federationsoperatör för hanteringen av informationsfederationen, samt att ha ett ramverk för styrning och ledning
En informationsfederation anger vilka interoperabilitetsspecifikationer som beskriver den specifika samverkan som sker inom federationen.
2.2 Interoperabilitetsspecifikation
Interoperabilitetsspecifikation: Ett samlingsbegrepp för överenskommelser som beskriver förutsättningar och krav för digitala tjänster. Den kan hänvisa till befintliga standarder eller specifikationer.
T2 - välfärden beskriver begreppet interoperabilitetsspecifikation enligt ovan. För att kunna säkerställa interoperabel digital samverkan krävs det att man för varje specifik samverkan beskrivs ur de fyra interoperabilitetsperspektiven juridik, organisation, semantik och teknik. Dessa beskrivningar publiceras i den digitala tjänstens interoperabilitetsspecifikation.
Varje informationsfederation ska i sin interoperabilitetsspecifikation och federationsavtal detaljera överenskommen tolkning av de lagar och policyer som reglerar samverkan mellan informationsfederationens medlemmar.
3. Tillit och säkerhet
Tillit behöver enligt T2 - välfärden etableras på två huvudsakliga nivåer.
Tillit behöver etableras mellan samverkande organisationer. Är det tryggt att dela information med en viss aktör? Litar vi på att informationen hanteras lagenligt och endast i avsett syfte. Finns och följs processer som säkerställer säker informationshantering?
Tillit behöver också etableras till samverkande parters tekniska förmåga att realisera tillitsskapande skyddsmekanismer korrekt vid teknisk överföring och behandling av information.
Att uppnå tillit inom kontexten interoperabel samverkan över organisationsgränser handlar främst om att samverkande parter behöver ha tillit till varandras organisatoriska och tekniska förmågor inom informationssäkerhetsområdet. Därutöver kräver ofta varje samverkanstillämpning specifik kvalitetssäkring för att säkerställa interoperabiliteten och undvika incidenter. Tillit regleras ofta enligt följande:
Tillit kan bygga på lag, avtal och/eller bevisade tillitsskapande förmågor.
Tillitsramverk stipulerar ofta specifika organisatoriska förmågor och arbetssätt.
En parts följsamhet mot dessa förmågor kan säkerställas med olika krav om försäkran
utan uppföljning, det vill säga baserat på grundmurad tillit.
egen intern revision
revision av extern part
revision av utpekad ackrediterad part
Notera att grad av försäkran som krävs kan ofta skilja sig mellan typ av aktör eller dess roll i samverkan. Till exempel kan i vissa sammanhang en statlig myndighet åtnjuta grundmurad tillit medan ett privat aktör för samma kontext ha revisionskrav på sig.
Det pågår nationell standardisering inom myndighetsuppdraget Ena - Sveriges digitala infrastruktur som kan vara av värde att bevaka.
3.1 Tillit mellan organisationer
I stort sett alla avtal och tillitsramverk inom interoperabilitetstillämpningar idag tar avstamp i, eller refererar till, ISO 27000-serien, vilket är en samling internationella standarder för informationssäkerhetsarbete. Det vore önskvärt att alla välfärdens aktörer ska certifiera sig mot dessa standarder, men då detta skulle innebära en stor samhällsförflyttning som kan antas ta många år och medföra stora kostnader nyttjas ofta anpassade krav reglerade av avtal istället.
I de samverkanskontext där Inera agerar federationsoperatör (eller tjänsteleverantör som det benämns i Ineras nuvarande modell) så grundas tillit mellan samverkande parter på de villkor som står att läsa i Ineras kundavtal.
3.2 Tillit till informationsöverföring
Tillit till informationsöverföringen handlar om hur samverkande parter agerar i den digitala infrastrukturen. Att man hanterar identiteter, åtkomstbeslut, informationsbehörighetsbeslut och dataskydd i samband med informationsöverföring enligt ingångna överenskommelser.
För en effektiv digitalisering på samhällsnivå och förbättrad interoperabilitet i de digitaliseringsinitiativ som genomförs rekommenderas att följa internationellt och nationellt etablerade standarder och använda dessa utan anpassningar.
OM man ser behov av att anpassa de standarder man förhåller sig till bör man återföra de icke tillfredsställda behoven till förvaltarna av standarden och man bör även engagera sig aktivt i arbetet eller i referensgrupper.
3.2.1 Digitala identiteter
Systemanvändare
Två hypoteser:
Använd SITHS Funktionscertifikat då tillit för dessa redan finns brett förankrat inom välfärden. Tillit skapas praktiskt genom SITHS existerande CA-struktur.
Använd ny struktur med certificate pinning av egenutgivna certifikat i en metadatatjänst enligt Ineras referensarkitektur för identitet och åtkomst.
Fysisk användare
Privatpersoner identifieras med identiteter följsam mot Elegitimation | Elegitimation. Idag omfattas BankID, Freja+, AB Svenska Pass, eller EU Foreign ID (utländsk e-legitimation som omfattas av eIDAS-förordningen)
Individer kan identifiera sig i sin yrkesutövning med en e-tjänstelegitimation - hit hör till exempel SITHS, EFOS och Freja Organisation eID. Inera bör stödja alla av Digg godkända tjänstelegitimationer.
3.2.2 Behörighetsgrundande information och åtkomstbeslut
En individs identitet kan kompletteras med behörighetsgrundande information antingen vid autentiseringen eller som del av åtkomstbeslutet. Exempel på behörighetsgrundande information är:
ställföreträdarroller (till exempel vårdnadshavare eller god man)
fullmakter
medarbetaruppdrag
Inom svensk vård och omsorg hanteras medarbetares behörighetsgrundande information enligt Behörighetsmodell för vård och omsorg och identitetsintyg kompletteras med behörighetsgrundande information baserat på medarbetarens val av uppdrag att verka i för tillfället.
Behörighetsgrundande attribut ska som princip informationsförsörjas av medarbetares arbetsgivare. Inom vård och omsorg idag sker detta som regel i samband med autentisering, men det kan i framtiden komma att finnas fler tillitsfulla sätt att tillföra attribut.
En fysisk användares eller en systemanvändares behörigheter i en digital tjänst avgörs genom att tjänsteproducenten i antingen en åtkomstintygstjänst eller som del av tjänsten själv evaluerar den digitala tjänstens åtkomstpolicy och ger användaren åtkomst till den information och funktionalitet hen har behörighet till.
Åtkomstpolicyer är främst att se som regelverk för att säkerställa efterlevnad av lagar, styrande lagtolkningar och de ingångna överenskommelser som finns för samverkan inom en specifik informationsfederation.
3.2.3 Dataskydd
T2-arkitekturerna rekommenderar direkta anrop mellan samverkande parter. I T2 - välfärden presenteras följande schematiska bild med exempel på skyddsåtgärder som, utöver det som beskrivs i säkerhetsanvisningar i RIV-TA, kan vara lämpliga att komplettera med för att skydda en digital tjänst.
Då hantering av standarder för identitets- och åtkomsthantering tagits upp högre upp fokuserar vi här på säkerhetsmekanismerna på nätverks- och applikationsnivå med syfte att stärka cybersäkerhetsnivån. Ansvar för etablering och utformning av dessa ligger främst på tjänsteproducenten.
Även om ansvar för utformning av dataskydd faller på varje tjänsteproducent följer här några vägledande principer som syftar till att ge goda förutsättningar för effektiv etablering av samverkan och adekvat säkerhet:
Begränsa inte åtkomst baserat på anropande parts IP-adress!
Basera åtkomst på tillitsfull hantering av identiteter och behörighetsgrundande attribut förmedlade på applikationsnivå.
Publicera APIer och webbtjänster på egna nätsegment (DMZ)
4. Teknisk arkitektur och infrastruktur
T2 - välfärden definierar ett antal aktörsmönster, informationsutbytesmönster och samverkansmönster som kan behöva stödjas för att möta verksamheters behov av samverkan.
För dessa mönster som presenteras av T2 - välfärden detaljerar T2 - vård och omsorg att en del förmågor bör realiseras centralt, medan andra bör realiseras lokalt hos de samverkande parterna. En teknisk arkitektur för samverkan omfattar således tekniska förmågor som realiseras av olika aktörer.
Aktörsroller som ingår i teknisk etablering av samverkan
4.1 Förberedande interaktioner
Innan parter kan etablera samverkan med informationsutbyte behöver det genomföras förberedande interaktion - de flesta kan och bör automatiseras, men en del kan behöva vara delvis manuella.
Registrering av API i tjänstekatalog
Registrering av avtalsparter
Distribution av stödtjänsters data för lokal användning
Registrering av IAM-relaterad data i metadatakällor
4.2 Tjänsteanrop
Aktörer, komponenter och interaktioner i samband med direkt anrop från API-klient till API
Huvuddragen i interaktionen ovan är:
Tjänstekonsumerande system söker API ur sin lokala tjänstekatalog
Tjänstekonsumerande system bekräftar att hittat tjänsteproducent är medlem i informationsfederationen
Tjänstekonsumerande system begär åtkomst till API från tjänsteproducentens åtkomstintygstjänst
Verifiering av tillit till tjänstekonsumerande systems identitet sker mot central källa för IAM-metadata.
Åtkomstbeslutet grundar sig delvis på tjänstekonsumenten är medlem i en informationsfederation där tjänsteproducentens API ingår.
Tjänstekonsumerande tjänst anropar tjänsteproducerande systems API
4.3 Anrop via förvaltningsgemensam tjänst
Med förvaltningsgemensam tjänst menas här en centralt tillhandahållen tjänst som tillför funktionalitet som underlättar informationsutbyte mellan tjänstekonsumenter och tjänsteproducenter. Detta är ofta i form av en sammansatt bastjänst som inhämtar information från flera källor och sammanställer ett aggregerat resultat eller resultat av en databehandling.
Den sammansatta bastjänsten tillhandahålls förvaltningsgemensamt inom federationen och detta är det sätt som vi visar det i bilden nedan.
Aktörer, komponenter och interaktioner i samband med anrop från API-klient, via en förvaltningsgemensam tjänst, till bakomliggande APIer
Huvuddragen i interaktionen ovan är:
Tjänstekonsumerande system söker fram den förvaltningsgemensamma tjänstens API ur den lokala tjänstekatalogen
Den förvaltningsgemensamma tjänstens medlemskap i informationsfederationen verifieras emot tjänstekonsumentens lokala federationskatalog.
Tjänstekonsumerande system begär åtkomst till den förvaltningsgemensamma tjänsten från den förvaltningsgemensamma tjänstens åtkomstintygstjänst
Verifiering av tillit till tjänstekonsumerande systems identitet sker mot central metadata.
Åtkomstbeslutet grundar sig på att tjänstekonsumenten är medlem i en informationsfederation där den aggregerande tjänsten ingår
Tjänstekonsumentens system anropar den förvaltningsgemensamma tjänsten
Den förvaltningsgemensamma tjänsten gör ett urval av vilka tjänsteproducenter som ska bidra till att utföra tjänsten. Detta inkluderar även att verifiera tjänsteproducenternas medlemskap i den aktuella informationsfederationen emot federationsoperatörens lokala federationsmedlemskatalog.
För varje tjänsteproducent söker den förvaltningsgemensamma tjänsten fram API från tjänstekatalogen, begär åtkomst till APIet, och anropar det.
När anrop till bakomliggande system har behandlats och svaret sammanställts returneras detta till tjänstekonsumenten
4.4 Aktörer och komponenter
Nedan listas vilka komponenter som behöver realiseras av olika aktörer. Om komponenter realiseras i egen regi eller via en leverantör är upp till respektive aktör. Målarkitekturen ställer inga krav på hur olika aktörer realiserar lokala stödtjänster, men de centrala stödtjänster som tas fram förvaltningsgemensamt bör utformas för att underlätta informationsförsörjning av lokala stödtjänster.Hur lokala stödtjänster utformas för den lokala användningen är en lokal fråga.
Komponent | Beskrivning |
---|---|
Tjänstekonsumerande system | Agerar API-klient i en interaktion. |
Tjänsteproducerande system | Exponerar API för samverkan. |
Förvaltningsgemensam tjänst | Tjänst som aktörer tar fram och förvaltar gemensamt, ofta via gemensamt utsedd förvaltare. |
Sammansatt bastjänst | Tjänst som exponerar API för behandling och sammanställning av information från flera tjänsteproducenter. |
Åtkomstintygstjänst | Tjänst som inhämtar behörighetsgrundande information, utvärderar denna mot åtkomstpolicyn för APIet och ger ut åtkomstintyg innehållande beviljade behörigheter. |
Tjänstekatalog | Håller information om vilka organisationer som erbjuder vilka API enligt vilka interoperabilitetsspecifikationer. Erbjuder mekanism för administration av data och distribution till lokala tjänstekataloger |
Lokal tjänstekatalog | Lokalt synkroniserad instans av den centrala tjänstekatalogen. |
Federationsmedlemskatalog | Håller information om vilka organisationer som är medlem i vilka informationsfederationer, samt vilka digitala identiteter som används i interaktionerna. Erbjuder mekanism för administration av data och distribution till lokala federationsmedlemskataloger |
Lokal federationsmedlemskatalog | Lokalt instans av den centrala federationsmedlemskatalogen. |
Metadata | Information om systemaktörers IAM-relaterade attribut |
5. Underlag för strategisk planering
T2-arkitekturerna är framtagna utifrån grundtanken att arkitekturen ska stödja realisering av samverkan utan att kräva stora investeringar i infrastruktur eller stödtjänster innan det finns reella behov som motiverar investeringarna. Motiven som man tänkt sig är att administration i förvaltningsgemensamma system blir mer kostnadseffektivt när antalet aktörer eller antalet samverkanskontext har vuxit så att det motiverar investeringen. Att på detta sätt skjuta på beslut kring design och realisering möjliggör att man bygger bättre kunskap kring de faktiska behoven som behöver mötas.
Denna erfarenhet kan också snabbare delas i de myndighetsdrivna initiativ inom interoperabelt informationsutbyte och IAM som pågår parallellt, samt erfarenheter från myndighetsdrivna initiativen kan återföras till T2-realiseringen.
Principen om att senarelägga beslut om förvaltningsgemensamma investeringar och designbeslut kring lösningars utformning motverkas dock av hur förvaltningsgemensamma initiativ prioriteras och budgeteras idag. Det kan kräva en framförhållning på upp till två år för att realisera identifierade behov. Detta kan motivera att man tar ett strategiskt beslut om att påbörja realisering av förvaltningsgemensam infrastruktur innan det finns faktiska prioriterade initiativ med behov.
5.1 Standarddriven realisering
Inom olika områden pågår det standardiseringsarbeten nationellt eller internationellt vilket kan påverka hur man väljer att utforma olika komponenter.
Till exempel bör stödtjänsters utformning redan från start verifieras att det stödjer samverkan baserad på FHIR.
Ytterligare exempel kan vara att realisera IAM-mönster baserat på OAuth2 och OpenID Federation då dessa standarder jobbas aktivt med i Myndighetssverige och inom EU.
5.1.1 Klientregistrering baserad på OpenID Federation
Den Svenska profileringen av OpenID Federation föreslår verifiering av IAM-metadata via så kallade resolver-tjänster. Då denna mekanism kommer innebära att klienter ej behöver registrerats i förväg hos åtkomstintygstjänster bör den temporära lösningen för klientregistrering bygga på data inhämtat från resolver-tjänsten. På detta sätt kan man bygga kunskap kring den kommande standarden i väntan på att den blir fastställd nationellt.
En schematiskt design för klientregistrering med hänsyn tagen till OpenID Federation
5.2 Behovsdriven realisering
Nedan listas vad som krävs för att möjliggöra nationella samverkanstillämpningar enligt T2 för olika aktörsmönster. Nedan analyseras informationsfederationer där federationsoperatören agerar tjänstekonsument, tjänsteproducent, eller endast federationsoperatör.
5.2.1 Federationsoperatör agerar också tjänsteproducent
Om man beslutar att införa en informationsfederation där federationsoperatören erbjuder en centralt realiserad tjänsteproducent enligt mönster många-till-en (till exempel en aggregerande tjänst) så medför det följande:
Federationsoperatören tillhandahåller en OAuth2-tjänst som ger ut åtkomstintyg för operatörens tjänster.
Tjänstekatalog är ej ett kritiskt behov utan kan konfigureras i varje API-klient
Federationsmedlemskatalog är ej ett kritiskt behov utan kan konfigureras i åtkomstintygstjänsten i form av klientidentiteter och tilldelade behörigheter.
5.2.2 Federationsoperatör agerar också tjänstekonsument
Om man beslutar att införa en informationsfederation där federationsoperatören erbjuder en centralt realiserad tjänstekonsument (till exempel Ineras NPÖ, Journalen) så medför det följande:
Tjänsteproducenterna tillhandahåller varsin OAuth2-baserad åtkomstintygstjänst
Tjänstekatalog är ej ett kritiskt behov, utan tjänsteproducenternas tekniska anslutningspunkt (URL) kan konfigureras i API-klienten.
Federationsmedlemskatalog är ej ett kritiskt behov utan API-klienten kan konfigureras manuellt i varje lokal åtkomstintygstjänst.
5.2.3 Federationsoperatören agerar endast federationsoperatör
Om man beslutar att införa en informationsfederation där federationsoperatören endast agerar federationsoperatör och inte ingår operativt i informationsförmedlingen (till exempel Ineras tjänster Elektronisk remiss och Utomlänsfakturering) så medför det följande:
Lokala åtkomstintygstjänster behöver förmågan att registrera API-klienter, företrädesvis automatiserat och med utgångpunkt från federationsmedlemskap
En central tjänstekatalog behövs
En central federationsmedlemskatalog behövs,