You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »

Version 0.2 Jan 2018

SDS Incident Management


Processen gælder for incidents der er indmeldt fra de enheder der supporterer brugere af de systemer, som SDS stiller til rådighed for parter i sundhedsvæsenet. Dette gælder således Produktions-, test- og uddannelses-miljøer.

Formålet med processen er at sikre en ensartet, struktureret, effektiv og dokumenteret behandling af incidents vedrørende de relevante løsninger. Processen skal være gennemskuelig for alle involverede parter. Samtidigt skal processen sikre en afstemt og præcis kommunikation til alle relevante interessenter for alle incidents. Dette gælder både udmeldinger på NSPOP og direkte kommunikation med primære interessenter ved P1 og P2 incidents.

Procesdokumentation 

Incident Management Proces flow og beskrivelse

Beslutningsregler ved løsning af Incidents

RACI og Rollebeskrivelser

Udmeldinger på NSPOP ifm. incidents

Kartotek med Standardudmeldinger: Standardudmeldinger V 1.03.xlsx

Kontaktpersoner for systemerne

Termer og definitioner for systemerne

Kategorisering (prioritet) af Incidents

Incident kategoriseres i forhold til impact (indvirkning på forretningen) og urgency (hvor hurtigt servicen skal genetableres). Prioriteringen af incident foretages af Sundhedsdatastyrelsens Nationale Service Desk, SDS eller 3. parts leverandør på baggrund af beskrivelse fra indmelderen.

Tabellen nedenfor beskriver de anvendte kategorier/prioriteringer samt mål for reaktionstid og løsningstid. Bemærk at målene for reaktionstid og løsningstid ikke er en SLA definition, men et udtryk for best effort. Dette betyder blandt andet at P1 og P2 incidents som udgangspunkt skal løses så hurtigt som muligt.

KategoriBeskrivelseMål for reaktionstidMål for løsningstid

Critical
P1

En forretningskritisk(*) service er ikke tilgængelig, eller funktionaliteten er reduceret i et sådan omfang, at basale funktioner ikke er tilgængelige for slutbrugerne.

15 min hvis indenfor normal arbejdstid (**)
30 min hvis udenfor normal arbejdstid (**)

2 timer

Major
P2

Væsentlige funktioner er utilgængelige, eller en større gruppe af slutbrugere har ikke mulighed for at anvende servicen.1 time4 timer

Medium
P3

En eller flere væsentlige funktioner er utilgængelige. Et begrænset antal slutbrugere oplever manglende funktionalitet.4 timer (kun normal arbejdstid) (**)2 arbejdsdage

Minor
P4

Mindre fejl, mangler og uhensigtsmæssigheder, der påvirker servicen i mindre grad1 arbejdsdag10 arbejdsdage

 (*) Forretningskritiske services er FMK, NSP fysisk infrastruktur, Importer og dekoblingskomponent (DCC), Secure Token Service, Gateway, Stamdatamodul

(**) Normal arbejdstid er 8-16 (ma-to) og 8-15.30 fredage

Definition af reaktionstid

Reaktionstiden måles fra starttidspunktet for event (alarm sms eller telefonopkald) til tidspunktet for påbegyndelse af behandlingen af incidentet.

Hvis incidentet er modtaget som udfyldt Webformular, så måles reaktionstiden fra tidspunktet hvor Webformularen er modtaget.

Definition af løsningstid

Løsningsstiden måles fra starttidspunktet for event (alarm sms eller telefonopkald) til tidspunktet hvor incidentet er løst eller afvist.

Tiden hvor leverandøren afventer yderligere information, der er nødvendig for at fortsætte løsningsforløbet, fra indmelder medregnes ikke.

Ændring af incident prioritet

Prioriteten kan ændres hvis incidentet viser sig at være anderledes mht impact og urgency end først antaget. Prioriteten kan også ændres for en lukket incident. Dette skal kun gøres i undtagelsestilfælde, hvor det ikke var muligt at fastsætte prioriteten rigtigt under løsningsforløbet. En ændring af prioriteten for en incidents skal altid opdateres i IBM Clear Quest.

Incidents på Test eller uddannelses miljøer

Incidents på test og uddannelsesmiljøer kan kun være enten P3 eller P4.

Scope for processen

Scopet for Incident Management processen er enhver hændelse, som afbryder, kan afbryde eller kan nedsætte kvaliteten af en service. Dette inkluderer incidents der er indberettet til Sundhedsdatastyrelsens Nationale Service Desk (IBM) samt incidents, der er indmeldt/detekteret af Netic eller Trifork. 

Den primære måde at indberette et incident til Sundhedsdatastyrelsens Nationale Service Desk er ved at udfylde en Web formular (link), der genererer en mail til fællespostkasse hos IBM. Alternativ kan incidents indberettes ved at ringe på telefonnummer +45 72228601. Alle incidents, der er indmeldt via telefon skal også indmeldes ved at udfylde web formularen.

Incident Management Processen for SDS adskiller sig fra mange incident processer, idet fokus er på interessenthåndtering og processen ikke alene dækker hurtigst mulig tilbagevenden til normal drift. Sidstnævnte opgave varetages i regi af de eksterne leverandører. Løsning af incidents med udgangspunkt i kendte løsninger er omfattet af processen, mens det detaljerede flow for løsning af incidents hos 3. parts leverandører IKKE er omfattet processen.


Scope inkludererScope inkluderer IKKE
Incident indberetning og registrering i PROD, TEST og UDDEvent monitorering
Klassifikation og prioritering af incidentsEn request for ny service eller ændring af eksisterende Service
Visitering af incidents og allokering til 3. parts leverandørRoot cause analysis (Problem Management)
Løsning af incidents (kun på overordnet niveau)Service Requests, dvs simple request fra brugere, der ikke omhandler afbrydelse af service
Lukning af incidents og kommunikation til indberetterDetaljeret flow for løsning af incidents hos 3. parts leverandør
Opdatering af database med kendte løsninger
Aktivering af Problem management process for major incidents
Aktivering af Change Management proces hvis en løsning er tilgængelig og skal implementeres
Kommunikation med pressen ved pressehenvendelser vedrørende incidents
Kommunikation med primære interessenter vedrørende P1 og P2 incidents
Udmeldinger på NSPOP
Skrivning og godkendelse af Incident rapporter


Basale Regler og beslutninger

  • Der vil kun være én Incident Management process for alle Systemer og Services under NSP'en 
  • IBM ClearQuest er master for alle incidents (undtagen rene infrastruktur incidents), dvs at alle væsentlige ændringer på incidentet skal opdateres i IBM ClearQuest
  • Alle statusændringer på incidents der er sendt til løsning hos 3. parts leverandør (håndteret i JIRA) skal replikeres til ClearQuest.
  • 1st Level support udføres af den lokale service desk
  • 2nd level support udføre af Sundhedsdatastyrelsens Nationale service desk
  • 3rd level support udføres af 3. parts leverandør (Trifork, Netic, Arosii, Systematic, etc).  
  • Incident Prioritering

    • Prioriteten bestemmes af Sundhedsdatastyrelsens Nationale Service Desk ved registering af incidentet
    • Prioriteten kan efterfølgende ændres af SDS eller 3. parts leverandør, hvis dette er nødvendigt
    • Prioriteten bestemmes ud fra de angivne definitioner og guidelines, se ovenfor.
    • Prioriteten kan ændres efter lukning af incidentet. Dette skal ske undtagelservist i tilfælde hvor det ikke var muligt at bestemme den korrekte prioritet af incidentet under løsningsforløbet

Relationer til SOP'er og andre processer


Proces / SOP NavnBeskrivelse af relationen
Problem ManagementOverordnet sker den samlede analyse af incidents som en del af problem management.
Hvis Incident Management ikke har en brugbar workaround på det rapporterede incident, et incident fremkommer gentagne gange eller Incidentet er kategoriseret 1 eller 2, skal det overdrages til Problem Management. Problem Management har til opgave at finde en holdbar løsning på problemet.
Det primære formål med Problem Management er at forebygge, at problems og deraf følgende incidents opstår, at forhindre gentagne incidents og at minimere konsekvenserne af incidents, som ikke kan forebygges.
Service Level
Management
Har til formål at afgrænse, dokumentere, aftale, overvåge, måle, rapportere og reviewe service levels for de services, som leveres. Ligeledes skal processen sikre, at alle aftalte service levels leveres for alle it-services, samt af services og deres performance måles på en ensartet måde. Rollen, som SLM er i 24:7-arbejdet defineret som en kundevendt rolle.

Change Management


Formålet med Change Management er at sikre, at alle ændringer bliver registreret, vurderet, godkendt, prioriteret, planlagt, testet, implementeret, dokumenteret og reviewet i et kontrolleret forløb.
Løs IncidentProcess til løsning af incident hos 3. parts leverandør. Processen vil blive trigget hvis incidentet ikke kan løses af 2. level (IBM) ud fra godkendt løsning eller workaround hentet i Knowledge Management databasen (SKMS).
Processen er intern for 3. parts leverandøren og vil ikke blive beskrevet yderligere i dette dokument.
Presse SOPVed pressehenvendelser i forbindelse med P1 og P2 incidents skal der kommunikeres med pressen. Dette skal ske i overensstemmelse med Presse SOP'en



  • No labels