Vägledning - Skapa federation för informationsutbyte i enlighet med T2
| Vägledning - Skapa federation för informationsutbyte i enlighet med T2Revision A ARK_0077 2025-01-17 |
Kommentar revision A
Vi söker just nu ett konkret case för att praktiskt testa de hypoteser som vägledningen återger. Vi ser ett behov av att utmana vissa slutsatser som i slutändan kan få stora konsekvenser på en förväntad kostnadsbild.
Revisionshistorik
Revision | Datum | Kommentar | Ändringar gjorda av |
---|---|---|---|
A | 2025-01-17 | Revision fastställd | Gabriel von Euler |
Definitioner
I detta dokument används termer från T2 - referensarkitektur för interoperabilitet inom svensk välfärd (T2 - välfärden) (Terminologi - T2 - välfärden - Confluence (atlassian.net)). Nedan redovisas de termer vi sett behov av att introducera i denna vägledning.
Ord/förkortning | Förklaring |
Anslutande part | Part som tecknat avtal med federationen men ännu inte är i produktion. |
Ansluten part | Part som har klarat alla anslutningskrav och är i produktion. |
Federation | I detta dokument detsamma som informationsfederation. |
Federationshuvudman | Den delägare som är utsedd att representera ägarkollektivet vid exempelvis avtalstecknande. |
Federationsmedlem | Organisation som tecknat avtal att ingå i federationen i avsikt att utgöra en ansluten part. |
Federationsoperatör | Den aktör som är utsedd av federationsägaren att förvalta federationen utifrån av Federationsägaren fastställda regler. |
Federationsägare | Den eller de organisationer som definierar och styr federationen utifrån gemensamt definierade regler för informationsutbytet så som teknik, semantik, legala tolkningar och organisatoriska regler och policyer. |
Informationsfederation | Ett antal aktörer, som i avtalad samverkan, utbyter information i ett gemensamt syfte. Detta sker med hjälp av gemensamt definierade regler för informationsutbytet avseende teknik, semantik, legala tolkningar och organisatoriska regler och policyer. Synonymt med ”federation för informationsutbyte”. |
Sammansatt bastjänst | En centralt tillhandahållen tjänst som tillför funktionalitet som avlastar och/eller förenklar för tjänstekonsumenter att använda en interoperabel lösning. En sammansatt bastjänst kan även användas för att underlätta för tjänsteproducenter att erbjuda sina APIer för konsumtion, till exempel genom transformation till en gemensam API-specifikation. |
Samverkansarkitekturen | Ineras samlingsbegrepp för alla de referensarkitekturer och anvisningar som tagits fram för att möjliggöra interoperabel samverkan mellan aktörer inom svensk vård och omsorg. |
T2 | T2 är en benämning för de två nya fastställda referensarkitekturna för interoperabilitet inom svensk välfärd generellt (T2 – välfärden) och mer specifikt svensk vård och omsorg (T2 – vård och omsorg). ”T2” relaterar till befintlig referensarkitektur som benämns T-boken, där T:et står för ”teknik”. T2-arkitekturerna kompletterar T-boken med nya integrationsmönster och stöd för nya tekniska standarder. |
1. Inledning
1.1 Syfte
Syftet med detta dokument är att ge aktörer inom svensk välfärd en vägledning för när det är motiverat att skapa en federation för informationsutbyte (även kallad informationsfederation) enligt T2 – välfärden och hur detta bör ske. Vägledningen vänder sig främst till beslutsfattare som underlag, samt till projektledare och projektgrupp för planering och genomförande.
1.2 Avgränsning
Vägledningen är utarbetad främst för kontexten nationella federationer för informationsutbyte inom svensk vård och omsorg. För andra tillämpningsområden kan vägledningen kanske inte användas direkt utan att anpassas.
1.3 T2 - ny referensarkitektur för interoperabilitet
Inera har tillsammans med regionerna tagit fram två referensarkitekturer för interoperabilitet som går under samlingsnamnet T2. T2 linjerar med arbeten i Myndighetssverige och inom EU, ger större flexibilitet i hur man utformar sina interoperabla lösningar, och öppnar upp för användandet av moderna informationsutbytesstandarder, både tekniska och semantiska sådana. T2-arkitekturerna fastställdes 2023 av regionerna.
Den nya samverkansarkitekturen öppnar även upp för att teknisk kommunikation kan ske direkt mellan anslutna parter. En sådan direkt kommunikation ger förutsättningar att öka robustheten och säkerheten i kommunikationen. Vissa verksamhetsbehov kan dock kräva informationsutbyte via en sammansatt bastjänst.
1.4 Vad utmärker en informationsfederation
Om många parter vill dela information med många andra och därigenom har behov av interoperabel samverkan är det motiverat att skapa en informationsfederation.
Det spelar ingen roll om informationsutbytet sker direkt mellan parterna, eller via en sammansatt bastjänst.
Vid samverkansmönstret en-till-många eller många-till-en, där tillit inte behöver finnas mellan många-aktörerna sinsemellan är samverkan inte en federation utan är snarare att betrakta som en fristående digital tjänst.
1.5 Nyttor med en informationsfederation
Nyttan med att etablera en informationsfederation kan vara att man kan digitalisera samverkansbehov som tidigare inte kunnat digitaliseras, eller att existerande lösningar kan effektiviseras.
En viktig aspekt är att man inom arbetet att ta fram en informationsfederation på ett naturligt sätt kan föra samtal om hur man bör lösa gemensamma problem för att på så sätt skapa förutsättningar för interoperabilitet och möjlighet för informationsutbyte och ytterligare samverkan.
En nyttoeffekt är att antal avtal som behöver tecknas i en informationsfederation ökar linjärt med antal samverkande parter, medan antal avtal som behöver tecknas med en bilateral avtalsmodell ökar exponentiellt. Bilaterala avtal tenderar till att divergera i sin utformning över tid vilket leder till ökad administration och bristande interoperabilitet. Även personuppgiftbiträdesavtal kan på detta sätt hanteras via en central avtalspart istället för upprättande av bilaterala avtal.
En annan nytta är att endast behöva ta fram och att förvalta en uppsättning överenskommelser och interoperabilitetsspecifikationer.
Nya lagkrav kan också motivera skapandet av en informationsfederation.
Om medlemmar i en federation ändå kan se behov av att komplettera federationsavtalet med bilaterala avtal sinsemellan för att reglera affärsvillkor, som till exempel verksamhetsmässiga kapacitetsgarantier och kostnader. Nyttan kan därmed begränsas av att inte alla medlemmar i en federation interagerar med alla övriga.
En annan möjlig begränsning av nyttan med en informationsfederation är om medlemmarnas verksamhetsmässiga efterfrågan eller utbud begränsar antal möjliga samverkanstillfällen.
1.6 Federationens livscykel
En informationsfederation behöver kunna skapas, förvaltas, och avslutas. Denna vägledning fokuserar i denna revision på skapandet av en federation. I skapandet ingår det att beskriva hur förvaltning och avslut ska gå till.
2. Skapa federation
Nedan ger vi vägledning inom alla de områden där vi identifierat att förberedelser behövs.
2.1 Ägar- och styrstruktur
För att möta ett verksamhetsbehov av informationsutbyte mellan många parter krävs att en eller flera organisationer tar initiativet till att bilda en informationsfederation. Dessa får en federationsägarroll.
I federationsägarrollen ingår att över tid styra över informationsfederationen och den federationsoperatör som förvaltar federationen. Denna styrning omfattar att fortlöpande utvärdera verksamhetsnyttan, och förmågan att kunna avsluta federationen när denna ej längre uppfyller verksamhetsbehoven.
Om flera aktörer är med i rollen som federationsägare, behöver det tas fram ett federationsägaravtal eller liknande som reglerar inbördes relationer, delegation av ansvar, och vem som är sammankallande. I detta avtal bör även reglera hur federationsägare kan inträda och utträda ur federationen, och hur federationen ska kunna avslutas.
Federationsägargrupperingen behöver även utse en part som federationens centrala avtalspart, vilken ska representera informationsfederationen när avtal ska tecknas.
2.2 Genomförandeplan
Att ta fram och bilda en ny informationsfederation kan utgöra ett stort och komplext arbete, som då lämpligen genomförs i projektform.
Det kan även behövas tecknas avtal med olika aktörer för att säkerställa projektleveransen. Federationsoperatören bör involveras i en tidig fas för att säkerställa ett gott införande och en smidig övergång.
I många fall kan en federationsoperatör också behöva involveras i arbetet med att ta fram infrastruktur för federationen, exempelvis stödtjänster om federationen ska tillhandahålla egna stödtjänster, samt testmiljöer.
2.3 Kostnadsmodell
En prismodell bör tas fram baserad på federationens business case som underlag till informationsfederationens prislistor.
2.4 Federations- och avtalsstruktur
Varje federation behöver definiera vilken övergripande aktörs- och avtalsstruktur som ska gälla för den färdiga federationen. Det rekommenderas att rita upp en översiktlig karta för att illustrera och tydliggöra hur strukturen är tänkt.
Modellen i T2 – välfärden ger endast en översiktsbild som vi uppfattat behöver detaljeras ytterligare för att kunna vara realiserbar inom svensk välfärdssektor.
2.4.1 Enligt T2
Roller enligt T2 beskrivs enligt följande:
2.4.2 Enligt denna vägledning
Det kan i många sammanhang kan finnas behov av att skilja mellan federationers ägarstruktur och federationsmedlemsstruktur. Ägarna är de som beslutar om, och ansvarar för, federationens struktur, styrning och regelverk.
I sin enklaste form finns det bara en avtalsrelation: den mellan federationen i form av federationens centrala avtalspart och federationsmedlemmarna. Detta uppstår när en ägare agerar federationsoperatör och är central avtalspart. I detta scenario står centrala avtalsparten själv för förvaltningen av federation och innehar federationsoperatörsansvaret, och stödtjänster realiseras av federationsoperatören i den omfattning de behövs.
I de fall där den centrala avtalsparten och federationsoperatören utgörs av två olika organisationer behövs ett avtal som reglerar vad som ingår i förvaltningsuppdraget. En viktig fråga att ta ställning till då är om det är federationsägaren eller federationsoperatören som är den centrala avtalsparten. Om federationsoperatören är tänkt att upphandlas och kunna bytas ut är det lämpligt att låta ägaren utgöra avtalsparten.
Andra viktiga områden att definiera är operatörens ansvar för medlemskvalificering, kvalitetssäkring och support.
I de fall någon form av stödtjänster bedöms behövas och om dessa inte förvaltas av ägaren eller federationsoperatören behöver de beskrivas och eventuellt regleras via avtal. Detta gäller både generella stödtjänster som federationsmedlemskatalog och tjänstekatalog, som mer tillämpningsspecifika som till exempel informationslokaliseringstjänster, spärrtjänster och utbudstjänster.
Det behöver också definieras om det ska finnas några restriktioner i form av vidarebefordran av information i underliggande led och eventuell användning av leverantörer utanför federationsmedlemmens organisation. Detta behöver i så fall beskrivas i anslutningsavtalet.
2.4.3 Livscykelhantering av avtal
Avtalens livscykler behöver planeras och kartläggas för att tillse att det inte uppstår glapp under federationens livstid.
2.5 Juridiska aspekter av aktörsroller
Det föreligger juridiska begränsningar om vilka organisationstyper som får samarbeta och köpa respektive sälja tjänster av varandra. Det påverkar vilka aktörer som kan agera i roller som federationsoperatör, federationsmedlem, etcetera.
Se separat sammanställning i Bilaga: Juridiska möjligheter för affärsmässiga relationer mellan olika typer av aktörer för samverkan inom vård och omsorg.
2.6 Interna avtal
2.6.1 Avtal med federationsoperatör
Ägarna behöver utse en federationsoperatör som tar ansvar för den operativa förvaltningen av federationen.
Om operatören tillhör en från ägaren fristående organisation behöver operatörens ansvar regleras i avtal. Där bör följande beskrivas:
Ansvar för federationsdokumentation, inklusive vidmakthållande och ändringshantering
Ersättningsmodell och fakturering
Anslutningsprocessen, inklusive test och kvalitetssäkring.
Ansvar för eventuella stödtjänster eller sammansatta bastjänster, inklusive SLA och informationssäkerhet.
Support och service
Eventuellt avslutande eller överlämnande till annan operatör
2.6.2 Avtal med infrastrukturtjänsteleverantör
Om det finns ett beroende i federationen till användning av stödtjänster som erbjuds av andra leverantörer än federationsoperatören behöver avtal slutas med dessa. Beroende vad det avser så kommer dessa avtal se olika ut men bör åtminstone reglera följande:
Ersättning
Informationssäkerhet
Anslutningsprocessen av parter
SLA
2.6.3 Övriga avtal som behövs för federationen
Beroende på informationsfederationens avtalsstruktur kan även andra avtal behövas tas fram eller tecknas.
2.7 När kan informationsfederationen anses vara skapad
En federation kan anses vara skapad när avsedd samverkan är realiserad. När informationsfederationen är skapad är den redo att övergå i förvaltning med tillhörande vidmakthållande och ändringshantering.
3. Federationsdokumention
3.1 Interoperabilitetsspecifikation
Regelverket för en samverkan beskrivs i en så kallad interoperabilitetsspecifikation som beskriver den verksamhetsmässiga samverkan, hur stödtjänster ska användas, med mera.
Det första som behöver beskrivas är syftet med samverkan, vilket behov ska lösas? Är det till exempel ett lagkrav, ett informationsbehov eller ett verksamhetsbehov som ligger till grund för federationen? Vad är omfånget, behöver några avgränsningar beskrivas? En informationsfederation avgränsas till ett syfte.
Interoperabilitetsspecifikationen beskriver samverkan ur perspektiven juridik, organisation, semantik och teknik.
3.2 Supporthantering
Det bör beskrivas hur supportkedjorna ska se ut. För fel rörande stödtjänsterna bör ju dessa ingå i supportkedjan, men när det gäller fel i kommunikationen mellan konsument och producent behöver det fastställas om det ska det ske direkt mellan anslutna parter eller om federationsoperatören ha någon koordinerande roll. De behöver även beskrivas hur verksamhetsmässiga avvikelser ska hanteras, om det ska ske direkt mellan parterna eller om federationsoperatören ska ha en roll.
3.3 Prislista och faktureringssätt
Prislista och faktureringssätt är något som behöver fastställas. Det rekommenderas att ha en separat prislista för anslutning och en annan för vidmakthållandet efter att anslutningen är genomförd. Anslutningsavgift är normalt en engångssumma, medan vidmakthållandeavgiften behöver faktureras löpande, till exempel månadsvis eller årsvis.
3.4 Federationsmedlemsavtal
Ett avtal behöver tas fram för att kunna tecknas av organisation som bli medlem i federationen.
Det är viktigt att slå fast om medlem har någon skyldighet att ansluta tekniskt och verksamhetsmässigt till federationen inom någon definierad tidsrymd och även beskriva vilken påföljden blir i annat fall.
Omvänt är det viktigt att beskriva hur medlemskapet påverkas om medlem väljer att upphöra med sin anslutning eller blir frånkopplad av operatören på grund av avtalsbrott eller liknande.
Avtalet bör referera till federationsdokumentationen inklusive de avgifter som ingår för anslutning och vidmakthållande. Avtalet bör också innehålla:
Tillitsramverk, det vill säga vilka organisatoriska förmågor (framför allt inom informationssäkerhetsområdet) som federationens parter behöver besitta och hur dessa styrks.
Eventuella förutsättningar innan anslutning får påbörjas eller godkännas: De federationer eller tekniska stödtjänster som den anslutande parten förutsätts vara godkänd och ansluten till.
3.5 Personuppgiftsbiträdesavtal
Personuppgiftsbiträdesavtal kommer att behövas för relationen mellan federationsmedlem och stödtjänstleverantör, avseende den behandling som sker av medlemmens kontaktuppgifter i adressbok eller katalog.
Federationens central avtalspart kan även fungera som avtalshub för federationsmedlemmarnas inbördes personuppgiftsbiträdesavtal.
3.6 Publicering
Om federationen innehåller många medlemmar och/eller vill bjuda in ytterligare medlemmar är det lämpligt att skapa en publik kommunikationsyta att publicera federationsdokumentationen på.
Om federationsdokumentationen eller delar därav ska publiceras bör följande beaktas:
Identifiera ytor för publicering.
Säkerställ ägarskap för innehållet.
Tillse tillgängligheten för innehållet över tid.
Säkerställ rutiner för att uppdatera publicerade dokument vid uppdatering.
För att avgöra om federationen ska publicera en förteckning över sina medlemmar bör även följande beaktas:
Om federationen hanterar uppgifter som enligt författning ska tillgängliggöras.
Om förteckningen innehåller skyddsvärd information, till exempel personuppgifter i en enskild firma.
3.7 Versionshantering
Under federationens livscykel kommer förändringar behöva göras i federationsdokumentationen och det är därför viktigt med versionshantering.
Förändringar i dokumentation och federationsavtalet kan få stor påverkan på federationens parter och det är därför viktigt att tydligt beskriva process för hur förändringar kommer att göras och hur detta kommer att kommuniceras till redan anslutna medlemmar.