Om färdplanen
Status

Versionv.01
MålgruppTaktiskt utskott, samverkansaktörer
Relaterat dokumentTaktisk färdplan - Federationsplattform


Arbetsnamn. "Federationskontext BAS" är ett arbetsnamn. Den slutgiltiga benämningen bör fastställas som en egen beslutspunkt senare, Q1 2027 (BP3, se avsnitt 5.4). Namnfrågan har svag koppling till piloten och behöver snarare mogna fram i takt med att vi förstår hur kontexten kompletterar redan befintliga federationer.


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

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:

Relationen mellan de två färdplanerna är:

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:

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

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 federationskontextens krav och villkor. Erbjudandet för dessa aktörer kommer dock att begränsas enligt vad som beskrivs i kapitel 3.

2.3 Målgrupp


3. Federationskontext BAS - inriktning och prioritering

3.1 Inriktning

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

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

3.2 Företrädarskap - det generiskt intressanta tillsammans med steg 1

Det generiska behovet handlar i grunden om att kunna lita på:

I steg 1 i Taktisk färdplan - Federationsplattform så etableras förmågan att lösa behoven som kommer till uttryck i (a)-(c). Det är dock vanligt att en aktör (inte sällan hos aktörer med mindre utvecklingskapacitet) ö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. För att kunna lösa sådana situationer krävs även förmåga att lösa behov (d). Det det sistnämnda som avses med företrädarskap. 

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.

3.3 Mappning: syfte × förmåga


Förmåga (ramverkets steg)EHM/NDI (överordnat kort–medellång sikt)Generiskt/tvärsektoriellt (långsiktigt syfte)
Steg 1 — verifierbar systemidentitet + organisationskopplingJa, realiseras i pilot 2026Ja, öppnas för andra aktörer från 2027
Steg 2 — företrädarskap (ett system agerar för annan organisations räkning)JaJa (den del av steg 2 som erbjuds generiskt)
Steg 2 — egenskapsintyg (verksamhetsmässig innebörd av ett Trustmark; egenskaper hos system/organisation, t.ex. "är vårdgivare", "är EHR-system")Ja, EHM enda egenskapsintygsägare initialtNej, erbjuds f.n. inte
Steg 3 — användaridentitet och organisationstillhörighetÖppen fråga (beslut efter utvärdering, BP5)Öppen fråga
Steg 4 — användarbehörighetÖppen frågaÖppen frå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.

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

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

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.

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

InteraktionKlient (system / antal / organisation)Steg

Behov av egenskapsintyg

("Egenskap som signaleras")

VOK — uppgiftslämning
  • VOK-klient
  • tiotal
  • vårdgivare/ombud
1N/A
VOK — uppgiftshämtning
  • VOK-klient
  • initialt 1 → 50-tal?
  • intressenter
1N/A
PDI — uppgiftslämning
  • EHR-system
  • hundratals
  • tjänsteleverantörer
1 (→2)"är EHR-system"
NTK — uppgiftslämning
  • NTK-klient
  • tiotal
  • tjänsteleverantörer
1N/A
Tillgångstjänst → NDI
  • Tillgångstjänst
  • initialt 2 → tiotal
  • EHM → regioner m.fl.
1 (→2)"är tillgångstjänst"
Tillgångstjänst → EHR
  • Tillgångstjänst
  • initialt 2 → tiotal
2"är tillgångstjänst"
NSF → EHR (spärrdistribution)
  • NSF (EHM)
2"är NDI-komponent"?

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.

Observera att ovanstående avseende vilka egenskapsintyg som krävs är en hypotes som löpande kommer behöva utvärdera under utvecklingens gång.

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

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

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.

544 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:

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

Ansvarsfördelning för egenskapsintyg:

AktörAnsvar
Federationsoperatör (Digg)Konfigurerar i tillitsankaret vilka egenskapsintygsägare som är betrodda och vilka typer av intyg de får utfärda. Går inte i god för att utfärdaren "gör rätt".
Egenskapsintygsägare (EHM)Definierar, utfärdar och ansvarar för egenskapsintygens korrekthet samt processer och kriterier bakom varje intyg.
Förlitande partBedömer själv om den litar på ett givet egenskapsintyg och dess utfärdare. Ansvaret för åtkomstbeslut kvarstår.

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.

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

5. Tidplan, milstolpar och beslutspunkter

Figur som övergripande visualiserar milstolpar och beslutspunkter

5.1 Milstolpar

TidpunktMilstolpe
Juni 2026Regelverk för Federationskontext BAS publiceras för inhämtning av synpunkter.
Q4 2026Pilot initieras. Anslutningsoperatör(er) OCH Federationsoperatör etablerade för pilot.
Årsskiftet 2026/2027Pilot genomförs med VOK som första NDI-komponent. Piloten testar den fulla kedjan → avtal, anslutning, registrering, tillitskedjor.
Q3 2027Beslut om slutgiltigt namn (BP3).
Från 2027Steg 1-förmågan öppnas för andra aktörer än EHM (generiskt erbjudande).
H2 2027Ytterligare NDI-komponenter kan kliva in och nyttja BAS i produktion. Steg 2 (företrädarskap + egenskapsintyg för EHM) börjar tillämpas.
2028Breddinförande av steg 2. Utvärdering av behovet av steg 3 (BP5). NFF och NSF ansluts.
2029EHDS-förordningens ikraftträdande. NCP för gränsöverskridande hälsodatautbyte.

5.2 Beslutspunkter

IDTidpunkt (ca)BeslutUnderlag/kriterierVems beslut
BP12026Etablera Federationskontext BAS och Digg som federationsoperatörSeparata beslutsunderlag; denna färdplanDigg
BP2Q2 2027 (efter VOK-pilot)Ta in fler NDI-komponenter i produktion samt öppna upp "steg 1" för andra aktörer.PiloterfarenheterEHM
BP3Q2 2027Fastställ slutgiltigt namn (ersätt arbetsnamnet "BAS")Bygger på förståelse av hur kontexten kompletterar befintliga federationer (Skolfederation, SAMBI). Kommunikativt viktigt.
BP4Q3 2027

Vägval: ska hälso- och sjukvården etablera federationskontext eller kan federationskontext bas ?

Bedöms efter utvärderad VOK-pilot och förhoppningsvis ytterligare två komponenter i produktion.

Kandidatkriterier: förvaltningsbörda, sektorsspecifika krav som BAS inte bär, skalbarhet, behovsbild.

Ska bedömas utifrån Regelverk för etablering av nya federationskontexter

EHM/DIGG i samverkan
BP52028Ska steg 3 (användaridentitet) tillämpas i BAS?Utvärdering av steg 1–2


6. Operativa leveranser

6.1 Tekniska komponenter i produktion

KomponentBeskrivningAnsvarig roll
TillitsankartjänstTrust Anchor enligt OpenID FederationFederationsoperatör (Digg)
Uppslags- och verifieringstjänstResolver enligt OpenID FederationFederationsoperatör (Digg)
AnslutningstjänstIntermediate entity med registrerings- och admingränssnittAnslutningsoperatör
ÅtkomstintygstjänstOAuth 2.0 Authorization ServerAnslutningsoperatör / federationsmedlem
ResursserverNDI-komponenterna (VOK, PDI, NTK) som skyddade resurserEHM

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:

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