På sidan:
| Table of Contents |
|---|
...
Tidsplan
| Område/Vecka | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | ||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Teknik inkl. tekniska krav | Svensk OIDF-profil v.1.0 | Registreringspolicyer v 0.9 (a.k.a. i stort sett klart) Open Source-komponenter tillgängliga* Kan föra dialog med Digg* | Sätta upp TEST-driftsmiljö.* Installation av OS-komponenter i lokal TEST-miljö* | Konfiguration av OS-komponenter i TEST-miljö* | Initiala systemtester* | Trust Anchor i SBX inställd enligt federationsreglerna för SIB och BAS-kontexten | Gemensamma tester med Digg* Färdigställa konfiguration* | Registrera registreraoch publicera metadata för VOK-komponenterna ("självhost:ad") konnektivitetstestKonnektivitetstest | Vara redo att genomföra verifiering av primära användningsfallen i testmiljö | genomföra Genomföra gemensamma tester | Produktionssättning Avser detta att alla komponenter ska vara färdiga i TEST??? | Jul | |||||||||||||||||||||||||||
Regelverk och avtal | Tekniska säkerhetskrav på en intermediate lämnade för synpunkter till anslutningsoperatörer | Avtalsutkast (inkl. villkor och policys) skickade på remiss | Utvärdera hur avtal ska vara utformade för att passa befintlig kundavtalsstruktur så väl som ägaruppdrag | Remissvar lämnade | Remissynpunkter omhändertagna | Omhänderta detaljfrågor och förbereda för avtalstecknade | Fed.op → Ansl.op → Fed.m har tecknat pilotavtal för att kunna genomföra i produktion | Jul | |||||||||||||||||||||||||||||||
| Beroenden som måste hanteras | Inskickade konkreta frågeställningar om Open Sopurce-komponenter till Digg | Möte för att stödja implementering av open source-komponenter | |||||||||||||||||||||||||||||||||||||
1. Syfte och avgränsning
Detta dokument samlar konkreta aktiviteter, tidplan, förutsättningar och risker per aktör för genomförande av Pilot VOK (Extern API-säkerhet för VOK) inom ramen för Federationskontext BAS, Steg 1 (MVP – maskin-till-maskin, systemidentitet).
Dokumentet utgör ett gemensamt planeringsunderlag för samtliga pilotaktörer och förvaltas löpande. Varje aktör ansvarar för att hålla sin del uppdaterad.
1.1 Pilotens mål
Verifiera att SIB:s federationsinfrastruktur fungerar i produktion genom att genomföra ett end-to-end-flöde där NVF (hos EHM) hämtar data från VOK via externt FHIR-API med åtkomstintyg verifierat via federationsinfrastrukturen. Piloten ska testa hela kedjan: avtal, anslutningsprocess, organisationsverifiering, teknisk registrering och det faktiska anropet.
1.2 Deltagande aktörer och roller
...
1.3 Scope – Steg 1 (MVP)
Piloten omfattar steg 1 i Taktisk färdplan vilket inkl. systemidentitet och organisationstillhörighet. Det innebär att VOK kan säkerställa identitet på anropande organisation och dess registrerade komponent.
2. Övergripande tidram
...
| Jul | |||||||||||||||||||||||||||||||||||||
| Utvärdering | Jul | ||||||||||||||||||||||||||||||||||||
| Planera utvärdering | Genomföra utvärdering | Jul | |||||||||||||||||||||||||||||||||||
Öppna frågor
| # | Fråga | Förslag / Hypotes | Ansvarig/hanteras av | Beslut senast | Status |
|---|---|---|---|---|---|
| Q1 | Testmiljö eller produktion, vad är minimal acceptabel pilotleverans om produktion inte är möjlig för alla parter? | End-to-end i testmiljö är minimum; produktion är ambition. | v22 (innan remiss) | Att besluta | |
| Q2 | HSM-krav för intermediate-komponenter, vilken nivå kravställs? | Ställningstagande för produktion behöver landa i tekniska säkerhetskrav. | Team Teknik (ordinarie samverkan) | v20–22 | Att besluta |
| Q3 | Hostad metadata, ska både hostad och egenpublicerad metadata prövas? | Ja, för breddat lärande. Påverkar konfiguration och test. | v20 | Att besvara | |
| Q4 | Vem är anslutningsoperatör i piloten, Inera, Internetstiftelsen eller båda? | Styr avtalsarbete och teknisk koordinering. | v20 (24 april) | Att besluta | |
| Q5 | Definition of done, vilka användningsfall är obligatoriska, vilka är nice to have? | Grunderna obligatoriska; incident- och lasttest nice to have. | v22 |
...
3. Aktiviteter per aktör
Varje aktör fyller i sina aktiviteter enligt strukturen nedan. Kolumnen Status uppdateras löpande.
Statusvärden: Ej påbörjad | Pågår | Blockerad | Klar
3.1 Digg – Federationsoperatör och Ledningsaktör
3.1.1 Teknisk infrastruktur
...
Uppsättning av Trust Anchor för Federationskontext BAS.
Nyckelceremoni genomförs tillsammans med Sweden Connect-ceremoni.
...
3.1.2 Normativt ramverk och avtal
...
3.1.3 Process och anslutning
...
3.1.4 Förutsättningar från Diggs sida
- Nuvarande nyckelpersoner (Henrik, Per, Team 401) är tillgängliga genom perioden. Sommarbemanning är en identifierad sårbarhet.
- Sunet-drift fungerar och kostnadsavtal är på plats.
3.2 Inera – Anslutningsoperatör
Denna sektion fylls i av Inera.
3.2.1 Teknisk infrastruktur
...
Känd signal: Inera har indikerat att produktion troligen ej är möjlig 2026, men test kan genomföras. Konsekvenserna av detta behöver diskuteras – se avsnitt 5 (Öppna frågor).
3.2.2 Normativt och avtal
...
3.2.3 Process och anslutning
...
3.2.5 Förutsättningar från Ineras sida
Fylls i av Inera.
3.3 Internetstiftelsen – Anslutningsoperatör
Denna sektion fylls i av Internetstiftelsen.
3.3.1 Teknisk infrastruktur
...
3.3.2 Normativt och avtal
...
3.3.3 Roll i piloten
...
3.3.4 Förutsättningar från Internetstiftelsens sida
Fylls i av Internetstiftelsen.
3.4 E-hälsomyndigheten – Federationsmedlem och API-ägare
Denna sektion fylls i av EHM.
3.4.1 Teknisk infrastruktur
...
3.4.2 Normativt och avtal
...
3.4.3 Process och anslutning
...
3.4.5 Förutsättningar från EHM:s sida
Fylls i av EHM.
4. Risker och beroenden
...
5. Öppna frågor
| Fråga | Kontext | Förslag/Hypotes | Ev. Beslut | Datum | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Vem är AO i piloten? | Att besluta | EHM:s formella åtagande? | Uppgiftskyldighet ej i kraft. Behövs formellt åtagande att resurser allokeras? | Ja. Utan tydligt åtagande riskerar piloten att stanna vid planering. | Att besluta | EHMs entiteter | Ska anslutningsoperatören host:a federationsmedlemmens metadata eller ska EHM publicera det självständigt? | Önskvärt om vi hade både och för att öka bredden på lärande av metoder (särskilt kring hosting-metoden) hur det kan fungera - | Att besvara | Definition of done? | Vad räknas som en genomförd pilot? | Att besluta |