Återkoppling på leverantörernas synpunkter i enkät


På leverantörsmötet 25/6 2019 ställdes flera frågor till leverantörerna som deltog i en enkät via Mentimeter som input till den Behovs- och marknadsanalys som SKL Kommentus Inköpscentral (SKI) genomför avseende ev. nationellt ramavtal för tjänster kopplade till Säker digital kommunikation. För vissa enkätfrågor hade leverantörerna möjlighet att lämna svar i fritext. För att ta del av de frågor och svar som enkäten omfattade och resulterade i, läs SDK - Frågor till och svar från leverantörer 190625.

Som återkoppling på de svar och synpunkter som inkom kopplat till respektive enkätfråga där leverantörerna kunde lämna fritextsvar har SDK-projektet och SKI bemött dessa i nedan tabell.



Frågeställning/kommentar via MentimeterSvar från SDK-projektet och SKI 
1

Fråga som ställdes till leverantörer i enkäten:

Vad är viktigt att tänka på avseende integrationsmöjligheter för Meddelandetjänsten mot andra system ex. mot e-post el. verksamhetssystem?

Inkomna svar/synpunkter från leverantörer avseende ovan fråga sammanställs och besvaras under nedan numrerade rader 2-6.

SDK-projektet önskar lyfta fram följande avseende integrationsmöjligheter kopplat till respektive lager:

Block1: Transportlager – Accesspunkt (Infrastruktur)

  • Anslutande part behöver etablera en anslutningspunkt till SDK-nätverket. Anslutningspunkten kallas ”Accesspunkt” och är en standardmjukvara som godkänts enligt CEF eDelivery och som används för att skicka och ta emot meddelanden inom SDK-nätverket.
  • Accesspunkter har interna API:er som möjliggör att hämta/lämna meddelanden, kontrollera meddelandestatus m.m.
    • Interna API används för att integrera mot Meddelandelager/Meddelandetjänst.

Block2: Meddelandelager/Meddelandetjänst (Integration)

  • Organisationen behöver ta fram en komponent som kallas meddelandelager eller meddelandetjänst. Meddelandetjänsten skulle kunna beskrivas som en integrationsmotor som löpande hämtar och lämnar meddelanden mot accesspunkten (via dess interna API:er. SOAP eller REST).
  • Meddelandetjänsten hanterar följande: 
    • Validera och kvittera SDK-meddelanden, dvs. kontrollera att meddelandet följer SDK:s schema och regelverk för meddelandehantering.
    • Kontrollera att angiven funktionsadress är korrekt och aktiv.
    • Skapa ett kvittensmeddelande (även felmeddelanden om en icke aktiv funktionsadress har angivits).
    • "Routa" meddelanden till det system (Meddelandeklient) som ansvarar för funktionsadressen.
    • Svarstidsbevaka sända meddelanden, dvs. bevaka att ett skickat meddelande kvitteras av mottagaren.

Block3: Meddelandeklient eller Verksamhetssystem

  • Organisationen behöver/bör ansluta minst ett verksamhetssystem eller en meddelandeklient. Dessa är de system som slutanvändare (personal) använder för att skapa och läsa SDK-meddelanden, t.ex. Office 365.
2
  • Standardisera
  • Standardkontrakt
  • Använda sig av redan etablerade standarder.
  • Följa standarder. Inte lokala anpassningar. Svensk marknad är för liten för att skapa ekonomisk bärkraft för en hög kostnadseffektivitet.
  • Inte egna lösningar utan standard

Standardisering finns i alla lagren av SDK som eDelivery-tillämpning: 

  • Ej standardiserat utöver SDK Innehållsspecifikation: Meddelandevalidering och kvittering

Meddelandeklient/Verksamhetssystem:

Transportlager (CEF eDelivery Accesspunkt)

Medddelandelager (integrationskomponent, tekniskt ramverk)

  • Formatet för det meddelande som skickas mellan organisationer (SDK Innehållsspecifikationer) är baserat på Ineras tekniska ramverk RIV-TA (Regelverk för interoperabilitet i vård och omsorg - Tekniska anvisningar): RIV Tekniska Anvisningar Översikt
  • Projektet har även tagit fram principer för meddelandehantering (validering, kvittens, felhantering) 

Payload (nyttolast: Meddelande)

  • Själva SDK-meddelandet är framtaget av SDK-projektet i samverkan med kommuner, regioner och statliga myndigheter i projektets referensgrupper, och är i dag ett proprietärt format. Se även nedan, punkt 5. 
  • SDK-formatet har dock inspirerats av det danska MeMo-formatet som också är ett meddelandeformat för ostrukturerat innehåll.
3Måste kunna nå privata personers e-mailadress med 2-vägs meddelanden. Samt att meddelandet ska kunna initieras utifrån.

Kommunikation med privatpersoner ingår ej i projektets uppdrag. Se tidigare svar i FAQ Leverantörsmarknad.

4Ett väl specificerat API för verksamhetssystemSDK-projektet har inte tagit fram en API-specifikation för verksamhetssystem. Dock finns SDK innehållsspecifikationer för meddelande respektive kvittens som organisationens verksamhetssystem och meddelandeklienter som ska kunna skicka och ta emot SDK-meddelanden måste förhålla sig till (kunna konsumera och producera). Se även kommentarer till punkt 1 och 2.
5Klar standard för payload, så att mottagande part verkligen kan läsa

SDK-projektet har tagit fram Innehållsspecifikationer för meddelande och kvittenser som beskriver hur payload ska hanteras.

  • Dokumentation (specifikation)
  • xml schema (XSD)
  • Valideringsskript (schematron)

Dessa publiceras på SDK-projektets öppna sida i Confluence: Teknisk dokumentation och specifikationer

Här finns även en /wiki/spaces/SDK/pages/39256594 avsnitt "3. Teknisk dokumentation och specifikationer"

6Kunna hantera flera format och externa kontakter

Format:

  • SDK tillåter idag endast ett meddelandeformat (dokumenttyp) för ostrukturerat innehåll. Infrastrukturen (eDelivery) kan dock hantera olika format (dokumenttyper), och i framtiden är det tänkbart att SDK skulle kunna hantera fler dokumenttyper för t.ex. strukturerat innehåll. 

Kontakter:

  • SDK Adressbok innehåller användarorganisationer och funktioner inom dessa som är godkända enligt SDKs tillitsramverk och som är anslutna till SDK. En användarorganisation kan i Adressboken söka på information om andra anslutna organisationer.  
7

Fråga som ställdes till leverantörer i enkäten: Vilka förutsättningar ser ni måste vara tillgodosedda vid projektets överlämning innan SDK kan "flyga" dvs. erbjudas och användas fullt ut i Sverige?

Inkomna svar/synpunkter från leverantörer avseende ovan fråga sammanställs och besvaras under nedan numrerade rader 8-18.

8

Ägarskap och förvaltning klarlagd. Support för anslutning mot SDK infrastruktur.

Tydliga ramverk för certifikat, tillit och teknik med ansvarsfördelning klargjord för olika ansvarsgränser mellan ex accesspunkt, meddelandetjänst och meddelandeklient.

Ägarskap:

  • Inera är projektägare för SDK och SDK-federationsoperatör under pilottester 2019. Inera kommer fortsatt att ansvara för Säker digital kommunikation under fortsatt projektår 2020 och säkrar även för kommuner och regioner förvaltning av framtaget resultat därefter.

Tillitsramverk:

  • SDKs tillitsramverk för användarorganisationer anger hur certifikat och tillit ska hanteras, Befintligt tillitsramverk togs fram 2018 och enligt detta godkänns följande certifikatsutfärdare: SITHS/EFOS, Myndighets CA (MCA) samt CA godkända av Microsoft Trusted Root Certificate Program: /wiki/spaces/SDK/pages/4032755 
  • Under 2019 kommer en mindre uppdatering av it-säkerhetsbilagan göras för att stödja årets pilotverksamhet.  
  • Under 2019 verifierar SDK-projektet följande certifikat i SDK Testbädd: SITHS eID, EFOS samt GlobalSign. Pilotaktörerna kan välja mellan SITHS eID samt någon av Microsofts CA som uppfyller kraven.
  • Fortsatt arbete kan behövas i kommande projektetapp ang. ansvarsfördelning. 
9Erbjuda en testbädd även i framtiden. Ramavtal. En framtida förvaltning av  resultatet.

Testbädd:

  • SDK Testbädd är en del av anslutningsprocessen till SDK och kommer att finnas kvar även i framtiden. Här är en beskrivning av avsedd användning med bl.a. testbädden: Avsedd användning med SDK Testbädd

Ramavtal: 

SKL Kommentus genomför under 2019 en behovs- och marknadsanalys ang. ev. ramavtal för tjänster relaterat till SDK. 

Förvaltning: 

Se kommentar i punkt 8.

10En pappersfri process. En internationellt skalbar profilering.

Pappersfri process:

  • För närvarande och för att stödja årets pilotverksamhet, finns ett antal dokument/mallar som anslutande part hanterar i anslutningsprocessen till SDK och med SDK-federationsoperatör: Anslutningsprocess
  • Ett self service-koncept kommer förhoppningsvis utvecklas under 2020.

Profilering:

11Bortsett från tekniska krav, behövs incitament för offentlig sektor att investera i sdkSDK-projektet drivs som ett svar på de stora behov som finns inom offentlig sektor att kunna utbyta känslig information digitalt och säkert mellan organisationer. SDK bygger på eDelivery som ramverk, vilket offentlig sektor redan investerar föranlett av bl.a. efaktura-direktivet och anslutning till PEPPOL. 
12Att gå igenom flera "use case" då SDK idag inte uppfyller behovet fullt ut

SDK är i dagsläget framtaget för att möjliggöra säker överföring av ostrukturerat innehåll via meddelanden. Tidigare behovsanalyser som genomförts av bl.a. SKL har visat att det finns många olika verksamhetsprocesser hos offentliga aktörer och privata utförare av offentligt uppdrag där det finns sådana behov. Det är upp till anslutande användarorganisation att exponera funktioner hos sig (göra det möjligt att skicka/ta emot till funktionsadresser) för att stödja olika verksamhetsprocesser. 

Samtidigt finns begränsningar i målgrupp och meddelandeformat (dokumenttyp) som man ska vara medveten om. Se även punkt 3 och 6. 

13Alla referensdokument (och) innehållande standarder måste vara i "släppta versioner". Hur får vi användarorganisationer att ta initiativ till att implementera detta från respektive applikation/system

Referensdokument

  • SDK baseras på CEFs standard eDelivery, där dokumentation publiceras och utvecklas löpande. Se även punkt 2.
  • SDKs specifikationer tas fram enligt en fastställd arbetsprocess för versionshantering och publicering av dokumentation: Versionshantering och publicering av dokumentation
  • Projektet kommer att lämna över specifikationerna till kommande förvaltning för fortsatt versionshantering och publicering. 
14Leverantörer som anslutit sig

Projektet publicerar och uppdaterar en sammanställning av leverantörer som har visat intresse att följa projektet och delta i leverantörsmöten: Leverantörslista.

  • Under etapp 2019 kan leverantörer tillsammans med pilotorganisationer anslutas till SDK Testbädd och genomföra tekniska tester.
  • Under 2020 planeras Testbädden öppnas för ytterligare tekniska piloter.
  • Fortsatt arbete är även tänkt att göras för att möjliggöra för leverantörer att göra en självständig anslutning inför breddinförande.
15Interoperabilitet med standarder för e-post och S/MIME samt Rights Management Services m.fl. för att säkerställa att användare inte går utanför lösningen i externa scenarion och mot innevånare/kunder etc. Även färdiga katalogintegrationstjänster.

Interoperabilitet:

  • Interoperabilitet mellan användarorganisationer baseras på CEF eDelivery. Specifik implementation av meddelandetjänst och meddelandeklient ligger utanför projektets scope, utan detta är frågor som respektive användarorganisation behöver genomföra. Se punkt 1.

Katalogtjänster:

  • En gemensam SDK Adressbok tas fram under 2019. I den ska information om anslutna användarorganisationer och funktioner inom dessa finnas. Adressboken administreras via grafiskt gränssnitt under pilotfasen, dvs. användarorganisationers administratörer får tillgång till och kan skapa och ändra sina adressuppgifter i adressboken. I fortsatt arbete planeras även en version av SDK Adressbok med stöd för synkroniserings-API från lokala kataloger hos användarorganisationer.
  • Här är en beskrivning av avsedd användning med SDK Adressbok: Avsedd användning med SDK Testbädd

Behörighet (Rights Management):

  • Det åligger varje ansluten användarorganisation att säkerställa att endast behöriga användare har åtkomst till SDK och kan ta del av information som utbyts via SDK. Detta regleras i SDKs Tillitsramverk för användarorganisationer med tillhörande it-säkerhetsbilaga. Se punkt 8.
16Bra dokumentation och flera (kod)implementationsexempel. Bra teknisk supportorganisation

Dokumentation:

Support: 

SDK-projektet och Inera ansvarar för förvaltning och support tills dess att resultatet överlämnas till stadigvarande förvaltning.

17ett bra och öppet api som är väl dokumenteratSe punkt 4, 5, 13. 16.
18Enkel dokumentation till kommuner som ej har resurser

SDK-projektet har hittills tagit fram beskrivningar i syfte att stödja olika intressenter och målgrupper. Bl.a. Avsedd användning med SDK, pilotverksamhet 2019, dokumentation och specifikationer. Se punkt 16.

En enkel checklista för vad man som intressent kan börja arbeta med och vilka olika aspekter som finns vid införande, finns på inera.se: https://www.inera.se/projekt/saker-digital-kommunikation/

Därutöver finns önskemål om ytterligare dokumentation till bl.a. mindre aktörer som ej har så mycket resurser när det gäller vad som behövs inför införande mm, vilket planeras för 2020.  

19

Fråga som ställdes till leverantörer i enkäten: Vilka områden är idag tydliga kring SDK?

Inkomna svar/synpunkter från leverantörer avseende ovan fråga sammanställs och besvaras under nedan numrerade rader 20-21.

20Att det är standard baserat. En hel del integration för integratörer.

Se punkt 1, 2, 5, 15.

21Den tekniska ursprungsspecifikationen, eDelivery. Avstegen/anpassningarna till tjänstens förhållanden. Protokollbegränsningar. Låg interoperabilitet.

SDK tillämpar CEF eDelivery (AS4), vilket innebär att CEF-certifierade accesspunkter kan anslutas till SDK-nätverket utan anpassning.

Se punkt 1, 2, 5 angående SDKs kompletteringar utöver eDelivery.


22

Fråga som ställdes till leverantörer i enkäten: Vilka områden är idag otydliga kring SDK?

Inkomna svar/synpunkter från leverantörer avseende ovan fråga sammanställs och besvaras under nedan numrerade rader 23-26.

23Hur ska privata personer och enskilda företag inkluderas?

Kommunikation med privatpersoner ingår inte SDKs scope/målgrupp. För detta finns det andra etablerade kommunikationskanaler.

Privata företag som är utförare med offentligt uppdrag ingår i SDKs målgrupp. 

24Vilken marknad finns. Gärna lite praktiska "use case".

Se punkt 11, 12. 

  • Under 2019 genomförs tekniska piloter med följande organisationer Pilotaktörer.
  • Under 2020 planeras ytterligare tekniska pilottester och verksamhetspiloter.  
  • Under 2020 planeras breddinförande och SDK ska då vara tillgängligt och möjligt att ansluta till för kommuner, regioner, statliga myndigheter och privata utförare av offentligt uppdrag. 
25Status på testmiljöer

SDKs testmiljö (SDK Testbädd) är tillgänglig för pilotorganisationer att ansluta till för genomförande av årets pilottester. Testbädden kommer även att finnas tillgänglig i framtiden. Se även punkt 9.

26Syfte och mål, ekonomiska följder och beräkningar, framtida standardisering. Varför inte återanvända befintliga etablerade kommunikationssätt, hur har detta utretts?

Se punkt 11, 12. Säker digital kommunikation (SDK) skapar förutsättningar för enkel, säker och enhetlig hantering av känslig information. Det gäller information som utbyts mellan verksamheter inom offentlig sektor inom till exempel vård, socialtjänst och skola.

Mer om projektet och bakgrunden finns bl.a. här: