1. Idé uppstår – initiering av pilotidé

Syfte: Fånga upp förslag tidigt utan att kräva för mycket underlag.

• En aktör (myndighet, programdel, leverantör, samverkanspart) lyfter en idé om pilot.
• Idén dokumenteras mycket kort, t.ex. i ett standardiserat pilotidé-formulär (se här: Pilotidéformulär - light - RU Identitet & Behörighet - Confluence) 
• Aktören bjuds in att föredra sin idé.
• Dialog sker

Innehåll (light-version):

• Kort beskrivning av pilotidén - mönster och scenarion
• Behov kopplat till Samordnad identitet och behörighet
• Vilken del av infrastrukturen / vilket steg i färdplanen som avses testas
• Föreslagen deltagare/aktör
• Grov tidsbild

Output: inkommen och registrerad pilotidé

Bakgrund och syfte

Verksamhets- och organisationskatalog för sektorn hälsa, vård och omsorg (VOK) hos E-hälsomyndigheten tillhandahåller en digital tjänst i form av en nationell katalog över vårdgivare och utförare av socialtjänst.

Katalogen tillhandahåller idag en e-tjänst för registrering av uppgifter. Katalogen ska även framöver tillhandahålla API:er för att registrera och hämta uppgifter. När API:erna tillgängliggörs krävs en säker åtkomstlösning för dessa API:er.

I dagsläget används VOK av Nationell vårdförmedling (NVF) för att hämta uppgifter, men detta görs genom interna anrop hos E-hälsomyndigheten. NVF ska dock använda VOK:ens kommande externa API:er.

De organisationer som behöver delta i piloten är

• E-hälsomyndigheten - tillhandahåller VOK och NVF
• Anslutningsoperatör: ej utsedd
• Federationsoperatör: Digg

2. Förtydligande och beredning av pilotidé Niklas: känns svårt att veta vad som ska skrivas här. Väldigt många olika typer av punkter som efterfrågas i underlaget. Överlapp mellan olika avsnitt. Känsla av "overkill" som riskerar bli hinder. 

Förenkla och strukturera.

Syfte: Säkerställa att idén är tillräckligt konkret för att kunna bedömas.

Här tas ett pilotunderlag fram (kan ske tillsammans med Digg/E-hälsomyndigheten).

Innehåll i pilotunderlag:

• Syfte och behov
  • Vilket behov adresseras?
  • Varför behöver detta testas i pilot?
  • Vad som ska testas
• Vilka funktioner/komponenter i infrastrukturen
• Vad är nytt/oprövat
• Avgränsning
  • Vad testas inte?
• Förväntad nytta och lärdomar
  • Vad vill vi veta efter piloten?
  • Hur bidrar resultatet till fortsatt utveckling?
• Koppling till steg i taktisk färdplan
• Förutsättningar (hos deltagande aktörer)
• Aktörer
• Juridik/säkerhet (översiktligt)
• Teknik (översiktligt)
• Risker och beroenden
• Tid och resursöversikt (grovt)
• Plan för omhändertagande av lärdomar

Output: Färdigt pilotunderlag

Pilotbeskrivning

Behov av Samordnad identitet och behörighet

Behov av extern API-säkerhet för VOK bedöms kräva säker kännedom om anropande organisation och dess system. 

Behovet bedöms finnas under 2026, då en e-tjänst (Nationell vårdförmedling) kommer att anropa API:er i VOK för att hämta uppgifter.

Nationell vårdförmedling (NVF) är en tjänst hos E-hälsomyndigheten men anropen sker till externa API:er och behöver således säkras på något sätt. Utgångspunkten är att Ena Samordnad identitet och behörighet lämpar sig väl för målet med åtkomstlösningen.

Arbete som krävs

Den tekniska utveckling som behöver ske i piloten är huvudsakligen fokuserad på åtkomstlösningen samt att tillgängliggöra de befintliga interna API-erna (FHIR) externt. NVF behöver anropa det externa API:et.

Det är alltså ingen större funktionell utveckling i VOK eller anropande system som piloten är beroende av.

Anropsflöde

Piloten kommer alltså att ha ett huvudscenario:

1) Användare arbetar i Nationell vårdförmedling (NVF) och vill söka efter vård

2) NVF anropar EHM:s auktorisationstjänst för att få ett åtkomstintyg

3) NVF anropar VOK:s externa FHIR-API, som anropar VOK-server API

I steg 2 används Samordnad identitet och behörighet för att verifiera identitet på organisation och system (NVF).

Komponenter som behöver registeras i Samordnad identitet och behörighet

3. Kvalitetssäkring – uppfyller piloten rätt syfte och vid rätt tillfälle?

Syfte: Säkerställa att piloten testar rätt saker.

Bedömning görs mot fasta kriterier, t.ex.: Niklas: man kan inte ha exempel på fasta kriterier (om det inte är upp till pilotaktören att själv bestämma kriterierna)

• Testar piloten de delar som behöver testas i aktuellt steg?
• Bidrar den till lärande för infrastrukturen (inte bara lokal nytta)?
• Finns tydlig hypotes eller frågeställning?
• Är piloten genomförbar inom rimlig tid och komplexitet?
• Finns förutsättningar hos deltagande aktörer?
• Återkoppling till aktör (myndighet, programdel, leverantör, samverkanspart) som lyft idén om pilot

Bedömningen kan göras av ett beredningsforum eller sakkunniggrupp.

Output: Rekommendation (gå vidare, omformulera/ komplettera)

Kvalitetssäkring – uppfyller piloten rätt syfte och vid rätt tillfälle?

Relation till färdplan i Samordnad identitet och behörighet

Piloten ska gå i produktion 2026. Under 2026 är det troligtvis enbart E-hälsomyndigheten som kommer vara aktuella som federationsmedlem. Därefter är det sannolikt att en eller flera vårdgivare/ombud också önskar använda de externa API:erna och därmed också behöver ansluta till Samordnad identitet och behörighet.

Bedömningen just nu är att det är tillräckligt för VOK att veta vilken organisation och vilket system hos denna organisation som gör anropet till API:et.

Därför bedöms MVP (steg 1 i taktisk färdplan) för Samordnad identitet och behörighet vara tillräckligt för att möta behovet. Det innebär också att syftet med MVP uppfylls genom denna pilot.

Det hade varit optimalt att piloten även ansluter en organisation som inte deltar i arbetet med Samordnad identitet och behörighet, men detta behöver av tidsskäl komma i senare skede.

Förutsättningar att göra arbetet

E-hälsomyndigheten bedömer att det finns förutsättningar att göra arbetet under 2026.

Dialog med potentiell anslutningsoperatör behöver ske för att bedöma förutsättningar hos denne.

Utkomst

Piloten bedöms kunna ge underlag till att dra lärdomar i fortsatt utveckling av Samordnad identitet och behörighet.

4. Bedömning mot taktisk färdplan och helhet Niklas: detta är väl mer för Ena än pilotaktören att fylla i? Dela upp behov av underlag med beredningsprocessen.

Syfte: Säkerställa rätt tajming och prioritering.

Hur passar piloten in i:

• Pågående och planerade piloter?
• Utvecklingstakten för infrastrukturen?
• Finns överlapp eller beroenden?
• Behövs piloten nu, senare – eller alls?
• Återkoppling till aktör (myndighet, programdel, leverantör, samverkanspart) som lyft idén om pilot (Niklas: fattar inte rubriken till punktlistan kopplat till denna punkt)

Output: Prioriteringsbedömning

Bedömning mot taktisk färdplan och helhet

Det finns inga andra piloter och därmed ingen konflikt, vare sig i lösning eller resuser.

Då målet är att piloten ska vara genomförd 2026 mappar det väl mot den taktiska färdplanen.

5. Samlad beredning och beslutsunderlag

Syfte: Göra det enkelt att fatta beslut.

Ett beslutsunderlag tas fram som sammanfattar:

• Pilotens syfte och innehåll
• Vad som testas och varför
• Koppling till steg och färdplan
• Förväntad nytta
• Risker/konsekvenser
• Rekommendation: genomför / avvakta / avslå
• Återkoppling till aktör (myndighet, programdel, leverantör, samverkanspart) som lyft idén om pilot

Output: Färdigt beslutsunderlag

Samlad beredning och beslutsunderlag
Niklas: detta är väl mer för Ena än pilotaktören att fylla i? Dela upp behov av underlag med beredningsprocessen.

• Pilotens syfte och innehåll
  • Möjliggöra extern API-säkerhet för VOK - verifiera organisation och system
• Vad som testas och varför
  • MVP i taktisk färdplan
• Koppling till steg och färdplan
  • MVP i taktisk färdplan
• Förväntad nytta
  • Provtrycka MVP och ge tillräcklig åtkomstlösning för VOK
• Risker/konsekvenser
  • Involvering av anslutningsoperatör krävs för att kunna genomföra piloten
  • Beroenden till releaser hos E-hälsomyndigheten
• Rekommendation: genomför / avvakta / avslå
  • Genomför
• Återkoppling till aktör (myndighet, programdel, leverantör, samverkanspart) som lyft idén om pilot

6. Beslut om pilot

Syfte: Formellt beslut om genomförande.

Beslut fattas i utsedd beslutsgrupp (t.ex. gemensam styrning Digg/EHM).

Beslutet bör omfatta:

• Ja/nej
• Eventuella villkor
• Inplacering i tidsplan
• Återkoppling till aktör (myndighet, programdel, leverantör, samverkanspart) som lyft idén om pilot
• Dokumentation i beslutslogg

Output: Beslutad pilot

Beslut

Ena arbetsgrupp beslutar att genomföra piloten.

Piloten startar från och med detta beslut med mål att piloten är i produktion och utvärderad under 2026.

7. Överlämning till genomförande

Syfte: Säkerställa att piloten faktiskt kan starta.

• Utse pilotansvarig
• Starta detaljerad planering
• Säkerställ uppföljning och hur resultat ska tas om hand

Output: Pilot redo att starta

Överlämning till genomförande
Niklas: ja, det behövs något om hur resultat ska tas om hand men behöver detta vara del av denna process? Kanske något som kan göras inom ramen för piloten?

XX ansvarar för att samordna piloten inom ramen för Samordnad identitet och behörighet.

Rapportering sker till Team Tillämpning i arbetsgrupp för Samordnad identitet och behörighet.