...

...

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

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

...

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

...

Att bygga upp en gemensam infrastruktur för identitet och behörighet låter sig inte göras enbart på ritbordet. Den måste prövas i praktiken. Federationskontext BAS är det första konkreta steget: den första federationskontext där den gemensamma federationsplattformen tillämpas i skarp drift.

Att det blir just Digg som etablerar BAS är i grunden en fråga om genomförbarhet. Digg är redan tillitsankare inom Sweden Connect och bygger och driftar i dag de typer av komponenter som en federationskontext kräver. Startsträckan för att också etablera en federationskontext och axla rollen som federationsoperatör är därför kort.

Att börja i en konkret tillämpning ger dessutom det lärande som behövs för att forma både BAS och federationsplattformen framåt, i stället för att försöka förutse alla tänkbara behov i förväg, vilket inte bedöms vara en framkomlig väg.

En sak är viktig att slå fast: BAS är inte "den nationella roten". Det som är nationellt gemensamt är ramverket, d.v.s. federationsplattformen, inte BAS. Andra aktörer som har samverkansbehov kan etablera egna federationskontexter med stöd av samma ramverk.

För den som vill förstå närmare vad BAS omfattar hänvisas till Definition av BAS som federationskontext, och för en beskrivning av värdet och erbjudandet till Erbjudande (BMC).

3. Federationskontext BAS - inriktning och prioritering

3.1 Vad BAS löser, och för vem

BAS finns för att lösa ett återkommande problem. När två organisationers it-system ska utbyta information automatiskt behöver den mottagande sidan kunna lita på vem som är i andra änden, vilket system det är och vilken organisation som står bakom det, utan att parterna först måste komma överens en och en. Det är den tilliten BAS tillhandahåller.

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

På kort och medellång sikt drivs BAS av ett konkret behov. E-hälsomyndigheten ska etablera en nationell digital infrastruktur för hälso- och sjukvården, och Digg har i uppdrag att stödja det arbetet. Det styr vad BAS realiserar först.

På lång sikt är BAS tänkt att fylla en bredare roll: att vara hemvist för informationsutbyten som inte hör hemma i någon av de mer nischade federationer som redan finns, t.ex. åtkomst till grunddata som många aktörer behöver, eller utbyten mellan ett fåtal parter. Det är BAS långsiktiga existensberättigande.

BAS är öppen för andra aktörer som uppfyller kontextens krav, men erbjudandet till dem är till en början avgränsat (vad som ingår framgår nedan). Primärt riktar sig BAS till de verksamheter som omfattas av förslaget till ändrad instruktion för Digg, som lämnades i samband med slutrapporten i december 2025. Andra organisationer kan ansluta i den mån de skapar förutsättningar för den primära målgruppen, t.ex. som leverantör eller anslutningsoperatör.

Eftersom BAS från start bär hälso- och sjukvårdens behov finns en öppen fråga att hantera framåt: ska hälso- och sjukvården på sikt ha en egen federationskontext, eller räcker BAS? Det är ett medvetet uppskjutet vägval. Vi avgör det först när vi vet mer, efter att ha prövat lösningen i praktiken. Tidpunkten för vägvalet framgår av tidplanen.

3.2 Företrädarskap

I sin enklaste form låter BAS en mottagare avgöra två saker: vilket system som anropar, och vilken organisation som ansvarar för det systemet. För många utbyten räcker det.

Men i praktiken driver organisationer ofta inte sina egna system. En mindre kommun kan låta en leverantör tillhandahålla den tekniska lösningen. Systemet är då inte kommunens eget, men det används för kommunens räkning. Mottagaren behöver i ett sådant fall veta något mer än vem som driver systemet: den behöver veta vilken organisation systemet agerar för.

Den förmågan, d.v.s. att kunna visa och verifiera att ett system agerar för en annan organisations räkning, kallar vi i detta dokument för företrädarskap.

Ett exempel: ett system som drivs av Leverantör AB hämtar information för Tvåköpings kommuns räkning. För att en mottagare ska kunna fatta beslut om åtkomst behöver den förstå att det är Tvåköpings kommun som efterfrågar informationen, om än via en leverantör, och kunna lita på den relationen.

Företrädarskap är, vid sidan av den grundläggande systemidentiteten, det som gör BAS användbart även utanför hälso- och sjukvården. Behovet är vanligt i offentlig sektor och inte bundet till någon särskild domän. Därför är det en av de förmågor BAS avser att erbjuda brett.

3.3 Vilka förmågor BAS tillämpar - och för vem

BAS uppfinner inga egna förmågor. Det tillämpar den stegmodell som federationsplattformen tillhandahåller, där förmågorna införs stegvis. För BAS är det främst de två första stegen som är aktuella i närtid.

Steg 1 ger den grundläggande tilliten: en mottagare kan verifiera vilket system som anropar och vilken organisation som ansvarar för det. Detta erbjuds både för hälso- och sjukvårdens behov och, från 2027, generiskt till andra aktörer.

Steg 2 lägger till två saker. Den ena är företrädarskap, beskrivet ovan. Den andra är egenskapsintyg, d.v.s. förmågan att intyga en verifierbar egenskap hos en organisation eller ett system, exempelvis att en organisation är vårdgivare eller att ett anropande system är ett journalsystem. Företrädarskap erbjuds brett. Egenskapsintyg erbjuds i nuläget endast för E-hälsomyndighetens behov, eftersom vi först behöver lära oss hur egenskapsintyg fungerar i praktiken innan förmågan breddas.

Steg 3 och 4 - som rör användares identitet respektive behörighet är öppna frågor som avgörs senare, mot bakgrund av erfarenheterna från de första stegen.

Figuren nedan sammanfattar hur de två syftena förhåller sig till förmågorna över tid.

3.3 Mappning: syfte × förmåga

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

4.1 Varför en nationell digital infrastruktur behövs

EHDS-förordningen ger patienter rätt till sina hälsodata och ställer krav på att Sverige kan ge både patienter och vårdpersonal åtkomst till relevanta hälsodata, oavsett var i landet, eller i EU, de finns. Hälsodata skapas och lagras hos vårdgivarna, i deras journalsystem.

Problemet är att hälsodata är utspridd. Det finns omkring 18 000 vårdgivare och hundratals olika journalsystem. Ingen kan rimligen fråga alla. Det krävs därför en stödjande infrastruktur som hjälper till att hitta var en viss patients uppgifter finns och att utbyta dem säkert. Det är detta E-hälsomyndigheten bygger som nationell digital infrastruktur. På kort sikt för att uppfylla EHDS, på längre sikt även för annan informationsdelning inom sektorn.

4.2 Infrastrukturens byggstenar i korthet

Infrastrukturen består av ett fåtal samverkande delar. Förenklat finns ett index som vet vilka vårdgivare som har uppgifter om en viss patient, en katalog som vet var systemens gränssnitt finns, och en katalog med kvalitetssäkrade uppgifter om vilka som faktiskt är vårdgivare. Därtill finns funktioner för patientens spärrar och för ombud och företrädare, samt en nationell kontaktpunkt för utbyte över landsgränser.

Dessa delar löser frågan om var informationen finns och hur den hämtas. De säger däremot inget om huruvida den som frågar går att lita på. Det är där BAS kommer in.

4.3 Vad BAS bidrar med - och varför det behövs

Det BAS tillför är tilliten: att den som tar emot ett anrop kan veta vilket system som anropar och vilken organisation som står bakom det, utan att varje par av parter först måste registrera varandra manuellt och hålla informationen uppdaterad.

Alternativet är att varje system som ska ta emot anrop själv håller reda på varje tillåten motpart i form av dess identitet, dess nycklar och vad den får göra och behöva underhålla detta löpande. I ett sammanhang med hundratals system som tillkommer och försvinner över tid blir det ohållbart. BAS gör att tilliten i stället kan hämtas från gemensam, verifierbar information.

I takt med att förmågorna byggs ut kan BAS bära allt mer. Först förmågan att fastställa vilket system och vilken organisation det handlar om. Därefter förmågan att intyga egenskaper, t.ex. att ett anropande system verkligen är ett journalsystem, eller att en organisation verkligen är en vårdgivare och förmågan att uttrycka att ett system agerar för en annan organisations räkning.

4.4 Hur det möter stegen

De tidiga behoven möts till stor del redan i steg 1: att lämna uppgifter till de nationella katalogerna och att låta åtkomsttjänster nå infrastrukturen. Här räcker det ofta att kunna fastställa vilken leverantör som anslutit ett system.

Steg 2 behövs när en mottagare måste kunna avgöra en egenskap, t.ex. om ett anropande system verkligen är ett journalsystem eller om en organisation verkligen är en vårdgivare, eller när ett system agerar för en annan organisations räkning. Egenskapsintygen i detta skede är medvetet enkla; de uttrycker en systemtyp eller en organisationsegenskap, inte resultatet av en djupgående granskning. Federationsoperatören (Digg) avgör vilka utfärdare som är betrodda och vilka slags intyg de får utfärda, men går inte i god för det enskilda intygets sakinnehåll, det ansvarar istället utfärdaren för, och den mottagande parten avgör själv om den litar på intyget. Inledningsvis erbjuds egenskapsintyg endast för E-hälsomyndighetens behov, dels eftersom behovet där är konkret och uttalat, dels för att lärandet kring egenskapsintyg ska få mogna innan förmågan breddas.

Den avgörande frågan och den största risken är skalbarheten. Hälsodata når infrastrukturen via hundratals journalsystem som drivs av i storleksordningen ett hundratal leverantörer. Anslutningsmodellen måste klara den volymen utan särlösningar för varje enskild integration.

4.5 Steg 3 och 4 - framtida frågor

BAS planerar i nuläget för steg 1 och 2. Om BAS ska gå vidare till steg 3 och 4, som handlar om användares identitet respektive behörighet, avgörs först när erfarenheterna från de första stegen utvärderats. Det är sannolikt där

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

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, i storleksordningen 18 000 vårdgivare med hundratals journalsystem (EHR-system). I 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 mest relevanta i 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 (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 vilka vårdgivare som har uppgifter om en patient, för att begränsa sökningar till relevanta vårdgivare. Exponeras som API och 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, 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.

5.2 NDI-komponenternas anslutningsbehov och steg (hypotes)

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 federationskontexterställs på sin spets, eftersom komplexiteten och de sektorsspecifika kraven växer när individnivån tillkommer. Frågan lämnas medvetet öppen — den och ska avgöras av erfarenhetererfarenhet, inte av principiella ställningstaganden i förväg.

...

5. Tidplan, milstolpar och beslutspunkter

Figur som övergripande visualiserar milstolpar och beslutspunkter

...

5.1 Milstolpar

...

5.2 Beslutspunkter

...

6. Operativa leveranser

...

6.1 Tekniska komponenter i produktion

...

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

...

6.3 Förvaltningsprocesser

Anslutningsprocess, incidenthantering och ändringshantering ska vara operativa och testas under piloten.

...

7. Mätbara mål och acceptanskriterier

BAS steg 1 anses uppfyllt när:

• Minst två oberoende federationsmedlemmar har system i drift (klient och 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 fastställd och förankrad.
• Roller, ansvar och policyer dokumenterade och fastställda.
• Förvaltningsprocesser testade i skarp drift.

...

8. Vad vi behöver lära oss

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

...

För VOK-piloten finns särskilt utformade Mål och utvärderingskriterier.

...

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