Vanliga frågor och svar

Sök bland våra vanliga frågor och svar.

Search

Tips om andra sidor för frågor och svar

Frågor och svar utifrån mer teknisk karaktär hittar du på denna sida.

Frågor och svar om SDK Öppen testmiljö för tjänsteleverantörer (SDK ÖTM) finns på denna sida

 

Vad är SDK?

Här hittar du frågor och svar om tjänsten och hur den är tänkt att användas.

Fråga

Svar

Fråga

Svar

Vilka slags användningsområden är det tänkt att SDK ska kunna tillämpas inom?

Täcks även säkra digitala möten?

SDK kan användas inom många olika verksamhetsområden där det finns behov av att kunna utbyta känslig information med andra organisationer via säkra digitala meddelanden. Tjänsten omfattar inte säkra digitala möten. Här finns mer detaljerad information om Säker digital kommunikations avsedda användning.

Ofta handlar det om sekretessklassad information som utbyts inom till exempel arbetsmarknad, socialtjänst och hälso- och sjukvård. Det kan handla om vårdplaner, behandlingsplaner, bedömningar av arbetsförmåga och utdrag ur belastningsregistret.

Går det att skicka säkerhetsklassad dokumentation kopplat till t.ex. upphandling via SDK?

Dokument eller information som är klassad med högre känslighetsgrad än konsekvensnivå allvarlig enligt MSBs modell, alltså kopplat till rikets säkerhet, ska inte skickas via SDK.

Exempel på information som SDK är tänkt att kunna användas för och som regleras enligt:

  • OSL – Offentlighets- och sekretesslagen ​

  • PDL – Patientdatalagen​

  • GDPR – Dataskyddsförordningen (The General Data Protection Regulation)​

  • SoLPUL – Lag (2001:454) om behandling av personuppgifter inom socialtjänsten​

Däremot inte information som lyder under säkerhetsskyddslagen.

Stöder SDK intern meddelandeöverförning?

Anslutna organisationer kan använda SDK för att skicka meddelande internt inom organisationen om så önskas. Bra att ha i åtanke då är att de funktionsadresser som används även är synliga och ska kunna ta emot meddelanden från externa parter.

Är tanken att datan ska stanna hos DIGG eller Inera den tiden som det tar för mottagaren att öppna sitt meddelande?

Datan "stannar inte" hos vare sig DIGG eller Inera, eftersom överföringen sker direkt från avsändande organisations accesspunkt till mottagande organisations accesspunkt. eDelivery och SDK är en s.k. fyrhörningsmodell.

Däremot behöver gemensamma tjänster hos Inera och DIGG fungera:

  • SDK Adressbok (hos Inera) för att kunna hitta mottagande organisations funktionsadress

  • SMP och SML (hos DIGG) för att lokalisera mottagande organisations accesspunkt.

Vilka filformat stöds i tjänsten och hur stora informationsmängder går det att skicka?

Finns det planer på att kunna skicka andra filformat framöver?

För närvarande stödjer SDKs specifikationer bilagor med filformatet PDF. Det finns en gräns på 30 MB storlek för ett SDK-meddelande inkl. bilagor.

Gränsen 30 MB är satt för att säkerställa att alla parter kan hantera de meddelanden filen. Nivån togs fram tillsammans med SDK-projektets referensgrupper under SDK-projektets gång.

När de gäller storlek på informationsmängderna, kan eDelivery, som SDK bygger på, hantera större filer och DIGG kravställer att en Accesspunktsoperatör ska kunna hantera 100 MB. Det går alltså att öka på storleken på SDK-meddelanden i fortsatt utveckling av tjänsten, och i takt med användarorganisationers behov och förutsättningar att hantera större meddelanden och bilagor.

När det gäller filformat, har formatet PDF valts pga. att det är arkivbeständigt och för att det minskar risken för överföring av skadlig kod jämfört med t ex. Word och Excel. Vissa av SDKs tidigare pilotorganisationer och referensgrupper har framfört behov av att stödja fler filformat t.ex. Word eller Excel. Andra menar att man i dagsläget inte har behov och att problemet med att använda andra format än PDF är arkivbeständighet. Det är möjligt att framöver vidareutveckla SDKs dokumenttyp/meddelandeformat för att stödja fler filformat i takt med användarorganisationers behov och förutsättningar.

Om en myndighet vill skicka fler än ett dokument till en myndighet, hur hålls/paketeras dessa dokument ihop så att det dels framgår att de hålls ihop och dels kommer in till mottagande myndighet samtidigt?

Storleksbegränsningen på 30 MB är det per dokument eller per ”paket” av dokument, se frågan ovan?

Ja, det går att skicka flera dokument (bilagor i samma meddelande). Detta beskrivs i den tekniska specifikationen ”SDK Innehållsspecifikation- Meddelande”. Ett meddelande kan innehålla 0..* bifogade filer.

Storleksbegränsningen om 30 MB gäller hela meddelandet, dvs både innehåll och bilagor. Begränsningen gäller själva meddelandetypen SDK-meddelande, men inte transportinfrastrukturen. Begränsningen är satt för att alla parter ska kunna hantera denna typ av meddelanden. Det går i framtiden att utöka storleken.  Se även FAQ i övrigt.

Hur är det tänkt kring namnsättningen på det som skickas?

Namnsättning på filnivå finns ej definierat i SDK, eftersom det handlar om ostrukturerat informationsinnehåll i meddelandet. Dvs. man kan utbyta SDK-meddelanden inom många olika verksamhetsområden och med många olika bilagor.

I meddelanderubriken i SDK-meddelandet kan man komma överens om vad som skrivs i rubriken mellan sändare och mottagare om behov finns. 

För varje dokument som bifogas är det filnamnet som används som identifierare. 

Kan man skicka med sin egen referens (avsändarens referens) eller kan man bara ange mottagande myndighets referens t.ex. ett ärendenummer?

Ja, man kan ange bådas referens. Det finns fält för detta i SDK-meddelandet. Om en part anger sitt referensid, måste mottagande part skicka tillbaka det till sändaren. Mottagaren kan också skicka sitt referensid och ursprunglig sändare måste då visa det för sina användare. 

Detta fält är frivilligt att använda i befintliga SDK-meddelanden. I framtiden kan man bygga på med andra SDK-meddelandetyper där t.ex. fältet skulle kunna göras obligatoriskt.

Varje meddelande har även ett unikt ”tekniskt” meddelande-id, som parterna i sina SDK-lösningar kan välja att använda i sina interna system för att ha kontroll över meddelandeutbytet.

Detta beskrivs i specifikationen ”SDK Innehållsspecifikation- Meddelande”.

Kan man markera ett skick som brådskande?

Nej, i nuläget finns inget specifikt attribut (fält) för detta i SDK. Det går att ange t ex att något är “brådskande” genom att skriva det i ärenderubriken. 

Behov har lyfts tidigare av att kunna sätta prioritet men man behöver då också komma överens om ett gemensamt regelverk för hur prioritet sätts. Det går att ta fram nya meddelandetyper i SDK som stödjer ytterligare fält. 

Vem är huvudansvarig för SDK-tjänsten?

Inera ansvarar tills vidare för tjänsten SDK som federationsägare.

Vad är eDelivery och varför har det valts som grund för SDK?

Regeringen och SKR har träffat en överenskommelse om en gemensam ambition, som förenar kommuner, regioner och statliga myndigheter, att införa ett säkert, snabbt och enkelt sätt för digital kommunikation mellan välfärdens verksamheter. Initialt kommer Inera, som hittills drivit utvecklingsarbetet kring säker digital kommunikation, vara den aktör som tillhandahåller infrastrukturen. fram tills att DIGG tar över. DIGG har fått i uppdrag att ansvara för SDK- infrastrukturen från senast 29 september 2023.

Myndigheten för digital förvaltning (DIGG) ansvarar för och tillhandahåller Plattform för eDelivery i Sverige. Plattform för eDelivery omfattar gemensamma komponenter, regelverk och specifikationer som tillhandahålls för accesspunktsoperatörers och deltagares anslutning till Plattform för eDelivery. Du kan läsa mer om eDelivery på DIGGs hemsida .

eDelivery är en rekommenderad arkitektur från EU för säker asynkron kommunikation som är baserad på internationella standarder och är väl beprövade i storskaliga implementationer. Arkitekturen är väl anpassad för den typ av integration som SDK behöver och eDelivery stödjer säker robust överföring av dokument och data på ett standardiserat och säkert sätt och följer en s.k. fyrhörningsmodell. Genom att använda eDelivery skapas förutsättningar för att på sikt knyta ihop lösningar över gränser. Arkitekturen är framtagen för att vara skalbar och ge möjlighet att bygga lösningar som kan konkurrensutsättas och ersättas över tiden.

Transportkvittenser: sådana ska skickas när ett meddelande har kommit till mottagande användarorganisations accesspunkt. Har man pratat om och är alla införstådda i att en sådan kvittens inte är att likställa med att handlingen anses som inkommen?  

Det finns två olika ”tekniska” kvittenser i SDK. 1) När mottagande organisations accesspunkt har tagit emot sändande organisations meddelande. 2) När mottagande användarorganisations meddelandetjänst har dekrypterat meddelandet. Detta liknar t.ex. hur Spridnings- och hämtningssystemet, SHS, fungerar.

Verksamhetsmässigt behöver mottagande organisations användare / system skicka ett nytt SDK-meddelande som ”svar” till sändande organisation. 

Se även fråga och svar under informationssäkerhet när en handling anses som utlämnad respektive inkommen vid meddelandeöverföring i SDK.

Varför bygger man inte ett klientkoncept centralt, varför innehåller t.ex. inte SDK även en tjänst (meddelandeklient) för användarna? 

SKR/Inera beslutade tidigt att inte ta fram lösningar eller produkter där det finns en leverantörsmarknad, vilket är fallet när det gäller meddelandeklienter. Dessa kan vara både i form av fristående produkter/lösningar eller integrerat i olika verksamhetssystem. Bland de leverantörer som följde det tidigare SDK-projektet fanns det såvitt vi vet flera leverantörer som erbjuder den typen av lösningar. 

SDK är en transportinfrastruktur för meddelandekommunikation och tillhandahåller inte lokala verktyg eller klientlösningar. De gemensamma delar som ingår i SDK-konceptet är SDK Testklient som finns i SDK Testbädd (QA), och som simulerar en meddelandeklient som ett testverktyg för att verifiera din organisations anslutning. Därutöver bygger eDelivery och SDK på att det finns både kommersiella lösningar och organisationer som själva vill utveckla egna lösningar, vilket SDK projektets tidigare pilotorganisationer har visat på. En del av de tidigare pilotorganisationerna (regioner och kommuner) valde att anskaffa/köpa en färdig klient och andra pilotorganisationer (framförallt större organisationer) valde att utveckla en egen klient.

Tjänsten ”Säkra meddelanden” används av vissa organisationer för att skicka meddelanden till enskilda individer. Kommer SDK tillåta utskick till en icke-ansluten SDK brevlåda t.ex. individer (för att undvika flera meddelandetjänster i en organisation)?

Nej, SDK är en federation vilket innebär att endast de organisationer som är anslutna till SDK kan skicka meddelanden till och från varandra. De meddelanden som skickas via SDK adresseras till och från funktionsbrevlådor som registreras i tjänstens adressbok.

Vad är skillnaden mellan SDK och säker e-post som t.ex. domstolarna och Allmänna reklamationsnämnden använder?

SDK är en gemensam tjänst som ska kunna användas av många olika organisationer och som bygger på gemensamt regelverk, gemensamma specifikationer och gemensamt sätt att hitta och adressera varandra via en gemensam adresskälla (SDK Adressbok). Respektive organisation kan använda befintliga eller anskaffa nya lösningar för t.ex. säker e-post om dessa är anpassade till SDK och organisationen är ansluten till SDK-federationen hos Inera.

Vad är PROD?

SDK PROD är SDKs gemensamma produktionsmiljö där anslutna användarorganisationer kan skicka meddelanden till och från varandra.

Målgrupp

Här hittar du frågor och svar om vilka målgrupper SDK är tänkt för.

Fråga

Svar

Fråga

Svar

Vilka organisationer kan ansluta till Säker digital kommunikation?

I nuläget kan kommuner, regioner och statliga myndigheter ansluta till Säker digital kommunikation. Ett arbete pågår för att göra det möjligt även för privata utförare med helt eller delvis offentligt finansierade uppdrag att ansluta till tjänsten.

Kan Säker digital kommunikation användas för intern kommunikation inom den egna organisationen, eller avser tjänsten enbart kommunikation mellan organisationer?

SDK kan användas för kommunikation mellan de organisationer som är anslutna till tjänsten. SDK kan även användas för kommunikation inom den egna organisationen. Bra att tänka på är att alla funktionsadresser som läggs upp i SDK Adressbok blir sökbara samt möjliga att skicka till för samtliga andra ansluta organisationer.

Kan man skicka meddelanden till privatpersoner via SDK?

Nej, SDK är en federation för organisationer, inte privatpersoner. Det innebär att endast anslutna organisationer kan kommunicera med varandra. De meddelanden som skickas via SDK adresseras till och från funktionsbrevlådor hos organisationerna och som registreras i tjänstens adressbok.

Hur fungerar anslutningen till SDK för kommunförbund och kommunalförbund?

Kommunalförbund kan ansluta till SDK i egenskap av juridisk organisation medan Kommunförbund är en intresseorganisation och därmed är det respektive kommun som behöver ansluta.

Införande och anslutningsprocess

Här hittar du frågor, svar, tips och råd om anslutning till SDK.

Fråga

Svar

Fråga

Svar

Hur beställer vi Säker digital kommunikation?

Kommuner och regioner har redan avtal med Inera och kan därmed beställa tjänsten direkt via Ineras Kundportal. Observera att det är organisationens behöriga beställare som behöver göra själva beställningen. I beställningen kan ni ange vem/vilka som ska vara kontaktpersoner för just SDK.

Myndigheter och så småningom privata utförare med offentligt finansierade uppdrag behöver först skriva avtal med Inera. Ni hittar mer information om Ineras kundavtal här.

Hur ändrar jag min organisations kontaktperson för anslutning till SDK?

Kontaktperson för anslutning är den eller de personer som är behöriga att skicka in anslutningsblanketter och självdeklaration för tjänsten till Inera. Den eller dessa personer anges av din organisation i samband med att din organisation beställer tjänsten.

För att ändra vem eller vilka personer ni har uppgett som “Kontaktperson för anslutning” ska detta Formulär fyllas i och skickas in till Inera.

Behörig att skicka in formuläret är befintlig kontaktperson/er för anslutning eller den person i er organisation som är behörig beställare i Ineras Kundportal.

Vad behöver vi tänka på innan vi beställer Säker digital kommunikation?

För kommuner har Inera tagit fram stödjande material i form av ett introduktionsmaterial samt en vägledning som syftar till att ge konkret stöd till en kommun som vill ansluta till Säker digital kommunikation (SDK). Vägledningen vänder sig främst till beslutsfattare och verksamheter, samt eventuella projekt/uppdragsledare och -ägare eller dylikt som håller ihop arbetet med SDK-resan för kommunen.  

Även andra organisationer än kommuner som planerar att införa SDK rekommenderas att ta del av det stödjande materialet. Materialet finns här:

Behöver organisationerna teckna avtal med Inera eller räcker det att leverantörerna gör det?

För att leva upp till säkerhetstänket med en federation måste kommuner, regioner och myndigheter själva teckna avtal med Inera.

Hur mycket och vilka resurser krävs på hemmaplan för att införa SDK? Hur mycket kostar anslutning i hårdvara och arbetsinsats?

När det gäller lokala resurser (it-miljöer och egna it-stöd mm.) så varierar dessa beroende på om man väljer att göra egen utveckling eller anlita leverantör, samt även beroende på hur stor del av organisationen som ska kunna använda SDK och behöver t.ex. meddelandeklienter.

Ett exempel från en pilotkommun under SDK projektet 2020: Räkna med årskostnad för 2 servers, licenskostnader för programvara, konsultkostnader för anslutning om en extern leverantör används. Totalt lade kommuner cirka 250 timmars arbetsinsats under SDK-piloten 2020 - ett breddinförande tar antagligen mycket mer resurser än så.

Ta gärna del av SDK-piloternas erfarenheter kring just detta. Vi har sammanställt en gemensamt pilotrapport från projektet Säker digital kommunikation 2021 - Q1 2022, där piloterna bland annat svarat på frågor om detta. Pilotrapporten inkl. en detaljerad bilaga här: https://inera.atlassian.net/wiki/spaces/OISDK/pages/2667577732

Vad kostar det att beställa Säker digital kommunikation?

För aktuell information om pris för tjänsten, se priser för Ineras tjänster på Ineras hemsida.

Anslutande organisationer står själva för kostnader i den egna verksamheten (t.ex. utveckling av de egna it-stöden) som föranleds av en anslutning till infrastrukturen för Säker digital kommunikation. Kostnader för lokala resurser varierar beroende på om man väljer att göra egen utveckling eller anlita leverantör, samt även beroende på hur stor del av organisationen som ska kunna använda SDK och som t.ex. behöver meddelandeklienter. I pilotrapporterna från Projektet Säker digital kommunikation 2020 och 2021/Q1 2022 finns erfarenheter från pilotaktörer vad gäller kostnader som är förknippade till anslutning och införande av Säker digital kommunikation.

Hur lång tid bör en organisation räkna med vid införandet av SDK?

Hela anslutningsprocessen och tid för införandet varierar bland annat beroende på vilka typ av tekniska beslut som tas SDK, hur mycker resurser som läggs i projektet och storleken på organisationen. Det som kan räknas in utöver ovanstående är eventuella ledtider mellan de olika intressenterna, Inera, DIGG och eventuella leverantörer.

Vilka resurser och kompetenser behövs med avseende på att sätta upp de olika delarna vid införandet av SDK, verksamhet, informationssäkerhet och teknik?

En lokal projektledare som driver projektet och ser över vilka delar som inkluderas i arbetet och var det är bra att börja.

Inom teknik rekommenderas resurser med kunskap inom arkitektur och teknik. Utöver att undersöka vilka beslut som ska tas inom teknik, bör organisationen även se över integration och infrastruktur med övriga existerande system.

Ett informationssäkerhetsarbete krävs, där regelverk för SDK och existerande processer ses över. Det kan vara bra att jobba med kompetenser som kan utföra en dataklasskonsekvensbedömning och en informationssäkerhetsresa.

För verksamheter bör verksamhetskunniga vara med i arbetet med att identifiera verksamheter och informationsutbyten som SDK ska användas inom. Se över om det finns någon verksamhet som uttryckt behov av SDK, finns det någon verksamhetsutvecklare som kan delta i införandet.

Var ska man börja sin anslutningsprocess? Finns det några tips och tricks?

Det finns mycket information att läsa in sig på för att få en första överblick kring införnade av SDK:

  • Ta del av checklista för införande

  • Se på pilotrapporter

  • Gå med i SDK Samarbetsrum och ta del av tips och tricks från andra organisationer

  • Se över Vägledning för kommunerna

  • Ta del av Bruttolista för informationsutbyten

  • Se över workshop-material för att hjälpa till i identifieringen av nyttiga informationsutbyten att börja med

Kan vi vara accesspunktsoperatör så att vår egen IT kan hantera denna?

Ja, det kan ni vara. För att få mer information om vilka krav som ställs för att vara accesspunktsoperatör behöver ni kontakta DIGG och beställa deras informationspaket. Det gör ni via info@digg.se

När ska SDK vara klar och när bör kommuner ansluta sig då leverantörer är klara med lösningen?

Tjänsten Säker digital kommunikation är tillgänglig för anslutning sedan 1 mars 2022.

Det finns redan idag många kommuner, regioner och statliga myndigheter som har inlett sin anslutningsprocess. Flera av dessa har redan tagit hjälp av leverantörsmarknaden inom anpassning av anslutande system (lokalt IT-stöd) med  teknisk förmåga att ansluta till SDK och skicka SDK-meddelanden.

Det finns också ett stort antal organisationer som inte kommit lika långt och som utreder sina behov. De har ännu inte gjort sina tekniska vägval för att sedan gå vidare och anskaffa rätt IT-stöd för just deras organisations behov. Sannolikt kommer även dessa ha behov av en leverantörsmarknad som tillhandahåller hela eller delar av SDK-anpassade lösningar. 

Finns det en standard kring vilket protokoll som ska användas mellan MK och MT?

Standardiserat Meddelandeflöde/Meddelande:

SDK standardiserar meddelanden som förmedlas mellan komponenter (Accesspunkt (AP), Meddelandetjänst (MT) och Meddelandeklient (MK)). https://inera.atlassian.net/wiki/spaces/OISDK/pages/2810413057 beskriver i detalj hur ett meddelande skall vara utformat tekniskt samt innehållsmässigt.

Standardiserat API:

Det är inte standardiserat hur SDKs Meddelanden skall utbytas mellan interna komponenter.

  • AP-MT

  • MT-MK

Detta innebär att varje komponent behöver lösa sitt integrationsbehov utifrån den teknologi som passar bäst.

SDK kravställer att komponenter följer SDKs regelverk och specifikationer gällande teknisk säkerhet och informationssäkerhet.

Behovet av ett standardiserat API har framfört tidigare men är inget som vi just nu arbetar med.

Vi rekommenderar användarorganisationer att kravställa att leverantörens komponenter skall tillhandahålla ett öppet tillgängligt plattformsoberoende API som möjliggöra integration med olika leverantörers lösningar. Det ska inte finnas leverantörsspecifik krav som begränsar användarorganisationens möjlighet att ansluta eller byta komponenter (t.ex. AP, MT, MK).

Behöver man en speciell programvara - mejlklient för att kunna använda SDK? Är alla mejlklienter tillåtna?

En användarorganisation behöver tre komponenter för att ansluta till SDK-federationen

  • Accesspunkt

  • Meddelandetjänst

  • Meddelandeklient/Verksamhetssystem

Dessa komponenter behöver antingen utvecklas på egen hand eller anskaffas och anpassas för att fungera i SDK-federationen. Det innebär bl.a. att de ska följa de tekniska specifikationerna och även krav inom informationssäkerhet och it-säkerhet. DIGG specificerar och godkänner Accesspunkten, medan Inera godkänner en användarorganisations Meddelandetjänst och Meddelandeklient i samband med anslutning till SDK.

När det gäller val av Meddelandeklient, ställer SDK inte krav som begränsar vilka klienter som används men den behöver stödja de gemensamma regelverk som gäller i SDK-federationen.

Se även frågor och svar under leverantörsmarknad nedan, samt: https://inera.atlassian.net/wiki/spaces/OISDK/pages/2716565840

Går det att använda en Meddelandeklient till flera kommuner, till exempel kommunalförbund?

Ja det gör det, om kommunerna har tydliga avgränsningar kring vem som har tillgång till vilka funktionsbrevlåda.

SDKs regelverket reglerar inte direkt hur en användarorganisation organiserar sin IT-drift, leverantörer eller mjukvara (t.ex. MT, MK). En förutsättningar att regelverk och specifikationer följs.

Kortfattat kan man säga att en användarorganisation kan använda en eller flera valfria leverantörer som levererar, tillhandahåller och förvaltar IT-lösningar som t.ex. Accesspunkt (AP), Meddelandetjänst (MT) och Meddelandeklient(er) (MK) under förutsättning att regelverk och specifikationer följs.

Är det möjligt med integration mot befintliga e-postsystem?

Ja, olika Meddelandeklienter kan integreras lokalt. Det är användarorganisationen som beslutar vilka lokala meddelandeklienter som man vill använda för att ansluta till SDK.

En e-postklient skulle dock kunna integreras eller länkas till en SDK-meddelandeklient för att möjliggöra att skicka SDK-meddelanden via e-postklienten. Meddelandet måste då anpassas för att kunna överföras enligt Innehållsspecifikation Meddelande (dokumenttyp). Det innebär bl.a. att ha stöd för att hantera integration mot SDKs gemensamma adressbok, alternativt en lokal adressbokskopia, och SDKs funktionsadresser, som används för teknisk adressering på funktionsnivå i SDK-nätverket. Den klient som ansluts måste följa de informationssäkerhetskrav som följer av hantering av känsliga personuppgifter.

Informationssäkerhet

Här hittar du frågor om informationssäkerhet kopplat till SDK. Informationssäkerhet är en grundpelare för att tilliten mellan organisationerna som använder SDK ska upprätthållas.

Fråga

Svar

Fråga

Svar

Vad behöver man som organisation tänka på inom informationssäkerhetsarbetet?

På våra öppna informationssidor finns relevant dokumentation om Informationssäkerhet.

Läs mer om tjänstens regelverk och krav inom informationssäkerhet här: https://inera.atlassian.net/wiki/spaces/OISDK/pages/2710601964

Läs mer om rekommendationer inom informationssäkerhet här:

https://inera.atlassian.net/wiki/spaces/OISDK/pages/2900590615

Inom mindre kommuner kan det vara brist på internt arbete och resurser inom informationssäkerhet. Kan man som organisation ta sig an det förberedande arbetet för SDK på något sätt trots det?

Ja, det går att påbörja arbetet dels med verksamhetskartläggning och det tekniska vägvalet. Ni kan även passa på att kartlägga vilka rutiner ni som organisation har inom informationssäkerhet idag. Se ovanstående fråga och svar med länkar till mer information.

Finns det möjlighet till stöd i införandet med informationssäkerhet, när i tiden är det tillgängligt i så fall?

Det går att ta del av presentationsmaterialet från Användarforum med fokus på informationssäkerhet. Forumet behandlar övergripande de olika delar som inkluderas i informationssäkerhetsarbetet för organisationerna. I presentationen finns även frågor som skickats in av kommuner och regioner i samband med mötet. Här kan ni nå presentationen.

Om mottagaren är ett funktionskonto hur vet man då att mottagaren är behörig till den information som man skickar? Behörig är ju den som deltar i aktuell patients vård, inte alla som jobbar på en viss funktion?

Varje organisation ansvarar för att en sekretessprövning genomförs innan sekretessbelagd information lämnas ut, detta sker redan idag. Den enda skillnaden som SDK medför att man har en större möjlighet att bedöma att mottagaren upprätthåller en adekvat skyddsnivå och att överföringen av informationen blir säkrare jämfört med t.ex. fax.

Användarorganisationen ansvarar för att de personer som tilldelas behörig till en funktionsadress ska vara behöriga att hantera den information som kan skickas till adressen. Detta regleras i regelverket för SDK Regelverk för anslutning till Säker digital kommunikation – Informationssäkerhet kapitel 4. Som exempel är en medicinsk sekreterare inte delaktig i den fysiska vården men har en viktig funktion i patientens vård kopplat till planering och har därmed rätt att hantera känslig information.

En förutsättning för att skicka meddelanden är krav på informationsklassning, men hur säkerställs två parters syn på aktuell informationsklassning?

Parternas syn på informationsklassning behöver inte säkerställas specifikt, så länge som båda organisationerna (parterna) gör en klassning som inte överskrider den nivå som SDK är dimensionerad för.

Informationssäkerheten inom SDK är dimensionerad för att svara mot de risker som uppgifter av allvarlig konsekvensnivå kan förväntas medföra, samt respektive användarorganisation ansvarar för den egna klassningen och för bedömningen av vilken information som kan överföras i digitala meddelanden via SDK och eDelivery transportinfrastruktur.

De dokument man skickar via SDK kommer att behöva mellanlagras när man tar ut information från ett system för att bifoga det i SDK-meddelandet. Mellanlagringen är vanligen lokal och kan inte bedömas som säker plats. Har ni någon rekommendation på metod för mellanlagring?

Varje organisation behöver själv ta fram rutiner och riktlinjer för hur dokument som skickas eller tas emot med SDK hanteras lokalt. Vissa organisationer har sett som alternativ att “bygga in” SDK i ett befintligt ärendehanteringssystem för att undvika mellanlagring.

Vem är legalt ansvarig om ett meddelande inte kommer fram?

Ansvaret för meddelandeutbytet ligger på sändande respektive mottagande användarorganisation i SDK. I SDKs regelverk för anslutning - informationssäkerhet regleras ansvar för uppgifterna som förmedlas via SDK. I SDKs tekniska specifikation för validering, felhantering och kvittens anges också krav på omsändning mm. 

Hänger SDK och Identifieringstjänst SITHS ihop?

Det finns beröringspunkter men är inte samma sak. Båda tjänsterna tillhandahålls av Inera.

SDK är en federation för säkert meddelandeutbyte mellan organisationer. Som en del i säkerheten krävs att anslutna organisationer har ett funktionscertifikat för kryptering av SDK-meddelanden, s.k. organisation-till-organisation (O2O)-kryptering och validering. SDKs Regelverk för anslutning till Säker digital kommunikation – Informationssäkerhet anger vilka certifikatsutfärdare som är godkända och varje organisation måste ha ett certifikat från någon av dessa utfärdare, där SITHS eID från Inera är ett av de godkända funktionscertifikaten.

SDKs regelverk anger också krav på transportkryptering av trafiken mellan anslutna organisationer där SITHS funktionscertifikat ska användas.

Eftersom SDK stödjer utbyte av känsliga personuppgifter, så innebär det även krav på att (slut)användarna är starkt autentiserade. Detta beskrivs också i SDKs Regelverk för anslutning till Säker digital kommunikation – Informationssäkerhet att varje användarorganisation behöver säkra det. Regelverket anger inte krav på vilka specifika eID som ska användas, men ett av dem som en användarorganisation skulle kunna använda är SITHS eID.

•Hur ser personuppgiftsansvaret ut mellan sändande och mottagande organisation?

I SDK skickas meddelandet direkt mellan avsändande organisation och mottagande organisation, dvs det finns ingen förmedlande part som blir personuppgiftsansvarig eller biträde. Detta beskrivs i SDKs regelverk inklusive när personuppgiftsansvar för den information som sänds i ett meddelande kan uppstå även hos mottagande organisation.

 Hos respektive användarorganisation kan det däremot finnas behov av att reglera personuppgiftsbiträdesförhållanden. T ex om en användarorganisation tillhandahåller teknisk lösning för flera underliggande organisationer, eller om extern leverantör anlitas. 

Är informationsutbyte i SDK en allmän handling eller ej?


Om en verksamhet skickar information via SDK till en extern part, betraktar man då informationen som utbyts (dvs själva meddelandet) som en allmän handling som skall sekretessbeläggas och diarieföras i verksamhetssystem eller hur ser man på detta? Är det ett arbetsmaterial?
Likaså om man internt utbyter information, men kanske använder sig av olika verksamhetssystem.

I SDKs Regelverk för anslutning till SDK - Informationssäkerhet, beskrivs när en handling betraktas som utlämnad från avsändaren respektive inkommen hos mottagaren. Den information som utbyts avser både meddelandet (löptext, rubrik) och ev. bilagor.  Se länk: Regelverk för anslutning till Säker digital kommunikation - Informationssäkerhet

Sändaren av ett SDK-meddelande ska göra en bedömning av om uppgifterna omfattas av sekretess eller ej, och markera detta i ett fält. Om ja, så ska man även ange vad som omfattas samt grunden för bedömningen anges i meddelandets fritextfält. Det fråntar inte mottagaren från att göra sin bedömning på motsvarande sätt. Detta beskrivs i ”Rekommendation för hantering av uppgifter som omfattas av sekretess i SDK”, Se länk: Rekommendation för hantering av uppgifter som omfattas av sekretess

Huruvida det utgör arbetsmaterial eller ej, är en bedömning som mottagaren behöver göra. Det finns ingen generell regel eller rekommendation i SDK för det, utan beror på vad det är för slags information och vilka rutiner man har för sin informationshantering generellt. 

Om information förs mellan interna system, t.ex. för att bifoga en pdf, blir säker hantering av den (lagring och överföring) också något som behöver finnas på plats. Även gallringsrutiner kan bli aktuellt för det system där man lagrar informationen.

Allmänt gäller att skickas information från en myndighet till en annan så är det expedierat från avsändande organisation och inkommit till mottagande organisation.  Det betyder att det är att betrakta som en allmän handling. 

Det är skillnad på om det är en offentlig allmän handling (ingen sekretess), eller om det är en allmän handling som omfattas av sekretess. Den kan omfattas i sin helhet av sekretess eller bara vissa delar. 

Om det är information som omfattas av sekretess ska avsändande organisation ange det i SDK samt beskriva varför (vilken sekretessparagraf), sen är det upp till den mottagande organisationen att bedöma sekretessfrågan hos sig. Se även nedan. 

Allmän handling som omfattas av sekretess ska registreras (5 kap. 1§ OSL). Det är inte lika med diarieföring. Det måste varje organisation ha koll på, vilka handlingar som registreras i vilka system. 

Diarium är ett exempel på registrering men det finns även andra system som t.ex. journalsystem. Kap. 5 2§ OSL beskriver kraven för registrering:

  1. Datum när det inkom eller upprättades måste framgå

2. Handlingen måste ha en unik identifierare (t.ex. diarienummer)

3. Avsändare eller mottagare av handlingen

4. Kort sammanfattning av handlingen. 

Är utbytet helt internt (och det inte korsar olika myndighetsgränser, t.ex. nämnder i kommun och region) så kan den inte betraktas som inkommen/expedierad, handlingen kan dock uppfylla andra kriterier som gör att det blir en allmän handling, t.ex. ”förvaras hos”.  (Tryckfrihetsförordningen: 2 kap. 4 §   En handling är allmän, om den förvaras hos en myndighet och enligt 9 eller 10 § är att anse som inkommen till eller upprättad hos en myndighet.). Expedierad faller under upprättad

Adressbok

Här hittar du frågor som rör SDK Adressbok. Hur man bygger upp sin organisations struktur mm.

Fråga

Svar

Fråga

Svar

Hur ska man bygga sin adressbok, kan man kan välja att ha det på individnivå eller är det är avsett för funktionsbrevlådor?

SDK Adressbok innehåller information på organisations- och funktionsnivå, dvs. inte på individnivå.

För SDK Adressbok finns ett s.k. Sök-API framtaget för att integrera den lokala meddelandeklienten mot SDK Adressbok vilket möjliggör för meddelandeklienten att använda adressboken som källa för att söka och hitta andra SDK-anslutna organisationer.

Har ni funderat kring hur flera verksamheter ska läggas upp inom samma organisationsidentifierare (domän + organisationsnummer)?

SDK Adressbok stödjer en organisationsstruktur i två nivåer, användarorganisation och underliggande organisation. På respektive nivå finns funktionsadresser. Underliggande organisation är ”frivillig” och det är användarorganisationen som ansvarar för och definierar dessa inom sin verksamhet.  Detta finns reglerat i SDKs regelverk inom informationssäkerhet samt det finns handledningar som beskriver hur det lämpligen sätts upp.

Exempelvis skulle det för domstolar kunna innebära: 

Sveriges domstolar = användarorganisation

Enskild domstol = underliggande organisation

Enhet eller motsvarande inom underliggande organisation kan ha minst en funktionsbrevlåda.

Uppdateras SDK Adressbok manuellt? Kommer det att finnas stöd för att synkronisera adressinformation från lokala kataloger?

Ja, användarorganisationens information (t.ex. funktionsbrevlådor) i SDK Adressbok underhålls manuellt via ett administrationsgränssnitt. Det är användarorganisationen själv som ansvarar för informationen samt att registrera och hålla den uppdaterad. 

SDK Adressbok erbjuder idag inget API för att uppdatera adressboken via synkronisering från lokala kataloger, såsom HSA-katalogen, lokalt Active Directory (AD) eller liknande. Ett synkroniserings-API är identifierat som ett behov och kan bli aktuellt framöver.

Hur hänger SDK Adressbok och Katalogtjänst HSA ihop?

En av viktig komponent i tjänsten är SDK Adressbok. SDK Adressbok är ett gemensamt adressregister för information om SDK-anslutna användarorganisationer och deras funktionsadresser. 

SDK Adressbok ingår inte som en del av eDelivery från CEF, utan är en kompletterande gemensam komponent som ingår i tjänsten. Det är bara organisationer som är anslutna till SDK som finns med i SDK Adressbok. Den används för att söka säkra mottagarorganisationer och funktioner inom dessa.

Varje organisation ansvarar för sina uppgifter i adressboken och att registrera/uppdatera dem. I befintlig version av SDK Adressbok administreras uppgifter i adressboken manuellt av en/flera behöriga administratörer hos användarorganisationen. 

Tanken är även att kunna försörja adressboken med koppling till lokala kataloger, dvs inte manuellt. Om/när det blir aktuellt, är det tänkbart att HSA kan vara en sådan adresskälla för de organisationer som finns i HSA. Om/när det blir aktuellt, kan det även vara lämpligt att utgå från Ineras referensarkitektur för grunddata och katalog för hur synkronisering mellan olika adresskällor ska ske.

Det ska även sägas att HSA innehåller även mycket annan information (t.ex. personuppgifter) som inte ska finnas i SDK Adressbok som är ett enklare ”adressregister” samt att SDK Adressbok även kommer innehålla organisationer/verksamheter utanför hälso- och sjukvården som inte finns i HSA.

Hur går arbetet med skapa en struktur för den regionala verksamheten i SDK Adressboken?

Det finns i dagsläget (november 2022) en handledning för Regional hälso- och sjukvård inom verksamhetsområde Primärvård och specialiserad psykiatrisk vård. Nästa steg i arbetet med regionens struktur är att ta fram en struktur för specialiserad somatisk vård och övrig hälso- och sjukvård.

SDK Adressbok har en viss struktur för kommuner och regioner, hur blir det med myndigheter?

Det finns i vår planering för 2023.

Vad är skillnaden på SMP och SDK Adressbok?

SMP står för den tekniska information mellan mottagare, medan SDK Adressbok beskriver organisationsstrukturen.

Hur fungerar det vid felskick? Går det att ångra ett meddelande när ett fel gjorts?

Det går inte att ångra ett meddelande vid felskick. Organisationen själva ansvarar för att sätta upp processer och rutiner för att ta hand om meddelande som hamnar hos fel mottagare.

Finns det risk att meddelande skickas till fel funktionsbrevlåda, specifikt om rätt mottagare inte är med i adressboken? Ett exempel är att skicka till fel funktion, men rätt kommun.

Ja, denna risk finns och därför är det viktigt att se till att ha så bra beskrivningar som möjligt av sina funktionsadresser för att hjälpa den sändande organisation. Sökord kan användas för att underlätta att hitta rätt mottagare.

När det gäller en organisationen som finns inlagt, men inte rätt funktion är det viktigt att ha egna rutiner för detta:
Även om det går så ska man inte skicka till fel del av mottagande organisation. Se över regler och processer för att se till att tjänsten används på bästa sätt.

Vad händer om mottagaren inte finns tillgänglig i SDK Adressbok?

Det krävs att både avsändare och mottagare är anslutna till SDK Adressbok och att mottagande respektive avsändande funktionsbrevlåda är registrerade för att kunna nyttja tjänsten.

Hur går det till när organisationen får tillgång till SDK Adressbok? Sker det automatiskt vi anslutning, eller krävs det någonting från organisationen?

SDK-miljöerna, med tillhörande SDK Adressbok, blir tillgängliga under anslutningsprocessen efter det att organisationen får ett konto och möjlighet att logga in i SDK Testbädd där organisationen ansluter för att testa sin Meddelandetjänst (MT) och Meddelandeklient (MK).

Adressboken nås via MK, antingen genom en integration med tjänsten, eller genom en läskopia. SDK Adressbok finns även i SDK PROD, som är den gemensamma produktionsmiljön.

Vem ansvarar för att registrera nya organisationer och funktionsadresser i SDK Adressbok? Hur ser administrationen ut och finns det olika typer av behörighet?

En federationsoperatör (Inera) lägger upp organisationen i SDK Adressbok. Användarorganisationen anmäler Organisationsadministratörer och Funktionsadministratörer till Inera. Dessa roller har olika behörigheter:
- organisationsadministratören kan hantera både beskrivning av organisationen och alla funktionsadresser.

- funktionsadministratören har behörighet att hantera organisationens funktionsadresser.

Kommer det finnas möjlighet till automatiserad administration av SDK Adressbok?

Befintlig version av SDK Adressbok bygger på att man administrerar sina uppgifter via en administratör. Det kan finnas en fördel att föra in manuellt till en början för att försäkra sig om att det blir korrekt och att organisationen förstår hur SDK Adressbok är uppbyggd och därmed skapar ändamålsenliga funktionsadresser.
Det finns tankar kring att ta fram ett s.k. Synk-API för att i framtiden potentiellt kunna automatisera överföring/synkronisering mellan lokala adresskällor och SDK Adressbok. Detta är identifierat som ett behov, men för närvarande pågår inget aktivt arbete.

I dagsläget går det att använda en import- och exportfunktion i SDK Adressbok för att undvika omfattande manuellt arbete. Ett tips är att först exportera ut en fil (excelformat) för att återanvända strukturen när man arbetar igenom sitt adressboksinnehåll som sedan kan importeras till adressboken. Mer om det i Användarhandledningen för administratörer av SDK Adressbok.

Vad ska man tänka på när man skapar funktionsbrevlådor i SDK Adressbok?

Börja med ett fåtal funktionsbrevlådor och komplettera efter hand. Tänk på att det är mellan funktioner som meddelanden skickas, inte mellan individer.

Leverantörsmarknad

Här finns det information för dig som är systemleverantör och för dig som funderar på om din organisation vill ta hjälp av en leverantör för den tekniska anslutningen till SDK

Fråga

Svar

Fråga

Svar

Vad kostar det att anskaffa lösningar för Säker digital kommunikation?

Anslutande organisationer står själva för kostnader i den egna verksamheten (t.ex. utveckling av de egna it-stöden) som föranleds av en anslutning till infrastrukturen för Säker digital kommunikation. Kostnader för lokala resurser varierar beroende på om man väljer att göra egen utveckling eller anlita leverantör, samt även beroende på hur stor del av organisationen som ska kunna använda SDK och som t.ex. behöver meddelandeklienter. I pilotrapporterna från Projektet Säker digital kommunikation 2020 och 2021/Q1 2022 finns erfarenheter från pilotaktörer vad gäller kostnader som är förknippade till anslutning och införande av Säker digital kommunikation.

Finns det systemleverantörer som kan hjälpa oss att ansluta till SDK?

Alla leverantörer som är intresserade av att testa sin lösning är välkomna att beställa och använda SDKs öppna testmiljö för tjänsteleverantörer, SDK ÖTM.

De leverantörer som är godkända publiceras här: https://inera.atlassian.net/wiki/spaces/OISDK/pages/2823553290

Finns det en lista på de leverantörer som erbjuder Meddelandeklient och Meddelandetjänst för SDK?

Inera håller en konkurrensneutral hållning, men ger leverantörer möjlighet att testa sina lösningar i ÖTM (öppen testmiljö) och därmed visas i en lista att de är tillgängliga för SDK (andra leverantörer kan vara tillgängliga trots att de inte deltagit i den här listan). De leverantörer som har anslutit till ÖTM, eller är på väg att ansluta är publicerade här.

Finns det någon godkänd meddelandeklient i dagsläget?

Det finns ett antal leverantörer som fungerar och levererar tjänsten och som varit leverantörer till tidigare piloter.
Inera erbjuder sedan juni 2022 leverantörer att få sina produkter SDK-godkända i Ineras Öppen testmiljö (SDK ÖTM). Det innebär att verifiera vissa krav på leverantörernas meddelandetjänst och meddelandeklient och att publicera en lista med vilka godkända leverantörer som finns. Detta ska underlätta för användarorganisationer att veta att de har en SDK-godkänd leverantör.
Inera godkänner meddelandetjänst och meddelandeklient. DIGG godkänner accesspunkt och publicerar en motsvarande lista med godkända Accesspunktsoperatörer.

Vad är skillnaden på Meddelandetjänst och Meddelandeklient?

Meddelandeklienten (MK) är det användargränssnitt som används när använder skickar meddelanden med SDK.
Meddelandetjänsten (MT) är den integrationsmotor (som en växel) som tar emot och skickar meddelandet mellan MK och Accesspunkten.

Finns det standardiserade API:er mellan Accesspunkt, Meddelandetjänst och Meddelandeklient?

Idag finns det inget standardiserat API mellan AP-MT och/eller mellan MT-MK. Det är alltså inte standardiserat hur SDKs Meddelanden skall utbytas mellan interna komponenter.

En utredning om möjligheten till en standardisering har därför påbörjats och förhoppningen är att kunna återkomma med besked redan under januari 2023.

Är er erfarenhet att man kravställer att leverantörer ska vara öppna för att ansluta fler MK?

Det ser olika ut baserat på hur en organisation tänker i sin anskaffning. Det vill säga om organisationen anskaffar en lösning för att snabbt komma igång för ett täcka ett mer kortsiktigt behov, eller om man vill ha en lösning som stödjer behov även långsiktigt och med till exempel flera meddelandeklienter (MK).

 

Om en organisation har behov av att kunna ansluta fler meddelandeklienter till meddelandetjänsten kan det tänkas att organisationen kravställer/utvärderar på integrationsförmåga i meddelandetjänsten mot specifika verksamhetssystem och/eller en mer generell integrationsförmåga.

 

Vår erfarenhet hittills är att det finns organisationer som tänker i dessa banor.

Går det att konfigurera någon funktion i Meddelandeklienten som sorterar/klassar den inkommande informationen till organisationen via SDK?

Nej, det är upp till varje organisation att lära ut anvädningen av SDK och se över vem som får tillgång till vilka funktionsbrevlådor internt.
I SDK Adressbok går det att underlätta sökande av mottagande funktionsbrevlåda genom att vara tydlig med sökord kopplade till specifika funktioner.

Går det att använda en Meddelandeklient till flera kommuner, till exempel kommunalförbund?

Ja det gör det, om kommunerna har tydliga avgränsningar kring vem som har tillgång till vilka funktionsbrevlåda.

SDKs regelverket reglerar inte direkt hur en användarorganisation organiserar sin IT-drift, leverantörer eller mjukvara (t.ex. MT, MK). En förutsättningar att regelverk och specifikationer följs.

Kortfattat kan man säga att en användarorganisation kan använda en eller flera valfria leverantörer som levererar, tillhandahåller och förvaltar IT-lösningar som t.ex. Accesspunkt (AP), Meddelandetjänst (MT) och Meddelandeklient(er) (MK) under förutsättning att regelverk och specifikationer följs.

Har ADDA tagit fram avtal man kan avropa på?

Adda har inte tagit fram ett specifikt ramavtal för Säker digital kommunikation. Det finns däremot möjlighet att använda befintliga ramavtal för IT-konsulttjänster och programvaror hos Adda. För information om Addas arbete inom området leverantörsmarknad för Säker digital kommunikation, vänligen besök Addas webbplats för mer information och kontaktuppgifter.

För närvarande håller Inera och Adda på att se över möjligheterna att förenkla för kommuner och regioner att teckna avtal med leverantörer för enkla SDK-lösningar.

Finns det något gemensamt kravunderlag för leverantörer?

Inera tillsammans med Adda och Införandeprojektet har plockat upp det här behovet och kommer utföra ett delprojekt kopplat till leverantörer.
RAM-avtal är inte aktuellt just nu.

Erfarenhetsutbyte och information

Fråga

Svar

Fråga

Svar

Kan jag ta del av piloterfarenheter från tidigare år?

Ja, i de gemensamma pilotrapporterna från 2020 och från 2021/2022 beskrivs piloternas erfarenheter inom bland annat informationssäkerhet, anslutning till SDK, erfarenheter från pilottesterna och resultat och nytta för verksamheten.

I rapporterna finns även exempel på vilka verksamhetsområden och processer som piloterna har valt att arbeta med inom bland annat områdena arbetsmarknad, socialtjänst och hälso- och sjukvård.

Pilotrapporterna finns här.

Finns det ett forum för att ta del av andras erfarenheter?

Ja, genom ett samarbete mellan Inera och SKR har vi satt upp ett Samarbetsrum för SDK.

Här kan kommuner och regioner:

  • Samla och dela information och dokumentation kopplat till arbete med SDK

  • Dela goda exempel från er egen organisation

  • Starta konversationstrådar för aktuella frågeställningar och resonemang

  • Hitta kontaktuppgifter till organisationer men liknande behov under anslutningsprocessen till SDK

De diskussioner och filer som delas bör vara relaterade till arbetet inom Säker Digital Kommunikation och kommer vara tillgängliga för alla som har tillgång till samarbetsrummet.

Anmäl en kontaktperson för er organisation till SDKinforande@inera.se för att bli inbjuden till Samarbetsrummet.

Finns det någon möjlighet att få veta vad andra organisationer tagit för beslut kring tekniska system för SDK?

Via SDKs Samarbetsrum finns det möjlighet att samverka kring det. Om du inte redan är inbjuden kan du mejla till SDKinforande@inera.se så skickar de en inbjuden.

 Accesspunkt/DIGG

Här kan hitta frågor och svar om accesspunkt, accesspunktsoperatör och DIGGs roll inom SDK.

Fråga

Svar

Fråga

Svar

Vad är en accesspunkt?

De meddelanden som skickas mellan användarna av SDK utväxlas via accesspunkter (även kallade anslutningspunkter). Det är de som transporterar och krypterar meddelandet från avsändaren till mottagaren.

Det gör de enligt de regler, rutiner och säkerhetskrav som ställs på accesspunkter enligt DIGGs ramverk. Den som ansvarar för accesspunkten kallas för accesspunktsoperatör. Både privata tjänsteleverantörer och offentliga aktörer kan bli godkända som accesspunktsoperatörer.

Vad innebär det att utveckla och vara sin egen accesspunktsoperatör (APO) för SDK?

För att kunna ta ställning till om man ska vara sin egen accesspunktsoperatör behöver man skapa sig en förståelse för transportinfrastrukturen och dess komponenter, regler, rutiner och principer. Man behöver också känna till de säkerhetskrav som ställs på en accesspunkt enligt DIGGs ramverk.

För att få förståelse för vad detta innebär mer konkret kan man beställa det informationspaket DIGG tagit fram. Det innehåller bland annat en beskrivning av ramverket för plattform för eDelivery, tekniska specifikationer, meddelandespecifikationer, transportmodeller och en beskrivning av gemensamma principer, regler och rutiner. Ni beställer informationspaketet via e-post till info@digg.se.

Går det att vara flera meddelandeklienter på en AP?

Ja, det går bra.

Finns det en lista över leverantörer av accesspunkt?

Ja, på DIGGs webbplats publiceras löpande de leverantörer och organisationer som blir plattformsgodkända som accesspunktsoperatörer, se följande länk -eDelivery | DIGG. Där listas de leverantörer som erbjuder sin accesspunkt som en tjänst samt de organisationer som utvecklat en accesspunkt för den egna verksamheten.

Vilka för- och nackdelar finns det med att vara accesspunktoperatör själv, respektive att dela på accesspunkt med andra?

Vad som kan ses som fördelar med att vara sin egen accesspunkt är att man internt har full insyn och kontroll över de komponenter som ingår samt är oberoende av en extern part.
En nackdel skulle kunna vara att det kräver både resurser och tid, dels för att genomgå anslutningsprocessen och i förlängningen även den förvaltning, drift, beredskap och vidareutveckling som krävs för att tillhandahålla sin egen accesspunkt.

Vad som kan ses som fördel med att istället anlita en tjänsteleverantör är att man inte behöver använda interna resurser och tid som anslutningen och förvaltningen av en accesspunkt kräver, utan kan istället fokusera på anslutningen till SDK.

Vad förväntas en organisation göra för att bli godkänd som accesspunktsoperatör?

För att bli en plattformsgodkänd accesspunktsoperatör krävs det att man genomgår en anslutningsprocess hos DIGG, som bland annat inkluderar att man:
• kvalificerar sig för ett plattformsgodkännande genom att utföra testfall enligt DIGGs instruktioner
• blir godkänd enligt gällande granskningskriterier för ett plattformsgodkännande av accesspunktsoperatör,
• försäkrar att den egna organisationen och dess programvara är följsam mot DIGGs ramverk vad gäller regler, rutiner och specifikationer.

Ni hittar mer information angående detta på DIGGs webbplats - eDelivery | DIGG

Hur ofta uppdateras DIGGs informationspaket?

För information som rör DIGGs informationpaket vänligen kontakta DIGG. Ni når dem via e-postadress info@digg.se eller telefonnummer 0771-11 44 00.