Checklista för anpassning av anslutande meddelandesystem till SDK

1. Syfte

SDK är en säker transportinfrastruktur för asynkron punkt-till-punkt (meddelande levereras direkt till mottagarens accesspunkt) arkitektur som bygger på Diggs plattform för eDelivery (baserad på CEF eDelivery). För att etablera SDK-förmåga inom en deltagarorganisation behöver IT-stöd anpassas och en eller flera klienter/verksamhetssystem behöver anslutas.

Accesspunkt (AP):

• En accesspunkt är en standardiserad mjukvara som anpassas enligt Diggs tekniska specifikationer.
• “AP-operatör är den part som tillhandahåller accesspunkt till en eller flera deltagarorganisationer i enlighet med SDK:s regelverk och avtal (en accesspunkt kan delas).
• En AP-operatör kan vara deltagarorganisationen själv eller en extern leverantör.
• En accesspunkt ska ha ett öppet tillgängligt API för att kunna integrera med olika meddelandetjänster.

Meddelandetjänst (MT):

• En integrationskomponent för att hantera meddelandeflöden mellan accesspunkt och meddelandeklienter/verksamhetssystem. En deltagarorganisation kan ha en meddelandetjänst.
• Dekrypterar, krypterar, signerar och validerar signatur på SDK-meddelanden.
• Validerar och kvitterar meddelanden (meddelande mottaget).
• Validerar giltig avsändare och mottagare mot SDK adressbok.
• Ansvarar för att leverera meddelandet internt inom deltagarorganisationen.
• En meddelandetjänst ska ha ett öppet tillgängligt API för att kunna integrera med olika accesspunkter och meddelandeklienter.

Meddelandeklient/Verksamhetssystem (MK):

• Representerar ett verksamhetssystem där användaren finns.
• Meddelandeklienten behöver anpassas för att kunna hantera SDK-meddelanden och kvittenser.
• Meddelandeklienten ska ha ett öppet tillgängligt API för att kunna integrera med olika meddelandetjänster.
• Söker mottagare i SDK Adressbok

Mål: Stödja en deltagarorganisation som ska etablera SDK-förmåga. Dokumentet lyfter fram områden som behöver utredas och vägval som behöver göras.

Checklistan är framtagen för att stödja deltagarorganisationer gällande vägval som behöver göras eller utredas för att etablera lokal SDK-förmåga från meddelandeklient/verksamhetssystem till accesspunkt.

Dokumentet avhandlar den del av IT-stöd och lokal infrastruktur som inom eDelivery betecknas som backend, dvs. mellan meddelandeklient/meddelandetjänst och accesspunkt.

Digg har tagit fram vanliga frågor och svar om anpassning av anslutande system till SDK, se FAQ för deltagarorganisationer. Länk till annan webbplats.

1.1 Målgrupp

Personer som ska genomföra förstudier eller analyser av behov och ta fram lösningsförslag för att etablera lokal IT-förmåga för SDK-anslutning.

• Lösningsarkitekter
• Projektledare/utredare

1.2 Dokument

Nedan listas ett urval av dokumentation och specifikationer som är relevanta vid anpassning av lokala komponenter för utbyte av SDK meddelanden.

Övergripande arkitektur

• SDK SAD

Implementationsnära specifikationer:

• Innehållsspecifikation – meddelande
• Specifikation av validering, felhantering och kvittens
• Meddelandespecifikation – meddelandekvittens Länk till annan webbplats.
• Kuverteringsprofil XHE Länk till annan webbplats.
• Rekommendation API MT-MK
• Transportmodell utökad bas med signering och kryptering Länk till annan webbplats.
• Transportprofil AS4 Länk till annan webbplats.
• PKI för accesspunkter komponentspecifikation Länk till annan webbplats.
• Certifikatspublicering REST binding till SMP Länk till annan webbplats.

Regler och informationssäkerhet

• Regelverk för deltagarorganisationer inom SDK
• Accesspunktsoperatör – gemensamma regler och rutiner Länk till annan webbplats.
• Testfall för meddelandesystem
• Bilaga för tillgänglighet inom SDK
• Handledning för administratörer i SDK adressbok

2. Sourcingstrategi SDK förmåga (vägval för etablering)

Regelverket för deltagarorganisationer inom SDK är framtaget för organisationer som har för avsikt att ansluta till SDK och specificerar de säkerhetskrav som ställs på anslutna aktörer till SDK.

Vid tillämpning av regelverk och specifikationer finns det frihet när det gäller hur krav skall implementeras. Det finns en hel del vägval som anslutande deltagarorganisationer behöver överväga.

3. Anskaffa helhetslösning eller anskaffa/utveckla olika delar

Kapitlet beskriver vilka vägval som kan bli aktuella för en deltagarganisation.

Oavsett anskaffningsstrategi är meddelandetjänst en strategisk komponent då den är central för en deltagarrorganisations meddelandeutbyte mellan en/flera meddelandeklient (-er)/verksamhetssystem och accesspunkt för vidare distribution inom SDK-federationen.

3.1 Helhetslösning

En helhetslösning innebär att accesspunkt, meddelandetjänst och meddelandeklient paketeras tillsammans. SDK-förmåga levereras och administreras som en tjänst.

En helhetslösning passar sannolikt organisationer som önskar anskaffa SDK-förmåga snabbt samt bedömer att en separat dedikerad klient passar verksamhetens behov.

Anskaffa lokala komponenter eller köpa som tjänst (Software as a service - SaaS) passar organisationer som önskar enkel paketerad lösning som inte kräver lokal drift eller förvaltning.

Viktiga vägval:

Fördelar

• Snabb anskaffning av SDK-förmåga.
• En fristående klient kan användas av alla i organisationen.
• Enkel anslutning till SDK-federationen.
• Enklare administration då leverantören tar driftansvar för alla komponenter. Alla delar levereras och administreras som en tjänst.

Nackdelar

• Separat klient för meddelandeutbyte, dvs ytterligare ett system för användarna.
• Om ytterligare meddelandeklienter/verksamhetssystem behöver integreras kan stöd saknas eller behöva hanteras som ett tillägg. Anslutning till ytterligare meddelandeklienter/verksamhetssystem kan bli kostsam.
• Information, t ex i bilagor (PDF eller annat format) måste importeras/exporteras mellan systemen.
• Hantering av ärendehistorik och beslut om slutlagring eller gallring av dokumentation.

Rekommendation

Även om en helhetslösning anskaffas är det viktigt att säkerställa att komponenter levereras med öppna API:er som möjliggör att komponenter kan bytas ut eller utökas. Komponenter bör levereras med ett öppet tillgängligt API som möjliggör byte av accesspunkt, meddelandetjänst och meddelandeklienter, se Rekommendation API MT-MK.

3.2 Anskaffa eller utveckla olika delar själv

Att etablera SDK-komponenter separat passar sannolikt organisationer som långsiktigt vill integrera med flera meddelandeklienter/verksamhetssystem. Organisationen bör ha en strategi för hur olika meddelandeklienter/verksamhetssystem skall integreras och kopplas till olika funktionsadresser.

Anskaffa eller utveckla olika delar själv passar organisationer som önskar installera och konfigurera AP själv, ta fram eller integrera med befintlig integrationslösning (meddelandetjänst/meddelandeväxel) för meddelandevalidering, meddelandekvittens och informationsutbyte med meddelandeklient/verksamhetssystem.

Rekommendation att undersöka:

• att det finns lokal kompetens inom integration.
• administration, anpassning/utveckling av integrationsflöden.
• om lokal infrastruktur t ex integrationsmotor (meddelandetjänst) kan användas för att hantera interna meddelandeflöden.
• vilka förutsättningar som finns för att anpassa befintliga meddelandeklienter/verksamhetssystem.
• om det finns egen förmåga att drifta och förvalta lösningen.

Generalisera komponenter för:

• Adressbokens API:er.
• Meddelandetjänstens API:er
• Accesspunktens API:er

Säkerställ att komponenter utformas/levereras med öppna API:er som möjliggör att komponenter kan bytas ut eller utökas. T ex att komponenter levereras med ett öppet tillgängligt API som möjliggör byte av accesspunkt, meddelandetjänst och meddelandeklienter, se Rekommendation API MT-MK.

Fördelar

• Egna komponenter ger anpassningsbarhet – full kontroll över koden.
• Integrationsflöden kan skräddarsys för verksamhetens behov.
• Lätt att koppla på nya klienter (verksamhetssystem).
• Återanvända befintliga komponenter för förvaltning och behörighetsstyrning.
• Lätt att byta implementation av accesspunkten.

Nackdelar

• Det tillkommer utvecklings- och förvaltningskostnader.
• Kräver ofta egna resurser och kompetens inom utveckling och integration, eventuellt även inom applikationsförvaltning, alternativt vana av att kravställa mot leverantörer.
• Kräver fortsatt vidmakthållande av egna lösningar för att t ex löpande följa SDK:s livscykel för tekniska specifikationer och dokumenttyper.
• Komplicerat om lösningar och förvaltning fördelas på flera team och plattformar.

4. Säkerhet

Regelverk för deltagarorganisationer inom SDK innehåller gemensamma krav som alla deltagarorganisationer behöver följa, se regelverk för deltagarorganisationer inom SDK.

4.1 Roller och ansvar - övergripande orientering

Inom SDK-federationen fördelas ansvar mellan följande aktörer och roller, se bilaga om aktörer och roller inom SDK.

4.1 Informationsklassning

SDK-federationen är framtaget för att stödja informationsutbyte av känsliga personuppgifter. Det är därför viktigt att alla ingående komponenter lever upp till gällande lagar och regelverk för vald informationsklassning.

Regelverk för delatagarorganisationer inom SDK innehåller gemensamma krav som alla deltagarorganisationer behöver följa. Se regelverk för deltagarorganisationer inom SDK samt bilaga för informationssäkerhet inom SDK.

4.2 Lokalt ansvar: Inre säkerhet (Inom deltagarorganisation)

Med inre säkerhet avses säkerhet mellan deltagarorganisationens interna komponenter. Regelverk för deltagarorganisationer inom SDK innehåller gemensamma krav som alla deltagarorganisationer behöver följa. Inom området inre säkerhet brukar nedanstående områden lyftas fram som viktiga.

4.2.1 Inloggning (Multifaktorautentisering)

Multifaktorautentisering (multifaktorsinloggning) kan uppnås på olika sätt. Ett vanligt sätt är att en e-legitimation används vid inloggning. E-legitimation kan integreras i användarens dator (operativsystem), alternativt används en intern/extern IdP (Identity Provider) via säkerhetsprotokoll som t.ex. SAMLv2/OAuth/OIDC.

4.2.2 Behörighetshantering (Auktorisation av personal)

• Säkerställa att behörighetssystemet endast ger behörig användare tillgång till informationen.
• Säkerställa att adressering av funktionsbrevlådor motsvara behörighetsmodellen (sekretessgränser).

4.2.3 Behörighetskatalog

• Behörighetsstyrning kan med fördel utgå från en för deltagarorganisationen gemensam katalog. Undersök om en gemensam behörighetskatalog kan användas, t.ex. lokalt Active Directory (AD) eller motsvarande.
• Fristående meddelandeklienter kan innebära att en klientspecifik behörighetskatalog behöver administreras.

4.2.4 Säkerhet mellan interna komponenter

Kommunikation mellan komponenter t.ex. accesspunkt, meddelandetjänst och meddelandeklient ska vara transportkrypterad och autentisering av systemen ska tillämpas (endast behöriga system ska kunna hantera information).

Rekommendation

• Komponenter som hanterar SDK-meddelanden måste vara anpassade för att hantera känsliga personuppgifter.
• IT-säkerhetsbilagan innehåller detaljerade krav på säkerhet och säkerhetsprotokoll.

4.3 Yttre säkerhet (mellan deltagarorganisationer)

Informationsöverföring mellan deltagarorganisationer hanteras av AP-operatörens accesspunkt. Diggs regelverk och specifikationer reglerar säkerhet mellan accesspunkter. I huvudsak är det nedanstående säkerhetsmekanismer som tillämpas, se även Plattform-informationssäkerhet och tillitsmodell. Länk till annan webbplats.

Hanteras av AP-operatör - accesspunkt:

• Transportkryptering (mTLS) kan även implementeras i skalskydd.
• Tillförlitlig källa för metadata och teknisk adressering. Signering av metadata i metadatatjänst (SMP) och Certifikatspubliceringstjänst (CertPub, del av SMP).
• AS4 meddelandekryptering (WS-Security AP till AP).

Hanteras av deltagarorganisation - meddelandetjänst:

• Kryptering och signering av nyttolast för SDK-meddelandet samt signering av kvittensmeddelande.
• Meddelandet krypteras och signeras innan det lämnas till accesspunkt för meddelandeöverföring.
• Behörighetshantering mellan accesspunkt och meddelandeklienter.

Läs mer om säkerhet i SDK SAD.

Rekommendation

• Använda stödfunktioner i SDK QA-miljö som hjälper deltagarorganisationen att validera följsamhet till tekniska krav.

5. Säkerhet i IT-drift

SDK har inte tagit fram SDK-specifika krav på lokal IT-drift. Vid anslutning till SDK regleras ansvarsförhållanden samt förväntningar gällande SLA, se bilaga för tillgänglighet inom SDK. Anslutande deltagarorganisation förväntas ha en säker och robust IT-drift eller ha förmåga att kravställa en säker IT-miljö. Deltagarorganisationen ska säkerställa att lokal IT-miljö är utformad på ett sätt så den kan hantera känsliga personuppgifter.

Rekommendation

• SKR/Inera har tagit fram bra anvisningar inom området som är tillgängliga för regioner och kommuner. Dessa anvisningar finns tillgängliga via Ineras kundservice.
  • Anvisning för Säkerhet i drift
  • Anvisning för Loggning i driftsmiljön
  • Anvisning Informationssäkerhet
• Digg har tagit fram ett beskrivande dokument som syftar till att öka medvetenhet och skapa förståelse kring Informationssäkerhet och tillit inom plattformen för eDelivery samt anslutning av federationer för samtliga intressenter oavsett roll.
  • Plattform - Informationssäkerhet och tillitsmodell Länk till annan webbplats.

6. Övergripande arkitektur

Avsnittet beskriver vilka övergripande frågor som behöver utredas för att kunna välja rätt anpassnings- och anskaffningsstrategi för att etablera lokal SDK-federation.

6.1 Ansvar för SDK:s olika delar

Utifrån SDK:s ovanstående övergripande arkitekturskiss fördelas ansvaret för att etablera komponenterna samt kravuppfyllnad enligt tabell nedan.

Kolumnen Omfattning ger en indikation på omfattning av resursbehov (tid eller kostnad) för att etablera SDK.

• S: Small
• M: Medium
• L: Large

Rekommendation

• Analysera vilka verksamhetsprocesser eller verksamhetsfunktioner som ska anslutas till SDK-federationen.
• Analysera vilka verksamhetssystem eller meddelandeklient (-er) som kan användas för att stödja en verksamhetsprocess/verksamhetsfunktion.
• En meddelandeväxel är en strategisk lokal SDK-förmåga som bör kunna stödja mer än ett verksamhetssystem/meddelandeklient.
• Analysera om er organisation har en gemensam behörighetshantering (t ex AD) som kan användas för behörighetsstyrning av funktionsbrevlådor i meddelandeklient.
• Komponenter kan etableras genom upphandling, avrop mot (framtida) ramavtal eller tas fram av egna resurser.
• Analysera vilka anpassningsmöjligheter som finns i verksamhetssystem/meddelandeklient
• Informationssäkerhetskrav:
  • Krav på multifaktorautentisering (meddelandeklient/verksamhetssystem)
  • Krav på behörighetsmodell

7. Meddelandeklient, meddelandetjänst och accesspunkt

Tabellen nedan sammanställer områden som kan underlätta anslutande parts förstudie inför införande.

7.1 Meddelandeklient - Verksamhetssystem

En verksamhetsprocess, t ex att skicka/ta emot en orosanmälan, representeras i SDK adressbok i form av en funktionsadress. Det är meddelandeklient/verksamhetssystem som ansvarar för lagring av meddelanden (ärendehistorik etc). Alla funktionsadresser som skapas i SDK adressbok ska i slutändan levereras till en meddelandeklient eller ett verksamhetssystem. Hur många meddelandeklienter eller verksamhetssystem som ska anslutas till SDK-flöden får avgöras av det lokala IT-landskapets utformning.

Meddelandeklienten ska också ha ett behörighetssystem som säkerställer att endast behörig användare har tillgång till information som förmedlas via SDK-federationen. Meddelandeklienten/verksamhetssystemet behöver kunna hantera två meddelandetyper (dokumenttyper, xml-meddelanden) som krävs inom SDK. Se bilaga om meddelandetyper.

Rekommendation

• Säkerhet
  • Multifaktor autentisering av användaren (t.ex. e-legitimation eller motsvarande)
  • Behörighetskontroll av användare
• Meddelande
  • Meddelandeklient/verksamhetssystem måste kunna skapa och hantera meddelande och meddelandekvittens enligt specifikation.
• Integration
  • Meddelandeklient/verksamhetssystem integreras med meddelandetjänst/meddelandeväxel.
    • Om möjligt används av Digg rekommenderade API:er
      • Integreras med meddelandetjänst/meddelandeväxel (Skicka/ta emot meddelanden, kontrollera meddelandestatus/kvittens)
    • Integration med SDK adressbok är nödvändig, alternativt ha en egen lokal läskopia av adressboken.

7.2 Meddelandeformat

När det gäller meddelandeklient eller verksamhetssystem kan det vara enklare att initialt välja en dedikerad meddelandeklient eftersom den kan vara enklare att anpassa enligt SDK meddelandeformat.

Meddelandeformatet är “e-post liknande” innehållsmässigt enligt följande övergripande struktur:

• Message
  • MessageHeader
    • Recipient
    • Sender
  • Message
    • Subject
    • Text
    • Attachement

Rekommendation

Man bör undersöka att meddelandeklienten eller verksamhetssystemet kan:

• hantera meddelanden (dokumenttyper)
  • Innehållsspecifikation Meddelande, se Innehållsspecifikation Meddelande.
  • Meddeladekvittens, se Meddelandespecifikation – Meddelande. Länk till annan webbplats.
• hantera bifogade filer i form av t ex PDF.
• sortera meddelanden enligt en meddelandetråd (konversations-id).
• presentera statusmeddeland tillsammans med meddelanden:
  • Transportkvittens - Meddelande har levererats till mottagarens accesspunkt
  • Meddelandekvittens - Meddelandet är validerat och är tillgängligt för mottagaren
  • Felhantering - Felmeddelanden

7.3 Meddelandetjänst - meddelandeväxel

Deltagarorganisationen behöver etablera en komponent som kallas meddelandetjänst/meddelandeväxel (MT). MT kan beskrivas som en integrationsmotor som löpande hämtar och lämnar meddelanden mellan accesspunkten och meddelandeklienter/verksamhetssystem (t ex via dess interna API:er; SOAP eller REST).

• Meddelandetjänsten ansvarar för att:
  • Kryptera, dekryptera, signera och validera signatur av meddelanden.
  • Validera SDK-meddelanden, dvs kontrollera att meddelandet följer schema och regelverk.
  • Kontrollera att funktionsadressen är korrekt och att den är aktiv.
  • Skapa ett kvitteringsmeddelande, inkl felmeddelanden om den funktionsadress som har angivits inte är aktiv.
  • Ansvarar för att "routa" meddelanden till verksamhetssystemen (meddelandeklienter) som ansvarar för funktionsadressen. Man bör ta höjd för att kunna hantera flera meddelandeklienter.
  • Svarstidsbevaka skickade meddelanden, dvs att ett skickat meddelande kvitteras av mottagaren. En kvittering innebär att meddelandet är utlämnat och har nått mottagaren.
  • Kommunicera meddelandestatus till meddelandeklient/verksamhetssystem.
• Integrationsgränsnitt:
  • Öppet integrationsgränssnitt (API) för att integrera med olika meddelandeklienter och accesspunkter.
  • Stödja API:er som Digg rekommenderar.
• Ett säkerhetskoncept för att säkra organisationens “inre säkerhet”:
  • Transportkryptering
  • Autentisering av systemkomponenter
  • Behörighetskontroll
  • Certifikat för signering och kryptering av meddelanden.
• Externa komponenter:
  • DNS för dynamisk inhämtning av metadata från SMP.
  • CertPub (SMP) register med deltagarorganisationers publika nycklar (kryptering, validering av signatur).
  • SDK adressbok för adressuppslag.

Meddelandetjänsten utgör en meddelandeväxel som transporterar meddelanden mellan meddelandeklienter, t ex olika verksamhetssystem, och deltagarorganisationens accesspunkt. Nedanstående tabell listar övergripande funktioner/förmågor som komponenten behöver stödja.

Se även testfall för meddelandesystem för anslutning till OPEN-TEST.

Rekommendation

Meddelandetjänst/meddelandeväxel är en komponent där utveckling/anpassning är nödvändig.

• Alla meddelanden krypteras genom att tillämpa Diggs specifikationer XHE. Se Transportmodell – utökad bas Länk till annan webbplats., och Kuverteringsprofil XHE Länk till annan webbplats..
• Varje meddelande (dokumenttyp) har sin tekniska utformning och valideringsregelverk.
• Meddelandeklienter måste integreras via meddelandetjänsten.
• Meddelandetjänsten bör ha ett öppet tillgängligt API som möjliggör integration mot olika accesspunkter och meddelandeklienter.

7.4. Accesspunkt (AP)

Accesspunkten är en integrationskomponent som är baserad på en standardiserad mjukvara. Accesspunkten består av applikationsserver, applikation och databas. Komponenten skall installeras och konfigureras enligt Diggs anvisningar för att fungera i SDK-federationen. Se Transportpofil AS4 Länk till annan webbplats., PKI för accesspunkter Länk till annan webbplats. samt Accesspunktsoperatör – gemensamma regler och rutiner. Länk till annan webbplats.

Accesspunkt medger anpassade interna integrationsgränssnitt beroende på mjukvara.

En accesspunkt som är integrerad i SDK-federationen kommer automatiskt att ta emot och leverera meddelanden till/från deltagarorganisationer inom federationen. Accesspunkten hanterar endast transport av meddelanden. Meddelanden skapas och hanteras av meddelandetjänsten.

Lokalt ansvar:

• Anskaffa en Accesspunkt
  • Alternativ: Via extern AP-operatör.
  • Alternativ: Ansöka om att bli AP-operatör.
  • Välja vilken mjukvara som ska användas som accesspunkt Länk till annan webbplats..
    • Installera och konfigurera accesspunkt (applikationsserver, applikation, databas).
    • Konfigurera enligt Diggs anvisningar.
      • Installera godkänt certifikat i accesspunkt.
      • Konfigurera “trust” till godkända certifikatsutställare.
    • AP-operatör registrera vilka dokumenttyper och deltagarorganisationer som accesspunkten skall kunna skicka och ta emot (hanteras via anslutningsprocess).
    • Federationsägare godkänner registrering i SDK-federation.
    • Accesspunkt integreras mot meddelandetjänst (MT).

Rekommendation

• Anskaffa godkänd accesspunkt via en AP-operatör eller ansök själv om att bli AP-operatör hos Digg.
• Anpassa lokal driftinfrastruktur för kommunikation mellan accesspunkter. Säkerställ transportkryptering (TLS) t ex terminering av TLS.
• Accesspunkt bör ha ett öppet tillgängligt API som möjliggör integration mot olika meddelandetjänster.

8. SDK adressbok

SDK adressbok är ett gemensamt adressregister för information om SDK-anslutna deltagarorganisationer och funktioner inom dessa. SDK adressbok är en komponent i SDK-federatioen.

Syftet med SDK adressbok är:

• Att vara en källa för adressuppgifter genom att behöriga användare registrerar och underhåller information om en deltagarorganisation och dess funktioner (funktionsadresser) via adressbokens administrationsgränssnitt.
• Att tillhandahålla funktionalitet för att hitta mottagare genom att SDK-anslutna deltagarorganisationer kan söka och hitta andra anslutna deltagarorganisationer och deras funktionsadresser.

Adressboken tillhandahåller ett integrationsgränssnitt ett så kallat Sök-API som kan användas för direktintegration eller skapa en lokal läskopia. Deltagarorganisationen anger behöriga administratörer under anslutningsprocessen och administrera själv sin information.

8.1 Strukturera adressboken - Använda standardiserade sökord

Adressboken ska struktureras för att stödja externa parters behov av att hitta rätt mottagare inom respektive deltagarorganisation. Adressboken ska inte vara strukturerad utifrån den intern organisationsstrukturen. Funktionsadresser i SDK adressbok behöver beskrivas på ett enhetligt standardiserat sätt för att stödja extern sökning. Detta uppnås genom att tillämpa sökord för funktionsadress enligt de kodverk som finns tillgängliga inom SDK adressbok.

I SDK finns i huvudsak tre typer av kodverk för att stödja behovet av att hitta rätt mottagare:

• Geografisk hemvist: Var tillhandahålls funktionen (kommun, län eller nationellt).
• Strukturkodver: Placering av funktion i verksamhetsstrukturen.
• Sökkodverk: En sökkod (sökord) för en specifik funktion.

Rekommendation

• Undersök om de kodver som finns tillgängliga i SDK adressbok kan tillämpas eller om nya kodverk behöver läsas in i eller tas fram.
• Strukturera funktionsadresser enligt Handledning för administratörer i SDK adressbok.

8.2 Integrera med/söka i SDK adressbok

Användare av meddelandeklienter/verksamhetssystem behöver kunna söka i SDK adressbok för att adressera ett meddelande. SDK adressbok innehåller alla anslutna deltagarorganisationers funktionsadresser.

Integration mot SDK:s adressbok kan göras via SDK:s Sök-API. Sök-API är framtaget för att stödja direktsökning men kan även användas för att skapa en lokal läskopia.

• Skapa en lokal läskopia av adressboken
  • Genom att uppdatera en lokal läskopia kan integration med meddelandeklienter/verksamhetssystem underlättas då befintlig funktionalitet kan återanvändas.
• Direktintegration via adressbokens Sök-API.
  • Funktioner: Fritextsökning, sökning baserat på urval och kodade värden.
• Strukturerad sökning
  • Tillämpa kodverk

Lokal läskopia:

Fördelar:

• Integration med befintlig kataloglösning kan underlätta integration med meddelandeklient/verksamhetssystem.
• Enklare integration.
• Mindre påverkan på meddelandeklient/verksamhetssystem.
• Minskar lokal påverkan vid SLA störningar i central adressbok.

Nackdelar:

• Avancerad kodad sökning mot adressboken kan vara svår att realisera.
• Lokal läskopia måste hållas uppdaterad och säker.
• Uppdateringar kan ta längre tid innan dessa får genomslag.

9. Leverantörsmarknad

Idag finns inget specifikt ramavtal för SDK-komponenter. Adda inköpscentral erbjuder kommuner och regioner stöd i form av ett dynamiskt inköpssystem för Säker digital kommunikation. Mer information om det stöd som erbjuds via Adda finns att läsa här: https://www.adda.se/upphandling-och-ramavtal/planerade-och-pagaende-upphandlingar/saker-digital-kommunikation-DIS Länk till annan webbplats.

Det finns även ett antal leverantörer som erbjuder SDK-komponenter, kontakta sdk@digg.se för mer information.

Etablering kan ske via befintligt avtal eller genom direktupphandling.

Rekommendation

• Ta ställning till om ni vill ta del av Addas dynamiska inköpssystem för Säker digital kommunikation.
• Undersök om befintliga avtal kan användas för att anskaffa och anpassning av nödvändig mjukvara.