Tjänsteavtal för ehälsotjänst

Tjänsteavtal för ehälsotjänst

INNEHÅLLSFÖRTECKNING 1. Inledning... 3 2. Samverkansformer... 3 2.1. Strategisk nivå... 3 2.2. Operativ nivå... 3 3. Samverkansprocesser... 3 3.1. Incidenthantering... 3 3.1.1. Incidentklassificering... 4 3.1.2. Eskaleringskedja... 5 3.2. Problemhantering... 5 3.2.1. Problemklassificering... 6 3.2.2. Generella principer... 6 3.3. Ändringshantering... 6 3.3.1. Ändringsklassificering... 7 3.3.2. Ändringsråd... 7 3.3.3. Ändringsstyrgrupp... 7 3.4. Releasehantering... 7 3.4.1. Processbeskrivning... 8 Inera B Box 177 03 Sid 2/8

1. INLEDNING Detta dokument utgör Bilaga 5, Samverkansformer och, till det Tjänsteavtal som upprättats mellan Inera och Kunden. 2. SVERKNSFORER Samverkansmodell för Tjänsten samt tilläggstjänster baseras på följande samarbetsorganisation. 2.1. Strategisk nivå På strategisk nivå sker den övergripande uppföljningen av Tjänsten, tilläggstjänster och anslutna system. Parterna kan exempelvis diskutera slutanvändares nyttjande av Tjänsten, förändringar och tillägg i Tjänsten samt större problem i Tjänsten. Inera beslutar om vilka förändringar och tillägg som ska införas i Tjänsten. Inera är sammankallade för möten på strategisk nivå. Sammansättning och form för sådana möten kan variera. Sådana möten ska ske regelbundet ca två (2) gånger per år. 2.2. Operativ nivå På operativ nivå hanteras frågor, incidenter och problem som rör den dagliga driften av Tjänsten, tilläggstjänster och anslutna system. Parterna ska kontinuerligt följa upp och kvalitetsgranska Tjänsten och integration av Kundens system. Sådan kvalitetsuppföljning ska ske kontinuerligt. På operativ nivå ska parterna även kommunicera information om driftstörningar och planerade ändringar och releaser i Tjänsten, tilläggstjänster samt anslutna system. Inera är sammankallande för möten på operativ nivå. Sammansättning och form för sådana möten kan variera. Kund förväntas delta på möten på operativ nivå ca fyra (4) gånger per år. 3. SVERKNSPROCESSER 3.1. Incidenthantering En incident kan t.ex. vara ett fel som härleds till en applikation eller ett systemsamband, en driftstörning eller ett fel i en tredjepartsprodukt. Incidenter i Tjänsten ska åtgärdas utan dröjsmål. vhjälpande ska ske genom rättelse, omleverans eller genom annat lämpligt kringgående (workaround). Om det visar sig att incidenten kräver ändring i Tjänsten initieras en ändringsbegäran, se rutiner för ändringshantering i punkt 3.3. Inera B Box 177 03 Sid 3/8

Var part ska ansvara för incidenthantering som föranletts av incident inom respektive parts ansvarsområde eller som orsakats av omständighet för vilken parten ansvarar. 3.1.1. Incidentklassificering Parterna ska kategorisera och prioritera incidenter enligt nedanstående tabell. Kategori Prio 1 Kritisk Påverkan llvarliga incidenter som har stor verksamhetskritisk påverkan för Kunden och/eller där Tjänsten inte kan nyttjas alls, alternativt endast nyttjas med för aktuell tjänst oacceptabel prestanda. Prio 2 Hög Prio 3 edel Prio 4 Låg llvarliga incidenter med viss verksamhetskritisk påverkan för Kunden och/eller där Tjänsten inte kan nyttjas i sin helhet. Incidenter med liten verksamhetspåverkan för Kunden och där verksamheten hos Kunden kan fortgå som vanligt. Påverkar en eller ett fåtal slutanvändare hos Kunden. indre avvikelser eller skönhetsfel utan direkt verksamhetspåverkan. Låg grad av fel som endast kräver aktivering av problemsökning efter överenskommelse. vhjälpning av incident ska påbörjas inom nedan angiven responstid. vhjälpning ska anses påbörjad då incidenten är registrerad och prioriterad. Responstid räknas från det att anmälan om incident inkommit till Inera eller från det att Inera själv identifierat en incident. Inera är endast skyldig att upprätthålla respektive responstid under angiven beredskapstid. Prioritet Responstid Beredskapstid Åtgärdstid Prio 1 - Kritisk Prio 2 Hög Trettio (30) minuter En (1) timme Dygnet runt Dygnet runt vhjälpning ska påbörjas inom responstiden och incidenten bör vara åtgärdad inom fyra (4) timmar. För det fall Inera inte finner det möjligt att åtgärda incidenten inom föreskriven tid, ska Inera återkoppla till Kunden med besked om när incidenten beräknas vara avhjälpt. vhjälpning ska påbörjas inom responstiden och incidenten bör vara åtgärdad inom fyra (4) timmar. För det fall Inera inte finner det möjligt att Inera B Box 177 03 Sid 4/8

Prioritet Responstid Beredskapstid Åtgärdstid åtgärda incidenten inom föreskriven tid, ska Inera återkoppla till Kunden med besked om när incidenten beräknas vara avhjälpt. Prio 3 - edium Två (2) timmar Kontorstid, helgfria vardagar Inera ska återkoppla till Kunden inom responstiden. vhjälpning och åtgärd sker enligt överenskommelse mellan Inera och Kunden. Prio 4 Låg Tjugofyra (24) timmar Kontorstid, helgfria vardagar Inera ska återkoppla till Kunden inom responstiden. Incidenter med prio 4 hanteras inom problemhantering. 3.1.2. Eskaleringskedja Incidenter som påverkar användning av Tjänsten för slutanvändare hos Kunden rapporteras till den lokala supporten hos Kunden. Om en incident inte omfattas av den lokala supportens ansvar ska den lokala supporten anmäla sådan incident till Nationell Kundservice som tillhandahålls av Inera. Nationell kundservice ansvarar för att utreda anmäld incident och ska vid behov involvera berörda aktörer, såsom systemförvaltning hos Inera, Försäkringskassan eller underleverantör. Incidenter som påverkar invånare vilka är slutanvändare av Intygsapplikationen anmäls till supporttjänst som anvisas i Intygsapplikationen. 3.2. Problemhantering ed problem avses orsaken till en eller flera incidenter. Syftet med problemhantering är att minimera omfattningen av antalet incidenter genom att hitta och åtgärda grundorsaken till aktuellt problem. vsikten är att skapa en permanent lösning. Vid problemhantering undersöks orsaken till återkommande incidenter, varefter en djupare analys av orsaken genomförs och ett permanent åtgärdsförslag utformas. Åtgärdsförslaget innehåller en uppskattning över tidsåtgången för genomförandet och eventuell påverkan på Tjänsten. Inera B Box 177 03 Sid 5/8

3.2.1. Problemklassificering Parterna ska klassificera och prioritera problem enligt nedanstående tabell. Kategori Prio 1- Kritisk Prio 2 Hög Prio 3 - edel Prio 4 Låg Påverkan ycket allvarlig nedgång av systemfunktionalitet, saknade funktioner eller andra komponenter i leveransen jämfört med vad som överenskommits i specifikationer och tjänstekontrakt. Tjänsten kan inte användas av Kunden. arkant degradering av funktionalitet och/eller prestanda i hela eller delar av Tjänsten jämfört med vad som överenskommits i specifikationer och tjänstekontrakt. Tjänsten kan användas av Kunden med hjälp av workarounds eller under vissa begränsningar. indre degradering eller begränsning av funktionalitet och/eller prestanda i hela eller delar av Tjänsten jämfört med vad som överenskommits i specifikationer och tjänstekontrakt. ktuell tjänst fungerar tillfredsställande trots felet och kan användas av Kunden. Fel som inte påverkar Tjänstens prestanda, stabilitet, funktionalitet eller orsakar missförstånd, exempelvis felstavningar, mindre fel i användargränssnitt etc. 3.2.2. Generella principer Inera ansvarar för problemhantering avseende Tjänsten. Kunden ansvarar för problemhantering avseende sina egna system. Lösning i produktion enligt åtgärdsförslag ska ske i enlighet med bestämmelser för ändringshantering i punkt 3.3. 3.3. Ändringshantering ed ändring avses tillägg, modifiering eller borttagande av något som kan påverka Tjänsten, exempelvis lösning av incident, problem, uppgradering eller driftsättning av ny version av Tjänsten. Ändringshantering startar med en ändringsbegäran, vilken initieras vid möten på såväl strategisk som operativ nivå. Samtliga ändringar i Tjänsten ska hanteras i enlighet med denna punkt 3.3. Härutöver ska sådana ändringar i Kundens system som påverkar integrationen till Tjänsten anmälas till Inera i skälig tid innan sådan ändring ska implementeras. Inera ansvarar för ändringar i Tjänsten. Kunden ansvarar för ändringar i sina egna system. Inera B Box 177 03 Sid 6/8

Inera ansvarar för att tillhandahålla ändamålsenliga testmiljöer, testfall och testdata. Inera ansvarar vidare för att Kunden inför test informerats om kriterier för godkännande av test. Genomförd ändring ska dokumenteras och part ska skriftligen återkoppla till den andra parten avseende resultatet av genomförd ändring. 3.3.1. Ändringsklassificering Ändringar ska kategoriseras och prioriteras enligt nedanstående tabell. Kategori kut Standard Normal Notering kuta ändringar hanteras på operativ nivå och tillämpas vid problemklass Kritisk och Hög. Ändringen utvecklas, testas och levereras till driftsättning omgående. Då omständigheterna kräver det kan akut ändring driftsättas utan föregående acceptanstest. Ändringar som på förhand överenskommits mellan parterna ska klassificeras som Standard. Ändringen är enkel, väl beprövad och medför minimal risk. Ändringsarbetet kan starta så snart en ändringsbegäran inkommit. Normala ändringar behandlas på operativ nivå och tillämpas på problemklass edel och Låg. Beslutade ändringar dokumenteras och tidsplan för ändringsarbetet fastställs. 3.3.2. Ändringsråd Ineras ändringsråd ( CB ) har till uppgift att granska tjänsteövergripande systemändringar för de kommande tolv (12) månaderna och granska ändringsbegäran inför driftsättningsbeslut hos ändringsstyrgruppen (se punkt 3.3.3). Ordförande för CB har mandat att besluta om ett första godkännande, alternativt avslag, av tjänsteövergripande systemändringar. 3.3.3. Ändringsstyrgrupp Ordförande för Ineras ändringsstyrgrupp ( CCB ) beslutar om driftsättning alternativt avslag av driftsättning av release utifrån ändringsbegäran som beslutats om i ett första skede av CB. 3.4. Releasehantering En release är en samling komponenter som krävs för att införa en eller flera godkända ändringar. Releasehantering omfattar planering, schemaläggning och kontroll när releaser flyttas till test- och produktionsmiljö. Inera ska utföra tester av release för Tjänsten i Ineras testmiljö. Releasen ska dokumenteras med Release Notes, installationsförfarande, om tillämpligt instruktion för avinstallation av tidigare release samt backningsförfarande. Inera B Box 177 03 Sid 7/8

lla releaser ska planeras och godkännas av CB och CCB enligt punkterna 3.3.2-3.3.3. 3.4.1. Processbeskrivning I ändrings- och releaseprocessen ingår att motta och utreda ändringsbegäran och förbättringsförslag, besluta om införande, planera, schemalägga, testa och godkänna resultatet samt driftsätta en ny release. Ändrings- och releasehantering ska ske enligt följande process. Nr ktivitet Kommentar Kund Inera 1 Lämna önskemål och krav på ändring. 2 otta, analysera och prioritera önskemål och krav på ändringar från Kund. 3 Om ett önskemål eller krav är motiverat, gör en ändringsbegäran. 4 Ta fram underlag till Strategisk nivå för beslut. 5 Gå igenom ändringsbegäran på Strategisk nivå. Besluta om åtgärd, dvs. om och när ändringsbegäran ska införas. 6 Gör upp en ändrings- och releaseplan, dvs. fastställ releasens innehåll samt tidpunkt. Kunden medverkar vid prioritering av önskemål och krav på ändringar. Inera är sammankallande till möten på Strategisk nivå. 7 Tillverka och testa ändring. 8 Informera intressenter om kommande release. 9 Godkänn och driftsätt release. 10 Implementera och testa releasen i egen testmiljö. = nsvarig = edverkar Inera B Box 177 03 Sid 8/8