Avrop av teknik

Det här avsnittet omfattar ett antal punkter som kan användas som stöd vid avrop av teknik för att införa och använda SDK. Under varje punkt finns några förslag på kravställning som gäller Accesspunkt och Meddelandesystem. Meddelandesystemet omfattar både Meddelandetjänst och Meddelandeklient. 

De regelverk som Digg har utformat omfattar en stor del av de krav som behöver ställas på Accesspunkten och Meddelandesystemet, men det finns områden som den organisation som avropar tjänster för SDK själv behöver komplettera med. Era egna unika behov påverkar naturligtvis också kravställningen. 

Vid ett avrop ställer ni förslagsvis funktionskrav som innebär att leverantören löpande ska leva upp till Diggs regelverk samt genomföra de tester som behövs för att ni ska kunna ansluta er till och använda infrastrukturen SDK.

Det kan vara affärsmässigt att beakta såväl era nuvarande behov av informationsutbyte via SDK som sådana som kan bli aktuella om några år. Ni kan även framtidssäkra krav, det vill säga att leverantören ”vid var tid” ska uppfylla det eller de regelverk ni efterfrågar. Fundera dock på vem som ska stå för risk och kostnader vid eventuella kommande förändringar av regelverken. 

Det sätt som tekniken ska tillhandahållas, som en tjänst eller som en lokalt installerad produkt, får stora konsekvenser för utformningen av de krav som behöver ställas vid ett avrop. 

Följsamhet mot Digg:s regelverk

Accesspunkt

Ramavtalsleverantören ska tillhandahålla en federationsgodkänd accesspunkt (eller inom 6 månader)

Ramavtalsleverantören ska vid var tid följa de regler och rutiner som Digg definierat för accesspunktsoperatörer och accesspunktsfunktionen som agerar i SDK-federationen.

Meddelandesystem

Meddelandesystemet ska vid var tid finnas på listan över system som genomfört av Digg godkända tester (eller inom 6 månader)

Meddelandesystemet ska vid var tid följa regler och rutiner enligt Digg:s regelverk för SDK.

Funktionella krav för meddelandesystemets användning

Det är viktigt att ställa krav som gör det möjligt att använda meddelandesystemet på ett effektivt sätt i de verksamhetsprocesser ni har valt för SDK, exempelvis:

• Användning av referenser, notifieringar och arbetsflöde 
• Loggning av händelser i systemet (inloggningar, skapa/ta bort/ändra meddelanden)
• Efterlevnad av specifika lagkrav med mera som rör verksamhetsprocessen och som kan ha konsekvenser för utformningen av meddelandesystemet.

Exempel som gäller notifieringar

• Avsändaren får kvittenser från mottagaren. Den som sänder ett meddelande via SDK ska, enligt Digg:s regelverk, notifieras av sin accesspunktsoperatör om meddelandet inte kan förmedlas till mottagarens Accesspunkt. Därmed har avsändaren möjligheter att vid behov vidta åtgärder, till exempel kontakta mottagaren på annat sätt. Vidare innebär Digg:s regler att avsändaren får en meddelandekvittens som innebär ”Levererat, läsbart och betrodd avsändare” när meddelandet kommit fram till mottagarens Meddelandetjänst. Om kopplingen mellan Accesspunkten och Meddelandetjänsten hos mottagaren inte fungerar skickas ingen meddelandekvittens och Meddelandesystemet ska notifiera avsändaren. Enligt Digg:s ”Bilaga för tillgänglighet inom SDK, avsnitt 2.2, ska mottagande Meddelandesystem skicka en meddelandekvittens inom 15 min till avsändarens Meddelandesystem. Vid ett avrop av Meddelandesystem kan det vara bra att beskriva hur notifieringarna ska utformas, till exempel att ”om ingen meddelandekvittens erhållits inom 15 minuter efter att ett meddelande har skickats ska avsändaren notifieras med e-post till en angiven e-postadress”.
• Mottagaren – När avsändaren har fått en mottagningskvittens av mottagarens Accesspunkt övergår ansvaret för handläggningen till mottagaren. De aktuella verksamhetsprocesserna får därefter avgöra behovet av att ställa krav på att tjänsten ska notifiera eventuella avvikelser, till exempel fördröjningar i mottagarens hantering som beror på att kopplingen mellan Accesspunkt och Meddelandetjänst inte fungerar, anställdas frånvaro eller liknande.

Såväl avsändare som mottagare behöver utforma rutiner för hur eventuella notifieringar ska tas om hand.

Krav som följd av det strategiska teknikvalet

Funktionerna kan avropas som tjänst eller som en programvara/produkt som ska installeras i era egna miljöer. Vägvalet får stora konsekvenser på krav på integrationer, servicenivåer och migrering. Det påverkar även behovet av intern kompetens. Vid köp av programvara behövs till exempel en egen administration för certifikatshantering, bevakning av förändringar i Digg:s regelverk med mera. 

Integration

Det behövs integrationer, dels sättet som accesspunkten och meddelandesystemet kommunicerar med varandra, dels hur meddelandeklient/verksamhetssystem ansluts till meddelandetjänsten.

Det finns standardiserade applikationsgränssnitt (API) för integration mellan Meddelandetjänst och Meddelandeklient. Meddelandesystemet ska integreras med SDK:s adressbok. Kontakta Digg för mer information.

På Diggs webb finns länkar till stödjande information som underlättar vid anslutning till SDK, där du bland annat kan läsa mer om SDK:s arkitektur.

Om de olika delarna upphandlas från olika leverantörer är det extra viktigt att säkerställa att tekniken för integrationen stöds på respektive sida. Tänk också på att klargöra ansvaret för de notifieringar ni ska få vid eventuella avvikelser, till exempel om ett meddelande inte förs över från Accesspunkten till Meddelandetjänsten eller inte kommer fram till rätt mottagare i Meddelandeklienten.

Servicenivåer, felsökning och support

Diggs gemensamma regler för accesspunktsoperatörer (avsnitt 3.7, punkt f), innebär att den organisation som anskaffar teknik för att använda SDK bör avtala om servicenivåer och stöd. Däremot finns det i nuläget inga detaljerade krav på servicenivåer avseende tillgänglighet, svarstider osv på accesspunktsfunktioner och meddelandesystem. Vid ett avrop är det därför viktigt att tydliggöra denna typ av krav, exempelvis:

• Tillgänglighetsnivå (anges ofta som en procentsats av en månads tid)
• Svarstider
• Utökade krav på hantering av stora filer (om det finns behov att hantera filer som är större än den miniminivå som Digg reglerat).

Andra krav kopplade till felsökning och support kan till exempel vara:

• Ramavtalsleverantören ska etablera kontaktvägar för driftstörningar och incidenthantering (Gemensamma regler, punkt 4.2, a och b.) 
• Ramavtalsleverantören ska aktivt felsöka och utreda felsituationer som uppkommer (och som inte hanteras automatiskt i SDK (exempelvis genom kvittenshantering)
• Ramavtalsleverantören ska vara behjälplig när avropsberättigad felsöker.

Kontinuitetshantering

Ramavtalsleverantören ska under ramavtalsperioden arbeta med kontinuitetshantering gällande den egna verksamheten, se exempel Ramavtalet Operatörstjänst för elektroniska meddelanden, Upphandlingsdokumentet avsnitt 6.10.6.

Migrering i samband med att kontrakt upphör att gälla

Digg:s regelverk omfattar inte rutiner för migrering i samband med att kontraktet upphör att gälla. Därför är det viktigt att ställa krav kring detta. Exempel på krav:

• Avropsberättigad ska kunna ladda hem information/loggar (även vid andra tidpunkter än vid avslut av kontrakt)
• Permanent borttagning av data efter kontraktets avslut
• Leverantören ska vara behjälplig med avregistrering/påregistrering om avropsberättigad byter accesspunkt eller meddelandetjänst (planeras gemensamt för att minimera fönstret då avropsberättigad inte är synlig i SMP och adressbok).

Äganderätt till information

Vid ett avrop är det viktigt att tydliggöra äganderätten av den information som hanteras i meddelandesystemet och accesspunkten, till exempel meddelanden, loggar, statistik med mera. Ramavtalsleverantören har inte rätt att använda informationen för andra ändamål än för upprätthållandet av tjänsten.

Revision

Se ramavtalens avsnitt rörande revision och fundera på om ni behöver anpassa dem. 

Ramavtal

Meddelandesystem samt accesspunkt till infrastrukturen för SDK kan avropas från ramavtalet för
Informationsförsörjning. 

Accesspunkt till infrastrukturen för SDK kan avropas från ramavtalet
Operatörstjänst för elektroniska meddelanden. För närvarande rekommenderar vi en RFI (Request for information) innan ett eventuellt avrop.