Page History

...

1. Inledning

1.1 Vad är detta dokument?

Detta dokument beskriver den taktiska färdplanen för Federationskontext BAS som den första operativa tillämpningen av den gemensamma federationsplattformen inom Samordnad identitet och behörighet (SIB).

Dokumentet anger vad BAS levererar, i vilken ordning förmågor tillämpas, vilka aktörer som är involverade och vilka förutsättningar som måste vara på plats. Det skiljer uttryckligen mellan de förmågor som BAS erbjuder för att möta E-hälsomyndighetens (EHM) behov och de förmågor som erbjuds generiskt till övriga aktörer (se kapitel 4).

1.2 Hur förhåller sig denna färdplan till färdplanen för federationsplattformen?

Samordnad identitet och behörighet bygger på en tydlig skiktning mellan två nivåer:

• Federationsplattformen är den gemensamma normativa grunden, d.v.s. "ramverksnivån". Här fastställs definitioner, rollmodell, regelverk, tekniska ramar, profiler, avtalsstrukturer och krav. Inga operativa tjänster ingår. Digg ansvarar för detta i rollen som ledningsaktör. Plattformens normativa artefakter publiceras öppet och kan tillämpas av aktörer som vill etablera egna federationskontexter.
• Federationskontexter är konkreta tillämpningar av ramverket, d.v.s. tillämpningsnivån. En federationskontext uppstår genom att ramverkets innehåll tillämpas med specifika parter, syfte och avgränsningar, och avgränsas av anslutning till ett tillitsankare. Här tillhandahålls operativa tjänster: tillitsankartjänst samt uppslags- och verifieringstjänst. BAS är den första sådana tillämpningen. Digg agerar här i rollen som federationsoperatör.

Relationen mellan de två färdplanerna är: färdplanen för federationsplattformen anger vilka normativa förmågor som utvecklas och i vilken ordning (stegmodellen). BAS-färdplanen anger hur, när, av vem och för vilket syfte dessa förmågor tillämpas operativt.

BAS-färdplanen definierar inga egna steg. Den refererar till plattformsfärdplanens stegmodell och förmågebeskrivningar (se Taktisk färdplan - Federationsplattform).

1.3 Drivande inriktning: Nationell digital infrastruktur för hälso- och sjukvård

Enligt Diggs regleringsbrev 2026 ska myndigheten, inom ramen för Ena, utveckla och tillhandahålla en sammanhållen infrastruktur för identitets- och behörighetshantering, och när det gäller en nationell digital infrastruktur i hälso- och sjukvården ska uppdraget genomföras i nära dialog med E-hälsomyndigheten.

BAS utvecklas därför primärt med utgångspunkt i EHM:s konkreta behov för att realisera den nationella digitala infrastrukturen (NDI) för hälso- och sjukvården. NDI ska möjliggöra säker och effektiv informationsdelning mellan kommunal vård, regional hälso- och sjukvård och tandvård samt stödja patientsäkerhet, minskad administration och kraven i EHDS-förordningen.

Inriktningen tjänar två syften: den säkerställer att BAS möter verkliga, konkreta behov redan från start, och den ger den praktiska erfarenhet som behövs för att förstå hur både Federationskontext BAS och federationsplattformen ska utformas framåt. Alternativet att försöka förutse alla tänkbara behov i förväg bedöms inte vara en framkomlig väg.

2. Varför BAS — och varför Digg, nu?

BAS etableras av tre skäl.

Genomförbarhet Digg är tillitsankare inom Sweden Connect och bygger redan upp och driftar motsvarande federationskomponenter som behövs inom BAS. Startsträckan för att också etablera en federationskontext och ta rollen som federationsoperatör för en första federationskontext enligt federationsplattformen bedöms förhållandevis kort. Det mest pragmatiska och realiserbara är därför att Digg etablerar BAS och agerar federationsoperatör.

Lärande. Processer, roller och teknik mognar först i drift. Utan en operativ federationskontext sker inget lärande och utan lärande kan vi inte utforma framtida kontexter, eller federationsplattformen, väl. Detta gäller särskilt egenskapsintyg, där lärbehovet är stort (se avsnitt 5.4).

Tvärsektoriella behov. Det finns behov som korsar sektorsgränser eller saknar naturlig hemvist i en nischad federationskontext — exempelvis åtkomst till grunddatadomäner (geodata, folkbokföring m.m.) och punkt-till-punkt-utbyten mellan ett fåtal aktörer. Hypotesen är att en generisk federationskontext som BAS kan utgöra hemvist för dessa behov långsiktigt. Detta är BAS långsiktiga existensberättigande (se avsnitt 4.2).

Skälen bakom, vad det är och dess erbjudande finns närmare beskrivet i:

• Definition av BAS som Federationskontext inom Samordnad identitet och behörighet - RU Identitet & Behörighet - Confluence
• Erbjudande (BMC)

2.1 BAS är inte "den nationella roten"

BAS får aldrig framställas som den enda eller överordnade federationskontexten. Det som är nationellt gemensamt är federationsplattformen (ramverket), inte BAS. Andra aktörer som identifierar samverkansbehov, exempelvis befintliga identitetsfederationer som Skolfederation eller SAMBI, kan etablera egna federationskontexter med stöd av samma ramverk.

2.2 BAS är öppen för fler aktörer

Även om EHM/NDI är den drivande inriktningen, är BAS öppen för andra aktörer som vill ansluta förutsatt att de uppfyller federationsplattformens krav och BAS anslutningspolicy. Den förmåga som öppnas generiskt är steg 1 och företrädarskapsdelen av steg 2 (se kapitel 4). Egenskapsintyg planeras i nuläget inte att erbjudas i någon annan omfattning.

2.3 Målgrupp

3. Federationskontext, samverkanskontext och ansvarsfördelning

3.1 Tre nivåer

Federationsplattformen utgör den gemensamma normativa grunden. Ansvar: ledningsaktören (Digg).

Federationskontext (t.ex. BAS) är en avgränsad tillämpning av federationsplattformen. En kontext får aldrig ändra, urholka eller sänka federationsplattformens villkor utan dokumenterad, motiverad och konsekvensbedömd avvikelse.

Samverkanskontext beskriver hur digital samverkan sker inom ett visst verksamhetsområde. Den ligger ovanpå den tekniska federationskontexten och preciserar vilka informationsutbyten som ska stödjas och vilka kompletterande regler som gäller. Samverkanskontexter hanteras inte av SIB utan av berörda verksamheter.

3.2 Varför denna distinktion är viktig

BAS tillhandahåller den tekniska och organisatoriska grunden för federativ tillit men avgör inte vad informationsutbytet ska innehålla eller vilka verksamhetsregler som gäller.

Konkret exempel: EHM registrerar Patientdataindex (PDI) i BAS. Att en ansluten parts system kan verifiera att PDI tillhör EHM och att anslutningen skett enligt gemensamma krav och villkor, det är BAS ansvar. Vilka vårdgivare som ska lämna uppgifter till PDI, vilka villkor som gäller för informationsutbytet och t.ex. vilka dataskyddsregler som tillämpas regleras av EHM och relevant lagstiftning, inte av BAS.

3.3 Aktörer och roller i BAS

Viktigt om ansvarsfördelningen vid obligatoriska tjänster. Federationsoperatören (Digg) ansvarar för att det finns förutsättningar och möjligheter att ansluta som anslutningsoperatör, d.v.s. att anslutningsmodellen är möjlig, att avtal kan tecknas och att tekniken fungerar. Federationsoperatören ansvarar däremot inte för att tillse att det finns en anslutningspunkt för varje federationsmedlem som vill ansluta.

Om en aktör vill driftsätta komponenter i federationskontexten som vilar på ett obligatorium dvs. där andra aktörer enligt lag eller förordning blir skyldiga att ansluta är det den aktörens ansvar att säkerställa att det finns anslutningsoperatörer, dvs. anslutningspunkter, för de aktörer som omfattas av obligatoriet. Att ett obligatorium kan uppfyllas är alltså inte federationsoperatörens ansvar.

4. Två syften och hur de mappar mot förmågorna

4.1 Förhållandet mellan syftena

BAS har två syften som ligger på olika tidshorisonter:

• EHM/NDI-syftet är överordnat på kort och medellång sikt. EHM har konkreta, tydliga behov i närtid, och Digg har ett uttalat uppdrag att stödja EHM. Tillsammans med genomförbarhetsskälet (avsnitt 2) gör detta EHM-syftet styrande för vad som realiseras först.
• Det generiska/tvärsektoriella syftet är BAS långsiktiga existensberättigande: att utgöra hemvist för tvärsektoriella behov och utbyten som saknar naturlig hemvist i mer traditionella federationskontexter.

Vägvalet om huruvida hälso- och sjukvården på sikt ska ha ett eget federationskontext (avsnitt 6.4, beslutspunkt BP4) kommer att förändra landskapet och påverkar hur de två syftena förhåller sig till varandra över tid.

4.2 Företrädarskap — det generiskt intressanta tillsammans med steg 1

Det generiska behovet handlar i grunden om att kunna lita på identiteten på en komponent, identiteten på en organisation och kopplingen mellan komponenten och organisationen samt, vid behov, vilken organisation en komponent agerar för.

Företrädarskap. Det är vanligt att en aktör (särskilt mindre aktörer) överlåter åt en leverantör att realisera en teknisk lösning. Komponenten är då per definition ofta inte aktörens egen, men används för att lösa aktörens informationsförsörjningsbehov.

Exempel: en komponent som drivs av Leverantör AB representerar Tvåköpings kommun i ett visst informationsutbyte. Den som ska fatta beslut om åtkomst behöver då förstå att det är Tvåköpings kommun som efterfrågar information, men via en viss leverantör, och kunna verifiera den relationen. Detta är detta som avses med företrädarskap.

4.3 Mappning: syfte × förmåga

Den centrala asymmetrin: företrädarskap erbjuds både för EHM och generiskt, medan egenskapsintyg i nuläget endast erbjuds EHM. Skälen till avgränsningen av egenskapsintyg utvecklas i avsnitt 5.4. Avgränsningen bygger på bästa bedömning i nuläget och kan komma att omprövas.

5. EHMs behov, NDI-komponenterna och stegvis tillämpning

5.1 NDI och dess komponenter

• VOK
  • VAD:
    • används för vårdförmedling/vårdsök
  • FÖR VILKA?
    • Vårdgivare - ska lämna uppgifter om sin organisation och verksamhet
  • NÄR?
    • För vårdförmedling/vårdsök: asap (pilot 2026)
    • Från 1 juli 2027 är antagandet

• PDI
  • VAD:
    • Patientdataindex, innehåller information om vilka vårdgivare som har data om vilka patienter
  • FÖR VILKA?
    • Vårdgivare - ska lämna uppgifter via API till PDI om vilka patienter de har relation till
  • NÄR?  
    • Från 1 juli 2027 är antagandet

• NTK
  • VAD:
    • Adresskatalog till endpoints hos vårdgivares system där man kan efterfråga hälsodatat för patienter
  • FÖR VILKA?
    • Vårdgivare ansvarar, men i praktiken är det tjänstelverantörer som pekar ut endpoints.
  • NÄR?
    • Från 1 juli 2027 är antagandet

Vem är att betrakta som vårdgivare?

Är det samma i alla ovanstående sammanhang?

1. Inledning

1.1 Vad är detta dokument?

Detta dokument beskriver den taktiska färdplanen för Federationskontext BAS — den första operativa tillämpningen av den gemensamma federationsplattformen inom Samordnad identitet och behörighet (SIB).

Dokumentet anger vad BAS levererar, i vilken ordning förmågor realiseras, vilka aktörer som är involverade och vilka förutsättningar som måste vara på plats.

1.2 Hur förhåller sig denna färdplan till ramverksfärdplanen?

Samordnad identitet och behörighet bygger på en tydlig skiktning mellan två nivåer:

Federationsplattformen är det gemensamma ramverket. Här fastställs specifikationer, profiler, rollmodell, avtalsstrukturer, kravkatalog, policyer och styrningsdokument. Ramverket definierar spelreglerna, vad som krävs för att bygga och driva en federation. Inga operativa tjänster ingår. Digg ansvarar för detta i rollen som ledningsaktör. Federationsplattformens normativa artefakter publiceras öppet (GitHub/Digg.se) och kan tillämpas av aktörer som vill etablera egna federationskontexter.

Federationskontexter är konkreta tillämpningar av ramverket. En federationskontext uppstår genom att ramverkets avtalsmallar tillämpas med specifika parter, syfte och avgränsningar. Här tillhandahålls operativa tjänster: tillitsankartjänst, anslutningstjänst, uppslags- och verifieringstjänst. Här ansluts organisationer och registreras tekniska komponenter. BAS är den första sådana tillämpningen. Digg agerar här i rollen som federationsoperatör.

Relationen mellan de två färdplanerna är: ramverksfärdplanen anger vilka normativa förmågor som utvecklas och i vilken ordning. BAS-färdplanen anger hur, när och av vem dessa förmågor tillämpas operativt.

BAS-färdplanen refererar till ramverkets normativa artefakter och stegmodell — den duplicerar eller omdefinierar dem inte.

1.3 Drivande inriktning: Nationell digital infrastruktur för hälso- och sjukvård

Enligt Diggs regleringsbrev 2026 ska myndigheten, inom ramen för Ena, "utveckla och tillhandahålla en sammanhållen infrastruktur för identitets- och behörighetshantering" och "när det gäller frågor om en nationell digital infrastruktur i hälso- och sjukvården, inklusive den nationella läkemedelslistan, ska uppdraget genomföras i nära dialog med E-hälsomyndigheten."

BAS utvecklas därför primärt med utgångspunkt i E-hälsomyndighetens (EHM) konkreta behov för att realisera den nationella digitala infrastrukturen (NDI) för hälso- och sjukvården. NDI ska möjliggöra säker och effektiv informationsdelning mellan kommunal vård, regional hälso- och sjukvård och tandvård samt stödja patientsäkerhet, minskad administration och kraven i EHDS-förordningen.

Denna inriktning tjänar två syften: den säkerställer att BAS möter verkliga och konkreta behov redan från start, och den ger den praktiska erfarenhet som behövs för att förstå hur både Federationskontext BAS och federationsplattformen ska utformas framåt. Alternativet — att försöka förutse alla tänkbara behov och utmaningar i förväg — bedöms inte som en framkomlig väg.

2. Varför BAS?

BAS etableras av tre skäl (källa: Erbjudande BMC v11, kap. 2):

Genomförbarhet. Det finns idag ingen annan aktör med beredskap att ta tillitsankarrollen. Digg ska vara tillitsankare inom Sweden Connect, vilket innebär att teknisk förmåga och driftkapacitet redan byggs upp. Tröskeln för att etablera BAS är därmed väsentligt lägre.

Lärande. Processer, roller och teknik mognar först i drift. Utan en operativ federationskontext sker inget lärande — och utan lärande kan vi inte utforma framtida kontexter väl.

Tvärsektoriella behov. Behov som korsar sektorsgränser eller saknar naturlig hemvist behöver en hemvist. Hypotesen är att BAS kan täcka dessa behov långsiktigt.

2.1 BAS är inte "den nationella roten"

BAS får aldrig framställas som den enda eller överordnade federationskontexten. Det som är nationellt gemensamt är federationsplattformen (ramverket), inte BAS. Andra aktörer som identifierar samverkansbehov kan etablera egna federationskontexter med stöd av samma ramverk.

2.2 BAS är öppen för fler aktörer

Även om EHM/NDI är den drivande inriktningen, är BAS öppen för andra aktörer som vill ansluta — förutsatt att de uppfyller federationsplattformens krav och BAS anslutningspolicy.

Den juridiska ramen för vilka verksamheter infrastrukturen får användas till styrs av den föreslagna instruktionsändringen och de lagrum som pekas ut där. Denna ram bedöms täcka hela EHMs behov för NDI, inklusive de privata vårdgivare och tjänsteleverantörer som berörs. Huruvida ramen täcker behov i andra sektorer (t.ex. utbildning) är en öppen fråga som inte påverkar BAS etablering.

2.3 Relation till sektorsspecifika behov

Strategin är att börja använda BAS för EHMs behov, som bedöms kunna tillgodoses inom de förutsättningar BAS skapar. Skulle det längs vägen visa sig att det tillkommer behov som BAS inte kan hantera, eller att BAS blir för förvaltningstungt, kan EHM etablera ett eget federationskontext och flytta över sina tjänster dit. Frågan om vad som motiverar ett eget federationskontext hänger samman med de regler som ska definieras i "Regelverk för etablering av nya federationskontexter".

Utgångspunkten är pragmatisk: BAS erbjuder en uppsättning förmågor. EHM nyttjar dem utifrån bästa förmåga. Där det fattas förmågor löser EHM det på annat sätt. Ambitionen är inte att förutse alla framtida utmaningar, utan att börja använda infrastrukturen och låta erfarenheterna styra vidareutvecklingen.

3. Federationskontext, samverkanskontext och ansvarsfördelning

3.1 Tre nivåer

Federationsplattformen utgör den gemensamma normativa grunden. Ansvar: ledningsaktören (Digg).

Federationskontext (t.ex. BAS) är en avgränsad tillämpning av federationsplattformen. En kontext får aldrig ändra, urholka eller sänka federationsplattformens villkor.

Samverkanskontext beskriver hur digital samverkan sker inom ett visst verksamhetsområde. Den ligger ovanpå den tekniska federationskontexten och preciserar vilka informationsutbyten som ska stödjas och vilka kompletterande regler som gäller. Samverkanskontexter hanteras inte av SIB utan av berörda verksamheter.

3.2 Varför denna distinktion är viktig

BAS tillhandahåller den tekniska och organisatoriska grunden för federativ tillit — men avgör inte vad informationsutbytet ska innehålla eller vilka verksamhetsregler som gäller.

Konkret exempel: EHM registrerar Patientdataindex (PDI) i BAS. Att en ansluten parts system kan verifiera att PDI tillhör EHM och att anslutningen skett enligt gemensam policy — det är BAS ansvar. Vilka vårdgivare som ska lämna uppgifter till PDI, vilka villkor som gäller för informationsutbytet och vilka dataskyddsregler som tillämpas — det regleras av EHM och relevant lagstiftning (EHDS-förordningen, patientdatalagen m.fl.), inte av BAS.

3.3 Aktörer och roller i BAS

Viktigt om ansvarsfördelningen vid obligatoriska tjänster: Federationsoperatören (Digg) ansvarar för att det går att ansluta anslutningsoperatörer — att anslutningsmodellen är möjlig, att avtal kan tecknas och att tekniken fungerar. Samverkansaktören (EHM) ansvarar för att det faktiskt finns anslutningsoperatörer som erbjuder tjänsten och som kan betjäna de aktörer som enligt lag eller förordning behöver ansluta. Digg tar inte ansvar för att det finns ett tillräckligt utbud av anslutningsoperatörer för varje tillämpning.

Anslutningsoperatör är en verksamhetsroll, inte en teknisk nod. En anslutningsoperatör kan registrera komponenter via flera mellanliggande noder och i flera federationskontexter.

4. EHMs behov och NDI-komponenterna

...

EHM bygger en nationell digital infrastruktur (NDI) för att möjliggöra säker informationsdelning inom hälso- och sjukvården. Hälsodata i Sverige är distribuerad — det finns , i storleksordningen 18 000 vårdgivare med hundratals journalsystem (EHR-system). NDI etablerar stödjande infrastruktur för att möjliggöra informationsdelning mellan dessa aktörer, som en central förutsättning för att uppfylla EHDS-förordningens kravI det korta perspektivet utgör NDI infrastruktur specifikt för att realisera EHDS, i det längre perspektivet ska NDI även stödja annan informationsdelning som sektorn har behov av.

NDI består av sex komponenter. De tre som är mest relevanta i det första skedet:

VOK — - Verksamhets- och organisationskatalogen. Samlar och tillgängliggör kvalitetssäkrade uppgifter om vårdgivare och utförare av socialtjänst. Används för att verifiera aktörer och stödja informationsutbyte. VOK exponeras som API och behöver kunna ta emot uppgifter från vårdgivare/ombud samt tillhandahålla information till system som behöver verifiera organisationer.(t.ex. "är denna organisation en vårdgivare?") och stödja informationsutbyte. Exponeras som API.

PDI - Patientdataindex. Nationellt index (i juridisk mening ett register) över PDI — Patientdataindex. Ett nationellt index med information om vilka vårdgivare som har uppgifter om en patient. Syftet är , för att begränsa sökningar till relevanta vårdgivare och system vid åtkomst till hälsodata. PDI exponeras . Exponeras som API och behöver kunna ta tar emot uppdateringar från alla vårdgivares journalsystem — , i praktiken hundratals system som drivs av tjänsteleverantörer.

NTK — - Nationell tjänsteadresseringskatalog. Register över API-endpoints hos vårdgivares system. Gör det möjligt att hitta rätt anropsadress för att hämta hälsodata från en viss vårdgivare. NTK behöver kunna ta , så att rätt anropsadress kan hittas. Tar emot uppgifter från tjänsteleverantörer av journalsystem.

Ytterligare tre komponenter tillkommer längre fram: Nationell företrädarfunktion (NFF), Nationell spärrfunktion (NSF) och Nationell kontaktpunkt (NCP) för gränsöverskridande hälsodatautbyte inom EU.

4.2 Vad SIB löser för NDI

NDI-komponenterna ställer krav som SIB adresserar i progressiva steg:

Systemautentisering — säkerställa att endast behöriga system (klienter) får åtkomst till NDI-komponenternas API:er. Utan SIB görs detta genom lokal klientregistrering per API — ett mönster som inte skalar. Med SIB kan man förlita sig på federationsmetadata istället.

Klientverifiering och nyckelhantering — koppla verifieringsnyckel till klientidentitet. Med SIB kan nyckelmaterial slås upp i federationsmetadata utan lokal konfiguration.

Tekniskt ramverk — åtkomstbegäran mot auktorisationstjänst sker enligt gemensamma tekniska specifikationer, så att varje enskild integration inte behöver testas individuellt.

Tillit till systemtyp (steg 2) — genom egenskapsintyg kan NDI-komponenterna veta att en anslutande klient är av en viss typ (t.ex. "är ett EHR-system" eller "är en tillgångstjänst") utan manuell verifiering per system.

Tillit till tjänsteleverantör (steg 2) — verifierbar information om vilken tjänsteleverantör som tillhandahåller ett visst system.

4.3 NDI-komponenternas anslutningsbehov

PDI-anslutning via API berör potentiellt samtliga vårdgivare i Sverige via deras tjänsteleverantörer. Anslutningsmodellen för BAS måste vara skalbar nog att hantera hundratals system som tillhör ett hundratal organisationer.

4.4 Behov som ännu inte är avgjorda

Flera frågor är under utredning:

• Behöver användarorganisation representeras i PDI-scenariot? Säkerhetsmässigt finns behov, men konsekvensen är att alla vårdgivare i Sverige måste registreras. Hypotesen är att detta kan skjutas till steg 2, men behovet finns och kommer senast 2029 (EHDS ikraftträdande).
• Hur hanteras endpoint discovery? Flera mekanismer är möjliga (SMART on FHIR, NTK-publicering, SIB-metadata). Vilket mönster som väljs påverkar vilken information som behöver finnas i federationsmetadata.
• Nätverksprovisionering (brandväggsöppningar etc.) löses inte av SIB och hanteras utanför federationskontexten.

5. Stegvis tillämpning av ramverkets förmågor i BAS

BAS definierar inte egna steg utan tillämpar successivt de normativa förmågor som ramverket gör tillgängliga. Tyngdpunkten ligger på steg 1 och 2, som drivs av EHMs identifierade behov.

5.1 Steg 1 — Verifierbar systemidentitet och organisationskoppling (MVP 2026)

BAS tillämpar ramverkets steg 1. Det som tillförs federationsmedlemmarna:

• Tekniska komponenter kan identifieras och verifieras genom signerad metadata och tillitskedjor
• Det går att fastställa vilken juridisk person som ansvarar för ett anslutet system
• Anslutning sker via anslutningsoperatör enligt gemensam anslutningspolicy
• Tillit uttrycks binärt: giltig metadata = tillit, ogiltig = inte

NDI-behov som möts i steg 1: VOK (uppgiftslämning och -hämtning), PDI (uppgiftslämning från EHR-system — grundscenario där det räcker att veta vilken tjänsteleverantör som anslutit systemet), NTK (uppgiftslämning), tillgångstjänsters åtkomst till NDI-komponenter.

Vad som inte ingår: delegering, egenskapsintyg om systemtyp, representation av användarorganisation, personidentiteter.

5.2 Steg 2 — Organisationsbehörighet och egenskapsintyg

BAS tillämpar ramverkets steg 2 när de normativa förmågorna blir tillgängliga. Planerad tillämpning under 2027.

Egenskapsintyg i BAS. BAS ska stödja egenskapsintyg (trust marks). Egenskapsintyg gör det möjligt att uttrycka verifierbara egenskaper om en organisation eller ett system, t.ex. "är ett EHR-system", "är en tillgångstjänst" eller "uppfyller krav X".

I det initiala skedet gäller följande avgränsning: endast statliga myndigheter får agera egenskapsintygsägare (utfärdare av egenskapsintyg) inom BAS. EHM är den första identifierade egenskapsintygsägaren.

De egenskapsintyg som är aktuella i det första skedet är relativt enkla och tunna — de uttrycker systemtyp eller organisationsegenskap, inte resultat av djupgående granskningsprocesser. Exempelvis kan ett egenskapsintyg ange att ett system har registrerats i en databas för CE-märkta medicintekniska produkter, utan att federationsoperatören granskar det underliggande beslutet.

Ansvarsfördelning för egenskapsintyg:

Övriga förmågor i steg 2:

• Stöd för delegering där ett system agerar för en annan organisations räkning
• Verifierbar information om tjänsteleverantör

NDI-behov som möts i steg 2: Automatiserad organisationsprövning (är det anropande systemet av typen EHR-system?), representation av användarorganisation vid behov, tillit till tjänsteleverantörer, distribution av NDI-spärrar (NSF → EHR), tillgångstjänsters direktåtkomst till EHR-system.

Steg 2 är avgörande för att BAS ska kunna hantera den fulla skalbarheten i NDI-scenarierna — särskilt de som involverar tiotusental vårdgivare vars behov kanaliseras genom ett hundratal tjänsteleverantörer.

5.3 Steg 3 och 4 — Framtida beslutspunkter

BAS planerar för steg 1 och 2. Huruvida BAS går vidare med steg 3 (användaridentitet) och steg 4 (användarbehörighet) är en öppen fråga som beslutas först när erfarenheterna från steg 1 och 2 utvärderats.

Det är sannolikt i steg 3 och 4 som frågan om huruvida BAS är rätt hemvist för alla behov aktualiseras på allvar. När användaridentitet och behörighetsinformation tillkommer ökar komplexiteten och potentialen för sektorsspecifika krav som kan motivera egna federationskontexter. Denna fråga lämnas medvetet öppen — den ska avgöras av erfarenheter, inte av principiella ställningstaganden i förväg.

Steg 3 kan bli aktuellt om NDI-scenarier som involverar personinloggning (t.ex. patienter eller vårdpersonal som nyttjar tillgångstjänster) behöver stöd via federationskontexten. Det är i detta steg som OpenID Federations chaining-förmåga kan bli relevant — exempelvis för att kedja användaridentitet från en annan federationskontext in i BAS tillitskedja.

6. Tidplan, milstolpar och NDI-tjänsternas anslutningsordning

6.1 Översikt 2026

6.2 Översikt 2027

6.3 Orientering 2028–2029

6.4 Beroenden mot ramverksfärdplanen

BAS kan inte produktionssättas förrän de normativa förutsättningarna är på plats:

...

kontaktpunkt (NCP) för gränsöverskridande hälsodatautbyte.

5.2 NDI-komponenternas anslutningsbehov och steg

Behoven kanaliseras genom ett begränsat antal organisationer (tjänsteleverantörer av journalsystem, tillgångstjänster) snarare än genom de enskilda vårdgivarna direkt (källa: Tekniskt PM v1, interaktionsavsnitt):

PDI-anslutning berör potentiellt samtliga vårdgivare via deras tjänsteleverantörer. Anslutningsmodellen för BAS måste vara skalbar nog att hantera hundratals system hos ett hundratal organisationer.

5.3 Steg 1 — Verifierbar systemidentitet och organisationskoppling (MVP 2026)

BAS tillämpar ramverkets steg 1. Det som tillförs federationsmedlemmarna:

• Tekniska komponenter kan identifieras och verifieras genom signerad metadata och tillitskedjor.
• Det går att fastställa vilken juridisk person som ansvarar för (driver/äger) ett anslutet system.
• Anslutning sker via anslutningsoperatör enligt gemensam anslutningspolicy.
• Tillit uttrycks binärt: giltig metadata = tillit, ogiltig = inte.

Steg 1 fokuserar på maskin-till-maskin utan användare i tillitskedjan och omfattar inga behörighetsbedömningar eller delegering.

NDI-behov som möts i steg 1: VOK (uppgiftslämning och -hämtning), PDI (uppgiftslämning i grundscenariot, där det räcker att veta vilken tjänsteleverantör som anslutit systemet), NTK (uppgiftslämning), tillgångstjänsters åtkomst till NDI-komponenter.

Erbjuds generiskt: ja, från 2027.

5.4 Steg 2 — Företrädarskap och egenskapsintyg

BAS tillämpar ramverkets steg 2 när de normativa förmågorna blir tillgängliga. Steg 2 delas i BAS upp i två delar med olika erbjudande:

• (a) Företrädarskap — erbjuds både för EHM och generiskt. Stöd för att ett system agerar för en annan organisations räkning, dvs. att skilja den organisation som driver en komponent (leverantör) från den organisation komponenten agerar för (huvudman).
• (b) Egenskapsintyg — erbjuds f.n. endast EHM. Egenskapsintyg är den verksamhetsmässiga innebörden av ett Trustmark (den tekniska bäraren enligt OpenID Federation, klädd med regler och egenskaper). Egenskapsintyg uttrycker verifierbara egenskaper hos en organisation eller ett system, d.v.s. egenskaper som är behörighetsgrundande och nödvändiga för att en förlitande part ska kunna fatta beslut om åtkomst. Det handlar alltså inte om relationen mellan komponent och organisation (det är företrädarskap), utan om t.ex. att en organisation "är vårdgivare" eller att ett system "är ett EHR-system". Utan sådan information saknas tillräcklig behörighetsgrundande grund för åtkomstbeslut. För EHM är detta byggstenar för att kunna automatiserad beslut om åtkomst.

I det initiala skedet gäller följande avgränsningar för egenskapsintyg:

• Endast EHM erbjuds egenskapsintyg. Skälen är två:
  • (1) EHM har ett uttalat behov och Digg har ett uppdrag att stödja dem, och
  • (2) det finns ett stort behov av att lära sig hur egenskapsintyg ska användas i federationskontexter vilket motiverar att avgränsa erbjudandet tills lärandet mognat.
• De aktuella egenskapsintygen är relativt enkla och tunna, de uttrycker systemtyp eller organisationsegenskap, inte resultat av djupgående granskningsprocesser. Federationsoperatören går inte i god för det underliggande beslutet.

Ansvarsfördelning för egenskapsintyg:

NDI-behov som möts i steg 2: automatiserad organisations- och systemtypsprövning (är anropande system av typen EHR-system?), representation av användarorganisation vid behov (via företrädarskap), tillit till tjänsteleverantörer, distribution av NDI-spärrar (NSF → EHR), tillgångstjänsters direktåtkomst till EHR-system.

5.5 Steg 3 och 4 — framtida beslutspunkter

BAS planerar för steg 1 och 2. Huruvida BAS går vidare med steg 3 (användaridentitet) och steg 4 (användarbehörighet) är en öppen fråga som beslutas först när erfarenheterna från steg 1 och 2 utvärderats (beslutspunkt BP5).

Det är sannolikt i steg 3 och 4 som frågan om huruvida BAS är rätt hemvist för alla behov aktualiseras på allvar. När användaridentitet och behörighetsinformation tillkommer ökar komplexiteten och potentialen för sektorsspecifika krav som kan motivera egna federationskontexter. Frågan lämnas medvetet öppen — den ska avgöras av erfarenheter, inte av principiella ställningstaganden i förväg.

6. Tidplan, milstolpar och beslutspunkter

Figur som övergripande visualiserar milstolpar och beslutspunkter

6.1 Milstolpar

6.2 Beslutspunkter

...

7. Operativa leveranser

7.1 Tekniska komponenter i produktion

7.2 Regelverk

BAS-specifikt regelverk avses skickas på remiss i juni 2026 och publiceras i draft-version. Det omfattar BAS-specifik anslutningspolicy, registreringspolicyer och metadata-krav. Regelverket refererar till federationsplattformens villkorsbilagor, avtalsmallar och policyer.-krav, och refererar till federationsplattformens villkorsbilagor, avtalsmallar och policyer.

Förfining av regelverk och avtal för anslutning till federationskontext tas fram under genomförande av VOK-pilot.

7.3 Förvaltningsprocesser

...

BAS steg 1 anses uppfyllt när:

• Minst två oberoende federationsmedlemmar har system i drift (
Client
• klient och
Resource Server
• resursserver) som kommunicerar via infrastrukturen.
• Ingen manuell utväxling av nycklar eller certifikat mellan parter
—
• - tillit etableras via federationsmetadata.
• Anslutningsprocessen är dokumenterad, testad och upprepad.
• Finansieringsmodell
framtagen
• fastställd och förankrad.
• Roller, ansvar och policyer dokumenterade och fastställda.
• Förvaltningsprocesser testade i skarp drift.

9. Vad vi behöver lära oss

Piloten och den tidiga driften av BAS ska ge svar på frågor som inte kan lösas teoretiskt:

Anslutningsmodellens skalbarhet. NDI-scenarierna innebär att hundratals system ska anslutas. Fungerar anslutningsprocessen utan specialanpassningar vid denna volym?

Avtalsstrukturen i praktiken. Håller fullmaktskonstruktionen när anslutningsoperatören tecknar FM-anslutningsförbindelser å federationsoperatörens vägnar?

Samverkansaktörens roll. EHM registrerar tjänster som andra organisationer blir skyldiga att ansluta till. Fungerar principen att EHM tillser att anslutningsoperatörer finns medan federationsoperatören godkänner dem?

BAS som hemvist. Räcker BAS förutsättningar för EHMs behov, eller uppstår krav som motiverar en egen federationskontext? Vilka kriterier avgör den frågan?

Egenskapsintyg i praktiken. Kan egenskapsintyg (trust marks) användas för att uttrycka systemtyp på ett hanterbart sätt? Fungerar avgränsningen till statliga myndigheter som utfärdare? Uppstår behov av mer avancerade granskningsprocesser?

10. Risker

Förväntansglidning. Aktörer förväntar sig att BAS löser juridiska frågor kring datadelning. BAS verifierar avsändare och tillitskedja — den förlitande parten ansvarar fortsatt för åtkomstbeslut.

Normativa beroenden. BAS kan inte produktionssättas om normativa artefakter från federationsplattformen inte är klara i tid.

Skalbarhet vid bred anslutning. PDI-scenariot innebär att hundratals system och organisationer ska anslutas. Om anslutningsmodellen inte skalar påverkas NDI-tidplanen.

Ansvarsfördelning vid obligatoriska tjänster. Ansvarsfördelningen mellan EHM (tillse att anslutningsoperatörer finns), federationsoperatören (möjliggöra anslutning) och anslutningsoperatörerna (betjäna aktörerna) behöver fungera friktionsfritt. Om denna kedja inte håller uppstår risk att obligatoriet inte kan uppfyllas.

Finansieringsmodellens mognad. Finansieringsmodellen för operatörsnivån är under utveckling. Om den inte är klarlagd innan anslutningsoperatörer förväntas investera kan nödvändiga aktörer inte delta.

BAS kontra eget federationskontext. Om BAS visar sig otillräcklig för EHMs behov behöver en övergång till ett sektorsspecifikt federationskontext kunna ske utan att redan anslutna parter påverkas.

Oklara signaler om BAS framtid. Om samverkansaktörer uppfattar att det finns intern osäkerhet om BAS långsiktiga roll och avgränsning, minskar incitamentet att investera i anslutning. Tydlig och konsekvent kommunikation om BAS inriktning är en förutsättning för förtroende.

Överlappande parallella initiativ. Det finns initiativ utanför SIB som delvis berör samma tillämpningsområde (t.ex. utökat användande av befintliga infrastrukturkomponenter för API-adressering och tillit). Otydlig avgränsning mellan dessa och BAS kan skapa förvirring hos aktörer som ska välja anslutningsväg.

11. Finansieringsförutsättningar

Finansieringen bygger på en skiktning som följer ansvarsfördelningen (källa: Finansieringsanalys, utkast mars 2026):

Federationsplattformen — gemensamma komponenter finansieras via Diggs anslag. Digg ska i normalfallet inte agera prissättande aktör på marknaden.

Operatörsnivån — den rekommenderade modellen är marknadsbaserad. Anslutningsoperatörer prissätter sina tjänster mot anslutna parter utifrån egna kostnadsstrukturer. Modeller med central prissättning eller statlig ersättning förkastas som generella modeller.

Finansieringsmodellen är ett pågående arbete och ännu inte beslutad.

12. Avgränsningar och förutsättningar

12.1 Vad BAS inte levererar

• BAS identifierar inte användare
• BAS fattar inga åtkomstbeslut och reglerar inga behörigheter
• BAS bär inga sektorsspecifika materiella krav — de hanteras i samverkanskontexter
• BAS löser inte nätverksprovisionering (brandväggsöppningar etc.)

12.2 Förutsättningar

kan lösas teoretiskt:

• Anslutningsmodellens skalbarhet. NDI-scenarierna innebär att hundratals system ska anslutas. Fungerar anslutningsprocessen utan specialanpassningar vid denna volym?
• Avtalsstrukturen i praktiken. Håller fullmaktskonstruktionen när anslutningsoperatören tecknar FM-anslutningsförbindelser å federationsoperatörens vägnar?
• Samverkansaktörens roll och obligatoriet. EHM registrerar tjänster som andra organisationer blir skyldiga att ansluta till. Fungerar principen att EHM ansvarar för att anslutningsoperatörer finns för dem som omfattas av obligatoriet, medan federationsoperatören godkänner dem och tillhandahåller förutsättningarna?
• Egenskapsintyg i praktiken. Detta är ett av de viktigaste lärbehoven. Kan egenskapsintyg användas för att uttrycka systemtyp och organisationsegenskap på ett hanterbart sätt? Fungerar avgränsningen till statliga myndigheter som utfärdare och till EHM som enda mottagare? Uppstår behov av mer avancerade granskningsprocesser?
• Företrädarskapets tekniska realisering. Vilken teknisk bärare/mekanism realiserar att en komponent agerar för en annan organisation, och hur avgränsas den mot egenskapsintyg så att det generiska erbjudandet (steg 1 + företrädarskap, utan egenskapsintyg) blir tekniskt koherent? (Se avsnitt 4.3.)
• BAS som hemvist. Räcker BAS förutsättningar för EHM:s behov, eller uppstår krav som motiverar en egen federationskontext? Vilka kriterier avgör frågan (BP4)?

10. Risker

• Förväntansglidning. Aktörer förväntar sig att BAS löser juridiska frågor kring datadelning. BAS verifierar avsändare och tillitskedja — den förlitande parten ansvarar fortsatt för åtkomstbeslut.
• Normativa beroenden. BAS kan inte produktionssättas om normativa artefakter från federationsplattformen inte är klara i tid.
• Skalbarhet vid bred anslutning. PDI-scenariot innebär att hundratals system och organisationer ska anslutas. Om anslutningsmodellen inte skalar påverkas NDI-tidplanen.
• Ansvarsfördelning vid obligatoriska tjänster. Kedjan EHM (tillse att anslutningsoperatörer finns för dem som omfattas av obligatoriet) → federationsoperatör (möjliggöra anslutning) → anslutningsoperatör (betjäna aktörerna) behöver fungera friktionsfritt, annars riskerar obligatoriet att inte kunna uppfyllas.
• Finansieringsmodellens mognad. Finansieringsmodellen för operatörsnivån är under utveckling. Om den inte är klarlagd innan anslutningsoperatörer förväntas investera kan nödvändiga aktörer inte delta.
• BAS kontra eget federationskontext. Om BAS visar sig otillräcklig för EHM:s behov behöver en övergång till ett sektorsspecifikt federationskontext kunna ske utan att redan anslutna parter påverkas.
• Oklara signaler om BAS framtid. Om samverkansaktörer uppfattar intern osäkerhet om BAS långsiktiga roll minskar incitamentet att investera i anslutning. Tydlig och konsekvent kommunikation om BAS inriktning är en förutsättning för förtroende.
• Överlappande parallella initiativ. Initiativ utanför SIB berör delvis samma tillämpningsområde. Otydlig avgränsning kan skapa förvirring hos aktörer som ska välja anslutningsväg.
• Federationsplattformens normativa artefakter för aktuellt steg publicerade och tillämpningsbara
• Finansieringsmodell för operatörsnivån klarlagd
• Minst en anslutningsoperatör godkänd och redo
Driftmiljöer (test, QA, produktion) etablerade