På sidan:
Uppgifter
Överenskommet arbetssätt
Mötesanteckningar
2026-08-19
SYFTE:
- Öka den gemensamma förståelsen för vad som behöver justeras eller förtydligas i federationsplattformens ramverk för att vi ska ha en gemensam och accepterad grund att utgå från för att ta fram avtal för genomförande av piloten.
MÅL:
- Vi har identifierat, beskrivit och isolerat centrala frågeställningar som behöver besvaras för att vi ska ha en första version av federationsplattformens ramverk som vi kan utgå från för att ta fram s.k. ”pilotavtal”.
- Vi har ett överenskommet nästa steg (läs: vad gör vi efter detta möte).
AGENDA
20216-05-29
Introduktion till juridikspåret för Samordnad identitet och behörighet
Deltagare:
- Johan Tjäder (uppdragsledare Digg)
- Niklas Dahlbäck (uppdragsledare EHM)
- @Anna Döös (jurist Digg)
- Britt-Marie Jönson (jurist Digg)
- Maria Wetterdal (jurist EHM)
- @Julia Pistol (jurist EHM)
1. Syfte med mötet
Syftet med dagens möte är att ge juristerna från Digg och E-hälsomyndigheten en gemensam grund för arbetet med Samordnad identitet och behörighet och få samsyn innan nästa möte den 2 juni där jurister från Inera och Internetstiftelsen deltar.
Mötet ska inte lösa hela den långsiktiga avtals- och styrmodellen. Det primära syftet är mer avgränsat:
skapa en grundläggande gemensam förståelse för vad Samordnad identitet och behörighet är,
tydliggöra skillnaden mellan federationsplattformen och federationskontext Bas,
beskriva den planerade piloten med vård- och omsorgskatalogen,
enas om vad juridikspåret behöver leverera för att piloten ska kunna genomföras,
identifiera vilka rättsliga frågor som behöver hanteras nu och vilka som kan hanteras senare.
Ovanstående kommer vara föremål för diskussion även i nästa möte med Digg, Inera och Internetstiftelsen.
2. Bakgrund: varför Samordnad identitet och behörighet?
Samordnad identitet och behörighet handlar om att skapa en gemensam grund för säker och interoperabel digital samverkan över organisationsgränser.
I dag finns många olika sätt att lösa identitet, systemtillit och behörighetsnära frågor. Det fungerar ofta i enskilda relationer, men blir svårt när många aktörer ska samverka med många andra aktörer. Resultatet blir fragmentering, återkommande speciallösningar, höga anslutningskostnader och oklar ansvarsfördelning.
Den grundläggande idén är därför inte att centralisera alla lösningar, utan att skapa en federativ modell där självständiga aktörer kan samverka enligt gemensamma regler, tekniska profiler och ansvarsfördelning.
Det innebär förenklat:
aktörerna behåller ansvar för sina egna system och sin egen verksamhet,
tillit skapas genom gemensamma regler, metadata, tillitskedjor och verifierbara intyg,
samma grundläggande modell kan återanvändas i flera olika federationskontexter,
"sektorsspecifika" (i brist på bättre ord) regler kan läggas till där det behövs, utan att hela infrastrukturen behöver byggas om.
3. De två huvudsakliga leveranserna
3.1 Federationsplattformen
Federationsplattformen är den gemensamma grunden. Den kan beskrivas som ett normativt och tekniskt ramverk för hur federationskontexter ska byggas.
Den innehåller bland annat:
gemensamma begrepp och roller,
grundläggande krav och vägledningar för federationskomponenter,
tekniska profiler och specifikationer,
krav och vägledning för harmoniserad anslutning av aktörer och registrering av dess komponenter,
strukturer för ansvar mellan olika roller.
Syftet med federationsplattformen är att skapa en gemensam bottenplatta så att olika federationskontexter inte utvecklas åt helt olika håll. Om varje kontext bygger sin egen modell från grunden får vi bara en dyrare version av dagens fragmentering.
Viktigt för juristerna:
federationsplattformen är initialt att betrakta som vägledning,
den är inte i sig direkt rättsligt bindande för någon federationskontext,
den ska däremot vara utgångspunkt för de federationsregelverk och avtal som tas fram inom en konkret federationskontext.
3.2 Federationskontext Bas (OBS - ska betraktas som ett arbetsnamn)
Federationskontext Bas är den första konkreta federationskontexten. Den har två huvudsakliga syften.
Det första syftet är att ge E-hälsomyndigheten en praktiskt användbar federationskontext där myndigheten kan börja realisera behov avseende identitet och behörighet kopplade till nationell digital infrastruktur inom hälso- och sjukvården.
Det andra syftet är bredare: att pröva om det finns ett generellt behov av en enklare federationskontext för grundläggande system- och organisationstillit över organisationsgränser.
Bas ska i första steget kunna ge svar på frågor som:
vilket tekniskt system anropar?
vilken organisation står bakom systemet?
är systemet och organisationen anslutna enligt gemensamma regler?
kan mottagaren verifiera detta maskinellt och standardiserat?
Detta är viktigt att avgränsa. Bas i första steget löser inte alla behörighetsfrågor. Det är inte en fullständig lösning för användarbehörigheter, yrkesroller eller komplexa sektorsspecifika åtkomstbeslut. Det handlar först om verifierbar systemidentitet och organisatorisk koppling.
4. Relation mellan federationsplattformen och Bas
En förenklad modell är:
Federationsplattformen
= gemensam grund, begrepp, roller, krav, tekniska profiler och vägledning
Federationskontext Bas
= första konkreta tillämpningen av plattformen, med egna avgränsningar, regler och avtal
Pilot
= kontrollerad prövning av om regelverk, roller, teknik och avtal fungerar i praktiken
Federationsplattformen ger alltså ramen. Bas behöver omsätta ramen till ett konkret federationsregelverk. Piloten testar om detta håller i verkligheten.
5. Piloten: vad ska prövas?
Den planerade piloten gäller vård- och omsorgskatalogen.
Utgångspunkten är att E-hälsomyndigheten vill tillgängliggöra en komponent, där anslutning sker genom Inera och/eller Internetstiftelsen som anslutningsoperatör, medan Digg tar rollen som federationsoperatör och tillhandahåller tillitsankartjänst.
Syftet med piloten är att lära och testa bl.a.:
om tekniken fungerar,
om anslutningsmodellen fungerar,
om regelverket är begripligt och tillämpbart,
om roller och ansvar är tillräckligt tydliga,
om parterna har de rättsliga förutsättningar som krävs,
om avtalsstrukturen räcker för en kontrollerad pilot.
Piloten ska alltså inte bara vara ett tekniskt test. Den ska också ge svar på om den juridiska och organisatoriska modellen är användbar.
Läs mer på: Mål och utvärderingskriterier
6. Juridikspårets primära uppgift
Juridikspårets första uppgift är att skapa de rättsliga förutsättningarna för att genomföra piloten.
Det betyder framför allt att klargöra:
vilka parter som deltar i piloten,
vilken roll respektive part har,
vilket ansvar respektive part tar,
vilka skyldigheter som behöver regleras,
vilka avtal eller överenskommelser som krävs,
vilka delar av regelverket som behöver vara bindande för piloten,
om det finns rättsliga hinder eller risker som måste hanteras innan piloten startar.
Det kortsiktiga målet är inte att ta fram den slutliga skalbara avtalsmodellen för hela infrastrukturen. Det målet finns, men kommer senare.
Det kortsiktiga målet är att piloten ska kunna genomföras på ett rättsligt ordnat sätt.
7. Avgränsning: vad ska inte lösas fullt ut nu?
För att arbetet ska bli hanterbart behöver vissa frågor hållas isär.
Ska hanteras nu
Rättsliga förutsättningar för den definierade piloten.
Parternas roller och ansvar i piloten.
Minsta nödvändiga avtals- eller överenskommelsestruktur.
Hur federationsregelverket för Bas får genomslag i piloten.
Ansvar för drift, anslutning, metadata, tillitsankare och anslutna komponenter.
Vad EHM, Digg, Inera och/eller Internetstiftelsen faktiskt åtar sig.
Ska identifieras men inte nödvändigtvis lösas fullt ut nu
Den långsiktigt skalbara avtalsmodellen.
Hur nya parter ansluts utan bilaterala avtal mellan alla.
Om och när hälso- och sjukvården behöver en egen federationskontext.
Hur egenskapsintyg ska användas bredare än för EHM:s behov.
Hur framtida behörighetsintyg, användaridentitet och användarbehörighet ska regleras.
Eventuella författningsändringar som krävs för en permanent modell.
8. Viktiga juridiska frågor att strukturera
8.1 Mandat och uppdrag
Vilket stöd har Digg för att agera federationsoperatör i piloten?
Vilket stöd har EHM för att delta och använda Bas för sina behov?
Är piloten förenlig med respektive myndighets uppdrag?
Behöver piloten beskrivas som försöksverksamhet, samverkan, teknisk test eller något annat?
8.2 Roller och ansvar
Vem är federationsoperatör? Digg
Vem är anslutningsoperatör? Inera/Internetstiftelsen
Vem ansvarar för anslutning av organisation?
Vem ansvarar för säker registrering av teknisk komponent? Anslutnigsoperatören
Vem ansvarar för riktigheten i metadata? Federationsmedlemmen, viss kvalitetssäkrande uppgift kan åläggas Anslutningsoperatören
Vem ansvarar för att tillit återkallas vid fel?
Vem fattar beslut om åtkomst i den mottagande tjänsten?
En central princip bör vara att skilja mellan juridiska parter och tjänsteorienterade roller. En aktör kan utföra en viss funktion utan att det juridiska ansvaret flyttas på ett otydligt sätt.
8.3 Regelverkets rättsliga status
Vilka delar av federationsplattformen används som vägledning?
Vilka delar behöver lyftas in i federationsregelverket för Bas?
Vilka delar behöver göras bindande genom avtal eller överenskommelse?
Hur hanteras ändringar av regelverket under piloten?
8.4 Avtal och överenskommelser
Vilka avtal eller överenskommelser behöver finnas mellan parterna?
Räcker en gemensam överenskommelse för piloten?
Behövs separata bilagor för ansvar, tekniska krav, informationssäkerhet, incidenthantering och förändringshantering?
Hur säkerställs att anslutningsoperatörens ansvar framgår tydligt?
Hur regleras eventuella underleverantörer?
8.5 Bas kontra sektorsspecifik kontext
Är det rättsligt tillräckligt att EHM:s första behov hanteras inom Bas?
Vilka behov kan hanteras inom Bas utan sektorsspecifik reglering?
Vilka behov bör uttryckligen inte hanteras inom Bas?
När skulle en särskild hälso- och sjukvårdskontext behöva övervägas?
Här bör budskapet vara tydligt: Bas är ett medvetet första steg, inte ett påstående om att alla sektorsspecifika behov redan är lösta.
9. Föreslaget resultat från dagens möte
Efter dagens möte bör vi ha enats om följande:
Juridikspårets uppgift för piloten.
Vilka aktörer som behöver ingå i den första juridiska analysen.
Vilka dokument som behöver tas fram eller kvalitetssäkras.
Vilka rättsliga frågor som är blockerande före pilotstart.
Vilka frågor som kan hanteras som lärdomar eller senare utvecklingsfrågor.
En enkel arbetsform för fortsatt samverkan mellan Digg och EHM:s jurister.
10. Nästa steg
- NU: Vardera part: sätta sig in i SIB för att skapa förutsättningar för att kunna lämna synpunkter på kommande utskick av federationsplattformens regelverk
- SEN: nytt möte efter sommaren för att diskutera det utskickade materialet och få igång dialog, förslag:
- 20 augusti kl. 13-15
- 21 augusti kl. 10-12
- DÄREFTER: när vi har ett accepterat och förankrat regelverk som ligger till grund för hur vi sätter upp federationskontexter → ta fram pilotavtal som möjliggör för genomförande av pilot