| Om färdplanen | |
|---|---|
| Status | |
| Version | v.01 |
| Målgrupp | Taktiskt utskott, samverkansaktörer |
| Relaterat dokument | Taktisk 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. |
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).
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).
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.
BAS etableras av tre skäl:
Skälen bakom, vad det är och dess erbjudande finns närmare beskrivet i:
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.
Ä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.
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.
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. |

| Förmåga (ramverkets steg) | EHM/NDI (överordnat kort–medellång sikt) | Generiskt/tvärsektoriellt (långsiktigt syfte) |
|---|---|---|
| Steg 1 — verifierbar systemidentitet + organisationskoppling | Ja, realiseras i pilot 2026 | Ja, öppnas för andra aktörer från 2027 |
| Steg 2 — företrädarskap (ett system agerar för annan organisations räkning) | Ja | Ja (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 initialt | Nej, 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.
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.
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):
| Interaktion | Klient (system / antal / organisation) | Steg | Behov av egenskapsintyg ("Egenskap som signaleras") |
|---|---|---|---|
| VOK — uppgiftslämning |
| 1 | N/A |
| VOK — uppgiftshämtning |
| 1 | N/A |
| PDI — uppgiftslämning |
| 1 (→2) | "är EHR-system" |
| NTK — uppgiftslämning |
| 1 | N/A |
| Tillgångstjänst → NDI |
| 1 (→2) | "är tillgångstjänst" |
| Tillgångstjänst → EHR |
| 2 | "är tillgångstjänst" |
| NSF → EHR (spärrdistribution) |
| 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. |
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.
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ör | Ansvar |
|---|---|
| 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 part | Bedö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.
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.

Figur som övergripande visualiserar milstolpar och beslutspunkter
| Tidpunkt | Milstolpe |
|---|---|
| Juni 2026 | Regelverk för Federationskontext BAS publiceras för inhämtning av synpunkter. |
| Q4 2026 | Pilot initieras. Anslutningsoperatör(er) OCH Federationsoperatör etablerade för pilot. |
| Årsskiftet 2026/2027 | Pilot genomförs med VOK som första NDI-komponent. Piloten testar den fulla kedjan → avtal, anslutning, registrering, tillitskedjor. |
| Q3 2027 | Beslut om slutgiltigt namn (BP3). |
| Från 2027 | Steg 1-förmågan öppnas för andra aktörer än EHM (generiskt erbjudande). |
| H2 2027 | Ytterligare NDI-komponenter kan kliva in och nyttja BAS i produktion. Steg 2 (företrädarskap + egenskapsintyg för EHM) börjar tillämpas. |
| 2028 | Breddinförande av steg 2. Utvärdering av behovet av steg 3 (BP5). NFF och NSF ansluts. |
| 2029 | EHDS-förordningens ikraftträdande. NCP för gränsöverskridande hälsodatautbyte. |
| ID | Tidpunkt (ca) | Beslut | Underlag/kriterier | Vems beslut |
|---|---|---|---|---|
| BP1 | 2026 | Etablera Federationskontext BAS och Digg som federationsoperatör | Separata beslutsunderlag; denna färdplan | Digg |
| BP2 | Q2 2027 (efter VOK-pilot) | Ta in fler NDI-komponenter i produktion samt öppna upp "steg 1" för andra aktörer. | Piloterfarenheter | EHM |
| BP3 | Q2 2027 | Fastställ slutgiltigt namn (ersätt arbetsnamnet "BAS") | Bygger på förståelse av hur kontexten kompletterar befintliga federationer (Skolfederation, SAMBI). Kommunikativt viktigt. | |
| BP4 | Q3 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 |
| BP5 | 2028 | Ska steg 3 (användaridentitet) tillämpas i BAS? | Utvärdering av steg 1–2 |
| Komponent | Beskrivning | Ansvarig roll |
|---|---|---|
| Tillitsankartjänst | Trust Anchor enligt OpenID Federation | Federationsoperatör (Digg) |
| Uppslags- och verifieringstjänst | Resolver enligt OpenID Federation | Federationsoperatör (Digg) |
| Anslutningstjänst | Intermediate entity med registrerings- och admingränssnitt | Anslutningsoperatör |
| Åtkomstintygstjänst | OAuth 2.0 Authorization Server | Anslutningsoperatör / federationsmedlem |
| Resursserver | NDI-komponenterna (VOK, PDI, NTK) som skyddade resurser | EHM |
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.
Anslutningsprocess, incidenthantering och ändringshantering ska vara operativa och testas under piloten.
BAS steg 1 anses uppfyllt när:
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.