Open	Målarkitektur för samverkan enligt T2 inom svensk välfärd   Revision PA3 ARK_0076 2025-02-03

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. T2 - välfärden

2. T2 - vård och omsorg

1.1 Syfte

Målarkitekturen syftar till att:

1. 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.

2. Beskriva hur samverkan fungerar med stöd av teknisk arkitektur och infrastruktur.

3. 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.

4. 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

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

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.

1. 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?

2. 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.

Open

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:

1. Tillit kan bygga på lag, avtal och/eller bevisade tillitsskapande förmågor.

2. Tillitsramverk stipulerar ofta specifika organisatoriska förmågor och arbetssätt.

3. En parts följsamhet mot dessa förmågor kan säkerställas med olika krav om försäkran

   1. utan uppföljning, det vill säga baserat på grundmurad tillit.

   2. egen intern revision

   3. revision av extern part

   4. 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.

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.

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

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.

Open

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:

1. Begränsa inte åtkomst baserat på anropande parts IP-adress!

2. Basera åtkomst på tillitsfull hantering av identiteter och behörighetsgrundande attribut förmedlade på applikationsnivå.

3. 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.

Open

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.

Open

• 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

Open

Aktörer, komponenter och interaktioner i samband med direkt anrop från API-klient till API

Huvuddragen i interaktionen ovan är:

1. Tjänstekonsumerande system söker API ur sin lokala tjänstekatalog

2. Tjänstekonsumerande system bekräftar att hittat tjänsteproducent är medlem i informationsfederationen

3. Tjänstekonsumerande system begär åtkomst till API från tjänsteproducentens åtkomstintygstjänst

   1. Verifiering av tillit till tjänstekonsumerande systems identitet sker mot central källa för IAM-metadata.

   2. Åtkomstbeslutet grundar sig delvis på tjänstekonsumenten är medlem i en informationsfederation där tjänsteproducentens API ingår.

4. 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.

Open

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:

1. Tjänstekonsumerande system söker fram den förvaltningsgemensamma tjänstens API ur den lokala tjänstekatalogen

2. Den förvaltningsgemensamma tjänstens medlemskap i informationsfederationen verifieras emot tjänstekonsumentens lokala federationskatalog.

3. Tjänstekonsumerande system begär åtkomst till den förvaltningsgemensamma tjänsten från den förvaltningsgemensamma tjänstens åtkomstintygstjänst

   1. Verifiering av tillit till tjänstekonsumerande systems identitet sker mot central metadata.

   2. Åtkomstbeslutet grundar sig på att tjänstekonsumenten är medlem i en informationsfederation där den aggregerande tjänsten ingår

4. Tjänstekonsumentens system anropar den förvaltningsgemensamma tjänsten

5. 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.

6. 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.

7. 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.

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.

Open

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:

1. Federationsoperatören tillhandahåller en OAuth2-tjänst som ger ut åtkomstintyg för operatörens tjänster.

2. Tjänstekatalog är ej ett kritiskt behov utan kan konfigureras i varje API-klient

3. 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:

1. Tjänsteproducenterna tillhandahåller varsin OAuth2-baserad åtkomstintygstjänst

2. Tjänstekatalog är ej ett kritiskt behov, utan tjänsteproducenternas tekniska anslutningspunkt (URL) kan konfigureras i API-klienten.

3. 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:

1. Lokala åtkomstintygstjänster behöver förmågan att registrera API-klienter, företrädesvis automatiserat och med utgångpunkt från federationsmedlemskap

2. En central tjänstekatalog behövs

3. En central federationsmedlemskatalog behövs,