Bilag 2: Kravspecifikation Kommunernes Ydelsessystem
INSTRUKTION TIL TILBUDSGIVER Bilag 2 med underbilag indeholder Kundens konkrete krav til Løsningen. (Bilag 12 Optioner er også en del af Kravspecifikationen, men der er en særskilt instruktion til besvarelse af dette bilag). Tilbudsgiver skal ikke udfylde nærværende bilag. Tilbudsgivers eventuelle forbehold til bilag 2 anføres i forbeholdslisten og skrives ind med track changes i selve bilaget i overensstemmelse med udbudsbetingelserne. Det bemærkes, at Kontrakten (forstået som Kontrakten uden bilag) og Driftskontrakten (forstået som bilag 7.2, 7.3 og 7.4) er at betragte som minimumskrav, jf. udbudsbetingelserne. Tilbudsgiver skal derfor sikre, at eventuelle forbehold til bilag 2 ikke udgør et forbehold overfor Kontrakten. Om Kravspecifikationen Kravspecifikationen er inddelt i flere sektioner og indeholder minimumskrav og krav. Optioner beskrives i bilag 12, idet der dog også er en Option i bilag 2.24. Krav kategori Minimumskrav (MK) Krav (K) Option (O) Beskrivelse Minimumskrav er et krav (se nedenfor), der uforbeholdent skal opfyldes af Tilbudsgiver. Opfyldes et Minimumskrav ikke, vil tilbuddet blive anset som ukonditionsmæssigt, og tilbuddet vil ikke blive taget i betragtning. Minimumskrav er forbeholdt de egenskaber i Løsningen, som er fundamentalt afgørende for, om Løsningen kan anvendes. Kategorien krav er KOMBITs krav til Løsningen, som Tilbudsgiver kan, men ikke skal opfylde. Kravsopfyldelse vil blive vurderet i henhold til tildelingskriteriet i udbudsbetingelserne. Alle Optioner angivet i kravspecifikationen er minimumsoptioner. Det betyder, at Leverandørens tilbud ikke vil være konditionsmæssigt, hvis ikke alle Optioner tilbydes. KOMBIT kan vælge at indfri Optionerne, men er ikke forpligtiget hertil. Uanset om udtrykket "skal" er brugt i beskrivelsen af et krav, skal det ikke opfattes som et minimumskrav. Det er således kun manglende opfyldelse af Krav anført som minimumskrav samt Optioner, der medfører ukonditionsmæssighed. Alle minimumskrav skal opfyldes. Opfyldes de ikke, vil tilbuddet ikke være konditionsmæssigt. Alle krav skal ikke opfyldes, for at KOMBIT kan tage Tilbudsgivers tilbud i betragtning. Kravene kan opfyldes af Leverandøren, og opfyldelsesgraden vil indgå som konkurrenceparameter ved tilbudsvurderingen. Opfyldes et krav ringe, vil tilbuddet score lavere på de relevante underkriterier til tildelingskriteriet det økonomisk mest fordelagtige tilbud, jf. Udbudsbetingelserne. Bemærk, at minimumskrav ikke indgår i tilbudsvurderingen. Bemærk endvidere at Optioner skal tilbydes, og at graden af opfyldelse af Optionen indgår i tilbudsvurderingen. Side 2 af 257
Krav og kravkategorier i Kravspecifikationen Alle krav er i Kravspecifikationen angivet ved et unikt fortløbende nummer og et navn og vil være angivet i tabeller som den følgende (der også er at finde i afsnit 1.4 i nærværende dokument): Krav [#]: [Navn] Kategori: Beskrivelse: Type: Kravtabellen er opbygget som følger: Krav [#]: Angiver et fortløbende unikt nummer. [Navn]: Angiver kravets navn. Kategori: Angiver kravets kategori. Type: Angiver en typificering af krav i følgende områder: Funktionelt krav (Hvad Løsningen skal gøre). Ikke-funktionelt krav (Hvordan Løsningen skal opføre sig). Lov og politik (Krav relateret til Lovgivning) Beskrivelse: En beskrivelse af kravet. Angiver forklarende bemærkninger samt referencer til tilgrænsende krav. Besvarelse af Kravspecifikationen Leverandørens besvarelse af Kravspecifikationen skal ske gennem udfyldelsen af kravskemaet i underbilag 2.2, og Løsningsbeskrivelsen i underbilag 2.1. Vejledning til udfyldelse af kravskemaet findes nedenfor, mens vejledningen til udfyldelse af Løsningbeskrivelsen fremgår af underbilag 2.1 samt delvist nedenfor. Udfyldelse af kravskemaet Kravskemaet er de samlede minimumskrav, krav og Optioner fra Kravspecifikationen. Leverandøren skal i kravskemaet markere Løsningens opfyldelse af kravene. Dette gør Leverandøren ved for hvert krav (dog ikke minimumskrav) i kravskemaet svarende til nedenstående Tabel 1 at angive, i hvilket omfang det er opfyldt. Kravnummer Titel Kravkategori Helt opfyldt Delvist opfyldt Ikke opfyldt Kommentar Leverandørens reference til Løsningsbeskrivelsen 1 Titel K 3 Titel MK 4 Titel O Tabel 1: Kravskema Side 3 af 257
Følgende retningslinjer gælder ved udfyldelse af kravskemaet: 1. Kan tilbudsgiver og dennes Løsningsbeskrivelse imødekomme det pågældende krav, angives Helt opfyldt. 2. Kan tilbudsgiver og dennes Løsningsbeskrivelse delvis imødekomme det pågældende krav, angives Delvist opfyldt. Angives Delvist opfyldt, skal Leverandøren i kommentarfeltet specificere, hvorfor kravets opfyldelse kun er delvis. 3. Kan Leverandøren ikke imødekomme det pågældende krav, angives Ikke opfyldt. Angives Ikke opfyldt, er kommentarer ikke nødvendige. 4. Hvis Leverandøren i en kommentar foretager konkrete referencer, fx til bilag 2 eller et underbilag, skal referencen være konkret, specifik og nem at finde. 5. Det er ikke muligt at angive eller kommentere minimumskrav, og manglende opfyldelse af disse vil medføre, at tilbuddet ikke er konditionsmæssigt jf. ovenfor og udbudsbetingelserne. Minimumskrav er derfor også markeret gråt og kan derfor ikke udfyldes. 6. Leverandøren må ikke ændre eller udfylde de med gråt markerede celler Udfyldelse af Løsningsbeskrivelsen Løsningsbeskrivelsen er tilbudsgivers beskrivelse af den tilbudte Løsning og en beskrivelse af, hvordan KOMBITs krav i Kravspecifikationen vil blive opfyldt. Løsningsbeskrivelsen skal udarbejdes som i underbilag 2.1. I Løsningsbeskrivelsen i underbilag 2.1 beskriver tilbudsgiver, hvordan tilbudsgiver imødekommer de specifikke krav, KOMBIT har angivet i Kravspecifikationen. Ønsker tilbudsgiver at vedlægge dokumenter til Løsningsbeskrivelsen, bør disse angives som underbilag med fortløbende nummerering, og der skal i Løsningsbeskrivelsen refereres til relevante underbilag. Referencen skal være konkret, afgrænset og nem at finde med sidetal og afsnitsnummer/overskrift. Er den ikke det, ignoreres referencen i tilbudsvurderingen. Særligt om Optioner Kravspecifikationen indeholder en række Optioner. Alle Optionerne er minimumsoptioner. Det betyder, at Leverandørens tilbud ikke vil være konditionsmæssigt, hvis ikke alle Optioner tilbydes. Dertil kommer, at selve opfyldelsen af Optionerne vil indgå som konkurrenceparametre i forhold til tilbudsvurderingen og i forhold til relevante underkriterier til tildelingskriteriet det økonomisk mest fordelagtige tilbud, jf. Udbudsbetingelserne. Leverandøren behøver i henhold til ovenstående ikke at opfylde alle beskrevne elementer i en Option, for at Tilbudsgivers tilbud er konditionsmæssigt, da de vil indgå i tilbudsvurderingen. For Optioner gælder, at Leverandøren særskilt skal prisfastsætte hver enkel Option, der afgives tilbud på. Prisen skal omfatte omkostninger til alle elementer, der er nødvendige for pågældende Options anvendelighed for KOMBIT. Side 4 af 257
Indholdsfortegnelse 1 Indledning... 7 Kravspecifikationens indhold... 7 Underbilag under nærværende bilag... 7 Ordliste... 8 Klassifikation af krav... 10 Anvendelse af informations- og begrebsmodel... 11 Lov og regelfortolkning... 12 2 Baggrund, vision og målsætninger... 12 Baggrund... 12 Vision og målsætninger... 14 Succeskriterier... 15 Målgrupper... 16 3 Introduktion til områdets begreber, Ydelser, processer og aktører... 16 Begreber... 16 Informationsmodel... 17 Ydelsesarter... 17 Processer... 18 Aktører... 19 4 Overordnede krav... 26 5 Funktionelle krav... 26 Opgaver og sager... 29 Behandling af ydelsessager... 44 Administration af Persons økonomi... 94 Tværgående funktionalitet... 102 Visninger... 118 Systemadministration... 132 Rapporter og udtræk... 149 Selvbetjening... 151 Krav til dataudveksling... 166 6 Ikke-funktionelle krav... 177 Offentlige strategier og generelle arkitekturprincipper... 177 Arkitektur... 178 Rammearkitekturens støttesystemer... 193 Integrationer... 202 Brugervenlighed og Look n Feel... 227 6.6 Lovkrav... 245 Side 5 af 257
Sikkerhed... 248 7 Referencer... 256 8 Revisionshistorik... 257 Side 6 af 257
1 Indledning Nærværende bilag 2 (Kravspecifikation) inklusive underbilag indeholder den samlede beskrivelse af kravene til Løsningen. Kravspecifikationens indhold Kravspecifikationen er struktureret i følgende afsnit: Nærværende kapitel 1 introducerer indholdet i kravspecifikationen og underbilag. Herudover beskrives den anvendte kravklassificering og bl.a., hvordan begrebsmodel og informationsmodel anvendes i kravspecifikationen. Kapitel 2 er et baggrundsafsnit, der kort introducerer KOMBITs og kommunernes behov for en fremtidig Løsning på kontanthjælpsområdet og tilgrænsende områder. Afsnittet tjener alene til det formål at give leverandøren formåls- og baggrundsviden i forhold til den Løsning, der skal leveres under Kontrakten. Kapitel 3 giver en kort introduktion til de forretningsprocesser, begreber, Ydelser og aktører, som løsningen skal understøtte, med henvisninger til mere detaljerede beskrivelser i relevante underbilag. Kapitel 4 indeholder nogle få overordnede krav, som er generelle for hele Løsningen, og derfor gælder på tværs af de understøttede forretningsprocesser og de efterfølgende kapitler. Kapitel 5 indeholder de funktionelle krav, som skal sikre, at Løsningen understøtter behandlingen af ydelsessagerne. Kapitlet er struktureret ud fra sagsbehandlingsprocessens hovedtrin. For hver af sagsbehandlingsprocessens hovedtrin er der udarbejdet en række generelle krav, som gælder på tværs af de Ydelser, som Løsningen understøtter. Hvor det er relevant, suppleres der med mere ydelsesspecifikke krav i underafsnit. Dertil kommer en række underafsnit med krav af mere tværgående karakter. Kapitel 6 indeholder ikke-funktionelle krav, herunder krav vedrørende brugervenlighed, sikkerhed, løsningsarkitektur, snitflader mv. Kapitel 7 indeholder referencer til dokumentation og anvenderkrav til Rammearkitekturens støttesystemer. Underbilag under nærværende bilag Under nærværende bilag 2 findes følgende underbilag: Underbilag 2.1: Løsningsbeskrivelse Underbilag 2.2: Kravskema Underbilag 2.3: Processer Underbilag 2.4: Begrebsmodel Underbilag 2.5: Informationsmodel Underbilag 2.6: Integrationer Underbilag 2.7: Lovgivning og beregningsregler Underbilag 2.8: Lovgivning Underbilag 2.9: Eksempler på rapporter Underbilag 2.10: Eksempler på skærmbilleder Underbilag 2.11: Kommunale personas Underbilag 2.12: Eksempler på breve Underbilag 2.13: Oversigt over Hændelser Underbilag 2.14: Underbilaget udgår. Underbilag 2.15: Oversigt over ydelsesarter Side 7 af 257
Underbilag 2.16: Ydelser og målgruppe- målgruppestatus Underbilag 2.17: Borger personas Underbilag 2.18: Persona brugerrejser selvbetjening Underbilag 2.19: Målepunkter og succeskriterier Underbilag 2.20: Eksempel på oplysninger i ydelsessag Underbilag 2.21: Oversigt over uforenelige Ydelser Underbilag 2.22: Kontering Underbilag 2.23: Minimumsoplysninger Underbilag 2.24: Kommunernes IT-Miljø Underbilag 2.25: Snitfladedokumentation Underbilag 2.26: Persona brugerrejse sagsbehandler Underbilag 2.27: Logning Underbilag 2.28: Filtrering af R75 oplysninger (udarbejdet som inspiration til Tilbudsgiver) Ordliste Ordlisten indeholder definitioner af termer, der anvendes i Kravspecifikationen. Når en term er defineret, vil den blive skrevet med stort begyndelsesbogstav. Bemærk, at der i underbilag 2.4 Begrebsmodel, fremgår en nærmere beskrivelse af forretningsmæssige begreber, samt at bilag 0 indeholder definitioner af termer benyttet i Kontrakten. Begreb Beskrivelse Adgangsstyring Støttesystemet Adgangsstyring, som er beskrevet i afsnit 6.3.2. Alternativ Modtager Anden Ydelse/ Andre Ydelser Ansøger Besked En virksomhed, myndighed eller en anden person end bevillingsmodtageren, som modtager en udbetaling i en sag. Betalingen vedrører typisk en vare eller en tjeneste, som kommunen betaler for som led i sagsbehandlingen. Er i informationsmodellen (underbilag 2.5) repræsenteret som Ydelsesmodtager. Betegner Ydelsesarter, der kan udbetales gennem Løsningen, men som hovedregel ikke understøttes beregningsmæssigt ud over skatteberegning. Det er fx helbredstillæg, udvidet helbredstillæg og personlige tillæg efter pensionslovene samt forskellige løbende økonomiske Ydelser efter Lov om social service. En Ansøger er den Person, som ansøger om en forsørgelsesydelse eller enkeltydelse mv. Ansøgeren kan ansøge både via selvbetjeningsløsningen og via papir. En Besked er oplysninger, der fremsendes fra et afsendersystem til Løsningen via Beskedfordeleren (se afsnit 6.3.1.1) eller via en direkte snitflade mellem afsendersystemet og Løsningen. En Besked oprettes på baggrund af en Hændelse, der er registreret i afsendersystemet. Se også Hændelse og Opgave. Beskedfordeler Støttesystemet Beskedfordeler, som er beskrevet i afsnit 6.3.2. Bruger Det fælles datagrundlag (DFDG) En person hos KOMBIT, en kommune eller andre, der skal anvende Løsningens brugergrænseflader, se i øvrigt bilag 0. Se brugeraktører i afsnit 3.5.2. I afsnit 5.1-5.5, 5.7 og 5.9 vil en Bruger typisk være en sagsbehandler I afsnit 5.6 vil en Bruger typisk være en administrator I afsnit 5.8 vil en Bruger typisk være en Person/Ansøger Det fælles datagrundlag er Styrelsen for Arbejdsmarked og Rekrutterings database til lagring af oplysninger om den kommunale beskæftigelsesindsats. I bekendtgørelse nr. 1420 af 23. december 2012 om det fælles datagrundlag og statistiske datavarehus fastsættes bestemmelser om, hvilke informationer, der skal indberettes til det fælles datagrundlag. Side 8 af 257
Dokumentfordeler Godtgørelse Hændelse Støttesystemet Dokumentfordeler, som er beskrevet i afsnit 6.3.2. Støttesystemet omtales også som fordelingskomponenten. Jobcentret kan efter LAB 82 og 83 bevilge Godtgørelse af udgifter forbundet med aktivering. Godtgørelsen kan bl.a. dække udgifter til buskort eller arbejdstøj. En Hændelse kan være: 1) En begivenhed, der sker ude i verden som fx at en Person flytter, udvandrer, dør, bliver forælder etc. 2) En begivenhed, der registreres i en anden it-løsning, som er relevant for Løsningen. 3) En begivenhed, der indtræder i Løsningen forårsaget af en Bruger- eller systemhandling. Se også Besked og Opgave. Når en Person foretager en handling, der medfører en sanktion, beskrives dette som en forseelse og ikke som en hændelse. INL Lov om integration af udlændinge i Danmark (integrationsloven), lovbekendtgørelse nr. 871 af 06/07/2007 med følgende ændringslov i 2007: 523 i 2008: 108 og 1336 i 2010: 429 og 1540 i 2011: 1367 i 2012: 922, 928 og 1380 og i 2013: 493 med tilhørende bekendtgørelser og vejledninger. Jobcenterløsning It-løsning til understøttelse af sagsbehandlingen i Jobcentrene. Der findes pr. medio april 2014 tre Jobcenterløsninger: KMD Opera, Facit og WorkBase. Klassifikation Støttesystemet Klassifikation, som er beskrevet i afsnit 6.3.2. KLE LAB LAB-målgruppe LAS Lovgivning Opgave KL Emnesystematik er en lovbaseret kommunal taksonomi (journaliseringsnøgle), der bruges til at registrere de kommunale opgaver (emner) og forvaltningshandlingen ift. opgaven (handlingsfacetterne) på den enkelte sag. Se evt. KLE Online: http://kle-online.dk/soegning [Indhentet 23-04-2014] Lov om en aktiv beskæftigelsesindsats, lovbekendtgørelse nr. 415 af 24/4/2013 med følgende ændringslov i 2012: 1380 og følgende i 2013: 493, 790, 895, 1610, 1612 med tilhørende bekendtgørelser og vejledninger. En målgruppe af Personer, der behandles efter specifikke punkter i LAB. Lov om aktiv socialpolitik, lovbekendtgørelse nr. 190 af 24/02/2012 med følgende ændringslove i 2012: 153, 267, 326, 473, 476, 928, 1346, 1380, 1399 og følgende fra 2013: 493, 494, 894 og 1612 og i 2014: 166 og 336 med tilhørende bekendtgørelser og vejledninger. Når der henvises til Lovgivningen i Kravspecifikationen, menes herunder både Lovgivning, bekendtgørelser, vejledninger samt ankeafgørelser mv. der fastlægger gældende praksis på området, og som er nævnt i underbilag 2.8 vedrørende relevant Lovgivning. En Opgave er en notififikationg til brugeren omkring noget der skal løses. Opgaver kræver således, at Brugeren foretager en eller anden form for handling. Organisation Støttesystemet Organisation, som er beskrevet i afsnit 6.3.2. Person Rammearkitekturen/Den Fælleskommunale Rammearkitektur En Person, som indgår i behandling af en sag i løsningen. Person 1 (primær part) og Person 2 (sekundær part) anvendes i sager, hvor Ansøgeren (Person 1) og dennes Ægtefælle (Person 2) begge er relevante for sagsbehandlingen, fx i sager vedr. kontanthjælp. De fælles rammer, KOMBIT på vegne af kommunerne sætter op for alle, der skal arbejde med kommunale processer og kommunal it. Det er populært sagt den spillebane og de spilleregler, der vil gælde for at være med til at levere it til kommunerne fremover. Rammearkitekturen er nærmere beskrevet i afsnit 6.3. Sags- og Dokumentindeks Sanktion SAPA Støttesystemet Sags- og Dokumentindeks, som er beskrevet i afsnit 6.3.2. En økonomisk konsekvens af Personens eller eventuelt Ægtefællens manglende medvirken i aktivering mv., som udgør forudsætningen for at blive bevilget en Ydelse., eksempelvis i form af nedsættelse af den bevilgede Ydelse. SAPA - Sagsoverblik/Partskontakt er en løsning, der giver sagsbehandlerne i en kommune et overblik over en borgers sager, journalnotater, dokumenter, bevillinger/ydelser og Hændelser på tværs af de fagssystemer, der anvendes i kommunen. Sagsbehandlerne kan tilgå fagsystemerne via SAPA. SAPA indkøbes af KOMBIT på vegne af kommunerne. Side 9 af 257
Serviceplatformen Søgnehelligdag Udbetaling Danmark Serviceplatformen er en integrationsplatform, der udstiller data og funktionalitet fra forskellige fag- og kildesystemer som services til brug for kommunernes it-løsninger.serviceplatformen er en del af Rammearkitekturen og yderligere information findes på www.serviceplatformen.dk. Serviceplatformen er indkøbt af KOMBIT på vegne af kommunerne. En helligdag, som falder på en hverdag undtagen lørdag. Benyttes fx ved ledighedsydelse. Det er 1. nytårsdag, Skærtorsdag, Langfredag, 2. påskedag, Store bededag, Kristi himmelfartsdag, 2. pinsedag, juledag og 2. juledag. Grundlovsdag behandles på samme måde. Udbetaling Danmark (UDK) er en ny offentlig myndighed, der fra oktober 2012 begyndte at overtage en række opgaver fra kommunerne. Det er udbetaling af børneydelser, barselsdagpenge, pensioner og boligstøtte. Ydelse Ydelsesart Udbetaling Danmark blev dannet, da KL og regeringen i juni 2010 indgik en aftale om at samle dele af den objektive sagsbehandling i fem centre med virkning fra efteråret 2012. En Ydelse, som kan bevilges og udbetales i Løsningen. Se også Ydelsesart Ydelsesart er en specifik type af Ydelse. Det kan fx være kontanthjælp, revalideringsydelse osv. Se en oversigt over Ydelsesarter i underbilag 2.15. Ydelsesindeks Støttesystemet Ydelsesindeks, som er beskrevet i afsnit 6.3.2. Ydelsessats Ægtefælle Sats, der refererer til specifik paragraf, styk, punkt i loven, typisk Aktivloven (LAS). Kontanthjælpssats og Revalideringsydelsessats er eksempler på Ydelsessatser. Til hver sats svarer et beløb, som gælder for en periode af en specificeret længde. Beløbet fastsættes årligt i vejledning fra STAR. Den Person, som er gift med Ansøger. Hertil regnes også personer, der har indgået registreret partnerskab før medio 2012. Såfremt der er indgået separation eller skilsmisse, anses Personen for at være enlig. Tabel 2: Definitioner Klassifikation af krav Kravspecifikationen er inddelt i flere sektioner og indeholder minimumskrav og krav. Optioner beskrives i bilag 12, idet der dog også er en Option i bilag 2.24. Krav kategori Minimumskrav (MK) Krav (K) Option (O) Beskrivelse Minimumskrav er et krav (se nedenfor), der uforbeholdent skal opfyldes af Tilbudsgiver. Opfyldes et Minimumskrav ikke, vil tilbuddet blive anset som ukonditionsmæssigt, og tilbuddet vil ikke blive taget i betragtning. Minimumskrav er forbeholdt de egenskaber i Løsningen, som er fundamentalt afgørende for, om Løsningen kan anvendes. Kategorien krav er KOMBITs krav til Løsningen, som Tilbudsgiver kan, men ikke skal opfylde. Kravsopfyldelse vil blive vurderet i henhold til tildelingskriteriet i udbudsbetingelserne. Alle Optioner angivet i kravspecifikationen er minimumsoptioner. Det betyder, at Leverandørens tilbud ikke vil være konditionsmæssigt, hvis ikke alle Optioner tilbydes. KOMBIT kan vælge at indfri Optionerne, men er ikke forpligtiget hertil. Uanset om udtrykket "skal" er brugt i beskrivelsen af et krav, skal det ikke opfattes som et minimumskrav. Det er således kun manglende opfyldelse af Krav anført som minimumskrav samt Optioner, der medfører ukonditionsmæssighed. Side 10 af 257
Alle minimumskrav skal opfyldes. Opfyldes de ikke, vil tilbuddet ikke være konditionsmæssigt. Alle krav skal ikke opfyldes, for at KOMBIT kan tage Tilbudsgivers tilbud i betragtning. Kravene kan opfyldes af Leverandøren, og opfyldelsesgraden vil indgå som konkurrenceparameter ved tilbudsvurderingen. Opfyldes et krav ringe, vil tilbuddet score lavere på de relevante underkriterier til tildelingskriteriet det økonomisk mest fordelagtige tilbud, jf. Udbudsbetingelserne. Bemærk, at minimumskrav ikke indgår i tilbudsvurderingen. Bemærk endvidere at Optioner skal tilbydes, og at graden af opfyldelse af Optionen indgår i tilbudsvurderingen. Alle krav er i Kravspecifikationen angivet ved et unikt fortløbende nummer og et navn og vil være angivet i tabeller som den følgende: Krav [#]: [Navn] Kategori: Beskrivelse: Type: Kravtabellen er opbygget som følger: Krav [#]: Angiver et fortløbende unikt nummer. [Navn]: Angiver kravets navn. Kategori: Angiver kravets kategori. Type: Angiver en typificering af krav i følgende områder: Funktionelt krav (Hvad Løsningen skal gøre). Ikke-funktionelt krav (Hvordan Løsningen skal opføre sig). Lov og politik (Krav relateret til Lovgivning) Beskrivelse: En beskrivelse af kravet. Angiver forklarende bemærkninger samt referencer til tilgrænsende krav. Anvendelse af informations- og begrebsmodel Begrebsmodellen beskriver de forretningsmæssige begreber, der omfattes af projektet. Begrebsmodellen fremgår i sin helhed af underbilag 2.4 (Begrebsmodel) og introduceres i afsnit 3.1. Informationsmodellen beskriver informationer, der skal håndteres indenfor systemets rammer. Fra de enkelte krav relateres der i nogle tilfælde til informationsmodellens bestanddele (i bemærkningsfeltet), således at Leverandøren får et indblik i hvilken information, der skal håndteres i en given funktion. Informationsmodellen fremgår i sin helhed af underbilag 2.5 (Informationsmodel) i form af en række UML klassediagrammer, og introduceres i afsnit 3.2. Der henvises fra funktionelle krav i kapitel 5 til informationsmodellen på følgende måde: Som udgangspunkt henvises til navnet på en delmodel eller til en eller flere pakker 1, som indeholder de informationer, som er relevante for kravet. Delmodeller er navngivet så navnet 1 UML Packages Side 11 af 257
starter med KY-, fx KY-sag. En henvisning til en delmodel, kan eksempelvis se således ud: Se informationsmodellen (KY-sag) i underbilag 2.5 ) og en henvisning til en pakke kan se således ud: Se eventuelt informationsmodellen (Beregningsgrundlag) i underbilag 2.5. Denne henvisning vil som hovedregel være relevant for alle de Ydelser, hvor pakken indgår. Alternativt henvises til specifikke klasser, attributter eller relationer, hvor der er behov for mere specifikke henvisninger, fx Se informationsmodellen (Økonomisk effektueringsplan) i underbilag 2.5 Endelig er der ved visse krav, der retter sig mod specifikke Ydelser, henvisninger til den eller de ydelsesspecifikke modeller. Eksempelvis kan henvisningen gå til Beregningsgrundlag i Kontanthjælps-modellen, hvis der er tale om et krav, som kun vedrører uddannelseshjælp eller kontanthjælp: Se informationsmodellen (Beregningsgrundlag i KY-uddannelseshjælp eller kontanthjælp) i underbilag 2.5. Lov og regelfortolkning Løsningen skal understøtte et forretningsområde, som er reguleret af Lovgivning på flere niveauer, dels faglovgivningen, såsom Lov om aktiv socialpolitik (LAS) og Lov om en aktiv beskæftigelsespolitik (LAB), og dels mere generel Lovgivning såsom Persondataloven og Retssikkerhedsloven. Den faglovgivning som Løsningen skal understøtte fremgår af underbilag 2.8 (Lovgivning) og der er henvisninger til generel Lovgivning i afsnit 6.6. I underbilag 2.7 (Lovgivning og beregningsregler) er beskrevet eksempler på, hvordan Lovgivning og beregningsregler fortolkes for en række af de Ydelser, som Løsningen skal håndtere. I underbilag 2.20 (Eksempel på oplysninger i en ydelsessag) gives eksempler på oplysninger om et ægtepar i en fiktiv sag om uddannelseshjælp eller kontanthjælp. Eksemplerne er ikke udtømmende, men kan give Leverandøren en grundig indsigt i lov og regelfortolkning på området og det forventes, at Leverandøren orienterer sig i materialet. Leverandøren må forvente, at der, i forbindelse med udvikling af de dele af Løsningen som skal anvende Lovgivning og beregningsregler herunder beregne Ydelser, vil være et tæt samarbejde mellem Leverandøren og Kunden med inddragelse af relevante kommunale fagfolk med henblik på mere præcist at fastslå den måde, hvorpå Lovgivning og beregningsregler skal fortolkes, og hvilke resultater Løsningen skal komme frem til. Processen herfor er nærmere beskrevet i bilag 8. 2 Baggrund, vision og målsætninger Dette kapitel indeholder en introduktion til baggrunden, visionen og målene for Kommunernes Ydelsessystem. Yderligere information kan findes på www.kombit.dk/ky. Baggrund Formålet med nærværende kravspecifikation er at sikre etableringen af en moderne, fælleskommunal it-løsning til understøttelse af kommunernes behandling af sager om bevilling og udbetaling af en række Ydelser på kontanthjælpsområdet og tilgrænsende ydelsesområder 2 samt til understøttelse af kommunernes behandling af administrationssager. 2 Der er tale om understøttelse af kommunernes sagsbehandling på ydelses-området og ikke jobcenter-området. På jobcenter-området eksisterer der flere konkurrerende it-løsninger og området er således ikke omfattet af Udbudsplanen for monopolområderne. Side 12 af 257
De Ydelser, som er omfattet af Løsningen er nærmere beskrevet i afsnit 3.3 samt underbilag 2.15, og den faglovgivning, som regulerer bevilling og udbetaling af Ydelserne, er oplistet i underbilag 2.8. Konkurrenceudsættelsen og etableringen af Kommunernes Ydelsessystem er et af flere projekter, som gennemføres som led i den fælleskommunale udbudsplan (yderligere information kan findes på www.kombit.dk/udbudsplan). Planen er et centralt led i den fælleskommunale digitaliseringsstrategi, der blev vedtaget i november 2010, og som nu er under udmøntning. Figur 1: Oversigt over den fælleskommunale Udbudsplan I forbindelse med udbudsplanen agerer KOMBIT indkøbscentral, og udbyder og indkøber de nye fælleskommunale løsninger på vegne af landets 98 kommuner. Alle kommuner vil således anvende Kommunernes Ydelsessystem, og betaler for anvendelsen via et årligt driftsbidrag til KOM- BIT. Driftsbidraget anvendes til at finansiere behovsafdækning, udbudsomkostninger, markedsdialog, udfasning af eksisterende løsninger, informationskampagner og projektstyring, samt systemudvikling, implementering, videreudvikling, vedligehold, support og drift af Kommunernes Ydelsessystem. 2.1.1 Kommunernes nuværende løsninger Den nuværende it-understøttelse af kontanthjælpsområdet sker i dag via beregningsunderstøttelse (gennem it-systemerne KMD Aktiv og BIS-Y), mens den egentlige understøttelse af selve sagsbehandlingen eksempelvis foregår i KMD Sag eller andre ESDH-systemer. KMD Aktiv, der anvendes i størstedelen af landets kommuner, er mere end 10 år gammelt og baseret på 3270-teknologi, mens BIS-Y er et nyere system, der anvendes i en enkelt kommune. KMD Aktiv og KMD Sag er omfattet af transitionsaftalen indgået mellem KL og KMD A/S i forbindelse med salget af sidstnævnte, hvorfor bl.a. udfasning af systemerne (dataudtræk m.v.) er underlagt særlige betingelser. Yderligere information kan findes på http://www.kl.dk/administrationog-digitalisering/losningsbeskrivelser-i-transitionsaftalen-id56081/ [indhentet 14-01-2014] Side 13 af 257
KMD Aktiv er driftssikkert og kendetegnet ved korte svartider, men flere kommuner rapporterer, at der er behov for hurtigere og billigere tilretninger i et kommende system Desuden skal sagsbehandlerne foretage en række dobbeltopslag og andre manuelle funktioner, som ikke virker tidssvarende, ligesom systemet ikke giver mulighed for automatisering og borger-vendt selvbetjening. Analyser forud for udarbejdelsen af Kontrakten har vist, at mange kommuner efterspørger en effektivisering af sagsbehandlingen gennem en væsentlig højere grad af beslutningsstøtte, automatisering og selvbetjening. For at sikre kommunerne de fulde gevinster ved Kommunernes Ydelsessystem er det således centralt, at der som del af projektet sker en gentænkning af it-understøttelsen af området, således at der ikke alene etableres en 1-til-1-kopi af den eksisterende it-understøttelse på området. Vision og målsætninger Kontanthjælp, uddannelsesydelse og de øvrige beslægtede ydelsesområder er en central del af det danske velfærdssystem. De Ydelser, der vil blive beregnet og efterfølgende udbetalt på baggrund af det kommende ydelsessystem, vil i mange tilfælde udgøre eksistensgrundlaget for de modtagende borgere. Løsningen vil blive anvendt i alle 98 kommuner, og samlet set skal der udbetales Ydelser for ca. 25 mia. kr. årligt. Visionen for Løsningen er, at der etableres en moderne, brugervenlig sagsbehandlingsløsning, som ressourceeffektivt, tidssvarende og omkostningseffektivt understøtter den kommunale sagsbehandling på kontanthjælpsområdet og tilgrænsende ydelsesområder via beslutningsunderstøttelse, fuldautomatisering ( straight-through processing ) og sammenhæng til selvbetjening for borgere. Løsningen skal kunne understøtte behandlingen af mere end 400.000 ansøgninger årligt og ca. 400.000 åbne sager svarende til ca. 300.000 beregninger og udbetalinger pr. måned. Det forventede antal samtidige Brugere, som Løsningen skal understøtte fremgår af afsnit 3.5.2. Internt i kommunerne skal Løsningen bidrage til at muliggøre hurtigere oplæring af nye medarbejdere i Løsningen, fleksibelt samarbejde mellem faggrupper på tværs af faggrænser og organisatoriske enheder, samt skabe mulighed for en differentieret indsats over for borgerne. For borgerne skal Løsningen yderligere bidrage til øget med- og selvbetjening og øget adgang til egne oplysninger og kommunikation med kommunen. Kontrakten skal således bidrage til at sikre følgende kvalitative gevinster: Større understøttelse og kvalitetssikring af sagsbehandlingens enkelte skridt (strukturerede valg, vejledninger, genbrug af data, indhentning af oplysninger fra eksterne registre m.v.). Hurtig, let anvendelig og overbliksgivende sagsbehandlingsløsning for sagsbehandlere. Let anvendelig og overbliksgivende selvbetjeningsløsning for borgerne. Øget retssikkerhed og støtte til borgere gennem forbedret udveksling og visning af data. Udvidede tilpasningsmuligheder i it-understøttelsen i forbindelse med breve, Opgaver og proces-understøttelse. Side 14 af 257
Fuld lovmedholdelighed gennem fælleskommunal kontrol med leverandørens implementering af lovændringer m.v. Stabil drift, som tilgodeser kontanthjælpsområdets væsentlighed for mange borgere. Fleksibilitet i forhold til justeringer af takster og mindre lovændringer (det er forventningen at større lovændringer vil kræve udvikling hos leverandøren). Løsningen skal være baseret på en moderne teknologisk platform, som med løbende vedligeholdelse og videreudvikling giver gode muligheder for levetid på 10-15 år. Teknologi, rettigheder og dokumentation skal have en sådan form, at Løsningen løbende kan bringes i gen-udbud af KOM- BIT på kommunernes vegne med henblik på optimering af udbytte og kvalitet, og reduktion i omkostninger. I forlængelse heraf er der formuleret seks målsætninger for etableringen af Kommunernes Ydelsessystem. For at Løsningen og Kontrakten i det hele taget kan betegnes som vellykket, skal Løsningen og Leverandørens øvrige leverancer understøtte målsætningerne og succeskriterierne for projektet. Prioritet # Målsætninger 1 A 1 B Understøtte korrekte og rettidige udbetalinger af Ydelser på kontanthjælpsområdet og tilgrænsende områder Sikre kommunerne min. 25 pct. lavere gennemsnitlige it-udgifter på kontanthjælpsområdet, samt afløfte kommunernes udbudspligt på området 2 C 2 D 3 E 3 F Sikre brugervenlig og effektiv it-understøttelse af de kommunale arbejdsgange på kontanthjælpsområdet og tilgrænsende områder gennem automatisering og beslutningsunderstøttelse Muliggøre bedre it-mæssig sammenhæng til tilgrænsende kommunale opgaver gennem åbne snitflader, datastandardisering mv. Bidrage til at skabe momentum for KL s indsats for regelforenkling på beskæftigelsesområdet Oparbejde erfaringer, som smidiggør gennemførslen af øvrige projekter i KOMBITs og KL s udbudsplan Tabel 3: Overblik over projektets målsætninger (prioriteret rækkefølge) Det bemærkes, at informationerne i dette afsnit ikke skal betragtes som krav til Leverandøren eller Løsningen, men som baggrundsinformation til Leverandøren. Succeskriterier Succeskriterierne for denne kontrakt understøtter målsætningerne for udbudsplanen. For at Løsningen og Kontrakten i det hele taget kan betegnes som vellykket, skal Løsningen og Leverandørens øvrige leverancer understøtte målsætningerne og succeskriterierne for projektet. Det forventes, at Leverandøren aktivt støtter KOMBIT i indfrielsen af målsætninger og succeskriterier herunder også målsætninger og succeskriterier, som Leverandøren har begrænset indflydelse på, jf. underbilag 2.19 Målepunkter og succeskriterier. Side 15 af 257
Målgrupper Løsningen vil primært blive anvendt af Ydelsescentret, der er den del af den kommunale forvaltning, der arbejder med udbetaling af økonomiske Ydelser på kontanthjælpsområdet. Sagsbehandlingen udføres i sammenhæng med jobcenterområdet, der varetager den opfølgningsmæssige opgave i forhold ydelsesmodtageren. Dertil kommer sagsbehandlere på tilgrænsende ydelsesområder, som anvender løsningen til udbetaling af Ydelser på de tilgrænsende områder. Selvbetjeningsløsningen vil primært blive benyttet til ansøgning om uddannelseshjælp eller kontanthjælp og til at understøtte en del af kontakten mellem sagsbehandler og Ansøger under sagsbehandlingen, fx ved behov for supplerende oplysninger. Brugerne af Løsningen forventes at være følgende, jf. afsnit 3.5 (Aktører): Person (ansøger om forsørgelsesydelse via selvbetjeningsløsning) Sagsbehandler (Ydelsescentret) Sagsbehandler (Jobcentret) Sagsbehandler (anden forvaltning) Kommunal administrator Central administrator Intern/ekstern revisor Kommunal mellemleder Kommunalt kontrolteam 3 Introduktion til områdets begreber, Ydelser, processer og aktører I dette kapitel beskrives de begreber, Ydelser, processer og aktører, som enten indgår i Løsningen eller som skal anvende Løsningen. Formålet med kapitlet er dels at give Leverandøren et grundlag for at forstå det forretningsmæssige domæne, som Løsningen skal understøtte og dels at stille krav til Leverandørens brug af de beskrevne begreber og processer, som udgangspunkt for den videre modellering og udvikling af Løsningens datamodel og brugergrænseflade. KOMBIT opfordrer leverandørerne til at sætte sig ind i de to eksempler på den kommende anvendelse af Løsningen: Underbilag 2.18 (Brugerrejse for KY selvbetjening) og bilag 2.26 (Brugerrejse for sagsbehandler). De to brugerrejser giver et indtryk af hvordan Løsningen skal kunne understøtte Ansøgere via selvbetjeningsløsningen og sagsbehandlerne i deres opgaver. Begrebsmodellen beskriver de forretningsbegreber, der er repræsenteret i domænet, og informationsmodellen viser de centrale informationer, som Løsningen indeholder. Processerne giver en sammenhængende fremstilling af aktiviteter for forskellige aktører og regler/forretningslogik udreder Løsningens Lovgivning og regelsæt. Begreber Begrebsmodellen skal bidrage til at forklare det forretningsområde, der skal it-understøttes. Ved design af Løsningen skal Leverandøren anvende begrebsmodellen som grundlag for udarbejdelse af bl.a. datamodel og konsistente brugergrænseflader, der anvender begreber, der er velkendte i forretningsområdet. Side 16 af 257
I underbilag 2.4 (Begrebsmodel) er begrebsmodellen med de centrale forretningsbegreber på et ikke-udtømmende niveau beskrevet. Kunden forstår centrale forretningsbegreber som begreber, der er elementære i al kommunikation inden for dette område. Krav# 1: Begrebsmodel Beskrivelse: Leverandøren skal anvende de udarbejdede begrebsmodeller og tilknyttede definitioner som grundlag for udarbejdelse af Løsningens logiske datamodel. - Se underbilag 2.4 Begrebsmodel. Informationsmodel Informationsmodellen viser Løsningens centrale informationer og deres attributter på et overordnet plan. De informationer, som anvendes i sagsbehandlingen er beskrevet på et ikke-udtømmende niveau i informationsmodellen i underbilag 2.5. Modellen er opdelt i et antal delmodeller, hvoraf nogle beskriver generelle begreber såsom Sag og Dokument, og andre beskriver de ydelsesspecifikke detaljer. Modellerne er udarbejdet, så de så vidt muligt følger et ensartet mønster med ensartede UML pakker i de enkelte delmodeller, såfremt UML pakken er relevant for den pågældende delmodel. Krav# 2: Informationsmodel Beskrivelse: Leverandøren skal anvende de udarbejdede informationsmodeller i Løsningen beskrevet i underbilag 2.5. som grundlag for udarbejdelse af Løsningens logiske datamodel. - Se underbilag 2.5 Informationsmodel. Ydelsesarter Løsningen skal anvendes til kommunernes behandling af sager om bevilling og udbetaling af en række Ydelser samt administrationssager. Disse introduceres kort nedenfor, og en samlet oversigt over de Ydelsesarter Løsningen skal understøtte fremgår af underbilag 2.15. Forsørgelsesydelser er de løbende Ydelser efter Lov om aktiv socialpolitik: Uddannelseshjælp, kontanthjælp, revalideringsydelse, ressourceforløbsydelse og ledighedsydelse samt fleksløntilskud efter Lov om en aktiv beskæftigelsesindsats. Fælles for forsørgelsesydelserne er, at de i vidt omfang skal understøttes med et beregningsmodul i Løsningen. Modulet skal også foretage beregning og træk af ATP og skat. Enkeltydelser er hjælp i særlige tilfælde efter Lov om aktiv socialpolitik kap. 10, og integrationslovens kap. 6. Det drejer sig om hjælp til rimeligt begrundede enkeltudgifter, hjælp til udsættelsestruede, hjælp til sygebehandling, hjælp til tandbehandling, hjælp til samværsudgifter, hjælp til forsørgelse af forældreløse børn og hjælp til flytning. Side 17 af 257
Andre Ydelser betegner Ydelsesarter, der kan udbetales gennem Løsningen, men som hovedregel ikke understøttes beregningsmæssigt ud over skatteberegning. Det er fx helbredstillæg, udvidet helbredstillæg og personlige tillæg efter pensionslovene samt forskellige løbende økonomiske Ydelser efter Lov om social service, fx merudgiftsydelse til børn med handicap, merudgifter til voksne og forskellige Ydelser til forældre med børn. Dertil kommer en række Ydelser efter Lov om en aktiv beskæftigelsesindsats, fx befordringsgodtgørelse efter 82 og Godtgørelse til udgifter ved aktivering efter 83, tilskud til mentorordning og lign. mv. Administrationssager er sager, hvor kommunen har truffet afgørelse om hel eller delvis administration af en ydelsesmodtagers økonomi efter LAS 90 eller har indgået en frivillig aftale med Personen. Dertil kommer et antal pensionister, hvor der efter pensionslovene er truffet beslutning om administration eller indgået frivillig aftale om administration af den pension, som beregnes og udbetales fra Udbetaling Danmark. Krav# 3: Understøttede Ydelsesarter Kategori: (MK) Type: Funktionelt Beskrivelse: Løsningen skal kunne håndtere behandlingen af de Ydelsesarter der er specificeret i underbilag 2.15. Der er overordnet set tale om følgende Ydelsesarter: Uddannelseshjælp Kontanthjælp Særlig støtte LAS 34 Ledighedsydelse Revalideringsydelse Fleksløntilskud Ressourceforløbsydelse Enkeltydelser Andre Ydelser Administration af Persons økonomi - Se specifikation af Ydelsesarter i underbilag 2.15. Processer I dette afsnit præsenteres de fremtidige processer (to be) hos Ydelsescentret, der fremover vil blive it-understøttede af Løsningen. Beskrivelsen af processerne har til formål at give en forretningsorienteret og sammenhængende præsentation af det fremtidige forløb af aktiviteter hos forskellige involverede aktører i forbindelse med behandlingen af ydelsessager. Dette skal sikre, at Leverandøren har forståelse for den forretningsmæssige virkelighed, som Løsningen skal anvendes i. De forretningsprocesser, som løsningen skal understøtte, er beskrevet i underbilag 2.3 med diagrammer og tilhørende procesbeskrivelser. Her er følgende processer beskrevet: Side 18 af 257
Processen vedr. uddannelseshjælp eller kontanthjælp (inkluderer særlig støtte). Processen vedr. ledighedsydelse. Processen vedr. revalideringsydelse. Processen vedr. ressourceforløbsydelse. Processen vedr. fleksløntilskud. Processen vedr. enkeltydelser. Processen vedr. udbetaling af Andre Ydelser. Processen vedr. administration af Persons økonomi. Krav# 4: Procesmodeller Beskrivelse: Leverandøren skal understøtte de otte udarbejdede procesmodeller i Løsningen beskrevet i underbilag 2.3. Se underbilag 2.3 Processer. Aktører Løsningen indgår i et samspil med en række forskellige brugeraktører og systemaktører. De forskellige aktører gennemgås i den følgende beskrivelse. 3.5.1 Kontekstdiagram Aktørerne i Løsningen er opdelt i: Brugeraktører, dvs. Brugere, som via brugergrænsefladen arbejder med Løsningen. Systemaktører, dvs. andre it-systemer eller services, som skal interagere med Løsningen. De forskellige brugeraktører er vist i nedenstående kontekstdiagram. Systemaktører, dvs. andre systemer der interagerer med Løsningen, er beskrevet i afsnit 6. Side 19 af 257
Person Ansøger om og modtager Ydelser Behandler ydelsessager Sagsbehandler (Ydelsescentret) Kommunalt kontrolteam Kontrollerer for socialt bedrageri Læser Sagsbehandler (Jobcentret) Kommunernes Ydelsessystem Kommunal mellemleder Udtrækker rapporter Læser Sagsbehandler (anden forvaltning) Kontrollerer kommunens sagsbehandling Administrerer centrale opsætninger Administrerer lokale opsætninger Intern/ekstern revisor Central administrator Kommunal administrator Figur 2: Kontekstdiagram brugeraktører 3.5.2 Brugeraktører De forskellige brugeraktører er beskrevet herunder. Brugeraktører vil blive skrevet med stort begyndelsesbogstav i Kravspecifikationen. Brugeraktørerne angives i flg. kategorier: Primære brugere: Sagsbehandler (Ydelsescentret) Kommunal administrator Kommunal mellemleder Sekundære brugere: Sagsbehandler (Jobcentret) Sagsbehandler (Anden forvaltning) Central administrator Intern/ekstern revisor Kommunalt kontrolteam Tertiære brugere Digital Ansøger Tilknyttet Ansøger Navn Rolle Person En Person der søger om en Ydelse og/eller eventuelt også modtager en Ydelse (forsørgelsesydelse, enkeltydelse eller Andre Ydelser) i kommunen Kan desuden være under administration af kommunen. Side 20 af 257
Navn Ansvar Org. og geografisk placering Antal/Kapacitet Navn Rolle Ansvar Org. og geografisk placering Antal/Kapacitet Person Søger Ydelsen og skal levere en mængde dokumentation for at modtage denne Ydelse. Kan både søge Ydelser via selvbetjeningsløsningen eller via en papiransøgning. Er som udgangspunkt bosat i kommunen På landsplan var der i 2012 ca. 218.000 såkaldte helårsmodtagere af forsørgelsesydelser (svarende til ca. 314.600 berørte personer) på beskæftigelsesområdet. Hertil kommer personer, som modtager Ydelser på øvrige delområder. Sagsbehandler (Ydelsescentret) Sagsbehandleren er den primære aktør i forhold til brugen af systemet. Benytter systemet til at udføre sin primære arbejdsopgave, som er behandling af ansøgninger og udbetaling af forsørgelses- eller enkeltydelser. Sagsbehandleren foretager endvidere fordeling af Opgaver og sager. Benytter Løsningen til at behandle ansøgninger samt udbetale Ydelser. En mindre gruppe af sagsbehandlerne vil være superbrugere af Løsningen. Det forventes, at der uddannes 4 superbrugere pr. gennemsnitskommune (50.000-60.000 indbyggere). Superbrugerne vil være supportberettigede Brugere med ret til at kontakte Leverandørens Service Desk jf. bilag 7 (Drift), hvis de ikke selv kan afhjælpe problemer i Løsningen. Ud over superbrugerne vil kommunens it-supportansvarlige også være supportberettigede Brugere. Vil som oftest være placeret i kommunens Ydelsescenter eller evt. borgerservice. Nogle kommuner vil have opgaven opdelt i to, således at en gruppe håndterer borgerkontakt og ansøgninger, mens en anden gruppe håndterer selve udbetalingerne (inkl. løbende sagsopfølgning). I større kommuner kan det være opdelt i mange forvaltninger. På landsplan eksisterer der ca. 3.000 personer (estimeret). Side 21 af 257
Navn Rolle Ansvar Org. og geografisk placering Antal/Kapacitet Sagsbehandler (Jobcenter) Der er et tæt samspil mellem jobcenter og Ydelsescentret. Således kan der også være situationer, hvor jobcentersagsbehandleren har brug for at kigge i en ydelsessag. Jobcentersagsbehandleren har ikke behov for at kunne arbejde i Løsningen men har behov for en læseadgang, så han/hun kan se, hvad der er sket i ydelsessagen. Benytter Løsningen til at slå ydelsessager op i forbindelse med behandling af en jobcentersag. Vil som oftest være placeret i kommunens jobcenter. Det vil være forskelligt i kommunerne, hvordan de vil give jobcentersagsbehandlerne adgang til ydelsessager, og adgangen vil ikke nødvendigvis ske via Løsningen. Det kan fx også ske via SAPA-løsningen. I det tilfælde vil Jobcentersagsbehandlerne ikke benytte Løsningen. På landsplan eksisterer der ca. 7.000 personer (estimeret). Navn Rolle Ansvar Org. og geografisk placering Antal/Kapacitet Navn Rolle Ansvar Org. og geografisk placering Antal/Kapacitet Sagsbehandler (anden forvaltning) En sagsbehandler i en anden del af forvaltningen, der er interesseret i at vide noget om en sag i Løsningen (læse sager). Adgangen til sagen vil som hovedregel ske via SAPA, og dermed vil Løsningen ikke blive direkte påvirket. Enkelte kommuner kan dog vælge at give specifikke medarbejdere adgang til Løsningen. Dette kunne fx være relevant i forbindelse med Andre Ydelser. Benytter Løsningen til at slå ydelsessager op i forbindelse med behandling af en sag i en anden forvaltning i kommunen. Andre forvaltninger i kommunen. Det forventes, at antallet af sagsbehandlere fra andre forvaltninger, der har direkte adgang til Løsningen, vil være på et lavt niveau. Estimeret 300 personer. Kommunal administrator En medarbejder i kommunen der har adgang til det kommunale administrationsmodul i Løsningen. Benytter Løsningen til at foretage de lokale konfigurationer, så de svarer til kommunens behov. Kan være placeret i Ydelsescentret, fx en erfaren Sagsbehandler. Kan også være placeret centralt, som fx en kommunal systemejer. På landsplan eksisterer der ca. 200-300 personer (estimeret). Side 22 af 257
Navn Central administrator Rolle Personen har adgang til det centrale administrationsmodul. Personen sørger for, at Løsningen er opsat og opdateret i forhold til nyeste Lovgivning (fx opdatering af satser), jf. i øvrigt de omfattede krav til systemadministration. Ansvar Benytter Løsningen til at foretage de centrale konfigurationer. Org. og geografisk placering eller KL. Alternativt kan rollen placeres hos en eller Kan være centralt placeret, eksempelvis hos KOMBIT flere nærmere udvalgte kommuner. Antal/Kapacitet 1-10 Navn Rolle Intern og ekstern revisor Der foretages intern og ekstern revision af Ydelsescentrets arbejde. Formålet med revisionen er at kontrollere korrekt/lovmedholdelig opgavehåndtering, -flow og dokumentation (herunder korrekt valg af refusionstype). Den interne revisor kan fx være en medarbejder fra økonomiafdelingen i en kommune. Den eksterne revisor er fra et uafhængigt revisionsfirma, der er udpeget af den kommunale tilsynsmyndighed jf. den kommunale styrelseslov. 3.5.2.1 Den eksterne revisor efterprøver ved revisionsbesøg i løbet af året, om kommunens administrative og regnskabsmæssige praksis, herunder forretningsgange, interne kontrolprocedurer samt procedurer for sagsbehandling, er hensigtsmæssige og fungerer på betryggende vis, samt om kommunen har hensigtsmæssige procedurer til at forebygge og afdække tilfælde af uberettiget modtagelse af Ydelser Ansvar Org. og geografisk placering Antal/Kapacitet Benytter Løsningen til at fremsøge sager, der skal foretages kontrol af. Kan være centralt placerede medarbejdere i Ydelsescentret (intern revisor). Eksterne revisionsfirmaer (ekstern revisor). I særlige tilfælde kan Rigsrevisionen også fungere som ekstern revisor. Intern kontrol: 1-10 i hver kommune (estimeret). Ekstern kontrol: 2-5 i hver kommune (estimeret). Side 23 af 257
Navn Kommunal mellemleder Rolle Kan være en teamleder i Ydelsescentret eller borgerservice, der har ansvaret for en gruppe af sagsbehandlere. Ansvar Benytter Løsningen til at udtrække forskellige typer af ledelsesinformation via rapporter i Løsningen. Org. og geografisk placering Vil typisk være placeret i Ydelsescentret. Antal/Kapacitet På landsplan eksisterer der 150-300 Navn Rolle Ansvar Org. og geografisk placering Antal/Kapacitet Kommunalt kontrolteam Sagsbehandlere eller andre kommunale medarbejdere med erfaring fra området. Kontrollerer for socialt bedrageri i forbindelse med ydelsessager. Benytter Løsningen til at udsøge sager til kontrol. Vil typisk være placeret i ydelsescentret. På landsplan eksisterer der 1-4 i hver kommune (estimeret). De følgende to aktører er en uddybning af aktøren Person, som benyttes i selvbetjeningsafsnittet (jf. Afsnit 5.8) Navn Rolle Digital Ansøger En Digital Ansøger er en Person, der logger ind på selvbetjeningsløsningen med NemID for at ansøge om en Ydelse eller se oplysninger om sin sag. En Digital Ansøger kan udstede fuldmagt til en Tilknyttet Ansøger, Ansvar Org. og geografisk placering Antal/Kapacitet Navn Rolle En Digital Ansøger kan invitere Ægtefælle som Tilknyttet Ansøger til at godkende dokumentation. Se Person. Se Person. Ca. 180.000 om året (af dem der er berettigede til at modtage en løbende Ydelse indgår i tallet på 218.000 helårspersoner (som er 314.600 berørte personer), jf. brugeraktør Person ). Tilknyttet Ansøger En Tilknyttet Ansøger er en Person, som logger ind på selvbetjeningsløsningen i rollen som fuldmagtshaver eller inviteret Ægtefælle. Som fuldmagtshaver logger den Tilknyttede Ansøger på selvbetjeningsløsningen med fuldmagt og kan herefter udarbejde hele eller dele af en ansøgning på Side 24 af 257
Navn Tilknyttet Ansøger vegne af den Digitale Ansøger og se sagens oplysninger. Som inviteret Ægtefælle logger den Tilknyttede Ansøger på selvbetjeningsløsningen på grundlag af invitationen og kan herefter godkende dokumentation, som den Digitale Ansøger har uploadet om Ægtefællen. Ansvar Org. og geografisk placering Antal/Kapacitet I begge tilfælde logger den Tilknyttede Ansøger på selvbetjeningsløsningen med NemID. Som fuldmagtshaver: Ansøge om Ydelse og se sagens oplysninger. Som inviteret Ægtefælle: Godkende dokumentation. I dette tilfælde kan den Tilknyttede Ansøger ikke se øvrige sagsoplysninger. En Tilknyttet Ansøger kan være bosat i hele Danmark. Se borger/person. Krav# 5: Brugeraktører som understøttes af Løsningen Beskrivelse: Løsningen skal understøtte følgende brugeraktører: Person Sagsbehandler (Ydelsescentret) Sagsbehandler (Jobcentret) Sagsbehandler (anden forvaltning) Kommunal administrator Central administrator Internt og ekstern revisor Kommunal mellemleder Kommunalt kontrolteam Digital Ansøger Tilknyttet Ansøger i rolle som fuldmagtshaver eller inviteret Ægtefælle Side 25 af 257
4 Overordnede krav I dette kapitel angives helt overordnede krav, som gælder på tværs af de Ydelser og processer, som Løsningen skal understøtte. Krav# 7: Gem alle oplysninger Beskrivelse: Alle oplysninger, der indberettes eller indhentes, beregnes mv., skal automatisk gemmes på sagen. a) Hvis der er indberettet eller indhentet data i Løsningen, skal det gemmes i databasen. b) Hvis der er beregnet beløb, skal de gemmes i databasen. Krav# 6: Løsningen skal overholde gældende Lovgivning Kategori: (MK) Type: Lov og politik Beskrivelse: Løsningen skal understøtte, at Kommunerne ved anvendelse af Løsningen overholder gældende relevant Lovgivning. Se underbilag 2.8 for en oversigt over relevant faglovgivning. Bemærkning Bemærkning - Se informationsmodellen i underbilag 2.5. 5 Funktionelle krav Dette kapitel indeholder KOMBITs krav til Løsningens funktionalitet. Figur 3 nedenfor giver et overblik over, hvilke områder de funktionelle krav er inddelt i, hvor nummeret indikerer i hvilket afsnit i kravspecifikationen, de givne krav er beskrevet. Side 26 af 257
5.1 Opgaver og sager 5.2 Behandling af ydelsessager 5.3 Administration af Persons økonomi 5.4 Tværgående funktionalitet 5.5 Visninger 5.6 Systemadministration 5.7 Rapporter og udtræk 5.8 Selvbetjening 5.9 Krav til dataudveksling Figur 3: Overblik over funktionelle krav Hvert afsnit i de funktionelle krav bliver indledt med en beskrivelse af den forretningsmæssige kontekst og forretningsbehovet, samt eventuelle start- og slutbetingelser. Beskrivelsen er efterfulgt af en række tekstuelle krav. Kravene tager udgangspunkt i en eller flere af de kortlagte forretningsbehov og processer, hvor forretningsprocesserne er beskrevet nærmere i underbilag 2.3. Her følger en beskrivelse af indholdet i hvert afsnit: Afsnit 5.1 indeholder en beskrivelse af, hvordan der oprettes og fordeles Opgaver. Hvordan sager oprettes, og hvordan sager og Opgaver hænger sammen. Afsnittet indeholder også en beskrivelse af, hvordan en sagsbehandler læser og løser Opgaven. Afsnit 5.2 indeholder meget af kernefunktionaliteten i Kommunernes Ydelsessystem; det at behandle en ydelsessag. Fra oplysning af sagen, beregning af Ydelsen, afgørelsen, effektueringen, vedligeholdelse af sagen samt afslutningen af sagen. Nedenstående Figur 4 giver indsigt i de aktiviteter, der typisk udføres i forbindelse med Opgavehåndteringen samt behandlingen af en ydelsessag, illustreret i den hyppigst forekommende sekvens i en sagsbehandlers arbejde. Figuren skal således ikke ses som en udtømmende illustration, og der vil være afvigelser, men den giver et godt indblik i det normale flow. De øverste fem aktiviteter beskrevet i afsnit 5.1 og de nederste seks aktiviteter er beskrevet i afsnit 5.2. Nummeret i hver aktivitet henviser til det underafsnit, hvor aktiviteten samt krav er beskrevet. I underafsnittene i 5.1 og 5.2 vil dele af denne figur være indsat for at tydeliggøre, hvor i processen man befinder sig. Side 27 af 257
5.1.1 Fremsøg sag 5.1.2 Opret opgave 5.1.3 Fordel opgave 5.1.4 Opret sag 5.1.5 Læs og løs opgave 5.2.1 Oplys sag 5.2.2 Fastsæt ydelsessats og beregn ydelse 5.2.3 Træf afgørelse 5.2.4 Effektuer 5.2.5 Vedligeholdelse af sag 5.2.6 Afslut sag Figur 4: Oversigt over underafsnit struktureret efter processen Afsnit 5.3 indeholder beskrivelse af håndtering af de sager, hvor kommunen administrerer Personens økonomi. Det er i de tilfælde, hvor Personen ikke er i stand til at administrere sin egen økonomi, fx betale husleje, el, vand osv. Afsnit 5.4 indeholder en beskrivelse af tværgående funktionalitet, som benyttes på tværs af de tre foregående afsnit. Fx benyttelse af breve og brevskabeloner, som både er relevante i afsnit 5.1, 5.2 og 5.3. Afsnit 5.4.5 indeholder en beskrivelse af forskellige visningskrav. Det vil sige funktionelle krav til brugergrænsefladen, således at Brugernes arbejdsgange understøttes i så høj grad som muligt. Dette skal ikke forveksles med brugervenlighedskrav, som er beskrevet i afsnit 6.5. Afsnit 5.6 indeholder beskrivelse af systemadministrations-funktionaliteten. Det er både en central systemadministration, der gælder på tværs af alle kommunerne og en lokal systemadministration, hvor den enkelte kommune kan konfigurere forskellige dele af Løsningen. Afsnit 5.7 indeholder beskrivelse af rapport og udtræksfunktionaliteten. Her beskrives hvilke muligheder, der er for Ledelsesinformation og statistik i Løsningen. Afsnit 5.8 indeholder beskrivelse af de funktionelle krav til selvbetjeningsløsningen. Afsnit 5.9 indeholder beskrivelse af, hvordan Løsningen udveksler data med andre myndigheder og organisationer. Der henvises til krav i dette afsnit fra de funktionelle krav i afsnit 5.1-5.8, der involverer udveksling af data med eksterne systemer. Krav i dette afsnit uddyber funktionelle aspekter, som er knyttet til udveksling af specifikke data, eventuelt på tværs af flere funktionelle krav, og refererer til de mere tekniske ikke-funktionelle integrationskrav i kapitel 6. Afsnittet er således et bindeled mellem funktionelle krav og ikke-funktionelle integrationskrav. Side 28 af 257
Et typisk scenarie For at give en meget kort introduktion til omfanget af systemet kommer her en meget kort scenariebeskrivelse af et typisk forløb for brugen af Løsningen. Vær opmærksom på at scenariet ikke er et udtømmende billede, men en hurtig oversigt over den vigtigste funktionalitet. Tallet i parentesen henviser til det afsnit, hvor kravene er beskrevet. - En Person søger om kontanthjælp via selvbetjeningsløsningen (5.8). - Løsningen opretter automatisk sagen (5.1.5) o og alle de data, Personen har indtastet i selvbetjeningsløsningen, overføres automatisk til sagen. - Løsningen opretter en Opgave vedrørende behandling af ansøgningen (5.1.3). - Løsningen fordeler automatisk Opgaven til den rette sagsbehandler ud fra kommunens fordelingskriterier (5.1.4). - Løsningen slår op i en række eksterne registre for at indhente oplysninger, der er nødvendige for at behandle sagen (5.2.1). - Sagsbehandleren oplyser sagen i Løsningen (5.2.1). - Løsningen fastsætter Ydelsessatsen og beregner den forventede Ydelse (5.2.2). - Sagsbehandleren afgør sagen og benytter en brevskabelon til at skrive en bevillingsskrivelse til Personen (5.2.3 og 5.4.3). - Løsningen bestiller en udbetaling i udbetalingssystemet (der sætter pengene ind på Personens konto) (5.2.4). - De efterfølgende måneder sker udbetalingerne automatisk, og sagsbehandleren er ikke i kontakt med sagen (5.2.4). - Løsningen modtager en Besked fra CPR, når Personen er fraflyttet kommunen (5.2.5). - Løsningen stopper automatisk den næste udbetaling og opretter en Opgave til sagsbehandleren (5.2.5). - Sagsbehandleren behandler Opgaven og træffer afgørelse om at lukke sagen (5.2.3). - Sagsbehandleren skriver et journalnotat og benytter brevskabelonen til at sende et afgørelsesbrev til Personen (5.4.2 og 5.4.3). - Løsningen ændrer sagens status til lukket (5.2.6). - Når kassationsfristen 3 år efter udløber, slettes sagen (5.2.6) Opgaver og sager Sagsbehandleren løser dagligt en række forskellige arbejdsopgaver i forbindelse med behandlingen af ydelsessager. En sagsbehandler vil overordnet modtage disse arbejdsopgaver på to måder. (A) Enten som en integreret del af Løsningen i form af Opgaver eller (B) ved henvendelser der genererer manuelle arbejdsopgaver. Det kan fx være et telefonopkald, en e-mail, eller at en borger henvender sig personligt. Dette er skitseret i Figur 5 nedenfor. Side 29 af 257
Figur 5: Kilder til arbejdsopgaver hos en sagsbehandler De manuelle arbejdsopgaver, der er genereret ved henvendelser, vil sagsbehandleren typisk behandle ved først at fremsøge den relevante sag, som henvendelsen drejer sig om. Sagsbehandleren vil, når hun har fremsøgt sagen, behandle arbejdsopgaven i Løsningen på samme måde som de Opgaver, der er oprettet i Løsningen. I visse tilfælde vil sagsbehandlere i Ydelsescentret, kommunale mellemledere, intern/ekstern revisor have behov for at foretage en avanceret søgning ud fra en række parametre for at kunne foretage intern eller ekstern kontrol med sagerne samt kontrol af social bedrageri i en række sager. Opgavelisten viser som udgangspunkt alle kommunens opgaver. Det kan fx være på baggrund af Beskeder fra eksterne systemer eller interne systemregler. Opgaver vil blive oprettet løbende og kan både blive oprettet automatisk af Løsningen eller manuelt af en Bruger. Opgavelisten har overordnet to formål: a) At give let mulighed for at fordele Opgaver (afsnit 5.1.4). Hver enkelt Opgave skal som udgangspunkt tilknyttes en sag (en eksisterende eller nyoprettet sag) samt fordeles til en sagsbehandler eller et team, før den kan behandles. b) At give den enkelte sagsbehandler overblik over de Opgaver, denne skal løse (afsnit 5.1.6). Dette skal ses som sagsbehandlerens mulighed for at styre, prioritere sine Opgaver og overholde deadlines etc. I Figur 6 har Kunden forestillet sig, hvordan en opgaveliste kunne se ud, blot for at give en visuel beskrivelse af konceptet. Opgavelisten kunne indeholde en lang liste med Opgaver, hvor hver Opgave indeholder en række relevante informationer, der understøtter de to ovenfor beskrevne formål. Det kunne fx være Opgavetitel, CPR nummer på den primære part i sagen, hvilken sagsbehandler Opgaven er fordelt til osv. Der er filtrering og sorteringsmekanismer, som gør, at det er muligt hurtigt at fremfinde de Opgaver, der er relevante for den enkelte sagsbehandler. Side 30 af 257
Opgaveliste Opgave Ydelsesart CPR blabla Sag Sagsbehandler Indkomst ændret Kontanthjælp 12345678 123 AOH Dokument modtaget............... Opfølgning Kontanthjælp 12345678... 434... Ansøging Enkeltydelse... 123 AOH Tidsfrist partshøring Kontanthjælp 99999999...... SKI Figur 6: Konceptuel tegning af opgaveliste I de efterfølgende afsnit beskrives hvordan Opgaverne oprettes, hvordan de fordeles og hvordan sagsbehandleren benytter opgavelisten som arbejdsredskab. Se desuden afsnit 5.5.2 for krav til visninger vedrørende opgavelisten. Der beskrives også, hvordan Opgaver hænger sammen med sager, og hvordan det ud over opgavefordeling også er muligt at fordele sager. Underafsnittene i afsnit 5.1 vil følge den tidligere beskrevne struktur fra Figur 4. Underafsnittene følger således den typiske proces ved håndtering af Opgaver og sagsoprettelse. Nedenfor i Figur 7 vises et udsnit af Figur 4, hvor afsnit 5.2 er foldet sammen, så det kun er aktiviteterne i afsnit 5.1, der vises. Nummeret i hver aktivitet henviser til de pågældende underafsnit, der beskriver aktiviteten. 5.1.1 Fremsøg sag 5.1.2 Opret opgave 5.1.3 Fordel opgave 5.1.4 Opret sag 5.1.5 Læs og løs opgave 5.1 Opgaver og sager 5.2 Behandling af ydelsessager Figur 7: Udsnit af " Oversigt over underafsnit struktureret efter processen" Side 31 af 257
5.1.1 Fremsøg sag enkel søgning Sagsbehandleren skal hurtigt kunne fremsøge sager ved forskellige typer af henvendelser. Ofte kan henvendelsen ske, mens sagsbehandleren er i gang med at behandle en anden Opgave. Krav# 8: Fremsøgning af sager Beskrivelse: Brugeren har let adgang til søgefunktionalitet, hvor sager kan fremsøges. Bemærkning a) Brugeren kan ved maksimalt to klik/tastetryk få adgang til søgefunktionaliteten fra hvilket som helst skærmbillede i Løsningen. b) Brugeren kan anvende flg. søgekriterier: sagsid, CPR-nummer, navn på Person, sagen omhandler, sagsbehandler/team på sagen, sagsstatus og Ydelsesart. c) En afsluttet sag kan fremsøges ved at søge på afsluttede sager. Der er læseadgang til hele sagen, men Brugeren kan ikke redigere allerede registrerede data. 5.1.2 Fremsøg sager avanceret søgning Sagsbehandlere, kommunale mellemledere, interne/eksterne revisorer skal kunne foretage en avanceret søgning på sager, der opfylder et eller flere søgekriterier. Søgeresultatet, der viser en liste af sager, anvendes til foretage intern og ekstern kontrol, kontrol af udbetalinger samt kontrol for socialt bedrageri. Intern og ekstern kontrol har til formål at sikre/styrke fagligheden i sagsbehandlingen og herigennem sikre en lovmedholdelig sagsbehandling samt overholdelse af standarder. Kontrollerne gennemføres ad-hoc såvel flere gange dagligt som med dages, ugers og måneders mellemrum. Intern og ekstern kontrol omfatter bl.a.: - Ledelsestilsyn: Kontrol af Brugernes sagsbehandling, fx om den har den rette faglige kvalitet. - Dokumentationskontrol: Kontrol af, om sagsbehandlerne opfylder dokumentationspligten. - Kontrol af Brugere med indberetningsadgang: Kontrol af om en Bruger har udbetalt penge til sig selv, familiemedlemmer, personer på samme bopæl mv. - Revisorkontrol: Kontrol af om sagsbehandlingen er gennemført i overensstemmelse med god praksis og relevante standarder. - Øvrig kontrol: Fx kontrol af sager, hvor betalingen går til en tredjepart, fx en tandlæge eller et flyttefirma. Kontrol af udbetalinger sker med henblik på at kontrollere for udbetaling til Brugere med indberetningsadgang til Løsningen. Løsningen skal kunne udtrække sager, således det bliver muligt at kontrollere, om en Bruger har udbetalt penge til sig selv, personer på samme bopæl som Brugeren eller til Brugerens familie Kontrol relateret til socialt bedrageri starter typisk ved, at det kommunale kontrolteam gennemfører stikprøver af sager eller udfører kontrol på baggrund konkret mistanke, fx på baggrund af henvendelse fra borgere eller på baggrund af en række kriterier, der opfyldes. Side 32 af 257
Krav# 9: Avanceret søgning Beskrivelse: Brugeren skal kunne anvende 20-30 søgekriterier til fremsøgning af sager. a) Brugeren kan anvende de søgekriterier, der indgår i den enkle søgning. b) Flg. øvrige kriterier skal kunne indgå i søgningen: - CPR nummer interval - Navn på parter i sagen - Adresse på parter i sagen - Fødselsdato og -år på parter i sagen - Periode for startdato og slutdato på Ydelse - Periode for startdato og slutdato på sag - Dokumentation i ansøgningsskemaet (fx foreligger der dokumentation for indestående på pensionsordning) - Opholdsbetingelser (har pågældende fx lovligt ophold i Danmark) - Bevilling og journalføring (er der fx foretaget vurdering af ret til Ydelse) - Særlig støtte (er der fx dokumentation for boligudgift, hvis relevant) - Sanktioner (antal/type/periode, ubehandlet) - Konteringer (fx i forhold til beløbsstørrelser) - Paragraf, som udbetaling er sket efter - Dato for ferieret jf. LAS 13, stk. 11 - Er der sket afregning til UDK jf. 96a c) Søgeresultatet kan opsættes, så det angiver Betalingsmodtagere på sager behandlet af en given sagsbehandler med angivelse af navn og adresse på betalingsmodtagerne, udbetalinger på kontonumre, som ikke er NemKonto kontonumre. Eksempler på søgebehov er: 1) Søgning på første udbetalingsdag, så man kan finde personer, der har gået langvarigt på hjælp 2) Særlig støtte 34 til boligudgifter så man kan se, hvem der får høj Ydelse 3) Særlig støtte 34 til boligudgifter pr. en given startdato så man kan se, hvem der har fået Ydelsen i lang tid 4) Søgning på alder så man kan finde personer, der passerer efterlønsalder, så de kan vurderes efter LAS 27 5) Seneste måneds udbetaling, så man kan se på CPR med særligt høje Ydelser. Side 33 af 257
5.1.3 Opret Opgave Opgaver kan oprettes i Løsningen via fire overordnede kilder. De kan oprettes på baggrund af: - en Besked/kald fra et eksternt system (fx en flyttebesked fra CPR) - en intern systemregel, der danner en Opgave (fx i forbindelse med en tidsfrist) - en manuel Brugeroprettet Opgave - Modtagelsen af et dokument fra et eksternt system (fx et brev fra den kommunale postscanningsenhed) Alle disse forskellige typer af Opgaver vil vises på opgavelisten. Dette er illustreret i Figur 8. Kilder til oprettelse af opgaver Besked/ kald modtaget Dokument modtaget Opret opgave Opgave vises på opgavelisten Manuel opgave (påmindelse) Intern regel Figur 8: Kilder til oprettelse af Opgaver Krav# 10: Oprettelse af Opgaver Beskrivelse: Løsningen kan oprette Opgaver. a) Der kan oprettes Opgaver manuelt af sagsbehandleren. b) Der kan oprettes Opgaver automatisk af Løsningen på baggrund af interne regler. c) Der kan oprettes Opgaver automatisk via Beskeder/kald fra eksterne systemer. d) Der kan oprettes Opgaver automatisk via indkomne dokumenter eller via ansøgning fra selvbetjeningsløsningen. Side 34 af 257
e) Alle oprettede Opgaver vises på en opgaveliste. f) Så mange informationer som muligt skal automatisk udfyldes ved opgaveoprettelse. - I underbilag 2.13 findes en oversigt over de Hændelser, der indtræffer, som Brugeren skal reagere på. Dette vil være input til de forskellige opgavetyper. - Se afsnit 5.1.3.1 for manuelt oprettede Opgaver, jf. punkt a. - Se Krav# 92 vedrørende automatiske reaktioner på Hændelser og interne regler, jf. punkt b og c. - Beskeder/kald fra eksterne systemer kan fx være Beskeder fra Beskedfordeleren eller fra jobcenterintegrationen, jf. punkt c. - Se afsnit 5.1.3.2 vedrørende oprettelse af Opgaver på baggrund af indkomne dokumenter, jf. punkt d. - Se afsnit 5.8.1.2 vedrørende ansøgninger fra selvbetjeningsløsningen. - Se 5.4.5 vedrørende anmodninger om sagsoverførsler. - Se informationsmodellen KY-Opgave i underbilag 2.5. Krav# 11: Informationer på en Opgave Beskrivelse: En Opgave indeholder bl.a. følgende informationer: - Opgavetype/titel, der afspejler den Hændelse, der har udløst Opgaven - Ydelsesart (kontanthjælp, enkeltydelse, etc.) - Person Opgaven omhandler (CPR + navn) - Sagen (Sagsnummer) - Sagsbehandler (navn eller team) - Dato for oprettelse af Opgaven - Status for Opgaven (Ubehandlet, Under behandling, Afsluttet) - Deadline for løsning af Opgave - Distrikt/område - Prioritet (Høj/Middel/Lav) - Ydelse sat på hold (Ja/Nej) - Opgavebeskrivelse - Frekvens ved tilbagevendende Opgave - Ydelsesart er beskrevet i Krav# 3. - Se informationsmodellen KY-opgave i underbilag 2.5. - I underbilag 2.13 findes en oversigt over de Hændelser, der indtræffer, som Brugeren skal reagere på. Dette vil være input til de forskellige opgavetyper. - Følgende er eksempler på opgavetyper o Ansøgning modtaget o Indstilling modtaget o Vurdér nye oplysninger på sagen: Feriepenge udbetalt Side 35 af 257
- Vurdér nye oplysninger på sagen: Indkomst ændretfrekvens ved tilbagevendende Opgave kan bl.a. være dagligt, ugentligt, månedligt, kvartalsmæssigt, halvårligt, årligt med udgangspunkt i en af Brugeren valgt dato. 5.1.3.1 Manuelt oprettede Opgaver (påmindelser) I forbindelse med behandling af en sag, vil der ofte være tilfælde, hvor Brugeren bliver nødt til at lægge sagen til side for på et senere tidspunkt at genoptage sagen. I de tilfælde er der behov for, at Brugeren bliver påmindet om sagen, så den ikke glemmes. Brugeren kan derfor oprette en Opgave til sig selv og derigennem påmindes via en manuelt oprettet Opgave på opgavelisten. Der kan også være andre situationer, hvor det kan være relevant at oprette manuelle Opgaver. Krav# 12: Manuelt oprettet Opgave Beskrivelse: Brugeren kan oprette en Opgave. a) Brugeren kan oprette en Opgave via sagen a. Der dannes i dette tilfælde automatisk en relation til sagen b) Brugeren kan oprette en Opgave uden relation til en sag. c) Opgaven indeholder samme informationer som beskrevet i Krav# 11. d) Brugeren kan redigere alle data på Opgaven. e) Ydelsesart, Person, sagsnummer og dato for oprettelse af Opgaven er forudfyldt, hvis Opgaven er oprettet via en sag. f) Det er muligt at oprette en Opgave, der gentages. Det kan vælges med hvilken frekvens, Opgaven gentages. Se informationsmodellen KY-opgave i underbilag 2.5. Ofte vil en Bruger benytte de samme Opgaver mange gange. For at undgå at Brugeren skal indtaste alle data på Opgaven hver gang, kan Brugeren vælge mellem en række forskellige standard- Opgaver, hvor den kommunale administrator har forudfyldt en række felter. Krav# 13: Standardopgaver Beskrivelse: Ved oprettelse af en Opgave er det muligt for Brugeren at tage udgangspunkt i en række af standardopgaver. - Se Krav# 12 om oprettelse af Opgave. - Se Krav# 189 for konfigurering af standardopgaver. 5.1.3.2 Opgaver oprettes på baggrund af indkomne dokumenter Løsningen kan modtage dokumenter via Dokumentfordeleren, der er beskrevet i afsnit 6.3.2.2. Ved modtagelse af dokumenter skal Løsningen oprette en Opgave, så Sagsbehandleren kan behandle det indkomne dokument. Kunden forestiller sig, at det typisk vil være dokumenter fra kommunale ESDH systemer, den kommunale scanningsenhed (scannet papirpost) og andre kommu- Side 36 af 257
Se desuden krav vedrørende dokumenter og håndtering heraf i afsnit 5.4.2 Dokumenter. Krav# 14: Oprettelse af Opgave ved modtagelse af dokumenter Beskrivelse: Løsningen kan ved modtagelse af dokumenter via Dokumentfordeleren oprette en Opgave og tilknytte de relevante metadata fra dokumentet på Opgaven. nale fagsystemer. Men da det er eksterne systemer, der sender dokumenter via Dokumentfordeleren, er det ikke muligt at vide, hvor mange og hvor præcise metadataene på dokumentet er. Ønsket er, at jo flere metadata der er på dokumentet, jo flere data kan Opgaven oprettes med. Ved fx modtagelse af et indscannet dokument fra postscanningsenheden, vil det således være forskelligt, hvor mange metadata der er på dokumentet og dermed hvor mange data, der kan overføres til Opgaven. - Metadata på dokumentet kunne fx være KLE nummer, Personens CPR-nummer. Sagsbehandlerens navn osv. - Se Krav# 17 vedrørende tilknytning af dokumenter til en Opgave. - Se afsnit 6.3.2.2 vedrørende Dokumentfordeleren. - Se informationsmodellen (KY-dokument, KY-sag) i underbilag 2.5. - Se snitfladerne SF2800 og SF2810 i underbilag 2.6 5.1.4 Fordel Opgave Fordeling af Opgaver består af to ting. For at kunne behandle en Opgave skal den være tilknyttet en sag og være tildelt en sagsbehandler eller et sagsbehandler-team. Manuelt oprettede Opgaver (påmindelser) behøver dog ikke at være tilknyttet en sag. I nogle tilfælde vil alle informationerne på en Opgave være udfyldt ved opgaveoprettelse (se afsnit 5.1.4.1 og 5.1.4.2 vedrørende automatisk fordeling), herunder både sag og sagsbehandler. Dermed vil Opgaven kunne fordeles automatisk. Andre gange vil der mangle informationer, så den ikke kan fordeles automatisk. Så skal Opgaven fordeles manuelt. I nogle kommuner vil der være en medarbejder, der er dedikeret til at fordele Opgaverne, i andre kommuner vil det være sagsbehandleren selv, der både fordeler og efterfølgende behandler sagerne. Hvis man i opgavelisten - uden nogen form for filtrering slået til - ser på alle kommunens Opgaver vil der altså være både Opgaver, der er tilknyttet eksisterende sager, og Opgaver, der endnu ikke er tilknyttet nogen sag. Opgaven vil som hovedregel skulle være tilknyttet en sag for at kunne behandles. Det betyder, at Opgaven skal tilknyttes en sag, og hvis den ikke kan tilknyttes en eksisterende sag, skal der oprettes en ny sag, hvor den kan tilknyttes. Dette er illustreret i Figur 9. Side 37 af 257
Opgave oprettet Tilføj evt. andre oplysninger Opret ny sag og tilknyt opgave til denne Tilknyt opgave til eksisterende sag Tildel sagsbehandler Opgave fordelt / klar til behandling Figur 9: Tilknytning af Opgave til sag samt tildeling af Sagsbehandler Da det ikke altid vil være muligt at vide hvor mange informationer, der er udfyldt, når Opgaven oprettes, skal det være muligt for Sagsbehandleren at tilføje og redigere oplysningerne på Opgaven (via opgavelisten), så den bliver lettere at fordele korrekt. Dette er selvfølgelig relevant i forhold til sag og Sagsbehandler, men også andre informationer såsom CPR-nummer eller Ydelsesart kan være relevant at tilføje, for at den dermed lettere kan blive endeligt fordelt. Krav# 15: Tilføjelse af manglende oplysninger på en Opgave Beskrivelse: Det er muligt for Brugeren at tilføje eventuelt manglende oplysninger samt redigere eksisterende oplysninger for hver Opgave. a) Brugeren kan tilføje, slette og redigere oplysningerne på en Opgave. b) Tilføjelse, redigering kan foretages direkte fra opgavelisten. c) Tilføjelse, redigering kan foretages direkte fra selve Opgaven. d) Når Brugeren tilknytter en Opgave til en sag, er det muligt at vælge en eksisterende sag eller at oprette en ny sag. - Se Krav# 21 vedrørende manuel oprettelse af sag. Krav# 16: Massebehandling af Opgaver Beskrivelse: Brugeren kan massebehandle Opgaver. a) Brugeren kan tilføje, slette og redigere oplysningerne på flere Opgaver samtidigt. - Med massebehandling menes fx at fordele flere Opgaver samtidig (fordele en række Opgaver til en ny Sagsbehandler) eller at ændre status på flere Opgaver samtidig (afslutte en række Opgaver samtidigt). Side 38 af 257
Nogle Opgaver er oprettet på baggrund af, at Løsningen har modtaget et dokument (se afsnit 5.1.3.2). Løsningen har i disse tilfælde dannet en Opgave, hvor dokumentet er tilknyttet. I disse tilfælde vil Brugeren ofte skulle læse dokumentet inden, Opgaven kan fordeles. Krav# 17: Opgaver med tilknyttede dokumenter Beskrivelse: Hvis der er tilknyttet et dokument på en Opgave, er der let adgang til at læse dokumentet. a) Brugeren kan direkte fra selve Opgaven få adgang til at læse dokumentet. b) Brugeren kan direkte fra opgavelisten få adgang til at læse dokumentet. c) Når Opgaven tilknyttes en sag, gemmes dokumentet automatisk på den givne sag. Relationen til Opgaven bibeholdes. d) Det er muligt at kopiere dokumentet til flere sager (i det tilfælde at dokumentet er relevant for flere sager). - Se Krav# 118 for manuel tilknytning af dokumenter til sag. 5.1.4.1 Automatisk tilknytning af Opgave til sag Hvor det giver forretningsmæssig mening, bør Opgaven tilknyttes automatisk til sagen. Det betyder, at hvis der er en entydig relation mellem Opgaven og sagen, skal tilknytningen ske automatisk. Hvis der derimod kan være tvivl om hvilken sag, Opgaven tilhører, bør tilknytningen ikke ske automatisk. Der vil fx oftest være en entydig relation, hvis det drejer sig om upload af et nyt dokument til en eksisterende sag via selvbetjeningsløsningen eller ved modtagelse af flyttebesked fra CPR, og der kun eksisterer én sag med det CPR-nummer i Løsningen. Krav# 18: Automatisk tilknytning af Opgaver til sag Beskrivelse: Løsningen skal automatisk tilknytte en Opgave til en eksisterende sag. a) Løsningen kan automatisk tilknytte en Opgave til en eksisterende sag, hvis der kan etableres en entydig relation til én sag ud fra oplysninger på Opgaven. I Afklaringsfasen defineres præcist i hvilke tilfælde, Løsningen automatisk skal tilknytte Opgaven til en sag. 5.1.4.2 Automatisk tildeling af Opgave til sagsbehandler Hvor det er muligt, bør Opgaven automatisk tildeles sagsbehandleren eller et team. Til dette benyttes forskellige fordelingsnøgler. Da kommunerne har forskellig organisering, skal det være muligt for kommunerne at vælge mellem de mest almindelige former for fordelingsnøgler, så Løsningen understøtter de forskellige kommunale organiseringer. Side 39 af 257
Krav# 19: Automatisk tildeling af Opgave til sagsbehandler Beskrivelse: Løsningen kan automatisk tildele en Opgave til en sagsbehandler eller et sagsbehandlerteam. En Opgave kan fordeles ud fra områdeopdeling, CPR interval og opgavetype eller en kombination mellem de tre. a) Løsningen kan automatisk tildele en sagsbehandler eller et sagsbehandler-team til en Opgave ud fra fordelingsnøglerne beskrevet herunder: a. Alle Opgaver, hvor parten i sagen bor i et specifikt geografisk område (socialdistrikter), skal fordeles til en specifik Sagsbehandler/team, b. Alle Opgaver, hvor parten i sagen har CPR-nummer i et særligt CPR-nummer interval, skal fordeles til en specifik Sagsbehandler/team. c. Med udgangspunkt i CPR-nummer på følgende form DDMMÅÅ- LLLL skal intervaller kunne laves på basis af dag (DD), måned (MM) eller løbenummer (LLLL). d. Alle Opgaver af en bestemt opgavetype skal fordeles til en specifik Sagsbehandler/team. b) Det er muligt at benytte alle fordelingsnøglerne i kombination, fx både områdedelt samt cpr-opdeling. c) Løsningen tager højde for hvilke fordelingsnøgler, der er opsat af den Kommunale administrator. - Se Krav# 361 om snitflade til CPR Vejregister. - Se Krav# 187 for konfigurering af hvilke fordelingsnøgler, der benyttes i kommunen. - Se afsnit 6.3.2.2 vedrørende Organisation. - Se afsnit 6.3.2.1 vedrørende Klassifikation. 5.1.5 Opret sag Formålet med opret sag er, at kommunen på baggrund af en henvendelse kan oprette en sag med tilhørende dokumenter, så den er klar til den videre sagsbehandling. Som beskrevet i tidligere afsnit skal der som hovedregel oprettes en sag, hvis kommunen modtager en oplysning, der ikke tilhører en allerede eksisterende sag. Typisk vil en sag oprettes ved modtagelsen af en ansøgning eller en indstilling. På enkelte Ydelsesarter kan en sag også oprettes ud fra Beskeder fra Jobcentret. Nedenstående Tabel 4 viser, hvilket format en ansøgning modtages i, samt den typiske efterfølgende behandling af oplysningen. Format Indgang i kommunen Sag oprettes i Løsningen Side 40 af 257
Fysisk dokument Digitalt dokument Data Besked Dokumentet modtages på papir i Ydelsescentret. Dokumentet modtages i Løsningen via Dokumentfordeleren (jf. afsnit 6.3.2.2) fx fra ESDH, postscanningsenhed eller andet eksternt system. Data modtages via selvbetjeningsløsningen (jf. afsnit 5.8.1.2). Besked fra Jobcentret angående Godtgørelser og LAB-målgruppe 2.7, 2.11 og 2.14. Manuelt Manuelt/Automatisk Automatisk Automatisk Tabel 4: Behandling af ansøgning/indstilling efter modtagelsesformat Krav# 20: Automatisk oprettelse af sag Beskrivelse: Løsningen skal kunne oprette sager automatisk på grundlag af Hændelser, der er sket i andre it-løsninger. a) Løsningen kan automatisk oprette en sag, når der modtages en ansøgning fra selvbetjeningsløsningen. Ved sagsoprettelsen gemmes ansøgningen som strukturerede data, der indgår dels som beslutningsgrundlag for oplysning af sagen og dels som den Digitale Ansøgers/Tilknyttede Ansøgers ansøgning, der til enhver tid kan tilgås af sagsbehandleren. b) Løsningen kan automatisk oprette en sag, når der modtages Beskeder fra Jobcentret vedrørende Godtgørelser og LAB-målgruppe 2.7, 2.11 og 2.14. c) Løsningen kan, hvis der er tilstrækkeligt med metadata på ansøgningen, automatisk oprette en sag, når der modtages en ansøgning via Dokumentfordeleren. d) Løsningen registrerer de krævede sagsoplysninger på sagen jf. kravet til manuel oprettelse af sag og opretter en Opgave om sagen. Sagsbehandler tilknyttes til sagen ved brug af de samme kriterier, som anvendes ved tildeling af en Opgave til sagsbehandler i Krav# 19. e) Hvis sagen er oprettet på en Person/ægtefælle, der ikke i forvejen har en igangværende sag i Løsningen, opdaterer Løsningen abonnementet i Beskedfordeleren og abonnementer på ændringer vedrørende CPR med Personens CPR-nummer. f) Løsningen registrerer Hændelse om oprettelse af sagen og sikrer at andre it-løsninger kan blive orienteret om hændelsen. g) Løsningen opdaterer Sags- og Dokumentindeks. h) Løsningen kan oprette en sag uafhængig af, hvor Personen har opholdskommune, men det signaleres hvis der ikke er overensstemmelse mellem opholdskommune og handlekommune, der modtager ansøgningen. - Se hændelseslisten i underbilag 2.13 vedrørende Beskeder via Beskedfordeleren. - Se afsnit 5.8 vedrørende selvbetjeningsløsningen. - Se afsnit 5.2.3.4 og 5.9.1.4 vedrørende Godtgørelser. - Se afsnit 6.3.2.2 vedrørende Dokumentfordeler. Side 41 af 257
- Se afsnit 6.3.2.5 vedrørende Beskedfordeleren. - Se afsnit 6.4.3.5 vedrørende snitflade til SKAT. - Se afsnit 6.4.3.2 vedrørende snitflade til CPR. - Se afsnit 6.3.2.3 vedrørende Sags- og Dokumentindeks. - Se informationsmodellen (KY-sag) i underbilag 2.5 i forbindelse med årsager til ansøgning. Krav# 21: Manuel oprettelse af sag Beskrivelse: Det er muligt for Brugeren at oprette en sag manuelt med tilhørende relevante oplysninger. a) Brugeren kan oprette en sag. b) Løsningen tilføjer sagsdata. c) Brugeren kan tilføje og ændre sagsdata. d) Ved oprettelse af sagen skal der bl.a. angives de oplysninger, der fremgår af underbilag 2.23 (Minimumsoplysninger). e) Hvis sagen er oprettet på en Person/ægtefælle, der ikke i forvejen har en igangværende sag i Løsningen, opdaterer Løsningen abonnementet i Beskedfordeleren og abonnementer på ændringer vedrørende CPR med Personens CPR-nummer. f) Løsningen registrerer Hændelse om oprettelse af sagen og sikrer at andre it-løsninger kan blive orienteret om hændelsen. g) Løsningen opdaterer Sags- og Dokumentindeks. h) Løsningen kan oprette en sag uafhængig af, hvor Personen har opholdskommune, men det signaleres hvis der ikke er overensstemmelse mellem opholdskommune og handlekommune, der modtager ansøgningen. - Sagsdata kan fx være oprettelsesdato, status mm. - Se hændelseslisten i underbilag 2.13. for udgående Beskeder til Beskedfordeleren. - Se afsnit 6.3.2.5 vedrørende Beskedfordeleren. - Se afsnit 6.4.3.2 vedrørende snitflade til CPR. - Se afsnit 6.3.2.3 vedrørende Sags- og Dokumentindeks. - Se informationsmodellen (KY-sag) i underbilag 2.5 i forbindelse med sagsoprettelse og årsager til ansøgning. Krav# 22: Oprettelse af Opgave ved sagsoprettelse Beskrivelse: Efter automatisk sagsoprettelse skal der automatisk oprettes en Opgave, hvor den nyoprettede sag er tilknyttet, som gør Brugeren opmærksom på sagen. a) Når der automatisk er oprettet en sag, opretter Løsningen automatisk en ny Opgave, hvor den nyoprettede sag er tilknyttet Side 42 af 257
a. Dette gælder dog ikke i tilfælde, hvor sagen er oprettet på grundlag af en meddelelse fra jobcentret om Godtgørelse. b) Ved manuel sagsoprettelse kan Brugeren yderligere vælge at gå direkte til sagsbehandlingen, og i dette tilfælde vil der ikke blive oprettet en Opgave. - Se Krav# 20 og Krav# 21 om sagsoprettelse. - Se hændelseslisten i underbilag 2.13 om oprettelse af Opgaver ved automatisk sagsoprettelse. - Se beskrivelse af godtgørelsessager i afsnit 5.2.3.4. Krav# 23: Tilknytning af KLE Beskrivelse: Når der oprettes en sag (både manuelt og automatisk), skal der automatisk tilknyttes KLE-nummer på sagen. a) Når der oprettes en sag, skal Løsningen automatisk tilknytte et KLE-nummer på sagen, herunder også handlingsfacet samt kassationskode. b) Løsningen skal sikre, at emne, handlingsfacet og kassationskode overholder KLE. c) Kassationskoden i Løsningen må aldrig kunne sættes kortere end 3 år. d) Kassationskoden skal som hovedregel være sat automatisk til 3 år. - Det må ikke være muligt at sætte (hverken manuelt eller automatisk) kassationskoden til mindre end 3 år, eftersom Løsningen skal levere data til Styrelsen for Arbejdsmarked og Rekruttering 3 år tilbage i tiden. - Se også Krav# 56 vedrørende Brugerens mulighed for at ændre kassationskoden i forbindelse med afgørelsen af en sag. - Se afsnit 6.3.2.1 vedrørende integration til Klassifikation. - I underbilag 2.15 Oversigt over Ydelsesarter ses hvilke KLE-numre, der skal tilknyttes til de enkelte Ydelsesarter. - Jf. OIO standarderne for Sag eller tilsvarende i forhold til mulige kassationskoder og frister. Se afsnit 7 for referencer til OIO_SAG. 5.1.6 Læs og løs Opgave Som beskrevet tidligere i afsnit 5.1 benyttes opgavelisten til at fordele Opgaverne. Derudover er opgavelisten også den enkelte sagsbehandlers indgang til Løsningen, hvorfra de kan plukke Opgaver, der skal løses. Formålet med opgavelisten er her at give den enkelte sagsbehandler et overblik over, hvilke Opgaver de skal løse og hjælpe med prioriteringen af opgaveløsningen. Opgavelisten kan også ses som sagsbehandlerens huskeliste, så ubehandlede Opgaver ikke glemmes. Side 43 af 257
Sagsbehandlerne kan være organiserede på mange forskellige måder i kommunerne. I nogle kommuner vil sagsbehandlerne behandle alle Ydelsessager fra start til slut. I andre kommuner kan det være mere specialiseret, så en sagsbehandler kun behandler nye ansøgninger på kontanthjælp. Løsningen skal tage højde for dette og være fleksibel nok til at kunne håndtere de forskellige behov for opgavefordeling. Krav# 24: Læs Opgaver Beskrivelse: Brugeren kan via en opgaveliste vælge en Opgave og læse indholdet i Opgaven. a) Brugeren kan fra en opgaveliste vælge en Opgave og se hele indholdet i Opgaven. b) Brugeren kan navigere direkte fra Opgaven til den tilknyttede sag o Hvis det er muligt entydigt at definere det præcise skærmbillede, hvor Opgaven kan løses, navigeres direkte til dette. - I forhold til b) så forventer Kunden, at der navigeres så dybt som muligt. Hvis Opgaven omhandler indtægter, så navigeres til indtægtsbilledet. Til tider vil det måske ikke være muligt at kende undersiden. I disse tilfælde navigeres blot til sagsoverblikket. - Se Krav# 17 angående tilknyttede dokumenter til Opgaver. - Se underbilag 2.10 Eksempler på skærmbilleder afsnit 2.1 for inspiration. Krav# 25: Ændring af status på Opgave Beskrivelse: Det er muligt for Brugeren at ændre status på en aktiv Opgave, dvs. ikke hvis Opgavens status = Afsluttet. Status må kun ændres fremadrettet. a) Brugeren kan ændre status på en Opgave fra opgavelisten. b) Brugeren kan ændre status på en Opgave fra selve opgaven. c) Brugeren kan ændre status på en Opgave fra sagsoverblikket på den sag, hvor til Opgaven er tilknyttet. - De forskellige muligheder for at ændre status på Opgaver er medtaget for at kunne understøtte sagsbehandlerens fleksible arbejde. Fx skal status kunne opdateres fra selve sagen, således at Brugeren ikke behøver at gå tilbage til opgavelisten for at markere en Opgave som løst. - Se Krav# 166 for visning af aktive Opgaver på sagen. Behandling af ydelsessager I dette afsnit beskrives kernefunktionaliteten i Kommunernes Ydelsessystem; det at behandle en ydelsessag. Nedenstående figur er et udklip af Figur 4, hvor aktiviteterne i afsnit 5.1 er foldet sammen, så kun aktiviteterne i afsnit 5.2 vises. Figuren giver indsigt i de aktiviteter, der typisk udføres i forbindelse med behandlingen af en ydelsessag, illustreret i den hyppigst forekommende sekvens i Side 44 af 257
en sagsbehandlers arbejde. Nummeret i hver aktivitet henviser til det afsnit, hvor aktiviteten samt krav er beskrevet. 5.1 Opgaver og sager 5.2.1 Oplys sag 5.2.2 Fastsæt ydelsessats og beregn ydelse 5.2.3 Træf afgørelse 5.2.4 Effektuer 5.2.5 Vedligeholdelse af sag 5.2.6 Afslut og arkiver sag 5.2 Behandling af ydelsessager Figur 10: Aktiviteter og typisk sekvens i behandlingen af en ydelsessag En ydelsessag indeholder hele sagens livsforløb, fra en Person ansøger om en Ydelse eller bliver indstillet til en Ydelse af Jobcentret, får bevilget Ydelsen, Ydelsen udbetales og sagen til sidst afsluttes. Hvis det drejer sig om en forsørgelsesydelse, vil den bevilgede Ydelse typisk udbetales flere gange, så Effektuer (5.2.4) vil gennemløbes igen og igen, indtil kommunen modtager nye oplysninger (jf. 5.2.5). Alt efter hvilke oplysninger, der modtages, vil der dannes en ny Opgave, og man går tilbage i sekvensen. Se i underbilag 2.3 for en beskrivelse samt diagram over forretningsprocesserne for de forskellige Ydelsesarter. Vær herunder opmærksom på at der kan være forskelle i sekvens og aktiviteter mellem de forskellige Ydelsesarter. De efterfølgende krav i afsnittet vil som hovedregel gælde for samtlige Ydelsesarter. Hvis der er krav, der er specifikke for en given Ydelsesart, vil det fremgå tydeligt af beskrivelsen. Nogle af Ydelsesarterne vil dog ikke være omfattet af hele funktionaliteten. Fx vil Løsningen ikke beregne beløbet til udbetaling for en enkeltydelse. Tabel 5 giver et indblik i hvilken funktionalitet, der er understøttet i hver enkelt Ydelsesart. Ydelsesart / Aktivitet Opret sag Oplys sag Sagsog opgavefordeling Fastsæt Ydelsessats og beregn Ydelse Træf afgørelse Effektuer Kontanthjælp X X X X X X X X Afslut og arkiver Vedligeholdelse af sag Uddannelseshjælp X X X X X X X X Ledighedsydelse X X X X X X X X Revalideringsydelse X X X X X X X X Side 45 af 257
Fleksløntilskud X X X X X X X X Ressourceforløbsydelse X X X X X X X X Enkeltydelser X X X X X X X Andre Ydelser X* X X* X* X X X* Administration af persons økonomi X X X X X X X Tabel 5: Oversigt over systemunderstøttelse af Ydelsesarter. *Se nedenstående beskrivelse For Andre Ydelser vil aktiviteter markeret med * kun være understøttet i og med, at funktionaliteten er tilvejebragt via de andre Ydelsesarter, som fx kontanthjælp. Andre Ydelser kan eksempelvis benytte sags- og opgavefordelingsaktiviteten, da det vil give fin mening at modtage Opgaver vedrørende fx flyttebeskeder fra CPR. Men det er ikke tænkt, at alle relevante beskeder på Andre Ydelser vil være en del af Løsningen. På samme måde vil der i udgangspunktet ikke være brevskabeloner specifikt til Andre Ydelser, men de brevskabeloner, der er lavet til de andre Ydelsesarter, kan benyttes, hvor det er relevant. Andre Ydelser forventes således ikke at være fuldt understøttet på samme måde som forsørgelsesydelser- og enkeltydelser. Se desuden afsnit 5.5.3 for krav til specifikke visninger i forbindelse med behandling af en ydelsessag. 5.2.1 Oplys sag Formålet med at oplyse sagen er - på baggrund af en ansøgning eller nye oplysninger til en eksisterende sag - at indsamle og vurdere informationer, så der kan træffes en afgørelse. Selve afgørelsen træffes ikke under oplysningen af sagen, men i praksis vil Sagsbehandleren undervejs i sagsoplysningen typisk få en idé om udfaldsrummet og kan derfor løbende målrette sagsoplysningen. Typisk indsamles informationerne med henblik på at 1) afgøre hvorvidt Personen har ret til den ansøgte Ydelse og forudsat at Personen har ret til den ansøgte Ydelse 2) at fastsætte Ydelsen og beregne det beløb, som skal udbetales, jf. afsnit 5.2.2. Når sagen er fuldt oplyst, er der indsamlet tilstrækkelige informationer til at kunne træffe en afgørelse. I tilfælde af at denne afgørelse indebærer en bevilling, er der ligeledes indsamlet tilstrækkelige oplysninger til at kunne fastlægge og beregne Ydelsen. Følgende Opgaver vil typisk finde sted under oplysning af sagen: - Indberetning af oplysninger, som sagsbehandleren tilvejebringer fra Personen eller tredjepart. - Vurdering af oplysninger fra ansøgning eller henvendelse fra Personen eller tredjepart, herunder beregning af rådighedsbeløb og formue i sager vedr. enkeltydelser. - Vurdering af oplysninger, som Løsningen indhenter fra eksterne systemer. - Sammenholde indberettede og indhentede oplysninger, fx fra eksterne systemer. - Vurdering af om oplysningsgrundlaget er fyldestgørende til at kunne træffe en informeret afgørelse og efterfølgende at kunne fastsætte Ydelse og beregne et beløb til udbetaling. - Indhentelse af supplerende oplysninger, fx ved manglende oplysninger. Side 46 af 257
- Vurdering af behovet for og eventuel gennemførelse af partshøring, eksempelvis ved modstrid mellem indhentede og indberettede indkomstoplysninger. Herudover kan der være en række specifikke Opgaver ved enkelte Ydelsesarter, jf. bl.a. afsnit 5.2.1.2-5.3.1. I Løsningen skelnes mellem de indhentede oplysninger (fra eksterne systemer og registre) og indberettede oplysninger (fra Personen). I nogle tilfælde vil samme oplysning både indhentes og indberettes. Fx skal Personen oplyse eventuelle indtægter og sende dokumentation herfor. Samtidig indhenter Løsningen via e-indkomst Personens eventuelle indtægter. Løsningen skal således håndtere flere sæt af samme data (se eventuelt relationerne Indberettet af Ansøger og Indhentet af kommunen i informationsmodellen (KY-Uddannelseshjælp eller kontanthjælp) i underbilag 2.5). Som oftest vil sager ikke kunne oplyses tilstrækkeligt i én arbejdsgang. Der vil ofte være behov for at parkere sagen, fx fordi der mangler oplysninger 3. Det at foretage Oplysning af sagen er som oftest den mest komplekse og tidskrævende Opgave for sagsbehandleren, når denne behandler en ydelsessag. Når der kommer nye oplysninger i en given sag, skal disse opdateres på sagen. Hvis det er oplysninger sagsbehandleren selv indtaster manuelt, vil det ske i forbindelse med genoplysningen af sagen. Kravene til (gen)oplysning af sag er beskrevet i afsnit 5.2.1. Andre gange vil opdatering af sagsoplysninger kunne ske automatisk i forbindelse med vedligeholdelse af sagen. Når Løsningen modtager oplysninger digitalt, skal oplysningerne så vidt muligt overføres til sagen, så sagsbehandleren ikke behøver indtaste oplysningerne manuelt. Bemærk, at sager vedrørende uddannelseshjælp eller kontanthjælp altid inkluderer en eventuel Ægtefælle og dennes oplysninger vedrørende indtægter, økonomi mv. Tilsvarende gælder i enkeltydelsessager for ægtepar. I disse sager tilknyttes Personen, der ansøger, som den primære part, og en eventuel Ægtefælle som sekundær part. Dette betyder, at Ægtefællen til en Person, som ansøger om uddannelseshjælp eller kontanthjælp, altid vil indgå i oplysning af sagen. Krav# 26: Indhent oplysninger i eksterne registre Beskrivelse: Inden en nyoprettet sag oplyses første gang, indhenter Løsningen automatisk de mulige relevante oplysninger fra eksterne systemer for den givne Ydelsesart. a) Løsningen indhenter automatisk nedenstående oplysninger fra eksterne systemer inden sagen oplyses første gang: A. Er Personen tilmeldt via jobcentret via jobcenterintegrationen. B. Persondata via CPR, herunder oplysninger om Ægtefælle og børn. C. Oplysninger om indtægt via E-indkomst. D. Oplysninger om ejerskab af virksomhed via SKAT R75. E. Oplysninger om formue mv. via SKAT R75. F. Oplysninger om skattekort via SKAT eskattekort. G. Oplysninger om, hvorvidt Personen har fået udbetalt feriepenge og i så fald hvornår, via Feriekonto. H. Oplysninger om opholdsgrundlag via UdlændingeInformationsSystemet. Oplysning om hvorvidt Personens Ægtefælle eller modtager SU via E- 3 Det er forhåbningen, at selvbetjeningsløsningen (jf. afsnit 5.8) vil mindske behovet for at indhente supplerende oplysninger, men der vil stadig være behov for at indhente supplerende oplysninger Side 47 af 257
indkomst. Oplysning om Personen modtager ekstra børnetilskud eller oplysning om, at Personen ikke modtager ekstra børnetilskud via YdelsesindeksOplysning om boligstøttebeløb for 34 sager om særlig støttes via Ydelsesindekset. Løsningen kan ved løbende vedligeholdelse af sagen automatisk slå op i ovenstående registre og opdatere oplysninger på sagen. - Se kapitel 6.4 for nærmere oplysninger om, hvilke systemer der integreres til. - Oplysninger, der skal hentes, er beskrevet i de respektive informationsmodeller og følgende er eksempler på, hvilke data, der skal hentes og hvor de kommer fra, men er ikke fyldestgørende for hele løsningen: o Se informationsmodellen (KY-kontaktforløb) i underbilag 2.5, ift. punkt A. o Se informationsmodellen (KY-Person) i underbilag 2.5, ift. punkt B. o Se informationsmodellen (Beslutningsgrundlag, Beregningsgrundlag) i underbilag 2.5, ift. punkt C. o Se informationsmodellen (KY-Person) i underbilag 2.5, ift. punkt D. o Se informationsmodellen (Beslutningsgrundlag, Beregningsgrundlag) i underbilag 2.5, ift. punkt E. o Se informationsmodellen (Beslutningsgrundlag, Beregningsgrundlag) i underbilag 2.5, ift. punkt F. o Se informationsmodellen (Beslutningsgrundlag, Beregningsgrundlag) i underbilag 2.5, ift. punkt G. o Se informationsmodellen (KY-Person) i underbilag 2.5, ift. punkt H. o Se informationsmodellen (KY-Uddannelseshjælp eller kontanthjælp) i o underbilag 2.5, ift. punkt I. Se informationsmodellen (Beslutningsgrundlag, Beregningsgrundlag) i underbilag 2.5, ift. punkt J. - Se afsnit 5.2.5 vedrørende Vedligeholdelse af sag. - I forhold til punkt b) så kan vedligeholdelse af sag fx ske ud fra interne regler eller når der modtages Beskeder fra eksterne systemer. Se underbilag 2.13 vedrørende Hændelser og Beskeder. - Se underbilag 2.28, som er udarbejdet som inspiration til Tilbudsgiver, om filtrering af R75 oplysninger i forhold til punkt E. Krav# 27:Manuelle opslag i eksterne registre Beskrivelse: Brugeren skal i løsningen på ethvert tidspunkt kunne foretage nye opslag i de eksterne registre. a) Brugeren kan på et hvert tidspunkt foretage opslag i de eksterne registre, der er beskrevet i Krav# 26 og herigennem indhente de til hver en tid aktuelle informationer. b) Løsningen opdaterer relevante sagsoplysninger. c) I de tilfælde hvor der allerede er registreret manuelt registrerede oplysninger i Løsningen, skal de nye data være gældende. Brugeren gøres opmærksom på, at der er uoverensstemmelser. - Manuelle genopslag kunne fx være relevante ved genoplysning af en sag på et tidspunkt efter den første afgørelse er truffet. - I forhold til punkt b, så kan det fx forekomme at en Person får nyt CPR-nummer. Løsningen skal kunne understøtte udskiftning af det eksisterende CPRnummer med et nyt CPR-nummer. Side 48 af 257
- I forhold til punkt c, så kan dette være relevant, hvis fx der er indtastet en alternativ adresse. Hvis der så kommer en adresseopdatering fra CPR, skal den nye adresse benyttes, men sagsbehandleren skal gøres opmærksom på, at der er kommet en ny adresse (så de eventuelt har mulighed for at skrive den alternative adresse ind igen). Krav# 28: Hent oplysning om samlevende Kravet udgår Krav# 29: Indberetning af oplysninger Beskrivelse: Det skal være muligt for Brugeren at angive manglende oplysninger samt opdatere allerede eksisterende oplysninger (både de indberettede og indhentede). a) Brugeren kan tilføje eventuelle manglende oplysninger. b) Brugeren kan opdatere allerede eksisterende oplysninger. c) Brugeren kan angive dato for, hvornår informationen er gældende fra og til. Perioden kan være helt eller delvist tilbage i tid. d) Oplysninger vedrørende Ægtefæller jf. Krav# 30 indgår ligeledes i dette krav. - Det kan fx dreje sig om oplysninger fra en ansøgning (i det tilfælde at kommunen har modtaget ansøgningen på papir). Det kan også være oplysninger Brugeren selv har indhentet, eksempelvis persondata, valg af skattekort (hovedkort/bikort/frikort), information om indtægter, informationer om formue mv. - Se informationsmodellen (KY-sag, KY-dokument, Beslutningsgrundlag, Beregningsgrundlag, Oplys sag) i underbilag 2.5 for hvilke informationer, der indgår i oplysningen af en sag. Vær herunder opmærksom på. at Ydelsesarterne ikke alle benytter samme informationer (jf. eventuelt underbilag 2.7). Krav# 30: Oplysning af Ægtefælles forhold Beskrivelse: Det skal på sager vedrørende visse Ydelsesarter være muligt for Brugeren at indberette de samme oplysninger for henholdsvis Personen og en eventuel Ægtefælle. Tilsvarende indhentes samme oplysninger automatisk for henholdsvis Personen og for Ægtefællen. a) I sager vedr. uddannelseshjælp eller kontanthjælp indhentes samme oplysninger som beskrevet i Krav# 26 automatisk også for Personens eventuelle Ægtefælle. b) I sager vedr. enkeltydelser indhentes samme oplysninger som beskrevet i Krav# 26 automatisk også for Personens eventuelle Ægtefælle. Side 49 af 257
c) I sager vedr. uddannelseshjælp eller kontanthjælp skal det være muligt for Brugeren at indhente oplysningerne for Ægtefælle manuelt som beskrevet i Krav# 27. d) I sager vedr. enkeltydelser skal det være muligt for Brugeren at indhente oplysninger for Ægtefælle manuelt som beskrevet i Krav# 27. - I underbilag 2.7 gives eksempler på, hvordan oplysningerne for Person og Ægtefælle anvendes ved beregning af beløb til udbetaling i sager om uddannelseshjælp eller kontanthjælp. - Se Krav# 161 vedrørende visning og overblik over Ægtefælle oplysninger. - Se informationsmodellen (KY-sag) i underbilag 2.5. Nogle oplysninger skal Personen selv indberette, men Løsningen indhenter de samme oplysninger via eksterne systemer (fx lønindkomst). Derved kan der opstå situationer, hvor Personen har indberettet noget andet end det indhentede. I disse tilfælde skal det være muligt for sagsbehandleren at vælge, hvilke der er de korrekte. Krav# 31: Valg af gældende oplysninger ved uoverensstemmelser Beskrivelse: Ved uoverensstemmelse mellem de indberettede og indhentede oplysninger skal Brugeren kunne markere hvilken oplysning, der er den gældende. a) Den markerede oplysning anvendes efterfølgende i sagsbehandlingen og beregninger, indtil der evt. indhentes en nyere version. b) Den fravalgte oplysning skal fortsat være registreret i sagens oplysninger. - Med uoverensstemmelse mellem gældende oplysninger menes, at Løsningen skal fange uoverensstemmelser mellem to "versioner" af samme oplysning (samme felt) fra forskellige kilder. Fx indtægt indberettet af Personen, og indtægt indhentet via E-indkomst. Kunden forventer således ikke, at der skal opdages uoverensstemmelser på tværs af forskellige slags oplysninger. - Se Krav# 26 - Krav# 30 om indberettede og indhentede oplysninger. - Se Krav# 163 for visuel markering af uoverensstemmelser - Se underbilag 2.10 Eksempler på skærmbilleder afsnit 2.5 for eksempel på, hvordan kunden kunne forestille sig en løsning. Sagsbehandleren kan tilgå SAPA for at danne sig overblik over borgerens sager i kommunen eller grundoplysninger om borgeren, som ikke fremgår af Løsningen. Sagsbehandlere i andre forvaltninger eller borgerservice kan fra SAPA tilgå en borgers sag i Løsningen. Krav# 32: Hop til SAPA Beskrivelse: Løsningen skal tilbyde Sagsbehandleren at hoppe til SAPAs visning af oplysninger om Personen. - Se afsnit 6.3.2.1 for anvenderkrav til dialogintegration også kaldet hop. Side 50 af 257
Krav# 33: Hop til Løsningen Beskrivelse: Løsningen skal give Brugere af andre it-systemer mulighed for at hoppe til en sag eller et dokument i Løsningen. - Eksempler på andre it-systemer kunne være SAPA. - Det er kun muligt at hoppe til Løsningen, hvis den givne Bruger som minimum har læserettigheder i Løsningen. - Se afsnit 6.3.2.1 for anvenderkrav til dialogintegration også kaldet hop. I nogle tilfælde kan der være behov for, at Sagsbehandleren kan indtaste en alternativ adresse, som er en anden adresse end den, Personen er registreret med i CPR. Det kan fx være i forbindelse med, at Personen benytter en partsrepræsentant, altså en person, der repræsenterer Personen og modtager dennes breve. Det kan også være, fordi Personen først dagen før meldte flytning, så den ikke er slået igennem i CPR endnu. Denne alternative adresse skal Løsningen benytte, når der skal afsendes breve. Krav# 34: Benyttelse af alternativ adresse Beskrivelse: Det skal være muligt for Brugeren at indtaste en alternativ adresse som fremover vil benyttes af Løsningen i stedet for den indhentede adresse fra CPR. - Den alternative adresse benyttes i forbindelse med indfletning af adresse ved udsendelse af breve. - Se Krav# 129 om udsendelse af breve. Som udgangspunkt vil sagsbehandleren altid benytte data, der er indhentet fra eksterne systemer. Men fejl eller mangler i data fra eksterne registre må ikke forhindre, at sagsbehandleren manuelt kan behandle sagen. Et eksempel kan være, at Løsningen skal kunne håndtere Personer, der ikke har noget hjem (og derfor ikke står opført i folkeregistret med bopæl i kommunen). I sådanne tilfælde vil sagsbehandleren fx ringe til Personen for afklaring af, hvor denne har sovet. Det nedskrives i et journalnotat, at Personen har oplyst, at han opholder sig i kommunen, og sagsbehandleren kan derefter behandle sagen. Det skal således altid være muligt for sagsbehandleren at behandle sagen manuelt. Krav# 35: Håndtering af Særtilfælde/ fejl i data fra eksterne registre Beskrivelse: Fejl eller mangler i data fra eksterne registre må ikke forhindre, at Brugeren manuelt kan behandle sagen. a) Manglende forbindelse til eksternt register må ikke forhindre Brugeren i at behandle en sag. b) Fejl i data indhentet fra eksternt register må ikke forhindre Brugeren i at behandle en sag. c) Manglende data fra eksternt register må ikke forhindre Brugeren i at behandle en sag. - Dette krav går på, at der ikke må være valideringer i forhold til manglende/fejlagtige data fra eksterne systemer, der må forhindre Brugeren i at behandle sagen. Side 51 af 257
5.2.1.1 Indhent supplerende oplysninger / partshøring Under oplysning af en sag vil der opstå tilfælde, hvor sagsbehandleren har behov for at kontakte Personen eller tredjepart for at få yderligere oplysninger eller valideret de eksisterende. Det sker enten ved indhentning af supplerende oplysninger eller ved partshøring. Indhentning af supplerende oplysninger er relevant, hvis sagsbehandleren mangler oplysninger for at være i stand til at vurdere sagen. Personen oplyses om hvilke oplysninger, der mangler samt om den frist, der gælder for at afgive oplysningerne. Hvis det er relevant, anmodes tredjepart (fx tidligere arbejdsgiver, pengeinstitut eller pensionskasse) om oplysninger. Formålet med partshøring er at vurdere, om der er indhentet oplysninger, som Personen ikke ved, vil indgå i afgørelsen, og som kan være til ugunst for Personen. Er det tilfældet, skal der ske partshøring. Bemærk at partshøring, såfremt det er hensigtsmæssigt, kan foretages samtidig med, at der indhentes supplerende oplysninger fra Personen. Funktionaliteten til indhentning af supplerende oplysninger og partshøring medfører ingen specifikke krav. Der benyttes generel tværgående funktionalitet beskrevet andre steder. Fx benytter sagsbehandleren brevfunktionaliteten beskrevet i afsnit 5.4.3 til at udforme brevet. Benytter journalnotats-funktionaliteten beskrevet i afsnit 5.4.2 og funktionaliteten til statusændringer beskrevet i afsnit 5.4.4. Partshøring kan foretages af sagsbehandleren, eller initieres af Løsningen på baggrund af en Hændelse som beskrevet i underbilag 2.13 Hændelsesliste. Der er derfor ingen krav i dette underafsnit, men afsnittet er bibeholdt for at gøre opmærksom på denne vigtige aktivitet, sagsbehandleren udfører i forbindelse med oplysningen af sagen. 5.2.1.2 Beregn rådighedsbeløb og formue Ved behandlingen af sager vedrørende enkeltydelser og ved udbetaling af visse Andre Ydelser er der under oplysning af sagen behov for at lave en rådighedsberegning. Formålet er at beregne Personens og eventuel Ægtefælles rådighedsbeløb med henblik på at vurdere, om Personen selv kan betale udgiften, der søges dækket. Rådighedsbeløbet vil indgå i den konkrete vurdering af, hvorvidt Personen får bevilget Ydelsen eller ej. Rådighedsbeløbet er forskellen mellem indtægter og rimelige og nødvendige udgifter. Hvilke, der er rimelige og nødvendige, er en konkret vurdering fra sag til sag. For sagsbehandleren ligger opgaven i at indsamle dokumentation for indtægter og udgifter for efterfølgende at vurdere hvilke udgifter, der er rimelige og hvilke der ikke kan medtages i rådighedsberegningen. Ved behandling af sager vedr. enkeltydelser og udbetaling af visse Andre Ydelser kan der endvidere være behov for at kunne opgøre Personens formue. Krav# 36: Beregn rådighedsbeløb Beskrivelse: En Bruger skal i løsningen kunne foretage en beregning af rådighedsbeløb ud fra oplysninger, som Brugeren indberetter og gemmer på sagen. a) Rådighedsbeløbet for en Person er beregnet ved at trække summen af godkendte udgifter fra summen af godkendte indtægter. b) Brugeren kan angive en bemærkning til hvert beløb. Side 52 af 257
c) Brugeren kan godkende om hvert beløb anvendes i beregningen. d) Beregningen kan foretages for begge Ægtefæller i en sag. - Rådighedsberegningen indgår i oplysning af sager vedr. fx enkeltydelser og udbetaling af visse Andre Ydelser, for Personen og dennes eventuelle Ægtefælle. - Se eventuelt Krav# 37 vedr. de oplysninger, der kan indgå i en beregning af rådighedsbeløb. Krav# 37: Oplysninger ved beregning af rådighedsbeløb Beskrivelse: Der er i Løsningen konfigureret en række relevante typer af udgifter samt relevante indtægter, der skal vises, når Brugeren påbegynder beregning af rådighedsbeløb og skal kunne rettes af Brugeren. a) Løsningen viser de typer, som den Kommunale administrator har konfigureret skal vises som standard. b) Løsningen giver Brugeren mulighed for at kunne indberette indtægter/udgifter i den specifikke sag for de typer, der vises som standard. c) Løsningen giver Brugeren mulighed for at kunne registrere yderligere indtægter/udgifter i den specifikke sag. d) Løsningen skal sikre, at der ikke kan indberettes en udgift, som overstiger det maksimumbeløb, der er konfigureret af den kommunale administrator. Hvis maksimumbeløbet er 0 (nul) kr., skal der ikke valideres for dette. - Eksempler på udgifter, der vises som standard, omfatter: husleje, el, telefon (maks. 100 kr.), løn, pension. - Se eventuelt informationsmodellen (KY-Enkeltydelse, Beslutningsgrundlag) i underbilag 2.5. - Se Krav# 199 vedrørende kommunal konfigurering. Krav# 38: Beregn formue Beskrivelse: En Bruger skal i Løsningen kunne foretage en beregning af formue ud fra oplysninger, som Brugeren indberetter og gemmer på sagen. a) Formuebeløbet for en Person er beregnet ved at summere godkendte formueposter. b) Brugeren kan angive en bemærkning til hvert beløb. c) Brugeren kan godkende om hvert beløb anvendes i beregningen. d) Beregningen kan foretages for begge Ægtefæller i en sag. - Formueberegningen indgår i oplysning af sager vedr. fx uddannelseshjælp eller kontanthjælp, enkeltydelser og udbetaling af Andre Ydelser. Den skal kunne foretages for Personen og dennes eventuelle Ægtefælle. Side 53 af 257
- Se Krav# 39 vedr. de oplysninger, der kan indgå i en beregning. Krav# 39: Oplysninger i formueopgørelse Beskrivelse: Der er i Løsningen foruddefineret en række relevante formueposter, der vises, når Brugeren påbegynder beregning af formue og som skal kunne rettes af Brugeren. a) Løsningen viser de beløbstyper, som den kommunale administrator har konfigureret og skal vises som standard. b) Løsningen giver Brugeren mulighed for at kunne registrere yderligere formueposter i den specifikke sag. - Eksempler på formueposter, der vises som standard, inkluderer: likvid formue, fast ejendom, bil. - Se informationsmodellen (Beslutningsgrundlag) i underbilag 2.5. - Se Krav# 200 vedrørende kommunal konfigurering. Mange kommuner indgår aftaler med eksempelvis optikere og behandlere om faste priser på en række varer og tjenester, som kommunen indkøber i sager vedrørende Andre Ydelser, eksempelvis udvidet helbredstillæg og personlige tillæg. Krav# 40: Adgang til kommunens prisaftaler Beskrivelse: En Bruger skal i løsningen have let adgang til kommunens eventuelle prisaftaler i forbindelse med fastsættelse af Ydelsen. a) Brugeren kan ved maks. to klik/tastetryk tilgå kommunens prisaftaler, hvis Brugeren har påbegyndt behandlingen af en sag om enkeltydelser eller Andre Ydelser. b) Løsningen skal sikre, at Brugeren kan fortsætte sagsbehandlingen, efter at have tilgået kommunens prisaftaler. c) Løsningen skal anvende henvisningen, som er konfigureret af den kommunale administrator, til at give en Bruger adgang til prisaftalen. - Behovet kan opstå eksempelvis i en sag vedrørende udvidet helbredstillæg. - Adgang til prisaftale kan ske ved, at Løsningen indeholder et link til et dokument med prisaftalen. - Se Krav# 203 vedrørende kommunal konfigurering af adgang til prisaftale. 5.2.1.3 Afsnittet udgår Krav# 41: Kravet udgår Kategori: Beskrivelse: Type: Side 54 af 257
Krav# 42: Kravet udgår Kategori: Beskrivelse: Type: 5.2.2 Fastsæt ydelsessats og beregn Ydelse Når en sag er oplyst tilstrækkeligt, kan det beløb, som skal udbetales, beregnes, såfremt det er vurderet, at Personen, der ansøger, har ret til den ansøgte Ydelse. Som det første fastsættes Ydelsessatsen, der er udgangspunktet for at beregne det beløb, som udbetales til Personen. Løsningen fastsætter Ydelsessatsen og beregner det beløb, som skal udbetales til Personen ud fra de oplysninger, som er registreret i Løsningen under oplysningen af sagen. Disse oplysninger kan være indberettet af sagsbehandleren eller indhentet fra eksterne systemer. Hvis der er tale om genoplysning af en eksisterende sag på et tidspunkt efter, at den første afgørelse i sagen er truffet, fx pga. nye oplysninger i sagen, kan der endvidere være registreret oplysninger i Løsningen på et tidligere tidspunkt, som også indgår. Faglovgivningen fastlægger for hver Ydelsesart det regelsæt, som bestemmer, hvilke betingelser en Person skal opfylde for at være berettiget til Ydelsen og fastsætter hvordan beregningen af det beløb, som Personen skal have udbetalt, skal foretages. I forbindelse med sager om uddannelseshjælp eller kontanthjælp skal Løsningen også kunne fastsætte Ydelsessatsen og beregne det beløb, som skal udbetales til en Ægtefælle. De primære kilder er Lov om aktiv socialpolitik (LAS) og Lov om en aktiv beskæftigelsespolitik (LAB). Se underbilag 2.8 for en oversigt over relevant faglovgivning. Reglerne, herunder hvad der skal til for at oplyse sagen tilstrækkeligt, varierer fra Ydelsesart til Ydelsesart. Eksempelvis inkluderer oplysning af en sag om uddannelseshjælp eller kontanthjælp også en eventuel Ægtefælle økonomiske situation, ligesom i enkeltydelsessager. For de øvrige Ydelser indgår Ægtefælle ikke. I sager om uddannelseshjælp eller kontanthjælp skal sagsbehandleren endvidere konkret vurdere behovet for engangshjælp og indberette et beløb, såfremt det bevilges. Følgende Ydelsesarter behandles i dette afsnit: Uddannelseshjælp eller kontanthjælp, herunder særlig støtte (LAS kapitel 4) Revalideringsydelse (LAS kapitel 6) Ledighedsydelse (LAS kapitel 7) Ressourceforløbsydelse (LAS kapitel 6 a) Fleksløntilskud (LAB kapitel 13) Enkeltydelse (LAS kapitel 10 eller INL kapitel 6) Side 55 af 257
Anden Ydelse, eksempelvis helbredstillæg og personligt tillæg til pensionister (Lov om social pension og Lov om højeste, mellemste, forhøjet almindelig og almindelig førtidspension m.v.). 5.2.2.1 Igangsætning af beregning af beløb til udbetaling Der vil være behov for at kunne beregne beløb til udbetaling, herunder at fastsætte Ydelsessats, på forskellige tidspunkter i sagsbehandlingen i henhold til sagens effektueringsplaner (se afsnit 5.2.3.2 om fastlæggelse af effektueringsplan). Det kan forekomme: under oplysning af sagen, både ved første ansøgning og efterfølgende, fx i forbindelse med nye oplysninger i sagen i forbindelse med, at der træffes afgørelse om bevilling ved effektuering og bestilling af udbetaling, fx ved de månedlige udbetalinger af forsørgelsesydelser. Når løsningen foretager beregning i en sag, gemmes resultatet af beregningen i sagens oplysninger om bevilget Ydelse og effektueringsplan med tilhørende oplysninger. Disse oplysninger er i en kladdetilstand, indtil der træffes afgørelse om bevilling og effektueringsplanen færdiggøres. Herefter udgør disse oplysninger grundlag for effektuering og bestilling af udbetaling. Der beregnes og effektueres som hovedregel for én udbetalingsperiode af gangen. En udbetalingsperiode er typisk en kalendermåned, men kan i visse tilfælde, fx ved 25 års fødselsdag i forbindelse med en sag om kontanthjælp, opdeles i delperioder, der beregnes separat. Udbetalingsperioden kan for en specifik sag være kortere fx pga., at Personen kommer i arbejde midt i måneden. Der vil efterfølgende blive igangsat beregninger automatisk, når der effektueres og bestilles udbetalinger, eksempelvis ved månedlig udbetaling af forsørgelsesydelser. Se eventuelt afsnit 5.2.4 om effektuering. Der vil derfor være behov for, at Brugeren kan igangsætte beregninger i en given sag, fx pga. af ændringer i sagens oplysninger. Der kan også være behov for at foretage en beregning for en periode, som ligger tilbage i tid, eksempelvis hvis der kommer en afgørelse i en klagesag, som betyder, at der oprettes en sag med start tilbage i tid eller ændres på sagens oplysninger med tilbagevirkende kraft. Nedenstående krav beskriver to forskellige måder, hvorpå beregning af beløb til udbetaling kan igangsættes. Krav# 43: Automatisk beregning af Ydelse ved udbetaling Beskrivelse: Løsningen skal til brug for udbetaling automatisk fastsætte Ydelsessats og beregne alle nødvendige beløb til brug for udbetaling på fastsatte tidspunkter for alle sager. a) Fastsættelse af Ydelsessatser og alle beregninger i alle sager skal foretages rettidigt i forhold til effektueringsplanen og de regler, som er fastsat vedrørende automatisk effektuering og udbetaling, således at udbetaling kan foretages i henhold til Lovgivningen. b) Hvis der på effektueringsplanen i en sag er angivet særskilt, at denne ikke skal indgå i den automatiske behandling, skal den udelades. Side 56 af 257
c) Hvis der på effektueringsplanen i en sag er angivet særskilt, at denne skal behandles på et specifikt tidspunkt, skal behandlingen foretages på dette tidspunkt. - Se Krav# 46 vedrørende fastsættelse af Ydelsessats. - Se Krav# 47 - Krav# 54 vedrørende beregning af beløb til udbetaling. - Se Krav# 198 vedrørende fastsatte tidspunkter for udbetaling. - Se Krav# 63, Krav# 64 og Krav# 107 vedrørende særskilte oplysninger i effektueringsplaner. - Se underbilag 2.8 vedrørende relevant faglovgivning. Krav# 44: Manuel igangsætning af beregning af Ydelse Beskrivelse: Det skal være muligt for en Bruger at igangsætte fastsættelse af Ydelsessats og beregning af beløb til udbetaling på en specifik sag for en af Brugeren valgt periode. Beregningens resultat skal gemmes på sagen, men skal ikke automatisk medføre, at der sker effektuering og bestilles udbetaling. Der skal dog være direkte adgang for Brugeren til at foretage effektuering og bestille en udbetaling ud fra resultatet af beregningen. a) Løsningen skal sikre, at fastsættelse af Ydelsessats og beregning af beløb til udbetaling foretages i henhold til Lovgivningen ud fra de oplysninger, som er registreret i sagen. b) Brugeren skal umiddelbart kunne se resultatet af beregningen. Hvis perioden er helt eller delvist tilbage i tid, fremgår konsekvenser af eventuelt ajourførte oplysninger. c) Brugeren skal kunne vælge at effektuere resultaterne og bestille udbetaling. d) Brugeren skal kunne vælge en periode, som beregningen foretages for, inden for indeværende og forrige kalenderår. e) Perioden kan ikke gå længere tilbage end sagens startdato. f) Perioden kan ikke gå længere tilbage end til ibrugtagningstidspunktet. g) Perioden kan ikke gå længere frem end indeværende udbetalingsperiode. h) Løsningen skal ud fra oplysninger, som er gemt på sagen, beregne Ydelsen for hver af de udbetalingsperioder, der ligger inden for den valgte periode. i) Beregningen skal for hver udbetalingsperiode anvende oplysninger og regler, som har gyldighed på det konkrete tidspunkt. - Behovet kan opstå i forbindelse med eksempelvis oplysning af sagen eller ændringer i sagens oplysninger, der påvirker beregninger for indeværende eller tidligere udbetalingsperioder. Side 57 af 257
- Se Krav# 46 vedrørende fastsættelse af Ydelsessats. - Se Krav# 47 - Krav# 54 vedrørende beregning af beløb til udbetaling. - Se Krav# 70 vedrørende manuel effektuering. - Se underbilag 2.8 vedrørende relevant faglovgivning. Krav# 45: Beregning skal benytte nyeste oplysninger Beskrivelse: Løsningen skal ved alle beregninger benytte de oplysninger i sagen, som er gældende, har gyldighed i udbetalingsperioden og er registreret senest. Dette gælder både oplysninger, som indeholder én værdi og oplysninger, som indeholder værdier for flere perioder inden for udbetalingsperioden. a) Hvis Brugeren ved uoverensstemmelse mellem indhentede og indberettede oplysninger, har markeret en af disse oplysninger som gældende, skal denne anvendes, indtil der er indhentet eller indberettet en nyere version af oplysningen. b) Hvis der kun er registreret én version af en specifik oplysning, der er gyldig i udbetalingsperioden, skal denne anvendes. c) Hvis der er registreret flere versioner af samme oplysning, der er gyldig i udbetalingsperioden, skal den, der er registreret senest, anvendes. - Mange af de sager, som håndteres ved brug af Løsningen, er aktive over længere perioder, eventuelt i adskillige år. I løbet af sagens levetid vil oplysninger, som ligger til grund for beregninger og udbetalinger, typisk ændres over tid. - Eksempelvis kan der på en sag registreres et beløb vedrørende Personens indtægter i udbetalingsperioden den 20. i måneden, som bliver ændret til et nyt beløb den 23. i måneden. Når beregning af beløb til udbetaling foretages, fx den 27. i måneden, skal det senest registrerede beløb anvendes. - Se Krav# 31 om valg af gældende oplysninger ved uoverensstemmelse. - Se Krav# 47 vedrørende beregning af beløb til udbetaling. - Se afsnit 6.2.4.1 vedrørende bitemporalitet. - Se informationsmodellen (Generelle egenskaber i KY-sag) i underbilag 2.5 vedrørende historikegenskaber. 5.2.2.2 Krav vedrørende beregning af beløb til udbetaling Generelt set indgår følgende elementer i beregningen af det beløb, som Personen skal have udbetalt: Fastsættelse af den Ydelsessats, som Personen er berettiget til (se Krav# 46). Til hver Ydelsessats svarer et beløb, som er udgangspunktet for beregning af det beløb, som skal udbetales til Personen. Beregning af det beløb, som Personen og eventuelt dennes Ægtefælle, skal have udbetalt (se Krav# 47). Denne beregning skal - afhængig af Ydelsesart og oplysningerne i den konkrete sag - tage højde for eventuelle tillæg og fradrag. Dette inkluderer en række elementer, herunder: o Beregning af indkomstgrundlag (se Krav# 48). Side 58 af 257
o Beregning af konsekvenser af sanktioner (se Krav# 49). o Beregning og indeholdelse af ATP (se Krav# 50). o Beregning og indeholdelse af A-skat (se Krav# 51). o Fradrag for forskudsvis udlagt børnebidrag (se Krav# 52). o Beregning af skattemæssige konsekvenser af boligrenter i forbindelse med særlig støtte (se Krav# 53). o Manuelt indberettede tillæg/fradrag (se Krav# 54). Reglerne for, hvordan Ydelsessatsen fastsættes og det korrekte beløb til udbetaling beregnes for de forskellige Ydelsesarter, fastlægges af den til enhver tid gældende Lovgivning (se underbilag 2.8 Lovgivning). Eksempelvis fastsættes beløbet til udbetaling for uddannelseshjælp eller kontanthjælp ud fra oplysninger om Personens indtægter og eventuel Ægtefælles indtægter (herunder eventuelle offentlige forsørgelsesydelser) mv. I underbilag 2.7 (Beregninger og regler) gives eksempler på, hvordan reglerne kan udmøntes, herunder hvilke oplysninger i sagen, som er nødvendige. Disse beskrivelser skal ses som et supplement til nedenstående krav. Krav# 46: Fastsæt Ydelsessats Beskrivelse: Løsningen skal fastsætte den Ydelsessats, som en Person er berettiget til ud fra oplysninger, som er registreret i Løsningen under oplysning af sagen. a) Ydelsessatsen skal fastsættes i henhold til Lovgivningen og sagens oplysninger. b) Hvis det fremgår af Lovgivningen, at der skal være fastsat Ydelsessats for Ægtefælle, skal dette også foretages. - Lovgivningen, som Løsningen skal håndtere, varierer fra Ydelse til Ydelse. Eksempelvis indgår både Personen, der ansøger, og dennes Ægtefælle i sager vedrørende uddannelseshjælp eller kontanthjælp. - Se informationsmodellen (Ydelseskatalog, Beregningsgrundlag) i underbilag 2.5. - Se underbilag 2.7 for eksempler på forskelle inden for Lovgivningen på området. - Se underbilag 2.8 vedrørende relevant faglovgivning. Krav# 47: Beregn beløb til udbetaling Beskrivelse: Løsningen skal beregne beløb, som skal udbetales i henhold til Lovgivningen. a) Resultatet af beregningen af beløb til udbetaling er sket i henhold til Lovgivningen, herunder gældende satser og grænsebeløb. b) Beregningen skal foretages med udgangspunkt i den fastsatte Ydelsessats, udbetalingsperiodens længde og alle relevante oplysninger i sagen. Side 59 af 257
c) Beregningen skal inkludere alle registrerede oplysninger, der påvirker størrelsen af det beløb, som udbetales. d) Hvis det fremgår af Lovgivningen, at der skal beregnes beløb til udbetaling for en eventuel Ægtefælle, skal Løsningen også foretage denne beregning i henhold til Lovgivningen. e) Hvis det fremgår af Lovgivningen, at en eventuel Ægtefælles indtægter mv. skal indgå i beregningerne af beløb til udbetaling, skal Løsningen også inddrage dette i beregningerne. - Resultatet af beregningen afhænger af Lovgivningen og de oplysninger, der er registreret i sagen. Eksempler på oplysninger, der påvirker beløb til udbetaling, er sanktioner, indtægter, Ægtefælles indtægter (ved uddannelseshjælp eller kontanthjælp), fradrag for forskudsvis udlagt børnebidrag, individuelle tillæg/fradrag, ATP, skat og boligstøtte. - Se informationsmodellen (KY-effektuering, Ydelseskatalog, Beslutningsgrundlag, Beregningsgrundlag) i underbilag 2.5. - Se Krav# 46 vedrørende fastsættelse af Ydelsessats. - Se Krav# 320 om anvendelse af Ydelsesindekset. - Se underbilag 2.7 for eksempler på forskelle inden for Lovgivningen på området. - Se underbilag 2.8 vedrørende relevant faglovgivning. De efterfølgende krav i dette afsnit er elementer, der indgår i beregningen af beløb til udbetaling. Krav# 48: Beregning af indkomstgrundlag Beskrivelse: Løsningen skal beregne indkomstgrundlaget til brug for beregning af beløb til udbetaling. a) Indkomstgrundlaget for Personen skal beregnes i henhold til Lovgivningen. b) Hvis det er nødvendigt for beregningen at beregne et indkomstgrundlag for en eventuel Ægtefælle, skal Løsningen også gøre dette. c) Løsningen skal foretage beregningerne med udgangspunkt i de indkomstoplysninger, som er indhentet og/eller indberettet under oplysning af sagen. - Det varierer fra Ydelse til Ydelse, hvilke oplysninger, der indgår i beregningen af indkomstgrundlaget. Eksempelvis er der forskel på, hvilke oplysninger, der indgår i indkomstgrundlaget i en kontanthjælpssag og en sag vedrørende revalideringsydelse. Boligstøtte indhentes til beregning af sager om særlig støtte jf. LAS 34. - Se informationsmodellen (Beregningsgrundlag) i underbilag 2.5. - Se Krav# 320 om anvendelse af Ydelsesindekset. - Se underbilag 2.8 vedrørende relevant faglovgivning. Side 60 af 257
Krav# 49: Beregn konsekvenser af sanktioner Beskrivelse: Løsningen skal beregne konsekvenserne af afgørelser om sanktioner og sikre, at disse konsekvenser slår igennem i beregningen af beløb til udbetaling. a) Konsekvenser af sanktioner skal beregnes i henhold til Lovgivningen. b) Konsekvenser af sanktioner skal indregnes i beregningen af beløb til udbetaling for den aktuelle udbetalingsperiode i henhold til Lovgivningen. c) Konsekvenser af en sanktion skal kun indregnes, hvis der er registreret en afgørelse om godkendelse af sanktionen. d) Hvis en sanktion skal påvirke flere udbetalingsperioder, skal Løsningen sikre, at dette sker. e) Hvis det fremgår af Lovgivningen, at sanktionen også skal påvirke en eventuel Ægtefælle, skal Løsningen håndtere dette. - Eksempelvis vil en sanktion efter LAS 42 stk. 2 nedsætte kontanthjælpen i 20 uger, hvilket vil påvirke flere udbetalingsperioder. En sådan sanktion skal i øvrigt også gælde for Personens Ægtefælle. En sanktion efter LAS 40 a kan også påvirke flere udbetalingsperioder, idet hjælpen kan standses i 1-3 måneder, og i stedet udbetales dag for dag i den periode. - Se Krav# 47 vedrørende beregning af beløb til udbetaling. - Se Krav# 61 om afgørelse om sanktion. - Se informationsmodellen (KY-effektuering) i underbilag 2.5. - Se underbilag 2.8 vedrørende relevant faglovgivning. Krav# 50: Beregn og indehold ATP-bidrag Beskrivelse: Løsningen skal beregne og indeholde både Personens og kommunens andel af et eventuelt ATP-bidrag og sikre, at det slår igennem i beregningen af beløb til udbetaling. a) Hvis det fremgår af Lovgivningen, at der skal indbetales til ATP, skal Løsningen beregne ATP-bidraget og sikre, at beløbet indeholdes. b) Både Personens og kommunens andel af ATP-bidraget skal beregnes. c) Personens andel af ATP-bidraget skal indregnes i beløb til udbetaling. d) Hvis der udbetales til både Personen og en eventuel Ægtefælle, skal Løsningen sikre, at beregning og indeholdelse af ATP-bidrag foretages for begge Personer. - Se Krav# 47 vedrørende beregning af beløb til udbetaling. - Se informationsmodellen (ATP, Skatteberegning) i underbilag 2.5. - Se underbilag 2.8 vedrørende relevant faglovgivning. Side 61 af 257
Krav# 51: Beregn og indehold A-skat Beskrivelse: Løsningen skal beregne og indeholde AMB og A-skat. a) Hvis det fremgår af Lovgivningen, at der skal trækkes AMB og/eller A- skat, skal Løsningen beregne disse beløb og sikre, at de indeholdes. b) De beregnede beløb skal indregnes i beløb til udbetaling. c) Hvis der udbetales til både Personen og en eventuel Ægtefælle, skal løsningen sikre, at beregning og indeholdelse af AMB og A-skat foretages for begge Personer. - Eksempelvis er uddannelseshjælp, kontanthjælp, revalideringsydelse, ledighedsydelse og fleksløntilskud A-skattepligtige. - Se informationsmodellen (ATP, Skatteberegning) i underbilag 2.5. - Se underbilag 2.8 vedrørende relevant faglovgivning. Krav# 52: Foretag fradrag for forskudsvis udlagt børnebidrag Beskrivelse: Løsningen skal fastsætte og indeholde fradrag for forskudsvis udlagt børnebidrag og sikre, at det slår igennem i beregningen af beløb til udbetaling. a) Hvis der i sagens oplysninger er registreret, at der skal foretages fradrag for forskudsvis udlagt børnebidrag, skal Løsningen sikre, at dette gøres i henhold til Lovgivningen og at der sker validering mod de objektive kriterier for fradraget. b) Konsekvensen af indeholdelsen skal indregnes i beløb til udbetaling i henhold til Lovgivningen. - Det er kun på visse Ydelsesarter: kontanthjælp, uddannelseshjælp og revalideringsydelse, at der afhængig af oplysninger i sagen og Lovgivningen skal foretages fradrag for forskudsvis udbetalt børnebidrag. - De objektive kriterier for fradrag fremgår af afsnit 5.9.3 om forskudsvist udlagt børnebidrag. - Se Krav# 47 vedrørende beregning af beløb til udbetaling. - Se 6.4.3.15 vedrørende snitflade til UDK. - Se informationsmodellen (Beslutningsgrundlag, Beregningsgrundlag) i underbilag 2.5. - Se underbilag 2.8 vedrørende relevant faglovgivning. Krav# 53: Beregn skatteværdi af renter på boliglån Beskrivelse: Løsningen skal indregne skatteværdien af renter, bidrag mv. for lån optaget i andels- eller ejerbolig i beregning af særlig støtte (LAS 34). Side 62 af 257
a) Hvis der er registreret oplysninger om lån i boligen i en sag om særlig støtte skal Løsningen beregne skatteværdien i henhold til Lovgivningen. b) Ved beregning skal aktuelle oplysninger om Personens fradrag og trækprocent anvendes. c) Skatteværdien skal indgå i beregningen af særlig støtte i henhold til Lovgivningen. - Se informationsmodellen (Beregningsgrundlag) i underbilag 2.5. - Se underbilag 2.8 vedrørende relevant faglovgivning. Krav# 54: Indberetning af individuelle tillæg/fradrag Beskrivelse: Det skal være muligt for Brugeren manuelt at indberette individuelle tillæg eller fradrag i en specifik sag, så de indgår i beregning af beløb til udbetaling. a) En Bruger skal kunne indberette de nødvendige oplysninger om et individuelt tillæg/fradrag på en specifik sag. b) Brugeren skal kunne vælge typen af tillæg/fradrag og indberette beløb, tidspunkt for effektuering eller antal gange og frekvens for effektuering. c) Løsningen skal ved indberetning sikre, at reglerne, som er konfigureret på Ydelsen og typen af tillæg/fradrag, overholdes. d) Registrerede tillæg/fradrag skal indregnes korrekt i beregningen af beløb til udbetaling. e) Løsningen skal ved indberetning registrere Hændelsen i sagshistorikken. - Se Krav# 194 vedrørende konfigurering af typer af individuelle tillæg/fradrag. - Se informationsmodellen (Ydelseskatalog, Bevilling, Bevilget Ydelse) i underbilag 2.5. 5.2.2.3 Beregning ved udbetaling af helbredstillæg og udvidet helbredstillæg I dette afsnit angives et specifikt krav til beregning vedrørende udbetaling af helbredstillæg og udvidet helbredstillæg. Kravet er det eneste til særskilt understøttelse af beregning af beløb til udbetaling i forhold til Andre Ydelser. Kravet udgør en undtagelse fra hovedreglen om, at Løsningen ikke understøtter beregninger vedrørende enkeltydelser og Andre Ydelser. Læs mere om Andre Ydelser i afsnit 3.3 og underbilag 2.3 om processen vedrørende enkeltydelser og processen vedrørende Andre Ydelser. Krav# 55: Beregning af helbredstillæg og udvidet helbredstillæg Beskrivelse: Løsningen skal beregne det beløb, som skal udbetales i helbredstillæg eller udvidet helbredstillæg. a) Det beløb, som skal udbetales i helbredstillæg, skal beregnes i henhold til Lovgivningen. b) Det beløb, som skal udbetales i udvidet helbredstillæg, skal beregnes i henhold til Lovgivningen. Side 63 af 257
- Se Krav# 364 vedrørende integration til SF1411 - Helbredstillæg og udvidet helbredstillæg er hjemlet i Lov om social pension og Lov om højeste, mellemste, forhøjet almindelig og almindelig førtidspension m.v. - Se underbilag 2.8 vedrørende relevant faglovgivning. 5.2.3 Træf afgørelse Under oplysning af sagen indsamles alle de oplysninger, der skal til for at afgøre sagen (jf. afsnit 5.2.1). På baggrund af disse oplysninger vurderer sagsbehandleren, om der er behov for en fastsættelse og beregning af Ydelsen (jf. 5.2.2). Når disse aktiviteter er udført, kan Sagsbehandleren træffe en afgørelse i sagen og indberette denne i Løsningen. Den indsats, der er forbundet hermed, vil ofte være begrænset, da størstedelen af sagsbehandlingen er foretaget under oplysning af sagen. Afgørelsen vil være en bevilling, et afslag eller afslutning af igangværende bevilling. Når der træffes en afgørelse, skal Personen orienteres herom. I forbindelse med afgørelsen vil Sagsbehandleren desuden færdiggøre en effektueringsplan (se afsnit 5.2.3.2), såfremt der bevilges en Ydelse. Som nævnt i afsnit 5.2.2.1 kan der tidligere i sagens forløb have været foretaget beregninger. Resultater herfra vil være gemt på sagen i kladdetilstand Alle afgørelser træffes som hovedregel af en Sagsbehandler, da der i de fleste Ydelser, der håndteres i Løsningen, ikke er lovmæssig hjemmel til at træffe objektive automatiske afgørelser. Krav# 56: Indberet afgørelse Beskrivelse: Det skal være muligt for en Bruger at indberette, at der er truffet en afgørelse med et givet udfald, fx bevilling, afslutning af bevilling eller afslag på bevilling. a) Løsningen validerer, at de nødvendige minimumsoplysninger for den relevante Ydelsesart er registreret på afgørelsen. b) Hvis de nødvendige minimumsoplysninger ikke er registreret, gøres Brugeren opmærksom på dette. c) Løsningen ændrer status på sagen. d) Løsningen opdaterer Ydelsesindekset i) Løsningen opdaterer Sags- og Dokumentindeks og sikrer, at andre it-løsninger kan blive orienteret om hændelsen. e). f) Hvis afgørelsen medfører bevilling af en Ydelse, registrerer Løsningen de nødvendige oplysninger om bevilling og effektueringsplan. Dette gælder også, hvis Ydelsen er tilbagebetalingspligtig. g) Hvis udfaldet er afslag på bevilling, kan Brugeren registrere en årsag til afslaget. Årsagen kan være suppleret af kommentar. h) Løsningen afsender Besked om bevilling til Jobcenterløsning. Side 64 af 257
i) Løsningen afsender Besked om udfald af afgørelsen til det fælles datagrundlag. j) Brugeren har mulighed for manuelt at forlænge kassationskoden fra standardværdien. k) Det skal være muligt at oprette en bevilling med tilbagevirkende kraft inden for indeværende og forrige år. l) Hvis afgørelsen medfører bevilling, opretter Løsningen abonnement på oplysninger fra skat på Personens CPR-nr. - Se Krav# 62 om automatisk oprettelse af effektueringsplan. - Oprettelse af bevilling med tilbagevirkende kraft er fx relevant i det tilfælde, hvor der foreligger en ankeafgørelse, der medfører behov for at udbetale kontanthjælp for de seneste 11 måneder. - Bemærk at krævede oplysninger for en afgørelse kan være forskellige fra Ydelsesart til Ydelsesart, se underbilag 2.23 (Minimumsoplysninger). - Se Krav# 23 vedrørende kassationskoder. - Se Krav# 265 om Jobcenterløsning. - Se Krav# 270 om det fælles datagrundlag. - Se informationsmodellen (KY-sag, KY-dokument, KY-bevilling, KY-effektuering, Beslutningsgrundlag, Træf afgørelse, Bevilling, Effektuering, Sanktionering, Beregningsgrundlag) i underbilag 2.5. - Jf. OIO standarderne for Sag eller tilsvarende i henhold til mulige kassationskoder og frister, se afsnit 7 for referencer til OIO_SAG. - Se underbilag 2.13 for oversigt over udgående Hændelser. Krav# 57: Besked om afgørelse Beskrivelse: Når afgørelsen er truffet, informeres Personen om udfaldet. a) Løsningen kan afsende en bevillingsskrivelse (inklusiv en effektueringsplan) eller et begrundet afslag med klagevejledning. b) Brevet kan indeholde information om tilbagebetalingspligt. c) Brugeren kan benytte brevfunktionaliteten beskrevet i Krav# 129 til at udforme brevet. - Se afsnit 5.4.3 vedrørende generelle krav til breve. - Se Krav# 63 vedrørende effektueringsplan. - Se Krav# 352 vedrørende Print på Serviceplatformen. - Det er ikke obligatorisk at sende en skriftlig Besked om afgørelsen, idet Beskeden i nogle tilfælde også kan gives mundtligt. Der kan være årsager til, at en sagsbehandler ønsker at se på hvilket grundlag, en tidligere afgørelse blev truffet. Det kan fx være, hvis parten i sagen stiller spørgsmål til afgørelsen, eller der er nye oplysninger i sagen. Hvis det er en afgørelse, der tidsmæssigt ligger et stykke tilbage, kan nogle af oplysningerne i mellemtiden have ændret sig. Derfor er det vigtigt, at sagsbehandleren kan se de oplysninger, som var til stede på det tidspunkt, afgørelsen blev truffet. Side 65 af 257
Krav# 58: Fremfinding af grundlaget for afgørelsen Beskrivelse: De oplysninger, der er blevet benyttet i forbindelse med at træffe en afgørelse, skal Brugeren til enhver tid kunne fremfinde igen samlet. Dette er særlig relevant, hvis der efterfølgende er blevet ændret i oplysningerne. - Se Krav# 152 vedrørende visning af sagen oplysninger pr. Brugervalgt dato og tid. - Se afsnit 6.2.4.1 vedrørende Bitemporalitet. 5.2.3.1 Behandling af sanktioner I forbindelse med sager om forsørgelsesydelser, eksempelvis uddannelseshjælp eller kontanthjælp og ledighedsydelse, skal Personen som hovedregel deltage i et kontaktforløb med Jobcentret. Såfremt Personen fx ikke møder op til samtaler eller tilsidesætter sin oplysningspligt, indstiller Jobcentret til Ydelsescentret, at Personen skal sanktioneres økonomisk, ligesom Jobcentret i visse tilfælde kan træffe afgørelse om sanktion. Indstillinger om sanktioner overføres automatisk fra JobcenterIøsningerne til Løsningen, der oprettes en Opgave, og Ydelsescentret træffer afgørelse om hvorvidt sanktionen gennemføres eller ej. I visse tilfælde kan Ydelsescentret på eget initiativ træffe afgørelse om sanktion, fx hvis Ydelsescentret bliver bekendt med, at Personen har tilsidesat sin oplysningspligt jf. LAS 42 stk. 2. Der er en sammenhæng mellem årsagen til sanktionsindstillingen og den målgruppe (jf. LAB), som Jobcentret har indplaceret Personen i, på den ene side og den specifikke henvisning til sanktionsbestemmelsen i LAS på den anden side. Denne sammenhæng er illustreret i nedenstående Tabel 2. Såfremt sanktionen skal gennemføres, skal Løsningen sikre, at konsekvenserne slår igennem på det beløb, som udbetales til Personen og eventuelt også Ægtefællen i sager vedr. uddannelseshjælp eller kontanthjælp. Dette involverer en række regler, som er fastsat for de forskellige Ydelsesarter, der bl.a. fastsætter den økonomiske størrelse af sanktionen, varigheden og hvorvidt sanktionen også skal gælde for Personens Ægtefælle. Input fra Jobcenterløsning Lovhenvisning i Løsningen Sanktion- Aarsag- Typekode LAB Målgruppe Sanktions-paragraf Hændelse 1 2, 12 39.1.2 Afviser arbejde 41.1.1 Afviser tilbud 11 69 d.2 Afviser arbejde 69 e.1 Afviser tilbud 7 77 a.1 Afviser fleksjob 77 a.2 Afviser tilbud 14 69 m Afviser tilbud 2 2, 3, 12,13 37.1 Udeblevet jobsamtale, samtale sygeopfølgning, rådighedsvurdering, møde i rehabiliteringsteam 36.1 Udeblevet tilbud, udeblevet foranstaltning sygeopfølgning, udeblevet læse-, skrive- og regnetest Side 66 af 257
Input fra Jobcenterløsning Lovhenvisning i Løsningen Sanktion- Aarsag- Typekode LAB Målgruppe Sanktions-paragraf Hændelse 11 69 c.1 Udeblevet fra jobsamtale, rådighedsvurdering, individuel samtale 69 b.1 Udeblevet fra tilbud 7 77.1 Udeblevet fra jobsamtale, individuel samtale, rådighedsvurdering, møde i rehabiliteringsteam 77 a, 2 Afviser eller ophører i tilbud 14 69 n Udeblevet fra individuel opfølgningssamtale 69 m Udebliver fra tilbud (i kraft fra 01.07.2015) 3 2, 3, 12,13 36.1 Udebliver fra sygeopfølgning 41.1.1 Afviser sygeopfølgning 11 Ingen sanktion Udebliver fra sygeopfølgning Ingen sanktion Afviser sygeopfølgning 7 Ingen sanktion Udebliver fra sygeopfølgning Ingen sanktion Afviser sygeopfølgning 14 Ingen sanktion Udebliver fra sygeopfølgning Ingen sanktion Afviser sygeopfølgning 4 2, 3, 12,13 38.1 Undlader tilmelding 38.2 Afmeldt jobnet pga. manglende bekræftelse 11 Ingen sanktion Skal ikke tilmelde CV derfor ingen sanktion Ingen sanktion Skal ikke tilmelde CV derfor ingen sanktion 7 77.2 Undladt at lægge CV på jobnet Ingen sanktion Skal ikke bekræfte derfor ingen sanktion 14 Ingen sanktion Skal ikke tilmelde CV derfor ingen sanktion Ingen sanktion Skal ikke bekræfte tilmelding derfor ingen sanktion 5 2, 3, 12,13 39.1.4 39.1.7 Undladt søge konkrete job Undladt at holde aftale om jobsøgning 11 69 d.4 Undladt at søge konkrete jobs 7 76 Ikke aktivt jobsøgende 14 69 0, 4 Undladt at søge konkrete jobs 6 2, 3, 12,13 39.1.1 Ophører arbejde 11 69 d.1 Ophører arbejde 7 77 a.1 Ophører fleksjob 77 a.2 Ophører tilbud 14 69 0, 1 Ophører arbejde 7 2, 3, 12,13 42 eller 43 Ikke oplyst om arbejde samtidigt med modtagelse af kontanthjælp eller uberettiget har modtaget hjælp under ophold i udlandet mv. 11 69 f.1 eller 69 f.2 Ikke oplyst om arbejde samtidigt med modtagelse af kontanthjælp eller uberettiget har modtaget hjælp under ophold i udlandet mv. 7 Ingen sanktion Ingen sanktion i ledighedsydelse. 14 69 q, 1 eller 69 q, 2 Ikke oplyst om arbejde samtidigt med modtagelse af ressourceforløbsydelse eller uberettiget har modtaget hjælp under ophold i udlandet m.v. 8 12, 13 39.1.6 Ophører uddannelse omfattet af uddannelsespålæg LAB 21b 800 2, 3, 12, 13 40a Gentagne undladelser 801 2, 3, 12, 13 39.8 Har ikke registreret i joblog på jobnet Tabel 6: Oversigt over sanktionsårsager og lovhenvisninger. Side 67 af 257
Krav# 59: Se indstilling fra jobcenter om sanktion Beskrivelse: Det skal være muligt for en Bruger at se en indstilling om sanktion, der er gemt på en sag. Der skal være direkte adgang til at angive en afgørelse om godkendelse eller afvisning af sanktionen. a) Alle indstillinger om sanktioner modtaget fra Jobcenterløsningen er tilgængelige for en Bruger. b) Løsningen har hvor det er entydigt muligt dannet lovhenvisning på sanktionsindstillinger, som er dannet på grundlag af Besked fra Jobcentret via snitflade. c) Løsningen viser hvor der er flere muligheder de mulige lovhenvisninger på sanktionsindstillinger, som er dannet på grundlag af Besked fra Jobcentret via snitflade. d) Brugeren kan tilføje/ændre oplysning om lovhenvisning. e) Brugeren kan navigere direkte til en funktion, hvor afgørelse om godkendelse/afvisning af sanktion kan registreres. - Se Tabel 6 vedrørende sanktionsårsager og lovhenvisninger. - Se Krav# 261 og Krav# 262 om Beskeder fra Jobcenterløsning. - Se Krav# 61 om godkendelse/afvisning af sanktion. - Se informationsmodellen (KY-kontaktforløb) i underbilag 2.5. Krav# 60: Opret indstilling om sanktion Beskrivelse: Det skal være muligt for en Bruger på eget initiativ at oprette en sanktionsindstilling på en sag. Der skal være direkte adgang for Brugeren til at angive en afgørelse om sanktionen. a) Brugeren kan oprette en sanktionsindstilling. b) Brugeren kan registrere oplysning om lovhenvisning, dvs. henvisning er til paragraf, stk., nr. c) Brugeren kan navigere direkte til en funktion, hvor afgørelse om godkendelse/afvisning af sanktion kan registreres. d) Der skal kunne oprettes flere sanktioner på samme sag. - Se Krav# 261 og Krav# 262 om Beskeder fra Jobcenterløsning. - Se Krav# 61 om godkendelse/afvisning af sanktion. - Se informationsmodellen (KY-kontaktforløb) i underbilag 2.5. Krav# 61: Angiv afgørelse om sanktion Beskrivelse: Det skal være muligt for en Bruger at angive en afgørelse om sanktion. Side 68 af 257
a) Løsningen skal sikre, at der er sammenhæng mellem den valgte sanktionsbestemmelse og den bevilgede Ydelse. - Afgørelsen kan tage udgangspunkt i en indstilling om sanktion fra Jobcentret (se eventuelt Krav# 59), eller en sanktion, som er indberettet på Ydelsescentrets eget initiativ (se eventuelt Krav# 60). - Se krav Krav# 49 om gennemførelse af sanktion. - Se informationsmodellen (KY-effektuering, KY-kontaktforløb, Træf afgørelse) i underbilag 2.5. - Se underbilag 2.8 vedrørende relevant faglovgivning. 5.2.3.2 Fastlæg effektueringsplan Hvis der er truffet afgørelse om, at Personen er berettiget til Ydelsen, sendes som en del af bevillingsskrivelsen oplysninger fra effektueringsplanen. Denne er en oversigt over Ydelsens størrelse, hvilken frekvens der udbetales med mv. Hvis der er foretaget beregning af beløb til udbetaling tidligere end det tidspunkt, hvor effektueringsplanen fastlægges, vil der være registreret en kladde effektueringsplan i sagen, som er udgangspunktet for at færdiggøre effektueringsplanen. Som oftest vil der ikke ligge nogen opgave for sagsbehandleren i denne aktivitet, da effektueringsplanen for langt de fleste sager følger standarden for den pågældende Ydelsesart mht. udbetalingstidspunkter mv. Men der kan være særtilfælde, hvor det er nødvendigt at ændre effektueringsplanen for den enkelte sag. Krav# 62: Automatisk oprettelse af effektueringsplan Beskrivelse: Løsningen skal sikre, at de oplysninger, som er nødvendige for effektuering og bestilling af udbetalinger gemmes i sagen, så de kan vedligeholdes og bruges ved efterfølgende effektueringer af udbetalinger. a) Løsningen skal sikre, at oplysninger til brug for effektuering og bestilling af udbetalinger automatisk gemmes i sagens oplysninger om bevilget Ydelse og effektueringsplan. b) Løsningen skal sikre, at oplysninger til brug for effektuering og bestilling af betaling via debitorsystem automatisk gemmes i sagens oplysninger om bevilget Ydelse og effektueringsplan. c) Løsningen skal sikre, at effektueringsplaner oprettes i henhold til Lovgivningen, sagens oplysninger og de oplysninger, som er konfigureret i Løsningen for den aktuelle Ydelsesart, kalender for beregning, effektuering og udbetaling. Side 69 af 257
- Forsørgelsesydelser som uddannelseshjælp, kontanthjælp, revalideringsydelse, ledighedsydelse og fleksløntilskud udbetales månedsvis. Er Personen under administration kan uddannelseshjælp og kontanthjælp udbetales i flere rater i henhold til oplysninger på en administrationsordning. - I situationer, hvor beløbsmodtager er en organisatorisk enhed i kommunen, kan beløbet overføres via snitflade til kommunens debitorsystem, som alternativ til udbetaling via udbetalingssystem. - Se afsnit 5.6.2 vedrørende konfigurering af Ydelser og kalender for beregning, effektuering og udbetaling. - Se Krav# 107 vedrørende tilknyttet administrationssag. - Se informationsmodellen (KY-effektuering, Beslutningsgrundlag, Beregningsgrundlag, Ydelseskatalog, Bevilling, Effektuering) i underbilag 2.5. - Se underbilag 2.8 vedrørende relevant faglovgivning. Krav# 63: Ændring af effektueringsplan i sager vedr. forsørgelsesydelser Beskrivelse: Det skal være muligt for en Bruger at ændre i oplysninger vedrørende effektueringsplanen på den enkelte sag. a) Brugeren kan ændre de nødvendige oplysninger om effektuering og udbetaling i sagen. b) Brugeren kan ændre de nødvendige oplysninger om effektuering og debitor-betaling i sagen. c) De nødvendige oplysninger udgør frekvens og hvorvidt hver enkelt udbetaling skal godkendes manuelt. d) Brugeren skal kunne indberette de nødvendige oplysninger, så sagen effektueres samtidig med almindelig massebestilling af udbetaling. e) Brugeren skal kunne indberette de nødvendige oplysninger om betaling hurtigst muligt. f) Brugeren skal kunne indberette de nødvendige oplysninger til, at Løsningen kan danne et straksudbetalingsbilag. g) Løsningen skal sikre, at ændringerne er i overensstemmelse med Lovgivning og de oplysninger, som er konfigureret i Løsningen om den relevante Ydelse. h) Se underbilag 2.8 vedrørende relevant faglovgivning. - Se Krav# 62 om automatisk oprettelse af effektueringsplan. - Se afsnit 5.6.2 vedrørende konfigurering af Ydelser og kalender for beregning, effektuering og udbetaling. - Se Krav# 79 vedrørende manuel godkendelse/annullering af udbetaling. - Se Krav# 73 vedrørende straksudbetalingsbilag. - Se informationsmodellen (KY-effektuering) i underbilag 2.5. - Se underbilag 2.8 vedrørende relevant faglovgivning. Side 70 af 257
Krav# 64: Indberet oplysninger om effektuering i sager vedr. enkeltydelser og Andre Ydelser Beskrivelse: Det skal være muligt for Brugeren manuelt at indberette nødvendige oplysninger vedrørende bevilling og effektueringsplan på en specifik sag, så Løsningen kan udbetale en bevilget enkeltydelse eller Anden Ydelse korrekt. a) Brugeren kan ændre de nødvendige oplysninger for at kunne fastsætte effektuering og udbetaling i sagen. b) Brugeren kan ændre de nødvendige oplysninger for at kunne fastsætte effektuering og debitor-betaling i sagen. c) De nødvendige oplysninger udgør valg af Ydelsesart, modtager, bevilget beløb, individuelle tillæg/fradrag, antal udbetalinger, betalingsdato(er), frekvens, hvorvidt hver enkelt udbetaling skal godkendes (se eventuelt Krav# 79), hvorvidt udbetaling kun skal ske ved modtagelse af regning. - Se Krav# 65 vedrørende registrering af Alternativ Modtager. - Se eventuelt informationsmodellen (KY-enkeltydelser, KY-Andre Ydelser) i underbilag 2.5. Krav# 65: Registrering af Alternativ Modtager Beskrivelse: Det skal være muligt for Brugeren manuelt at tilknytte en virksomhed som Alternativ Modtager på effektueringsplanen i en ydelsessag eller på en betalingsaftale i en administrationssag. Som en del heraf skal Brugeren i Løsningen kunne fremsøge virksomheder fra CVR-registret. a) Brugeren skal kunne registrere de nødvendige oplysninger om en Alternativ Modtager, så der kan udbetales til denne. b) Brugeren skal som en del af registreringen kunne fremsøge virksomheder fra CVR-registret ved hjælp af CVR-nummer eller navn og adresse på virksomheden. Løsningen skal overføre de nødvendige oplysninger fra CVR-registret. c) Brugeren skal kunne tilknytte Alternativ Modtager til effektueringsplanen i en ydelsessag eller til en betalingsaftale i en administrationssag. d) Løsningen skal ved effektuering og udbetaling i sagen anvende de registrerede oplysninger, så der udbetales rettidigt og korrekt til den alternative modtager. - Se informationsmodellen (KY-bevilling, KY-effektuering) i underbilag 2.5. - Se afsnit 5.3 vedrørende administrationssager. - Se afsnit 6.4.3.7 vedrørende ØiR snitflade til udbetalingssystem. - Se afsnit 6.4.3.12 vedrørende snitflade til CVR-registret. Side 71 af 257
Krav# 66: Registrering af specifik bankkonto Beskrivelse: Det skal være muligt for Brugeren manuelt at registrere et specifikt bankkontonummer som alternativ til Nemkonto. a) Brugeren skal kunne registrere et specifikt bankkontonummer som et alternativ til NemKonto for en specifik Person. b) Brugeren skal kunne registrere et specifikt bankkontonummer som et alternativ til NemKonto for en specifik Alternativ Modtager. c) Brugeren skal kunne tilknytte kontonummeret til alle eller udvalgte effektueringsplaner for Personen eller den alternative modtager. d) Løsningen skal anvende oplysningerne, når der overføres udbetalingsanmodninger til udbetalingssystem. e) Løsningen skal sikre, at en registrering af specifik bankkonto fremgår af særskilt kontrolrapport. - Se informationsmodellen (KY-bevilling, KY-effektuering) i underbilag 2.5. - Se afsnit 6.4.3.7 vedrørende ØiR snitflade til udbetalingssystem. - Se afsnit 5.7.1 vedrørende rapporter. 5.2.3.3 Afsnittet udgår Krav# 67: Kravet udgår Kategori: Beskrivelse: Type: 5.2.3.4 Etabler sag og afgørelse på baggrund af inddata fra Jobcenterløsning Som hovedregel er det Ydelsescentret, der både bevilger og effektuerer Ydelserne på baggrund af eksempelvis information fra Jobcentret om kontaktforløb mv. Der er dog nogle få undtagelser, idet fleksløntilskud (LAB) og enkelte Andre Ydelser bevilges af Jobcentret og effektueres i Ydelsescentret, eksempelvis Godtgørelse til befordringsgodtgørelse efter LAB 82 og udgifter ved deltagelse i tilbud efter LAB 83. I disse tilfælde er der behov for, at der i Løsningen kan oprettes en sag med tilhørende bevilling, effektueringsplan mv. ud fra information fra en Jobcenterløsning, således at Ydelsen kan effektueres automatisk uden Ydelsescentrets involvering. Dette supplerer sagsbehandlerens generelle mulighed for at oprette og behandle sager, som også gælder for sager om disse Ydelser. Krav# 68: Automatisk etablering af sag ud fra information fra Jobcenterløsning Beskrivelse: Løsningen skal kunne registrere de oplysninger, som er nødvendige for, at der kan effektueres og udbetales visse Ydelser udelukkende på baggrund af oplysninger, som overføres fra en Jobcenterløsning. Side 72 af 257
a) Løsningen kan på baggrund af data fra Jobcentret gøre følgende uden en Brugers indblanding: A. Løsningen kan oprette en sag vedrørende den Ydelsesart, som svarer til den type Godtgørelse, der fremgår af Beskeden. B. Sagen er tilknyttet korrekt til den Person, som har fået bevilget Godtgørelsen. C. Oplysninger fra Beskeden er registreret korrekt på sagen. D. Løsningen kan registrere en afgørelse om bevilling med tilhørende effektueringsplan, så Løsningen kan effektuere og udbetale Ydelsen. E. Løsningen kan afslutte og lukke sagen samt genoptage sagen. - Se Krav# 91 om effektuering ud fra oplysninger fra Jobcenterløsning. Dette vedrører et begrænset antal godtgørelsesydelser, der kan overføres via integration til Jobcenterløsning. - Se Krav# 258 vedrørende Besked fra Jobcenterløsning. - Se informationsmodellen (KY-Sag, KY-effektuering, Beslutningsgrundlag, Beregningsgrundlag, Ydelseskatalog, Bevilling, Effektuering) i underbilag 2.5. - Se Hændelseslisten i underbilag 2.13. 5.2.4 Effektuer Når der er truffet en afgørelse, bevilget en Ydelse og effektueringsplanen er fastlagt, er det tid til at effektuere afgørelsen. Dette vedrører Beregning (jf. afsnit 5.2.2) Bestilling af udbetalingen (jf. afsnit 5.2.4.1) Kontering (jf. afsnit 5.2.4.2) af dette (jf. afsnit 5.2.4.4). For sager om visse Godtgørelser mv., der bevilges af Jobcentret og udbetales af Ydelsescentret, er der også behov for automatisering 5.2.4.1 Bestil udbetaling Løsningen anvendes til at håndtere økonomiske Ydelser, der som hovedregel udbetales til den Person, som er berettiget til Ydelsen eller i visse tilfælde til en Alternativ Modtager, eksempelvis tandlæger eller optikere eller boligselskaber og forsyningsselskaber. Endelig kan der være beløb som skal betales til en organisatorisk enhed inden for kommunen. Forsørgelsesydelserne udbetales som hovedregel månedsvis bagud, således at pengene er til disposition den sidste bankdag i måneden, dvs., der massebestilles udbetalinger. Der kan også være tale om udbetalinger, som skal foretages på andre tidspunkter, herunder dag-til-dag udbetalinger. Når der effektueres, sker det i henhold til sagens effektueringsplan. Der foretages beregning og der bestilles udbetaling og konteres. Det er helt centralt, at Løsningen kan bestille udbetalinger ved at aflevere udbetalingsanmodninger til et eksternt udbetalingssystem og sikre grundlaget for, at Side 73 af 257
bogføring af udbetalingen sker i et eksternt økonomisystem, ved at overføre posteringer hertil. På denne måde adskilles den fagspecifikke sagsbehandlingsfunktionalitet i Løsningen fra mere generel udbetalings- og bogføringsfunktionalitet, som Løsningen deler med andre fagsystemer. Der kan være behov for, at den enkelte udbetaling af en forsørgelsesydelse som kontanthjælp eller udbetaling af en enkeltydelse, skal godkendes af en Bruger, før den kan effektueres. Ved eksempelvis kontanthjælp kan det skyldes, at Personen har indtægter i udbetalingsperioden, som skal nedsætte beløbet til udbetaling, når Personen har fremsendt dokumentation for indtægterne. Ved enkeltydelser kan det skyldes, at Personen skal dokumentere en given udgift, for at udbetalingen godkendes. I sager vedrørende enkeltydelser eller Andre Ydelser samt administrationssager, hvor der er bevilget hjælp til betaling af bestemte tjenester eller varer, modtager Ydelsescentret endvidere regninger fra behandlere eller andre leverandører af tjenester eller varer, som skal betales. Løsningen skal kunne modtage elektroniske fakturaer, ligesom en sagsbehandler skal kunne registrere papirregninger. Nogle udbetalinger, eksempelvis udbetaling af enkeltydelser, skal i særlige tilfælde foretages straks. Dette betyder som hovedregel, at Løsningen skal bestille udbetalingen umiddelbart efter, at de nødvendige oplysninger er indberettet, og anmode udbetalingssystemet om, at udbetalingen foretages hurtigst muligt, dvs. samme eller næste bankdag. Undtagelsesvis kan Brugeren vælge at udskrive et straksudbetalingsbilag, som efterfølgende kan benyttes ved kontant udbetaling eller udstedelse af check. Løsningen skal ikke sende udbetalingsanmodning for et sådant straksudbetalingsbilag, men kontere det korrekt. Krav# 69: Automatisk effektuering af udbetalinger Beskrivelse: Løsningen skal effektuere udbetalinger på fastsatte tidspunkter ved at overføre oplysninger til et eksternt udbetalingssystem. a) Løsningen skal automatisk effektuere beregning, udbetaling og kontering på de tidspunkter, der er konfigureret i Løsningen for de enkelte ydelsesarter. b) Alle beregninger og udbetalinger er effektueret korrekt og rettidigt i henhold til oplysningerne på sagens effektueringsplaner. c) Hvis der på en effektueringsplan i en sag er registreret specifikke oplysninger om undtagelse fra den generelle effektuering, herunder særskilt tidspunkt for effektuering og udbetaling, er den effektueret korrekt og rettidigt i henhold til disse oplysninger. d) Hvis der til en ydelsessag er tilknyttet en administrationsordning med oplysninger, der påvirker effektuering og udbetaling, er der taget højde herfor ved effektuering og udbetaling. e) Ydelsesindeks er opdateret korrekt. f) Udbetalingen er bestilt uden tilvalg af print af udbetalingsspecifikation. Side 74 af 257
- Forsørgelsesydelser som uddannelseshjælp, kontanthjælp, revalideringsydelse, ledighedsydelse og fleksløntilskud udbetales månedsvis. Er Personen under administration, kan uddannelseshjælp og kontanthjælp udbetales i flere rater. - For enkeltydelser og Andre Ydelser effektueres der typisk en eller flere gange ugentligt. - Se Krav# 198 vedrørende kalender for beregning, effektuering og udbetaling for forsørgelsesydelser og løbende enkeltydelser. - Se Krav# 63 vedrørende specifikke oplysninger på den enkelte sags effektueringsplan). - Se Krav# 71 vedrørende massebestilling af udbetalinger. - Se Krav# 72 vedrørende anmodning om udbetaling hurtigst muligt. - Se Krav# 107 vedrørende tilknyttet administrationssag. - Se informationsmodellen (KY-effektuering, Beslutningsgrundlag, Beregningsgrundlag, Ydelseskatalog, Bevilling, Effektuering) i underbilag 2.5. - Se afsnit 6.4.3.7 om ØiR snitflade til udbetalings- og økonomisystemer. - Se afsnit 6.3.2.4 om Ydelsesindekset. Som supplement til den automatiske effektuering skal en Bruger kunne igangsætte effektuering manuelt. Krav# 70: Manuel effektuering og bestilling af udbetaling Beskrivelse: Det skal være muligt for en Bruger at igangsætte effektuering i en specifik sag, så Løsningen kan bestille en udbetaling. a) Brugeren skal kunne igangsætte effektuering i en specifik sag valgt af Brugeren. b) Løsningen skal sikre, at der anmodes om rettidig udbetaling ud fra de oplysninger, der er gemt på sagens effektueringsplan. c) Udbetalingsanmodningen skal indeholde tilstrækkelige oplysninger til, at udbetalingssystemet kan udbetale beløbet i henhold til Lovgivningen og effektueringsplanen mv. d) Udbetalingsanmodningen skal konteres. e) Ydelsesindeks skal opdateres. f) Udbetalingen er bestilt uden tilvalg af print af udbetalingsspecifikation. - Der kan i visse tilfælde være behov for, at Brugeren kan bestille en udbetaling, der fx baseres på en beregning, som er foretaget for tidligere udbetalingsperioder. Det kan være i en sag, hvor der er kommet en afgørelse i en tilknyttet klagesag. - Se Krav# 44 om manuel igangsætning af beregning. - Se afsnit 6.4.3.7 om ØiR snitflade til udbetalings- og økonomisystemer. - Se afsnit 6.3.2.4 om Ydelsesindekset. Side 75 af 257
Når der effektueres, involverer det nedenstående elementer: Krav# 71: Massebestilling af udbetalinger Beskrivelse: Løsningen skal sikre bestilling af udbetaling, således at alle udbetalinger for alle bevilgede Ydelser i alle sager (massebestilling) automatisk sker i overensstemmelse med effektueringsplanen. Udbetalinger bestilles ved at aflevere udbetalingsanmodninger til økonomisystemet via ØiR snitflade. a) Løsningen skal anmode om udbetaling i alle sager, hvori der skal ske udbetaling i den aktuelle udbetalingsperiode. b) Udbetalingsanmodningerne skal indeholde tilstrækkelige oplysninger til, at udbetalingssystemet kan foretage udbetaling af det rigtige beløb i overensstemmelse med effektueringsplanen. c) Udbetalingsanmodningerne skal indeholde den rette information i henhold til de oplysninger, som er indberettet på effektueringsplanen i de enkelte sager. d) Alle beløb, der indgår i alle bestilte udbetalinger, skal konteres. e) Ydelsesindeks er opdateret for alle udbetalinger. f) Udbetalingen er bestilt uden tilvalg af print af udbetalingsspecifikation. - Se Krav# 192, Krav# 193 og Krav# 198 og kravene i afsnit 5.2.2, 5.2.3.2 og 5.3.3 vedrørende effektuering. - Se afsnit 5.2.4.2 vedrørende kontering. - Se afsnit 6.3.2.4 om Ydelsesindekset. - Se afsnit 6.4.3.7 om ØiR snitflade til udbetalings- og økonomisystem. Krav# 72: Bestil udbetaling hurtigst muligt Beskrivelse: Løsningen skal kunne bestille en udbetaling, der gennemføres hurtigst muligt, så den er til disposition samme eller næste bankdag. a) Hvis der er registreret udbetaling hurtigst muligt, skal Løsningen anmode om udbetaling, så den er til disposition hurtigst muligt, dvs. samme eller næste bankdag. b) Udbetalingsanmodningerne skal indeholde tilstrækkelige oplysninger til, at udbetalingssystemet kan udbetale hurtigst muligt. c) Udbetalingsanmodningerne skal indeholde den rette information i henhold til de oplysninger, som er indberettet på effektueringsplanen. d) Udbetalingsanmodningerne skal konteres. e) Ydelsesindeks skal opdateres. f) Udbetalingen er bestilt uden tilvalg af print af udbetalingsspecifikation. - Hensigten er, at udbetalingen sker samme eller næste bankdag, såfremt udbetalingssystemet og tilknyttede systemer, herunder sammenhæng med pengeinstitutter etc. tillader det. Side 76 af 257
- Se afsnit 5.2.4.2 vedrørende kontering. - Se afsnit 6.3.2.4 om Ydelsesindekset. - Se afsnit 6.4.3.7 om ØiR snitflade til udbetalings- og økonomisystemer. Krav# 73: Dan straksudbetalingsbilag Beskrivelse: Løsningen skal kunne danne et straksudbetalingsbilag, der kan udskrives lokalt. a) Løsningen skal kunne danne et straksudbetalingsbilag i forhold til de oplysninger, der er registreret i sagens effektueringsplan. b) Straksudbetalingsbilaget skal udskrives med oplysninger fra sagen, når Brugeren har valgt at udskrive bilaget lokalt. c) Straksudbetalingsbilaget skal konteres. d) Ydelsesindeks skal opdateres. - Straksudbetalingsbilaget er et alternativ til bestilling af udbetaling hurtigst muligt via udbetalingssystemet, og bruges, når en Person skal have udbetalt penge her og nu. - Se Krav# 137 vedrørende lokalt print. - Se afsnit 5.2.4.2 vedrørende kontering. - Se afsnit 6.3.2.4 om Ydelsesindekset. - Se afsnit 6.4.3.7 om ØiR snitflade til økonomisystem. Krav# 74: Bestil debitorbetaling Beskrivelse: Løsningen skal kunne bestille en betaling til en organisatorisk enhed inden for kommunen, som foretages via kommunens debitorsystem. a) Anmodninger om debitor-betaling skal indeholde tilstrækkelige oplysninger til, at debitorsystemet kan betale. b) Anmodninger om debitor-betaling skal indeholde den rette information i henhold til de oplysninger, som er indberettet på effektueringsplanen. c) Løsningen skal sikre, at alle nødvendige oplysninger er overført til et eksternt debitorsystem. d) Anmodninger om debitorbetaling skal konteres. - Dette er et alternativ til bestilling af udbetaling via udbetalingssystemet, såfremt betalingsmodtageren er en organisatorisk enhed i kommunen. Dette kan forekomme, fx hvis der foretages fradrag for betaling for dag- eller klubtilbud efter LAS 96. Her overføres pengene via kommunens debitorsystem. - Se afsnit 5.2.4.2 vedrørende kontering. - Se afsnit 6.4.3.7 om ØiR snitflade til debitor- og økonomisystemer. - Se informationsmodellen (KY-effektuering, Debitorbetaling) i underbilag 2.5. Side 77 af 257
Krav# 75: Udbetalingsspecifikation til Person Beskrivelse: Løsningen skal levere en udbetalingsspecifikation via Print på Serviceplatformen ved enhver udbetaling til en Person, der har fået bevilget en Ydelse. a) Løsningen kan afsende en udbetalingsspecifikation ved enhver bestilling af udbetaling til en Person. b) Udbetalingsspecifikationen skal indeholde oplysninger om bevilget Ydelse, tillæg og fradrag, herunder beløb anvendt til administration samt indeholdt ATP og A-skat mv. for den aktuelle udbetaling og for året til dato. c) Løsningen skal levere en udbetalingsspecifikation, selvom udbetalingen er på 0 kr., så Personen kan se, hvorfor han ikke har modtaget penge. - Se Krav# 71 og Krav# 72 vedrørende udbetalinger til Personer. - Se Krav# 352 vedrørende Print på Serviceplatformen. - Se informationsmodellen (KY-effektuering, Bevilling, Effektuering, Sanktionering, ATP + Skatteberegning) i underbilag 2.5. Krav# 76: Overførsel af oplysninger til indkomstregistret (eindkomst) Beskrivelse: Løsningen skal, når der udbetales skattepligtige Ydelser automatisk, overføre oplysninger pr. Person eller Alternativ Modtager til indkomstregistret (eindkomst). a) Løsningen skal aflevere de krævede oplysninger til indkomstregistret ved enhver udbetaling af skattepligtige Ydelser. b) Oplysningerne udgør Ydelser, bruttobeløb, indeholdt A-skat, AMB, ATP, B-skattepligtige beløb og øvrige obligatoriske oplysninger krævet af indkomstregistret. c) Oplysningerne skal indberettes under det korrekte SE-nummer. - Se Krav# 354 vedrørende snitflade til indkomstregistret (eindkomst). Krav# 77: Tilbagebetalingspligtigt beløb restanceføres i debitorsystem Beskrivelse: Løsningen skal restanceføre tilbagebetalingspligtige beløb i et eksternt debitorsystem. a) Tilbagebetalingspligtige beløb skal restanceføres samtidig med bestilling af udbetaling. b) Løsningen skal sikre, at kun beløb, som er godkendt af en Bruger, restanceføres. c) Løsningen skal sikre, at alle nødvendige oplysninger overføres til et eksternt debitorsystem. Side 78 af 257
- Se Krav# 69 og Krav# 70 vedrørende effektuering af udbetalinger. - Se afsnit 6.4.3.7 om ØiR snitflade til debitorsystem. Krav# 78: Betalingsmeddelelse til Alternativ Modtager Beskrivelse: Løsningen skal ved hver udbetaling til Alternativ Modtager aflevere oplysninger til en betalingsmeddelelse til udbetalingssystemet. a) Løsningen skal aflevere de nødvendige oplysninger for en betalingsmeddelelse til udbetalingssystemet ved enhver udbetaling til en Alternativ Modtager. b) Oplysningerne udgør beløb, hvem betalingen vedrører, årsagen til betalingen samt en valgfri tekst. - Betalingsmeddelelsen svarer til en betalingsmeddelelse fra Betalingsservice eller en linje på et kontoudtog fra et pengeinstitut. - Se informationsmodellen (KY-andre Ydelser, KY-enkeltydelser, Betalingsadministration) i underbilag 2.5. - Se Krav# 352 vedrørende Print på Serviceplatformen. - Se afsnit 6.4.3.7 om ØiR snitflade til udbetalingssystem. Krav# 79: Manuel godkendelse af udbetaling Beskrivelse: Det skal være muligt for Brugeren at godkende eller annullere en specifik udbetaling før den udbetales, såfremt det er angivet i effektueringsplanen, at der skal godkendes manuelt. a) Brugeren skal kunne godkende en specifik udbetaling, såfremt det er angivet i effektueringsplanen, at der skal godkendes manuelt. b) Brugeren skal kunne annullere en specifik udbetaling, såfremt det er angivet i effektueringsplanen, at der skal godkendes manuelt. c) Løsningen skal sikre, at udbetaling kun bestilles, såfremt den er godkendt. d) Udbetalingen skal gemmes som annulleret, hvis den er blevet annulleret af Brugeren. - Se Krav# 63 og Krav# 64 vedrørende angivelse af, at der skal godkendes manuelt. Krav# 80: Manuel registrering af regning Beskrivelse: Det skal være muligt for en Bruger i Løsningen at indberette en regning, der modtages papirbaseret. Side 79 af 257
a) Brugeren skal kunne indberette de nødvendige oplysninger om en regning, herunder kreditoroplysninger, betalingsidentifikation, betalingsdato, beløb. b) Brugeren skal kunne tilknytte regningen til en effektueringsplan i en ydelsessag eller til en betalingsaftale i en administrationssag. c) Løsningen skal sikre, at der er registreret tilstrækkelige oplysninger til, at regningen kan betales - Se Krav# 82 vedrørende godkendelse og betaling af regning. Krav# 81: Automatisk registrering af regning Beskrivelse: Løsningen skal automatisk registrere en regning, der modtages elektronisk. a) Alle regninger, der modtages elektronisk via snitflade skal registreres i Løsningen. b) Alle regninger skal tilknyttes den ydelsessag eller administrationssag, som regningen vedrører. c) Alle bilag, der modtages sammen med en regning, skal tilknyttes sagen som dokumenter. d) Efter registrering af regningen skal Brugeren have adgang til at behandle den i Løsningen. - Disse regninger modtages som e-fakturaer via kommunens NemHandelsløsning. - Se Krav# 82 vedrørende godkendelse og betaling af regning. - Se afsnit 6.4.2.3 vedrørende snitflade til automatisk modtagelse af regning. Krav# 82: Godkendelse af regning Beskrivelse: Brugeren skal i Løsningen kunne godkende eller afvise en regning modtaget fra en ekstern part. a) Brugeren har adgang til at godkende eller afvise en regning, inden den betales. b) Løsningen skal sikre, at regningen kun betales, hvis den er godkendt. c) Løsningen skal for en godkendt regning overføre de nødvendige oplysninger til udbetalingssystemet, så betaling kan ske i henhold til regningen. d) Løsningen skal sikre, at en godkendt regning konteres i, og at de nødvendige oplysninger overføres til et eksternt økonomisystem så der kan ske bogføring. - Se Krav# 80 vedrørende manuel registrering af regning. - Se Krav# 81 vedrørende automatisk registrering af regning. - Se afsnit 6.4.3.7 om ØiR snitflade til udbetalings- og økonomisystemer. Side 80 af 257
- Se afsnit 5.2.4.2 vedrørende kontering. 5.2.4.2 Kontering Løsningen understøtter gennem korrekt kontering, dvs. indføring af beløb på en konto i Løsningen, at kommunens økonomistyring, herunder regnskabsaflæggelse og håndtering af statsrefusion mv. sker på et korrekt grundlag for de Ydelser, som håndteres i Løsningen. Konteringen skaber grundlaget for, at Løsningen kan overføre oplysninger til et eksternt økonomisystem, hvor bogføringen i kommunens regnskab sker. Dette vedrører alle sager om forsørgelsesydelser, enkeltydelser og Andre Ydelser samt administrationssager. Eksempelvis skal beløb, som udbetales i kontanthjælp, konteres forskelligt afhængig af den type af aktivering, som Personen deltager i, og om Personen har haft sammenhængende fravær i en given periode. Løsningen skal derfor kunne kontere udbetalinger mv. i henhold til kommunens kontoplan og Lovgivning om eksempelvis statsrefusion samt kommunens eventuelle opdeling i administrative enheder og distrikter. Selve bogføringen sker i kommunens økonomisystem, som Løsningen derfor skal have snitflader til (6.4.4.7 Økonomi). I underbilag 2.22 (Kontering) beskrives informationsgrundlaget for at mappe fra sagsoplysninger i Løsningen til oplysninger, der overføres til økonomisystemet. Der er i nogle tilfælde behov for, at Løsningen kan foretage omkontering, hvis der med tilbagevirkende kraft ændres i oplysninger, som har ligget til grund for beregning og kontering. Eksempelvis kan det på et senere tidspunkt blive oplyst fra Jobcentret, at en Person, som modtager kontanthjælp, i en periode har deltaget i en anden type aktivering, end det har været oplyst på udbetalingstidspunktet. I dette tilfælde skal ændringen påvirke konteringen med tilbagevirkende kraft, men ikke påvirke udbetalinger til Personen. Når der bevilges en Ydelse, afgøres det, om Ydelsen undtagelsesvist er med tilbagebetalingspligt. Der kan være tale om beløb, der af Brugeren markeres som tilbagebetalingspligtigt. Det kan også være beløb, som Løsningen automatisk konstaterer, er tilbagebetalingspligtige, eksempelvis som følge af en sanktion. Eksempelvis kan Brugeren efter konkret individuel vurdering bevilge et beløb som løbende Ydelse eller enkeltydelse, som Personen skal betale tilbage. Det kan eventuelt også på et senere tidspunkt konstateres, at et beløb er tilbagebetalingspligtigt. Beløb, som er tilbagebetalingspligtige, konteres på særlige konti og der overføres oplysninger til et debitorsystem, således at beløbene kan restanceføres korrekt. Krav# 83: Korrekt kontering Beskrivelse: Løsningen skal ud fra sagens oplysninger kontere alle beløb i overensstemmmelse med Lovgivningen, de kontoplaner og de konteringsregler, som er konfigureret i Løsningen. a) Alle beløb skal konteres i overensstemmelse med Lovgivningen samt de kontoplaner og konteringsregler, som er konfigureret i Løsningen. b) Alle personrelaterede beløb skal henføres til den rette Person. c) Dette gælder også i tilfælde, hvor det samlede beløb, der udbetales, er en sum af flere beløb, der skal konteres forskelligt. d) Dette gælder også for tilbagebetalingspligtige beløb. e) Dette gælder også ved effektuering af administrationsordninger. Side 81 af 257
f) Løsningen skal sikre, at de nødvendige oplysninger overføres til økonomisystem for alle konteringer, således at der kan bogføres. - Eksempler på beløb, som skal konteres og overføres til bogføring i et eksternt økonomisystem, inkluderer: o Bruttobeløb på bevilgede Ydelser o Beløb til udbetaling (udbetales til Personen, til Alternativ Modtager eller overføres til en anden enhed i kommunen) o Fradrag for sanktioner o Fradrag for forskudsudlagt børnebidrag o ATP (både Persons og kommunens andel), AMB, A-skat o Beløb trukket til administration af Persons økonomi o Individuelle tillæg/fradrag o Tilbagebetalingspligtige beløb - Der er også tilfælde, hvor det samlede beløb, der udbetales, er en sum af flere beløb, der skal konteres forskelligt. Eksempelvis hvis en del af en bevilget Ydelse er tilbagebetalingspligtig. - Se Krav# 195 og Krav# 197 vedrørende konfigurering af konteringsregler. - Se Krav# 85 vedrørende tilbagebetalingspligtige beløb. - Se Krav# 109 vedrørende effektuering af administrationsordninger. - Selve bogføringen sker i et eksternt økonomisystem ud fra oplysninger, der overføres fra Løsningen på tidspunktet for bestilling af udbetaling eller debitor-betaling (se 6.4.3.7). - Se informationsmodellen (KY-bevilling, KY-effektuering, KY-kontaktforløb, KY-kontering, Ydelseskatalog, Beslutningsgrundlag, Beregningsgrundlag, Bevilling, Sanktionering, ATP + Skatteberegning) i underbilag 2.5. - Se underbilag 2.8 vedrørende relevant faglovgivning. - Se afsnit 6.6.4, 6.6.5 og 6.6.6 vedrørende Lovgivningen omkring bogføring og statsrefusion. Krav# 84: Korrekt kontering med tilbagevirkende kraft Beskrivelse: Løsningen skal automatisk konsekvensberegne og foretage omkontering af de nødvendige beløb, hvis der med tilbagevirkende kraft ændres i oplysninger i sagen, som har indflydelse på kontering. a) Alle konsekvenser af ændringer i sagens oplysninger med tilbagevirkende kraft skal beregnes og konteres i henhold til Lovgivningen samt de kontoplaner og konteringsregler, som er konfigureret i Løsningen. b) Dette gælder også i tilfælde, hvor det samlede beløb, der udbetales, er en sum af flere beløb, der skal konteres forskelligt. c) Dette gælder også for tilbagebetalingspligtige beløb. d) Løsningen skal sikre, at de nødvendige oplysninger overføres til økonomisystem korrekt og rettidigt, således at der kan bogføres. Side 82 af 257
e) Løsningen skal kun kontere med tilbagevirkende kraft i indeværende og forrige år, og kun såfremt der ikke er låst for dette jf. Krav# 115. f) Løsningen skal kun kontere med tilbagevirkende kraft tilbage til det tidspunkt hvor kommunen har taget Løsningen i brug. - Se Krav# 85 vedrørende tilbagebetalingspligtige beløb. - Se afsnit 6.4.3.7 om snitflade til økonomisystemet. - Se underbilag 2.8 vedrørende relevant faglovgivning. - Se afsnit 6.6.4, 6.6.5 og 6.6.6 vedrørende lovgivningen omkring bogføring og statsrefusion. Krav# 85: Kontering af tilbagebetalingspligtige beløb Beskrivelse: Løsningen skal kontere tilbagebetalingspligtige beløb. a) Alle tilbagebetalingspligtige beløb skal konteres i overensstemmelse med Lovgivningen samt de kontoplaner og konteringsregler, som er konfigureret i Løsningen. b) Dette gælder også i tilfælde, hvor det samlede beløb, der udbetales, er en sum af flere beløb, hvoraf kun nogle er tilbagebetalingspligtige. c) Dette gælder også for beløb, der af Brugeren er markeret som tilbagebetalingspligtige. d) Dette gælder også for beløb, som Løsningen automatisk konstaterer, er tilbagebetalingspligtige. e) Et tilbagebetalingspligtigt beløb, som Løsningen automatisk har konstateret, skal kun konteres som sådan, hvis det er godkendt af Brugeren ved at vælge hjemmel (paragraf mv.) ved afgørelsen. I modsat fald konteres det ikke som tilbagebetalingspligtigt. f) Løsningen skal sikre, at de nødvendige oplysninger overføres til eksternt økonomisystem, således at der kan bogføres. g) Brugeren skal kunne vælge, at Personen ikke ønsker at få udbetalt den tilbagebetalingspligtige del af det bevilgede beløb til særlig støtte jf LAS 34. - Der kan være tale om beløb, der af Brugeren markeres som tilbagebetalingspligtigt. Det kan også være beløb, som Løsningen automatisk konstaterer, er tilbagebetalingspligtige, eksempelvis som følge af en sanktion. Brugeren skal kunne godkende eller afvise tilbagebetalingspligten. - Et andet eksempel på kontering af tilbagebetalingspligtige beløb er ved bevilling af særlig støtte efter LAS 34, hvor begge Ægtefæller under visse betingelser hæfter solidarisk for den del, der er ydet til dækning af renter og afdrag vedrørende ejerboliger og andelsboliger. Dette håndteres ved særskilt kontering af sådanne beløb (jf. LAS 92 stk. 1-3). - Se Krav# 49 vedrørende konsekvenser af sanktioner. - Se Krav# 83 og Krav# 84 vedrørende kontering. Side 83 af 257
- Se Krav# 87 om markering af tilbagebetalingspligtigt beløb. - Se Krav# 10 vedrørende automatisk oprettelse af Opgave. - Se afsnit 6.4.3.7 vedrørende snitflade til eksternt økonomisystem. - Se underbilag 2.8 vedrørende relevant faglovgivning. - Se afsnit 6.6.4, 6.6.5 og 6.6.6 vedrørende Lovgivningen omkring bogføring og statsrefusion. Krav# 86: Manuel kontering Beskrivelse: Det skal være muligt for Brugeren at kunne foretage en manuel kontering på en sag. a) Brugeren skal kunne indberette de oplysninger, som er nødvendige for, at Løsningen kan foretage kontering a) Løsningen skal kontere og sikre, at de nødvendige oplysninger overføres til eksternt økonomisystem, så der kan bogføres - Som hovedregel foretager Løsningen al kontering på baggrund af de oplysninger, som er registreret i sagen, men der kan være behov for at kunne foretage konteringer manuelt, eksempelvis ved fraflytning fra kommunen eller dødsfald. - Eksempelvis i en sag, hvor kommunen Bruger Løsningen til at administrere en Persons pension, kan der være behov for at kunne registrere det pensionsbeløb, som er overført fra UDK til kommunen, såfremt det ikke er sket automatisk. - Se eventuelt informationsmodellen (KY-kontering, Ydelseskatalog, Bevilling, Effektuering) i underbilag 2.5. - Se afsnit 6.4.3.7 vedrørende ØiR snitflade til eksternt økonomisystem. - Se underbilag 2.8 vedrørende relevant faglovgivning. - Se afsnit 6.6.4, 6.6.5 og 6.6.6 vedrørende Lovgivningen omkring bogføring og statsrefusion. Krav# 87: Markering af tilbagebetalingspligtigt beløb Beskrivelse: Det skal være muligt for Brugeren at markere, at et beløb, som skal udbetales, er tilbagebetalingspligtigt, således at beløbet konteres i henhold hertil. a) En Bruger skal kunne markere et beløb som tilbagebetalingspligtigt før udbetalingstidspunktet. b) En Bruger skal kunne markere et beløb som tilbagebetalingspligtigt på et senere tidspunkt. Gyldigheden er begrænset til indeværende og forrige år, dog ikke tidligere end det tidspunkt hvor kommunen har taget Løsningen i brug. Løsningen skal i dette tilfælde sikre, at beløbet om nødvendigt omkonteres med tilbagevirkende kraft. Side 84 af 257
c) En Bruger skal kunne markere et tilbagebetalingspligtigt beløb som værende ikke-tilbagebetalingspligtigt på et senere tidspunkt. Gyldigheden er begrænset til indeværende og forrige år, dog ikke tidligere end ibrugtagningstidspunktet. Løsningen skal i dette tilfælde sikre, at beløbet om nødvendigt omkonteres med tilbagevirkende kraft. d) Løsningen skal sikre, at Brugeren angiver en årsag: lov, paragraf, stk., nr. e) Brugeren skal kunne godkende, om beløbet skal restanceføres i debitorsystemet. Løsningen skal gemme denne oplysning på effektueringsplan i sagen. - Se Krav# 85 vedrørende kontering af tilbagebetalingspligtig Ydelse. - Se Krav# 84 vedrørende kontering med tilbagevirkende kraft. - Se eventuelt informationsmodellen (Bevilling) i underbilag 2.5. - Se afsnit 6.4.3.7 vedrørende snitflade til eksternt økonomisystem. - Se underbilag 2.8 vedrørende relevant faglovgivning. - Se afsnit 6.6.4, 6.6.5 og 6.6.6 vedrørende Lovgivningen omkring bogføring og statsrefusion. 5.2.4.3 Afsnittet udgår Krav# 88: Kravet udgår Kategori: Beskrivelse: Krav# 89: Kravet udgår Kategori: Beskrivelse: Krav# 90: Kravet udgår Kategori: Beskrivelse: Type: Type: Type: 5.2.4.4 Effektuering på baggrund af inddata fra Jobcenterløsning I sager om de Andre Ydelser, som bevilges af Jobcentret og effektueres i Ydelsescentret, eksempelvis Godtgørelse til udgifter ved deltagelse i tilbud efter LAB 82 og 83, registreres der oplysninger i Løsningen, som danner udgangspunkt for effektuering og senere afslutning af sagen. I disse tilfælde skal den bevilgede Ydelse kunne effektueres automatisk uden Ydelsescentrets involvering. Side 85 af 257
Krav# 91: Automatisk effektuering af sag ud fra information fra Jobcenterløsning Beskrivelse: Løsningen skal automatisk kunne foretage effektuering og udbetaling af Ydelser udelukkende på baggrund af oplysninger, som er overført fra en Jobcenterløsning. a) Løsningen skal effektuere udbetalingen i henhold til Lovgivningen ud fra oplysninger, der modtages fra Jobcenterløsningen om bevilling af Ydelser, således at der kan konteres, udbetales og bogføres. b) Løsningen skal sikre, at der effektueres for alle bevillinger, der vedrører Ydelser, hvor det er centralt konfigureret på Ydelsen, at der kan bevilges på denne måde. c) Løsningen skal sikre, at der kun kan effektueres for bevillinger, der vedrører Ydelser, hvor det er centralt konfigureret på Ydelsen, at der kan bevilges på denne måde. d) Løsningen skal sikre, at effektuering og udbetaling kun foretages, hvis beløbet er mindre end det maksimale beløb for Godtgørelse, som er konfigureret i Løsningen. e) Løsningen skal sikre, at beløbet periodiseres i forhold til start- og slutdato for Godtgørelsen, hvis dette er angivet i oplysningerne fra Jobcentret. - Se Krav# 68 vedrørende oprettelse af sag ud fra oplysninger fra Jobcenterløsning. - Se Krav# 204 vedrørende konfigurering af maksimalt beløb. - Se Krav# 260 vedrørende Godtgørelse fra Jobcentret. - Se informationsmodellen (KY-Sag, KY-effektuering, Beslutningsgrundlag, Beregningsgrundlag, Ydelseskatalog, Bevilling, Effektuering, KY-Kontaktforløb) i underbilag 2.5. - Se underbilag 2.8 vedrørende relevant faglovgivning. 5.2.5 Vedligeholdelse af sag Mange sager kan løbe over længere perioder, hvor der fx sker udbetalinger hver måned. Ofte vil sagsbehandleren ikke gå ind på sagen hver måned. Sagerne og dertil hørende udbetalinger vil således køre automatisk måned efter måned. Men forskellige Hændelser og interne regler kan medføre, at der er behov for, at enten sagsbehandleren eller Løsningen vedligeholder sagen. Når det er sagsbehandleren, der vedligeholder sagen, betyder det, at Løsningen opretter en Opgave til sagsbehandleren, som sagsbehandleren derefter løser (beskrevet i afsnit 5.1). Løsningen kan også vedligeholde sagen uden sagsbehandlerens indblanding. Kravene til disse automatiske reaktioner beskrives i dette afsnit. Side 86 af 257
Nogle gange vil vedligeholdelse af sagen således blot betyde, at Løsningen opretter en Opgave til sagsbehandleren. I andre tilfælde kan Løsningen reagere automatisk på de nye oplysninger og foretage automatiske handlinger. Det kan også være en kombination af de to. Et eksempel kan være, at en Person er død. Denne Hændelse bliver Løsningen bekendt med via en CPR-Besked. I dette tilfælde stoppes udbetalingen automatisk, når CPR-Beskeden modtages. Der oprettes derefter en Opgave til sagsbehandleren, hvorefter sagsbehandleren færdigbehandler Opgaven. Der kan være flere kilder til, at vedligeholdelsen af sagen påbegyndes. A. Ved modtagelse af Beskeder fra andre it-systemer (fx via Beskedfordeleren beskrevet i afsnit 6.3.2.5). B. Ved modtagelse af dokumenter fra andre it-systemer (via Dokumentfordeleren beskrevet i afsnit 6.3.2.2). C. Ved interne regler i Løsningen. D. Via andre kanaler (fx e-mail, personlige henvendelser, telefonopkald osv.). I underbilag 2.13 ses en liste over de relevante Hændelser, der kan indtræffe, som Løsningen skal kunne danne og reagere på. Denne liste indeholder både Hændelser udefra (A+B) og interne regler (C). For hver Hændelse er der i underbilaget beskrevet, hvordan Løsningen skal reagere på Hændelsen. Disse Hændelser skal gemmes og vises i sagshistorikken. En Hændelse kan påvirke enkelte eller flere af en Persons sager i Løsningen. Krav# 92: Dan og reager på Hændelse Beskrivelse: Løsningen skal automatisk kunne danne Hændelser på grundlag af oplysninger, der modtages eller hentes via snitflader til andre it-løsninger eller allerede findes i Løsningen og efterfølgende reagere på Hændelserne. a) Løsningen skal kunne modtage eller hente og gemme oplysninger fra en it-løsning og på grundlag af dette danne en Hændelse og udføre de handlinger, der er angivet i underbilag 2.13. b) Løsningen skal kunne danne en Hændelse på grundlag af en intern regel i Løsningen og udføre den handling, der er angivet i underbilag 2.13. c) Løsningen skal for hver Hændelse kun reagere på de Ydelsesarter, der er noteret i underbilag 2.13 d) Løsningen skal vise Hændelsen i sagshistorikken med en betegnelse, der er forståelig for Brugeren. e) Hændelserne i underbilag 2.13 skal registreres i Løsningen f) Hændelser skal registreres med samme metadata som journalnotater. g) Hvis Hændelsen er dannet på grundlag af en Besked, der er modtaget i Løsningen via Beskedfordeleren, registreres Hændelsen som udgangspunkt med det dataindhold, Beskeden indeholder. - I forhold til punkt c, så menes der, at det kun er de Ydelser, der er noteret i kolonnen Hvilke Ydelser er Hændelsen relevant for, hvor de automatiske Side 87 af 257
reaktioner skal træde i kraft. Fx er Hændelsen kontaktforløb ændret kun relevant for forsørgelsesydelser og skal dermed ikke træde i kraft ved enkeltydelser. - Se oversigt over ind- og udgående Hændelser i underbilag 2.13. - Se Krav# 127 om journalnotat. - Se Krav# 170 om visning af sagshistorik. - Se Krav# 185 vedrørende den kommunale administrators mulighed for at konfigurere hvordan Løsningen reagerer på de forskellige Hændelser. - Se Krav# 190 og Krav# 191 vedrørende administrators mulighed for at konfigurere interne regler. - Se Krav# 20 vedrørende oprettelse af sag. - Se Krav# 10 vedrørende oprettelse af en Opgave. - Se Krav# 26 vedrørende opdatering af sagsinformation via opslag i eksterne registre. - Se Krav# 94 vedrørende opdatering af sagsoplysninger fra selvbetjeningsløsningen. - Se Krav# 352 vedrørende Print på Serviceplatformen. Krav# 93: Omdannelse fra Besked til Opgave Beskrivelse: Når Løsningen modtager en Besked, vil der ofte skulle dannes en Opgave til Brugeren. a) Ved Opgaver oprettet på baggrund af en Besked, skal Beskeden omdannes til en for Brugeren forståelig opgavetype samt opgavebeskrivelse. b) Løsningen skal sikre, at der ikke går informationer tabt fra omdannelse af en Besked til en Opgave. 5.2.5.1 Opdatering af sagsoplysninger fra selvbetjeningsløsningen Ved benyttelse af selvbetjeningsløsningen (se afsnit 5.8) modtager Løsningen data på struktureret form og alle data skal kunne overføres til sagen direkte. Dette gælder både i ansøgningsøjeblikket og ved vedligeholdelse af sagen. Krav# 94: Opdatering af sagsoplysninger fra selvbetjeningsløsningen Beskrivelse: Når der modtages sagsinformation i Løsningen via selvbetjeningsløsningen, overføres disse automatisk til sagen. Dette gælder både ved ansøgningstidspunktet og ved vedligeholdelse af sagen. - Data fra selvbetjeningsløsningen vil typisk være ansøgninger, men kan også være Personens opdateringer af sagsdata fra Min Sag. Dette er særligt Side 88 af 257
relevant i forbindelse med modtagelse af en ansøgning, hvor fx alle ansøgningsdata skal overføres (jf. Krav# 20). - Se afsnit 5.8 og 6.4.2.4 vedrørende selvbetjening. - Se informationsmodellen (KY-dokument, KY-sag, Oplys sag, Beslutningsgrundlag, Beregningsgrundlag, Ydelseskatalog) i underbilag 2.5. 5.2.5.2 Opdatering af metadata på sagen En sag, som behandles i Løsningen, vedrører én specifik Person (primær part), som har ansøgt om eller er blevet indstillet til en Ydelse. Dertil kan der være en eller flere yderligere parter, som skal tilknyttes sagen af hensyn til fx beregninger (eksempelvis Ægtefælle og børn). Dette kan gøres både i forbindelse med oprettelse af sagen og i forbindelse med vedligeholdelse af sagen. Krav# 95: Tilknytning af yderligere Personer til sag Beskrivelse: Brugeren skal kunne knytte og fjerne relation mellem sagen og relevante Personer (parter). Der skal være en entydig relation mellem sagen og de tilknyttede parter, så deres relationer i sagen er klar. a) Brugeren kan knytte og fjerne relationer mellem en sag og en part. b) Hvis relationen til en part fjernes, og parten ikke har/får egen sag i Løsningen, skal abonnementet på parten fjernes i Beskedfordeleren, CPR og SKAT. c) Brugeren kan vælge typen af relation, når parten tilknyttes. d) Det er muligt at tilknytte en partsrepræsentant. - Bemærk desuden at Ægtefællen til en Person, der ansøger om uddannelseshjælp eller kontanthjælp, som udgangspunkt også vil modtage hjælp. Der er således en relation mellem en sag om uddannelseshjælp eller kontanthjælp og begge Ægtefæller. - Se informationsmodellen (KY-Sag). - Se afsnit 6.3.2.5 vedrørende Beskedfordeleren. - Se afsnit 6.4.3.2 vedrørende snitflade til CPR. - Se afsnit 6.4.3.5 vedrørende snitflade til SKAT. I de kommuner, hvor der er en fast sagsbehandler knyttet til sagen, kan der være behov for at overflytte hele sagen til en anden sagsbehandler. Det kan fx være pga. en dårlig relation mellem sagsbehandleren og Personen. Det skal derfor være muligt at ændre den primære sagsbehandler på en enkelt sag. Det kan derefter betyde, at fx alle Opgaver på denne sag vil blive fordelt til den nye sagsbehandler i stedet. Krav# 96: Ændring af primær sagsbehandler Beskrivelse: Det er muligt for Brugeren at ændre den primære sagsbehandler på en enkelt sag. Side 89 af 257
- Se Krav# 216 vedrørende den kommunale administrators mulighed for at flytte en hel sagsstamme. - Se informationsmodellen (KY-Sag). 5.2.6 Afslut sag En sag afsluttes efter det er besluttet, at Personen ikke skal modtage nogen Ydelse (længere). Der kan være flere årsager til at afslutte en sag og det kan ske under forskellige faser i en sag. Det kan fx være pga. et afslag på ansøgningen; det kan være, at forholdene i en aktiv sag har ændret sig, så der ikke længere er grundlag for, at Personen modtager Ydelsen, eller det kan være, at Ydelsen er færdigudbetalt som fx ved enkeltydelser. Selve beslutningen om at afslutte sagen foregår i aktiviteten 5.2.3 Træf afgørelse, og det forventes ikke, at Brugeren skal gøre noget aktivt i forbindelse med at afslutte sagen. Bemærk for sager vedrørende uddannelseshjælp eller kontanthjælp, hvor Personens Ægtefælle er tilknyttet som sekundær part, kan være behov for at oprette en særskilt sag for Ægtefællen i de tilfælde, hvor Ægtefællen selv er omfattet af ændringskravet og dermed kan være berettiget til uddannelseshjælp eller kontanthjælp efter, at Personens sag er afsluttet. Når en sag er afsluttet, kan der som udgangspunkt ikke længere redigeres eller tilføjes informationer til sagen, ligesom Løsningen ikke længere vil modtage Beskeder vedrørende den givne sag (det er dog muligt at genåbne en lukket sag). Det er stadig muligt at omkontere samt ændre tidligere udbetalte Ydelser til tilbagebetalingspligtig hjælp. I dag er der ikke lovgivningsmæssigt krav til, at Løsningen skal arkivere, da de sager, der behandles i Løsningen, ikke i sig selv ikke er bevaringsværdige. De oplysninger der skal bevares om kontanthjælp mm., modtager Statens Arkiver fra Danmarks Statistik og Styrelsen for Arbejdsmarked og Rekruttering. Krav# 97: Afslut sag Beskrivelse: Løsningen skal kunne afslutte en sag enten på grundlag af en Brugers ønske om at afslutte sagen eller på grundlag af en Hændelse om manglende dokumentation på ansøgning indsendt via selvbetjeningsløsningen. a) Løsningen ændrer status på sagen, så det fremgår at sagen er afsluttet. b) Løsningen gemmer sagen med den kassationskode, der blev sat ved afslutning af sagen. c) Hvis Personen ikke har andre igangværende sager i Løsningen, opdaterer Løsningen abonnementet i Beskedfordeleren samt abonnementer vedrørende skat og CPR med fjernelse af Personens CPR-nummer. d) Løsningen registrerer afslutningen af sagen i sagshistorikken Side 90 af 257
e) Løsningen opdaterer Sags- og Dokumentindeks og sikrer at andre it-løsninger kan blive orienteret om hændelsen.. f) Løsningen opdaterer bevillingen hos Jobcentret - Se afsnit 5.4.4 vedrørende Status og låsning af sager og Opgaver. - Se hændelseslisten i underbilag 2.13 for udgående Beskeder til Beskedfordeleren. - Se hændelseslisten i underbilag 2.13 for beskrivelse af automatisk afslutning af sagen. - Se afsnit 6.3.2.1 vedrørende Klassifikation. - Se afsnit 6.3.2.3 vedrørende Sags- og Dokumentindeks. - Se afsnit 6.3.2.5 vedrørende Beskedfordeler. - Se afsnit 6.4.3.2 vedrørende snitflade til CPR. - Se afsnit 6.4.3.5 vedrørende snitflade til SKAT. - Jf. OIO standarderne for Sag eller tilsvarende i forhold til mulige kassationskoder og frister. Se afsnit 7 for referencer til OIO_SAG. - Se Krav# 265 om Besked til Jobcentret om bevilling. - Se Krav# 352 vedrørende Print på Serviceplatformen. Krav# 98: Opdatering af afsluttede sager Beskrivelse: Når en sag er afsluttet, kan den opdateres i begrænset omfang. a) Der kan tilføjes journalnotater til sagen efter denne er afsluttet. - Se Krav# 99 vedrørende genåbning af sag. - Se Krav# 145vedrørende mulighed for at overføre en kopi af den afsluttede sag til en anden kommune. Selvom der er truffet afgørelse om et afslag eller bevilling er ophørt og sagen er afsluttet, kan der til tider være behov for at genåbne sagen. Det kan fx være i tilfælde af, at kontaktforløbet genoptages i Jobcentret eller i tilfælde af, at Personen klager over afgørelsen og får medhold. Krav# 99: Genoptag sag Beskrivelse: Brugeren skal kunne genoptage en afsluttet sag. Der kan derefter arbejdes videre med sagen som en igangværende sag. a) Brugeren kan genoptage en sag. b) Hvis sagen er genoptaget på en Person, der ikke har andre igangværende sager i Løsningen, opdaterer Løsningen abonnementet i Beskedfordeleren samt abonnementer vedrørende skat og CPR med Personens CPR-nummer. c) Løsningen opdaterer status på sagen. Side 91 af 257
d) Løsningen registrerer en Hændelse Løsningen opdaterer Sags- og Dokumentindeks og sikrer at andre it-løsninger kan blive orienteret om hændelsen.. - Se afsnit 5.4.4 vedrørende status på sager. - Se hændelseslisten i underbilag 2.13 for udgående Beskeder til Beskedfordeleren. - Se afsnit 6.3.2.3 vedrørende Sags- og Dokumentindeks. - Se afsnit 6.3.2.5 vedrørende Beskedfordeler. - Se afsnit 6.4.3.2 vedrørende snitflade til CPR. - Se afsnit 6.4.3.5 vedrørende snitflade til SKAT. Når en sag er lukket, sættes der en kassationsfrist for, hvornår sagen skal slettes. Med slettes menes en fysisk sletning i databasen, således at sagen ikke kan genfindes, og der bør ikke være noget spor efter sagen, når den er blevet slettet. For at undgå en katastrofe, hvor sager fx ved en fejl bliver slettet permanent, forestiller Kunden sig, at der indføres et mellemlag, hvor kun en Bruger med den særlige rolle Sagskassations Administrator (jf. afsnit 6.7.4 for beskrivelse af roller) i en begrænset periode kan genfinde de slettemarkerede sager. Det ekstra mellemlag er således kun en intern tilstand, inden sagen slettes endegyldigt, så en slettemarkeret sag skal fremgå som slettet for eksterne systemer. Figur 11 viser, hvordan dette mellemlag er tænkt. I stedet for at slette sagen direkte, når kassationsfristen udløber, så slettemarkeres sagen. På samme måde kan den kommunale administrator også slettemarkere fejloprettede sager, før kassationsfristen udløber (jf. Krav# 215). Når en sag er slettemarkeret, har de kommunale Brugere ikke længere adgang til sagerne. Men Brugeren med den særlige rolle Sagskassations Administrator vil stadig kunne fremsøge en slettemarkeret sag og eventuelt genskabe sagen. Efter den fastsatte dato vil den slettemarkerede sag så endegyldigt slettes, så heller ikke Brugeren med den særlige rolle Sagskassations Administrator vil kunne genfinde sagen. Side 92 af 257
Sag Åben Kommunal bruger kan fremsøge sag [Sagsbehandler lukker sagen. Kassationsfrist er sat] Sag Lukket [Kommunal administrator slettemarkerer sag manuelt] [Kassationsfristen udløber og sagen slettemarkeres automatisk] Sag kan kun fremsøges, hvis brugeren har rollen Sagskassations Administrator Sag Slettemarkeret Sag Slettemarkeret [1 år efter slettemarkeringsdatoen slettes sag automatisk] Sag er fysisk slettet [4 år efter lukket-dato slettes sag automatisk] Sag Slettet Krav# 100: Automatisk slettemarkering af sager Figur 11: Sagstilstande i forbindelse med sletning Beskrivelse: Løsningen skal automatisk slettemarkere lukkede sager, når kassationsfristen udløber. a) Løsningen slettemarkerer lukkede sager, når kassationsfristen udløber. b) Løsningen opdaterer Sags- og Dokumentindeks og Ydelsesindeks om sletning af sagen og sikrer at andre it-løsninger kan blive orienteret om hændelsen.. c) - Vær opmærksom på at i forhold til eksterne systemer er sagen slettet ved en slettemarkering. Slettemarkeringen er kun en intern tilstand. - Se Krav# 215 for administrators mulighed for at slettemarkere sager manuelt. - Jf. OIO standarderne eller tilsvarende for Sag i forhold til mulige kassationskoder og frister, Se afsnit 7 for referencer til OIO_SAG. - Se afsnit 6.3.2.3 vedrørende Sags- og Dokumentindeks. - Se hændelseslisten i underbilag 2.13 for udgående Beskeder til Beskedfordeleren. - Se afsnit 6.3.2.4 vedrørende Ydelsesindeks. - Se afsnit 6.3.2.5 vedrørende Beskedfordeler. Side 93 af 257
- Se afsnit 6.7.4 vedrørende roller. Krav# 101: Fremsøgning og genskabelse af slettemarkerede sager Beskrivelse: Løsningen skal give en Bruger mulighed for at fremsøge og genskabe slettemarkerede sager. - Se afsnit 6.7.4 vedrørende roller. Krav# 102: Automatisk sletning af sager Beskrivelse: Løsningen skal automatisk slette de slettemarkerede sager i Løsningen og de korresponderende sager i selvbetjeningsløsningen. a) Løsningen sletter de slettemarkerede sager, efter de har haft tilstanden slettemarkeret i et år. b) I det tilfælde, hvor en sag er blevet slettemarkeret manuelt af en Kommunal administrator, skal der minimum være gået 4 år, efter sagen blev lukket af Brugeren, inden den slettemarkerede sag kan slettes. c) Det må ikke være muligt at genfinde sagen på nogen vis, dvs. at en sletning her stiller krav til en fysisk sletning. - Årsagen til punkt b) er, at hvis en Kommunal administrator sletter en sag inden kassationsfristens udløb, kan det risikeres at slette sagen endegyldigt inden den egentlige kassationsfrist. Derfor sættes en grænse på 4 år (som sikrer, at sagen tidligst slettes 3 år efter indeværende år). - Se Krav# 215 for Kommunal administrators mulighed for at slettemarkere sager manuelt. - Jf. OIO standarderne for Sag eller tilsvarende i forhold til mulige kassationskoder og frister. Se afsnit 7 for referencer til OIO_SAG. Administration af Persons økonomi Når en Person modtager forsørgelsesydelse eller pension, kan der opstå et behov for, at Ydelsescentret administrerer en del af Personens økonomi. Kommunen kan med hjemmel i Aktivloven eller pensionslovene træffe afgørelse om at foretage betaling af eksempelvis husleje, el og varme på Personens vegne eksempelvis, hvis Personen har misligholdt sine huslejebetalinger eller hvis det skønnes, at Personen ikke kan administrere kontanter. Det er også muligt for kommunen at administrere Personens økonomi i større eller mindre omfang på baggrund af en frivillig aftale med denne. Dette medfører typisk, at Ydelsescentret, inden Ydelsen udbetales til Personen, betaler en eller flere af Personens faste udgifter og eventuelt også, at Ydelsen udbetales til Personen i flere rater i løbet af en udbetalingsperiode. Side 94 af 257
Der etableres en selvstændig sag ( administrationssag ), som knyttes til en ydelsessag. Administrationssagen gennemgår de samme hovedtrin som ydelsessagerne, dvs., sagen oplyses, der træffes afgørelse eller indgås en frivillig aftale. Såfremt der iværksættes administration, etableres som en del af administrationssagen en administrationsordning, der kan sammenlignes med en budgetkonto med tilhørende betalingsservice. Til administrationsordningen tilknyttes via en administrationsplan en eller flere bevilgede Ydelser, hvorfra beløbet til administration skal trækkes. Der tilknyttes en eller flere betalingsaftaler til de udgifter, som skal betales. Se nedenstående Figur 12. Ydelssessag Bevilling Administrationssag Bevilget ydelse Betalingsaftale Effektuering Beløb til administration Administrationsordning Administrationsplan Effektueringsplan Administrationskonto Restbeløb Ydelsesmodtager (Person) Betaling af regninger Alternativ modtager Figur 12: Administrationsordning Normalt vil det resterende beløb blive udbetalt til ydelsesmodtageren, når der udbetales forsørgelsesydelser generelt, dvs. som hovedregel sidste dag i måneden. Hvis det resterende beløb skal udbetales til ydelsesmodtageren på et andet tidspunkt eller i rater, eksempelvis med lige store ugentlige beløb, tilknyttes en rateudbetalingsplan til administrationsordningen. Se nedenstående Figur 13. Side 95 af 257
Ydelssessag Bevilling Administrationssag Bevilget ydelse Betalingsaftale Effektuering Beløb til administration Administrationsordning Rateudbetalingsplan Administrationsplan Effektueringsplan Administrationskonto Ydelsesmodtager (Person) Restbeløb udbetalt i rater Betaling af regninger Alternativ modtager Figur 13: Administrationsordning med rateudbetaling af restbeløb til ydelsesmodtager Krav i dette afsnit er rettet specifikt mod Løsningens understøttelse af disse administrationssager og skal ses som supplement til de generelle krav, som retter sig mod de øvrige Ydelser, som Løsningen skal understøtte. Se desuden afsnit 5.5.5 for krav til specifikke visninger i forbindelse med administration af Personens økonomi. 5.3.1 Læg Personens budget under oplysning af administrationssag Ved oplysning af en administrationssag er der typisk behov for at kunne lægge et budget med indtægter og udgifter for at vurdere, hvorvidt administration skal iværksættes og i så fald hvilke udgifter, der skal administreres. Budgettet kan sammenlignes med et almindeligt 12 måneders husholdningsbudget. Krav# 103: Læg budget ved oplysning af administrationssag Beskrivelse: En Bruger skal i Løsningen kunne lægge et budget for Personen til brug for oplysning af en administrationssag. a) Brugeren kan lægge et budget for en Person med angivelse af udgifter og indtægter på månedsbasis. b) Brugeren skal kunne vælge blandt de typer af indtægter og udgifter, som er konfigureret lokalt. c) Brugeren skal kunne tilføje indtægter og udgifter til det specifikke budget. d) Løsningen skal danne og vise summer for budgettet. e) Budgettet er knyttet til Personens administrationssag. - Se Krav# 201 vedrørende oplysninger, der kan indgå i et budget. - Se informationsmodellen (Budget) i underbilag 2.5. Side 96 af 257
5.3.2 Træf afgørelse i administrationssag Typisk er formålet med en administrationssag at sikre, at Personen får betalt husleje, således at vedkommende ikke sættes ud af sin bolig. Det kan dog også forekomme, at Personen frivilligt indgår en aftale om administration. Administrationsordningen knyttes til en eller flere ydelsesbevillinger, hvorfra der trækkes et beløb til administration. Bemærk, at der eksempelvis for to Ægtefæller, der modtager uddannelseshjælp, kontanthjælp eller pension kan administreres fælles udgifter såsom husleje. Der er ofte tale om en forsørgelsesydelse, som allerede er bevilget i løsningen, men en stor del af administrationssagerne vedrører pensionsydelser, der udbetales af Udbetaling Danmark og endelig administreres i nogle sager Andre Ydelser, som ikke håndteres i Løsningen, fx sygedagpenge. I sådanne tilfælde skal der oprettes en ydelsessag med en bevilling på en Anden Ydelse, som administrationsordningen kan tilknyttes (se eventuelt Krav# 192 og Krav# 193). Der er endvidere behov for at indberette betalingsaftaler for de udgifter, der administreres af Ydelsescentret, og eventuelt en rateudbetalingsplan, hvis det resterende beløb skal opdeles i rater og udbetales til Personen på andre tidspunkter end det normale. Det skal være muligt at kunne spare op af forsørgelsesydelsen til udgifter, der betales kvartalsvis eller halvårligt, således at Personens udbetalte Ydelse udjævnes. Det håndteres af Brugeren, der kan bruge budgettet, når det bestemmes hvilket beløb, der skal trækkes fra den bevilgede Ydelse. Krav# 104: Indberet afgørelse eller frivillig aftale om administration Beskrivelse: Det skal være muligt for en Bruger at indberette en afgørelse eller frivillig aftale om administration af en Persons økonomi. a) En Bruger skal kunne indberette en afgørelse om at administrere Personens økonomi. b) En Bruger skal kunne indberette og efterfølgende redigere en frivillig aftale om at administrere Personens økonomi. c) Der skal oprettes en administrationsordning med særskilt konto, som løbende bruges til registrering af saldoen på Personens administrationsordning. d) Brugeren skal kunne indberette et overtræksbeløb på ordningen. Defaultværdien skal være nul (0) kr. e) Overtræksbeløbet må ikke overskride det maksimale overtræksbeløb. f) Løsningen skal gøre Brugeren opmærksom på det, hvis det ved tilknytning af administrationsplaner og betalingsaftaler kan forudses, at der inden for indeværende og de to følgende udbetalingsperioder vil opstå en negativ saldo, som overskrider det indberettede overtræksbeløb. - Se Krav# 202 vedrørende maksimalt overtræksbeløb. - Se Krav# 105 vedrørende tilknytning af administrationsordning til bevilget Ydelse. - Se Krav# 106 vedrørende tilknytning af betalingsaftaler. Side 97 af 257
- Se informationsmodellen (KY-effektuering, Beslutningsgrundlag, Bevilling, Træf afgørelse) i underbilag 2.5. Krav# 105: Tilknyt administrationsordning til bevilget Ydelse Beskrivelse: Det skal være muligt for en Bruger at knytte administrationsordningen til en eller flere bevilgede Ydelser, hvorfra der kan trækkes et beløb til administration. a) Det er muligt for Brugeren at knytte administrationsordningen til en eller flere bevilgede Ydelser. b) Administrationsordningen kan tilknyttes bevilgede Ydelser i to Personers ydelsessager. c) Der er oprettet en administrationsplan, som udpeger en specifik bevilget Ydelse og indeholder information om det beløb, som skal trækkes fra Ydelsen til administrationsordningen, samt hvornår beløbet skal overføres - Bemærk, at administrationsordningen kan tilknyttes bevilgede Ydelser i to Personers ydelsessager, eksempelvis hvis der administreres fælles udgifter for to Ægtefæller, der begge modtager uddannelseshjælp, kontanthjælp eller pension. - Se informationsmodellen (KY-effektuering) i underbilag 2.5. Krav# 106: Tilknyt betalingsaftale til administrationsordning Beskrivelse: Det skal være muligt for en Bruger at tilknytte en betalingsaftale til administrationsordningen, for hver udgift, som betales. a) Det er muligt for Brugeren at indberette de nødvendige oplysninger til at oprette en betalingsaftale knyttet til administrationsordningen. b) Betalingsaftalen skal indeholde de oplysninger, som er nødvendige for, at løsningen rettidigt og korrekt kan betale en af de udgifter, som kommunen administrerer, når administrationsordningen effektueres. c) Oplysningerne inkluderer betegnelse, betalingsidentifikation, beløb, Alternativ Modtager, betalingstidspunkt og betalingsfrekvens, markering for om betalingen skal godkendes manuelt ved hver effektuering. d) Hvis beløbet skal overføres til en anden enhed i kommunen via debitorsystem, er det muligt for Brugeren at angive de nødvendige oplysninger på betalingsaftalen til, at denne overførsel kan foretages korrekt, når der effektueres. - Se Krav# 65 vedrørende registrering af Alternativ Modtager. - Se Krav# 82 vedrørende manuel godkendelse. - Se eventuelt informationsmodellen (KY-effektuering) i underbilag 2.5. Side 98 af 257
- Se afsnit 6.4.3.7 om snitflade til debitorsystemet i forbindelse med overførsel. til anden enhed i kommunen, fx betaling for dagtilbud jf. LAS 96. Krav# 107: Tilknyt rateudbetalingsplan til administrationsordning Beskrivelse: Det skal være muligt for en Bruger at tilknytte en rateudbetalingsplan til administrationsordningen. a) Det er muligt for Brugeren at indberette de nødvendige oplysninger til at oprette rateudbetalingsplan knyttet til administrationsordningen. b) Udbetalingsplanen fastsætter, hvordan det resterende beløb på den bevilgede Ydelse, som ikke er fratrukket til administration, udbetales til Personen. c) Der skal kunne udbetales lige store brøkdele fordelt jævnt over udbetalingsperioden eller et antal udbetalinger med specifikke beløb på specifikke ugedage, dage eller datoer. d) Løsningen skal sikre, at præcis det resterende beløb, som ikke er fratrukket til administration, udbetales i udbetalingsperioden i henhold til rateudbetalingsplanen. e) Hvis der ikke er registreret en rateudbetalingsplan, udbetales restbeløbet jf. effektueringsplanen i ydelsessagen. - Udbetalingsplanen indeholder oplysninger, der bruges ved udbetaling i rater og udbetaling af det resterende beløb, som ikke er anvendt til administration. - Se afsnit 5.2.4.1 vedr. effektueringsplanen i ydelsessagen. - Se Krav# 109 vedrørende effektuering for administrationssager. - Se eventuelt informationsmodellen (KY-effektuering) i underbilag 2.5. 5.3.3 Effektuering vedrørende administrationsordning Når administrationsordningen er etableret med tilhørende administrationsplaner, betalingsaftaler og rateudbetalingsplan sker der løbende effektuering af ordningen. Dette svarer til, at der gemmes en effektueringsplan på en ydelsessag, som er udgangspunkt for effektuering og bestilling af udbetalinger. I administrationssager effektueres der i henhold til den administrationsordning, der er gemt i sagen. Det sikrer, at der på de fastsatte tidspunkter overføres penge fra den eller de bevilgede Ydelser til administrationsordningen i henhold til administrationsplanen, udbetales i henhold til de indberettede betalingsaftaler, og at den resterende Ydelse udbetales til Personen eventuelt i henhold til en rateudbetalingsplan. Krav# 108: Modtag oplysninger om pensionsydelse til administration Beskrivelse: Løsningen skal løbende kunne modtage oplysninger om overførsel af pension fra Udbetaling Danmark s Social Pension system og kontere beløbet på den dertil oprettede bevilling og bevilget Ydelse. Side 99 af 257
a) Løsningen kan modtage oplysninger om overførsel af pension fra UDK Social Pension for alle de sager, hvor der administreres økonomi for en Person, der modtager pension fra Udbetaling Danmark. b) Oplysningerne er registreret korrekt på den administrationssag og tilknyttede ydelsessag, som oplysningerne vedrører. - Når Ydelsescentret administrerer økonomien for en Person, modtager Personen enten en forsørgelsesydelse, som er bevilget i Ydelsescentret, eller en pensionsydelse, som er bevilget af Udbetaling Danmark. Der kan derfor være behov for at få overført pensionsydelsen fra Udbetaling Danmark. - Se afsnit 6.4.3.18 vedrørende snitflade til UDK Social Pension. - Se eventuelt informationsmodellen (KY-effektuering) i underbilag 2.5. Krav# 109: Effektuér administrationsordninger Beskrivelse: Løsningen skal effektuere administrationsplan, rateudbetalingsplan, og betalingsaftaler på alle administrationsordninger. a) Alle administrationsordninger er effektueret, således at følgende sker rettidigt og korrekt i henhold til administrationsplaner, rateudbetalingsplaner og betalingsaftaler: A. Overførsel fra den bevilgede Ydelse til administrationsordningen. B. Betaling til alternative modtagere. C. Udbetaling af resterende beløb til Personen i henhold til rateudbetalingsplanen, hvis der er registreret en sådan. D. Aflevering af udbetalingsanmodninger til udbetalingssystemet og/eller dannelse af straksudbetalingsbilag. - Se Krav# 105 vedrørende overførsel fra den bevilgede Ydelse til administrationsordningen. - Se Krav# 106 vedrørende betaling til Alternativ Modtager. - Se Krav# 107 vedrørende udbetaling af resterende beløb til Personen. - Se Krav# 83 vedrørende kontering. - Se Krav# 71 og Krav# 72 vedrørende aflevering af udbetalingsanmodninger til udbetalingssystemet. - Se Krav# 73 vedrørende dannelse af straksudbetalingsbilag. - Se afsnit 6.4.3.7 om ØiR snitflade til udbetalings- og økonomisystemer. Krav# 110: Negativ saldo må ikke overstige indberettet overtræksbeløb Beskrivelse: Løsningen skal sikre, at en eventuel negativ saldo på administrationsordningen ikke overskrider det indberettede overtræksbeløb. Side 100 af 257
a) Løsningen skal sikre, at en negativ saldo på en administrationsordning på intet tidspunkt overstiger det overtræksbeløb, som er indberettet på administrationsordningen. b) Løsningen skal sikre, at der er dannet en Opgave til Brugeren, hvis saldoen på en administrationsordning bliver negativ. c) Løsningen skal sikre, at der er dannet en Opgave til Brugeren, hvis der er betalinger, som ikke kan effektueres pga. overskridelse af overtræksbeløbet. - Behovet kan opstå, hvis der eksempelvis er variable poster på en huslejeregning. I en given måned kan huslejebeløbet overstige det normale. Hvis en eventuel negativ saldo på administrationsordningen overstiger det indberettede overtræksbeløb, medfører det, at der er betalinger, som ikke kan effektueres. - Se Krav# 10 vedrørende automatisk oprettelse af Opgave. Krav# 111: Deaktivering af administrationsordning Beskrivelse: Løsningen skal deaktivere administrationsordningen, hvis en eller flere af de bevilgede Ydelser, som administrationsordningen er tilknyttet, stoppes. a) Løsningen skal sikre, at administrationsordningen deaktiveres samtidig, hvis en eller flere af de bevilgede Ydelser, som ordningen er tilknyttet, stoppes. b) Løsningen skal sikre, at en deaktiveret administrationsordning ikke effektueres. c) Løsningen skal sikre, at der er dannet en Opgave til Brugeren, når en administrationsordning deaktiveres. d) Det skal være muligt for Brugeren at genaktivere administrationsordningen. 5.3.4 Afslutning af administrationsordning Når der ikke længere skal foretages administration, skal sagsbehandleren afslutte administrationsordningen og tilhørende administrationsplan(er), betalingsaftaler og rateudbetalingsplan, inden administrationssagen kan lukkes. Som en del af dette skal sagsbehandleren tage stilling til, hvordan en eventuel restsaldo på administrationsordningen skal behandles. Krav# 112: Afslutning af administrationsordning Beskrivelse: Brugeren skal kunne afslutte en administrationsordning. a) Det skal være muligt for en Bruger at afslutte en administrationsordning. Side 101 af 257
b) Løsningen skal sikre, at alle tilhørende administrationsplaner, betalingsaftaler og rateudbetalingsplaner afsluttes og konteres korrekt samtidig med administrationsordningen. c) Brugeren skal kunne vælge, hvordan en eventuel restsaldo skal behandles. Den kan udbetales eller tilbageføres til kontoen for en Ydelse, som administrationsordningen er tilknyttet. d) Hvis saldoen tilbageføres, skal løsningen ud fra saldoen (nettobeløb) beregne det bruttobeløb, som skal konteres. e) Hvis der undtagelsesvis er en negativ saldo, skal Brugeren gøres opmærksom herpå. Brugeren skal i dette tilfælde manuelt foretage afslutning og kontering af de enkelte dele af administrationsordningen. - Se Krav# 86 vedrørende manuel kontering. Tværgående funktionalitet Dette afsnit indeholder funktionalitet, der kan være relevant under hele sagsbehandlingsforløbet, dvs. tværgående funktionalitet, som Brugeren altid skal kunne trække på. 5.4.1 Valideringer Krav# 113: Validering af uforenelige Ydelser Beskrivelse: Løsningen skal ved oprettelse af en sag samt ved afgørelse om bevilling validere om Ydelsen, ifølge bevillingsreglerne for Ydelsen, er uforenelig med Ydelser, som allerede er bevilget til Personen. h) Løsningen har foretaget validering af uforenelige Ydelser ved oprettelse af sag. i) Løsningen har foretaget validering af uforenelige Ydelser ved registrering af afgørelse. j) Hvis det forsøges at oprette sag med uforenelig Ydelse, gør Løsningen Brugeren opmærksom herpå og kræver, at Brugeren eksplicit bekræfter sagsoprettelsen. k) Hvis det forsøges at bevillige uforenelige Ydelser, gør Løsningen Brugeren opmærksom herpå og kræver, at Brugeren eksplicit bekræfter afgørelsen om bevilling. - Se Krav# 21 og Krav# 22 om oprettelse af sag. - Se Krav# 56 om indberetning af afgørelse. - Se underbilag 2.21 Oversigt over uforenelige Ydelser. Side 102 af 257
Krav# 114: Begrænsning i bevilling af Ydelser Beskrivelse: Løsningen skal sikre, at en Bruger ikke kan bevilge en Ydelse til sig selv eller sin Ægtefælle/Samlever. SKAT lukker på en given dato for modtagelse af oplysninger til det foregående indkomstår.(datoen udmeldes årligt på SKATs hjemmeside). Det skal således ikke være muligt for en Bruger i Løsningen at indberette til kontering i et låst indkomstår, da Løsningen derved ikke ville kunne indberette korrekt til SKAT efterfølgende. Krav# 115: Ingen indberetninger i et låst indkomstår Beskrivelse: Løsningen skal sikre, at Brugeren ikke kan indberette til kontering i et låst indkomstår. Hvis en Bruger forsøger at indberette til kontering i et låst indkomstår, skal Brugeren gøres opmærksom på, hvorfor dette ikke kan lade sig gøre. - Se Krav# 196 vedrørende den centrale administrators mulighed for at konfigurere datoen for låsningen af indkomståret. Krav# 116: Ingen aktive Opgaver på afsluttede sager. Beskrivelse: En sag kan ikke afsluttes, hvis der eksisterer aktive Opgaver på sagen. a) En sag kan ikke afsluttes, hvis der eksisterer aktive Opgaver på sagen. b) Brugeren skal tage stilling til, om aktive Opgaver på sagen kan afsluttes sammen med sagen. c) Hvis Brugeren har angivet, at Opgaverne kan afsluttes, afslutter Løsningen Opgaver og sag. - Se krav Krav# 97 vedrørende afslutning af sag. 5.4.2 Dokumenter og journalnotater I Løsningen både gemmes, læses og produceres dokumenter og journalnotater. Med journalnotatet kan sagsbehandleren opfylde sin notatpligt og gemme noter, fx i forbindelse med telefonsamtaler og møder. Et journalnotat vil altid være knyttet til én sag, og vil være med til at danne indholdet i sagshistorikken (jf. afsnit 5.5.4). Journalnotatet kan redigeres af en Bruger indtil det låses af Brugeren eller automatisk af Løsningen. Ofte indgår den samme tekst i forskellige journalnotater, og derfor har kommunen mulighed for at benytte journalnotatsskabeloner. Sagsbehandleren kan således ved oprettelsen af et journalnotat vælge at tage udgangspunkt i en journalnotatsskabelon, hvor det meste indhold er forhåndsudfyldt. Sagsbehandleren kan indtaste de informationer, der mangler, og på den måde hurtigt kunne danne et journalnotat. Side 103 af 257
Alle dokumenter og journalnotater, der er relevante for behandlingen af en sag, skal være tilgængelige via Løsningens brugergrænseflade. Løsningen skal kunne modtage dokumenter og journalnotater, der er oprettet i it-løsninger, der anvendes i bl.a. borgerservicecentret, og tilknytte dokumentet/journalnotatet til en sag. Krav# 117: Automatisk tilknytning af dokument eller journalnotat til sag Beskrivelse: Løsningen skal kunne knytte et dokument eller et journalnotat til sagen automatisk, hvor det er muligt. a) Hvis sagen er tilknyttet en ansøgning i selvbetjeningsløsningen, tilknytter Løsningen dokumenter modtaget via selvbetjeningsløsningen til sagen via ansøgningens relation til sagen. b) Hvis sagen har modtaget og gemt et dokument eller låst journalnotat på sagen via Dokumentfordeleren, knyttes dokumentet/notatet til sagen via CPR-nummer, sags-id, eller sagsbehandlernavn. Løsningen opretter en Opgave til sagsbehandleren. c) Hvis der ikke findes en sag, som dokumentet/journalnotatet kan tilknyttes, opretter Løsningen en Opgave til sagsbehandleren. d) Løsningen opdaterer Sags-og dokumentindekset med dokumentreferencen og sikrer at andre it-løsninger kan blive orienteret om hændelsen.. e). f) Flg. kriterier for tilknytning af dokumenter til sagen skal anvendes: CPRnummer på part i sagen og sagsid. I Afklaringsfasen defineres yderligere 2-4 kriterier for tilknytning af dokumenter/journalnotater til sagen. KOMBIT foreslår flg. fremgangsmåde for tilknytning af dokumenter til sagen: Ved modtagelse af dokumenter via Dokumentfordeleren kan tilknytningen til sag afgøres således: 1. Hvis der er angivet sags-id i dokument eller metadata på dokument, så skal Løsningen tilknytte dokumentet til sagen med det angivne sags-id. Sags-id er den unikke reference mellem dokument og sag. 2. Hvis der er angivet CPR-nr. i dokument eller metadata på dokument, og der kun findes én sag med CPR-nummeret i Løsningen, så skal Løsningen tilknytte dokumentet til sagen med det angivne CPR-nummer. 3. Hvis der er angivet CPR-nr. i dokument eller metadata på dokument, og der findes flere sager med CPR-nummeret i Løsningen, så skal Løsningen se, om der er angivet en ydelseskode i dokumentet, der matcher en af sagerne, og hvis ja, så tilknytte dokumentet til sagen med det angivne CPR-nummer og ydelseskode. 4. Hvis der er angivet CPR-nr. i dokument eller metadata på dokument, og der findes flere sager med CPR-nummeret i Løsningen, så skal Løsningen se, om der Side 104 af 257
er angivet et KLE-nr. i dokumentet, der matcher en af sagerne og hvis ja, så tilknytte dokumentet til sagen med det angivne CPR-nummer og KLE nummer. 5. Hvis sagstilknytningen ikke kan etableres, fordi der er flere sager med samme CPR-nr, samme ydelseskode eller samme KLE-nr. skal Løsningen danne en opgave og undlade at placere dokumentet på en sag. Hvis der er sat en given ydelseskode på og den kan komme via dokumentfordeleren, så er den mere præcis end KLE. - Eksempler på it-løsninger, der opretter journalnotater er SAPA og KMD Sag. - Eksempler på metadata fra dokumentet er: CPR-nummer, Ydelsesart, KLEnummer og sagsid. - Se Krav# 20 om automatisk oprettelse af sag. - Se Krav# 14 om modtagelse af dokumenter. - Se Krav# 345 om modtagelse af ansøgninger fra selvbetjeningsløsningen. - Se hændelseslisten i underbilag 2.13 for udgående Beskeder til Beskedfordeleren. - Se afsnit 6.3.2.2 om Dokumentfordeleren, som er ansvarlig for afsendelse af journalnotater til fagsystemer. - Se afsnit 6.3.2.3 vedrørende Sags- og Dokumentindeks. - Se informationsmodellen KY-dokument, KY-sag i underbilag 2.5. - Se Krav# 122 om håndtering af ikke relevante dokumenter Krav# 118: Manuel tilknytning af dokumenter til sag Beskrivelse: Brugeren skal ved sagsoprettelse og på et hvert tidspunkt i sagsbehandlingen kunne tilknytte et eller flere dokumenter til sagen. a) Brugeren kan udvælge et eller flere dokumenter fra lokalt bibliotek eller Løsningen og knytte dem/det til sagen. b) Brugeren kan tilknytte en e-mail med eventuelle vedhæftede dokumenter til sagen. c) Brugeren kan, i forbindelse med tilknytningen til sagen, give hvert enkelt dokument et nyt brugervendt navn. d) Løsningen har opdateret Sags- og Dokumentindekset med dokumentreferencen og har sikret at andre it-løsninger kan blive orienteret om hændelsen. e) - Eksempler på dokumenter, der skal tilknyttes en sag er: dokumentation for indtægter eller formue, en e-mail (selve e-mailen og eventuelle vedhæftede filer i binært format). - Se Krav# 21 om manuel oprettelse af sag. Side 105 af 257
- Se hændelseslisten i underbilag 2.13 for udgående Beskeder til Beskedfordeleren. - Se afsnit 6.3.2.3 vedrørende Sags- og Dokumentindeks. - Se informationsmodellen KY-dokument, KY-sag i underbilag 2.5. I dag modtages mange dokumenter via e-mails. Derfor skal det være muligt for sagsbehandleren let at overføre selve e-mailen samt de eventuelle vedhæftede dokumenter til Løsningen. Dette er også relevant i de tilfælde, hvor sagsbehandleren kommunikerer med Personen via e-mail. I disse tilfælde skal e-mailen vedlægges sagen som dokumentation. Behovet er således, at det er let at gemme både ind- og udgående e-mails og eventuelle vedhæftninger på sagen. Krav# 119: Drag n drop funktionalitet Beskrivelse: Brugeren skal kunne gemme dokumenter, dokumenter vedhæftet i e-mails samt selve e-mailen på en sag ved hjælp af drag n drop funktionalitet. a) Brugeren kan trække dokumenter, e-mails og dokumenter vedhæftet e- mails lokalt fra Brugerens maskine til sagen i Løsningen. b) Løsningen tilknytter dokumenterne til sagen. c) Løsningen kan håndtere tilknytning af e-mails fra e-mail-programmerne, herunder MS Outlook, Lotus Notes og Groupwise. d) Løsningen opdaterer Sags- og Dokumentindekset med dokumentreferencen og sikrer at andre it-løsninger kan blive orienteret om hændelsen.. e) Drag n drop,skal kunne foretages på Løsninger, der afvikles i citrix miljø, jf. kravene til Kommunernes it-miljø, bilag 2.24 f) - Se Krav# 118 om manuel tilknytning af dokumenter til en sag. - Se hændelseslisten i underbilag 2.13 for udgående Beskeder til Beskedfordeleren. - Se afsnit 6.3.2.3 vedrørende Sags- og Dokumentindeks Krav# 120: Åbne og læse dokumenter via lokal applikation Beskrivelse: Brugeren skal kunne åbne dokumenter, der er tilknyttet sager i Løsningen i den applikation, dokumentet blev dannet i. a) Brugeren kan åbne dokumenter, der er tilknyttet sager i Løsningen i den applikation, dokumentet blev dannet i, hvis applikationen er installeret på Brugerens pc. b) Løsningen åbner tilknyttede pdf-dokument via den lokale pdf-reader. c) Løsningen åbner tilknyttede e-mails via den lokale e-mailklient (fx MS Outlook). d) Løsningen åbner tilknyttede tekstdokumenter og regneark via den lokale kontor-applikation (fx MS Office). Side 106 af 257
e) Løsningen åbner tilknyttede billeddokumenter via den lokale billedvisningsapplikation. f) Hvis Brugeren ikke har en applikation installeret, som kan åbne den givne filtype, gøres Brugeren opmærksom herpå. Krav# 121: Kopier dokument fra en sag til en anden Beskrivelse: Brugeren skal kunne kopiere et dokument og tilknytte kopien til en anden sag. a) Det kopierede dokument gemmes og tilknyttes en specifik sag b) Løsningen opdaterer Sags- og Dokumentindekset med dokumentreferencen og sikrer at andre it-løsninger kan blive orienteret om hændelsen.. c) - Se hændelseslisten i underbilag 2.13 for udgående Beskeder til Beskedfordeleren. - Se afsnit 6.3.2.3 vedrørende Sags- og Dokumentindeks Løsningen kan ikke garantere, at de dokumenter og journalnotater, der modtages via Dokumentfordeleren (afsnit 6.3.2.2), altid er relevante for de sager, der eksisterer i Løsningen. Det kan fx være, at et indscannet dokument ved en fejl sendes til Ydelsescentret, men burde have været til Jobcentret. Løsningen skal kunne håndtere, hvordan dette irrelevante dokument ekspederes videre i kommunen. Krav# 122: Håndter ikke relevante dokumenter og journalnotater Beskrivelse: Brugeren skal kunne returnere dokumenter og journalnotater, der ikke er relevante for en sag. a) Brugeren kan angive, at et dokument/journalnotat er fejlplaceret på en sag. b) Løsningen fjerner dokumentet/journalnotatet fra sagen via Dokumentfordeleren. c) Brugeren kan angive, at en Opgave om placering af et dokument/journalnotat ikke er relevant. d) Løsningen fjerner Opgaven og informerer afsenderen af dokumentet/journalnotatet, om at dokumentet/notatet ikke er tilknyttet sagen. - Se Krav# 14 om modtagelse af dokumenter. - Se afsnit 6.3.2.2 vedrørende Dokumentfordeleren. Side 107 af 257
Krav# 123: Begrænsning af filtyper Beskrivelse: Løsningen skal sikre, at dokumenter af filtypen.exe, cmd eller andre lignende eksekverbare filer ikke kan gemmes og tilknyttes sager i Løsningen. - Se Krav# 14 om modtagelse af dokumenter. - Se Krav# 118 og Krav# 119 om tilknytning af dokumenter. Krav# 124: Sletning af dokumenter Beskrivelse: Løsningen skal sikre, at dokumenter, der er gemt på en sag, ikke kan redigeres eller slettes. a) Dokumenter på en sag kan ikke redigeres eller slettes. b) Undtagelser herfor er følgende: a. Udgående breve der endnu ikke er afsendt. Brugeren kan redigere og slette breve ved brugen af brevskabeloner, så længe brevet ikke er afsendt. b. I tilfælde af irrelevante dokumenter beskrevet i Krav# 122. - I tilfælde af behov for redigering kan Brugeren gemme en ny version af dokumentet med et andet navn og knytte det til sagen. - Se afsnit 5.4.3 om breve og brevskabeloner. Krav# 125: Oprettelse af journalnotat Beskrivelse: Brugeren skal kunne oprette et journalnotat på hvilket som helst tidspunkt under behandlingen af en sag. a) Brugeren kan oprette et journalnotat på sagen. b) Brugeren kan benytte en skabelon i forbindelse med oprettelsen af journalnotatet. c) Journalnotater kan udarbejdes på grundlag af en journalnotatsskabelon, hvortil der kan tilføjes yderligere oplysninger. d) Brugeren kan angive, at et journalnotat er friholdt for aktindsigt. e) Løsningen opdaterer Sags- og Dokumentindekset med referencen til journalnotatet. - Se Krav# 212 om skabelon for journalnotat. - Se informationsmodellen KY-Sag for oplysninger om data, der undtages offentliggørelse. - Se hændelseslisten i underbilag 2.13 for udgående Beskeder til Beskedfordeleren. - Se afsnit 6.3.2.3 Sags- og Dokumentindekset. Side 108 af 257
Krav# 126: Formatering og stavekontrol i journalnotat Beskrivelse: Løsningen skal sikre, at journalnotatet har simpel tekstredigering og stavekontrol. a) Tekstredigering af notatet understøtter formatering af tekst med fed, kursiv og understregning. b) Tekstredigering af notatet understøtter opstilling ved brug af punktliste. c) Løsningen gør Brugeren opmærksom på stavefejl i journalnotatet. Krav# 127: Indhold i journalnotat Beskrivelse: Et journalnotat indeholder følgende informationer: Overskrift Notattekst (plads til minimum 10.000 tegn). Status (Åben/Låst) Bruger, dato og tidsstempel for oprettelse og evt. redigering. Reference til sag. Reference til en eller flere Personer i sagen. Evt. reference til et relateret dokument. - Se informationsmodellen KY-sag i underbilag 2.5. Krav# 128: Ændring og sletning af journalnotat Beskrivelse: Brugeren skal kunne redigere og slette et journalnotat, der ikke er låst. a) Brugeren kan redigere eller slette et journalnotat, der ikke er låst. b) Brugeren kan låse et journalnotat. c) Brugeren kan tilknytte en kopi af et journalnotat til en anden af Personens sager. d) Løsningen opdaterer dokumentreferencen i Sags- og Dokumentindekset. Dokumentet påvirkes ikke. e) Løsningen låser automatisk et journalnotat efter det antal dage fra oprettelse, som er konfigureret af den kommunale administrator. - Kopi af et journalnotat kan tilknyttes flere sager, fx hvis Personen har både en kontanthjælpssag og en enkeltydelsessag, hvor notatet er relevant. - Se Krav# 210 om kommunal konfigurering af frist for automatisk låsning. - Se Krav# 211 om angivelse af, at låste journalnotater ikke skal vises på sagen. - Se afsnit 6.3.2.3 Sags- og Dokumentindekset. - Se hændelseslisten i underbilag 2.13 for udgående Beskeder til Beskedfordeleren. Side 109 af 257
5.4.3 Breve og brevskabeloner Der anvendes i dag en lang række breve og brevskabeloner i forbindelse med sagsbehandlingen, fx vedrørende partshøring, samtykke, orienteringer, bevillinger, afslag mv. Sagsbehandleren vil under sagsbehandlingen have behov for at sende breve til Personen og eventuelt også til tredjepart. For at lette sagsbehandlerens arbejde skal der være let adgang til en række brevskabeloner, så sagsbehandleren ikke skal bruge tid på at formulere de samme breve igen og igen. I nogle at disse brevskabeloner er indholdet fast (med indflettede strukturerede data), mens der i andre derudover vil være behov for, at sagsbehandleren kan tilføje tekst som fx en konkret individuel begrundelse for afslag, til brevet. Løsningen vil indeholde en række centralt oprettede brevskabeloner, som kommunerne kan benytte i forbindelse med sagsbehandlingen. Da kommunerne har forskellige behov, vil der dog være behov for, at nogle kommuner opretter deres egne lokale skabeloner i tilfælde af, at de centrale ikke er tilstrækkelige. De lokale skabeloner kan både være udtryk for helt nye typer af breve, der ikke eksisterer som centrale brevskabeloner, og det kan være tilpassede lokale versioner af de centrale skabeloner for at understøtte kommunernes forskelligheder. Se underbilag 2.12 for en ikke-udtømmende liste over breve, samt eksempler på en række breve. I det følgende beskrives krav til Løsningens håndtering af breve og brevskabeloner. Krav# 129: Udarbejdelse af breve Beskrivelse: Brugeren skal kunne udarbejde et brev baseret på en brevskabelon. a) Brugeren kan vælge mellem et antal brevskabeloner, der er tilgængelige i Løsningen. b) De tilgængelige brevskabeloner kan være centrale skabeloner, der er ens for alle kommuner eller lokale skabeloner, der er specifikke for Brugerens kommune. c) Løsningen indsætter automatisk kommunale grundoplysninger og relevante data fra sagen i flettefelter i brevet baseret på den valgte skabelon. d) Brugeren kan udfylde felter, der ikke er flettefelter i skabelonen. e) Brevet kan downloades lokalt og redigeres i de to gængse tekstbehandlingsformater ODF (.odt) og OOXML (.docx). f) Formatering og placering af indholdselementer bibeholdes, når brevet åbnes og redigeres. g) Modtageroplysninger placeret i brevhovedet, så det passer til en rudekuvert. Øvrig tekst placeres, så den ikke er synlig i ruden på en rudekuvert. h) Brugeren kan gemme brevet som kladde eller færdigt brev, hvorefter det knyttes til sagen. i) Afsendelse af brevet medfører opdatering af Sags- og Dokumentindekset. - Se Krav# 177 om oversigt over brevskabeloner. - Se Krav# 178 om adgang til brevskabeloner. - Se Krav# 136 om afsendelse af breve via Print på Serviceplatformen. - Se Krav# 137 om lokalt print. - Det er obligatorisk for det offentlige at anvende de åbne standarder for redigerbare tekstdokumenter ODF og OOXML - se evt. Digitaliseringsstyrelsen: Side 110 af 257
http://www.digst.dk/arkitektur-og-standarder/standardisering/aabne-standarder--vejledning [indhentet 01-10-2013] Krav# 130: Centrale brevskabeloner Beskrivelse: Løsningen skal indeholde centrale brevskabeloner, der kan anvendes af alle kommuner. a) Skabelonerne vil have både faste sektioner, flettefelter, hvor Løsningen automatisk kan indflette informationer fra sagen samt sektioner, hvor Brugeren kan indtaste fritekst, der indflettes i brevet. b) Data, der allerede forefindes i Løsningen, kan indflettes automatisk, herunder eksempelvis CPR-nummer, Personens navn og adresse, Sags-ID, ydelsesbetegnelse og beregnet beløb til udbetaling. c) Breve udarbejdes i fonten Arial og brødtekst i størrelse 10. I Afklaringsfasen defineres det eksakte antal og indhold af centrale brevskabeloner. - Leverandøren er ikke ansvarlig for det faglige/juridiske indhold i centrale brevskabeloner. - Se underbilag 2.12 for eksempler på breve. - Se Krav# 177 om oversigt over brevskabeloner. - Se Krav# 178 om adgang til brevskabeloner. - Se Krav# 341 om unikt, læsbart sags-id. Krav# 131: Lokale brevskabeloner Beskrivelse: Brugeren skal kunne anvende en lokal brevskabelon. a) Brugerne kan tilgå lokale brevskabeloner, såfremt en kommunal administrator har oprettet disse. b) Skabelonerne vil have både faste sektioner, flettefelter, hvor der skal indflettes informationer fra sagen samt sektioner, hvor Brugeren kan indtaste fritekst i brevet. c) Information, der allerede forefindes i Løsningen, kan indflettes automatisk, herunder eksempelvis CPR-nummer, Personens navn og adresse, Sags-ID, ydelsesbetegnelse og beregnet beløb til udbetaling. d) Breve udarbejdes i fonten Arial og brødtekst i størrelse 10. - Leverandøren er ikke ansvarlig for det faglige/juridiske indhold i lokale brevskabeloner. - Se Krav# 207 om brevskabeloner oprettet af den kommunale administrator. - Se Krav# 177 om oversigt over brevskabeloner. - Se Krav# 178 om adgang til brevskabeloner. - Se Krav# 341 om unikt, læsbart sags-id. Krav# 132: Kommunespecifikke grundoplysninger Beskrivelse: Centrale og lokale brevskabeloner skal indeholde kommunespecifikke grundoplysninger såsom navn, logo, adresse og åbningstider. Side 111 af 257
- Se Krav# 208 om opsætning af kommunespecifikke grundoplysninger. - Se underbilag 2.12 med eksempler på breve og kommunespecifikke grundoplysninger. Krav# 133: Oprettelse af brev baseret på tom skabelon Beskrivelse: Brugeren skal kunne danne et brev, som ikke indeholder faste skabelonelementer udover kommunens grundoplysninger. a) Løsningen har dannet et brev, der kun indeholder de kommunespecifikke grundoplysninger. b) Brevet kan downloades lokalt og redigeres i de to gængse tekstbehandlingsformater ODF (.odt) og OOXML (.docx). c) Formatering og placering af indholdselementer bibeholdes, når brevet åbnes og redigeres. - Se Krav# 132 om kommunespecifikke grundoplysninger. - Se Krav# 177 om oversigt over brevskabeloner. - Se Krav# 178 om adgang til brevskabeloner. Krav# 134: Håndtering af brev som kladde Beskrivelse: Brugeren skal kunne gemme et brev som kladde og kunne genoptage redigeringen af kladden på et senere tidspunkt. a) Brugeren kan gemme et brev som kladde. b) Brugeren kan redigere kladden. c) Brugeren kan gemme kladden som færdigt brev. - Se Krav# 129, Krav# 130, Krav# 131 om brevskabeloner. - Se Krav# 177 om oversigt over brevskabeloner. - Se Krav# 178 om adgang til brevskabeloner. Krav# 135: Angiv forsendelsestype for breve Beskrivelse: Brugeren skal kunne angive forsendelsestype for et brev. a) Brugeren kan angive, at brevet skal sendes anbefalet eller med krav om afleveringsattest. b) Brugeren kan angive, at brevet skal sendes som A- eller B-post. - Se Krav# 209 om konfigurering af defaultværdi for breve som A- eller B-post. Krav# 136: Afsendelse af breve via Print på Serviceplatformen Beskrivelse: Brugeren skal kunne afsende et brev via Print på Serviceplatformen. Side 112 af 257
a) Hvis Brugeren har angivet, at et brev med et antal bilag skal afsendes, anvender Løsningen snitfladen til Print på Serviceplatformen til afsendelse af breve og bilag. b) Når Brugeren har angivet, at breve og bilag skal afsendes, gemmer Løsningen brev og bilag i PDF/A-2 format på Personens sag. c) Løsningen har registreret, at brevet håndteres af Print på Serviceplatformen. d) Løsningen afsender udskriften til Print på Serviceplatformen (SF1600) og hér kontrolleres det, om borgeren er tilmeldt Digital Post. Hvis dette er tilfældet, sendes brevet til Digital Post. Hvis Personen ikke er tilmeldt Digital Post, sendes brevet med almindelig papirpost. e) Løsningen har medsendt information om, hvorvidt breve sendes som A- eller B-post på grundlag af den kommunale administrators registrering eller den enkelte Brugers valg. f) Afsendelse af brevet medfører opdatering af Sags- og Dokumentindekset. - Løsningen får i retursvaret fra Print på Serviceplatformen Besked om, hvorvidt brevet er sendt til Digital Post eller med papirpost. - Se Krav# 352 om Print på Serviceplatformen. - Se Krav# 209 om den kommunale administrators valg af defaultopsætning af A eller B-post. - Se Krav# 135 om Brugerens valg af A eller B-post. Som hovedregel sendes breve via integration til Print på Serviceplatformen (jf. Krav# 136) Men der kan være tilfælde, hvor brevet ikke skal sendes via denne kanal. Fx hvis Personen sidder fysisk til møde med sagsbehandleren. I disse tilfælde er der behov for, at sagsbehandleren kan printe brevet lokalt og udlevere det til Personen. I disse tilfælde skal Løsningen ikke sende brevet via Print på Serviceplatformen. Krav# 137: Valg af lokalt print til udskrivning af breve og rapporter Beskrivelse: Brugeren skal kunne udskrive breve og rapporter på lokal printer. a) Brugeren kan angive, at breve og rapporter skal udskrives lokalt. b) Hvis Brugeren har angivet, at brevet skal afsendes, har Løsningen gemt brevet i PDF/A-2 format på Personens sag. c) Løsningen har registreret, at brevet/rapporten er udskrevet lokalt. For de fleste breve er det sagsbehandleren, der initierer, at der skal afsendes brev. Men i enkelte tilfælde kan Løsningen automatisk udsende breve uden sagsbehandlerens indblanding Krav# 138: Automatisk udsendelse af breve Beskrivelse: Løsningen skal kunne udsende breve automatisk på grundlag af Hændelser, der registreres på sagen via snitfladen til Print på Serviceplatformen. Side 113 af 257
a) Løsningen udsender breve på grundlag af Hændelser, der afstedkommer automatisk udsendelse af breve, jf. underbilag 2.13. Hændelserne kan afstedkomme udsendelse af breve til et udsnit af Personer eller alle Personer med igangværende sager. b) Løsningen gemmer brevet/brevene i PDF/A-2 format og tilknytter det Personens/Personernes sag. c) Løsningen har udsendt brevet via Print på Serviceplatformen. d) Løsningen har medsendt information om, hvorvidt breve sendes som A- eller B-post på grundlag af den kommunale administrators registrering. e) Løsningen har registreret en Hændelse om udsendelsen af brevet på sagen. f) Afsendelse af brevet medfører opdatering af Sags- og Dokumentindekset. Eksempler på breve, der udsendes automatisk, er: - Udbetalingsspecifikationer (ved udbetaling af Ydelser). Ved udsendelse af udbetalingsspecifikationer udsendes et antal specifikationer svarende til antal igangværende sager på udbetalingstidspunktet, hvorfor masseprint er relevant. - Erklæring om oplysningspligt (udsendes regelmæssigt i sager vedrørende forsørgelsesydelser). - Brev om opfølgning på boligoplysninger (særlig støtte, LAS 34). - Se Krav# 352 om Print på Serviceplatformen. - Se Krav# 209 om den kommunale administrators opsætning af A- eller B- post. 5.4.4 Status og låsning af sager og Opgaver En sag og en Opgave kan have forskellige former for status. I dette afsnit beskrives de forskellige statusser, samt hvordan det er muligt at ændre disse. En sag i Løsningen vil altid have en status. Løsningen følger OIO Standarden eller tilsvarende for Sag (i standarden kaldes status for sagstilstande). Se afsnit 7 for referencer til OIO_SAG. Men derudover vil der være behov for at udvide med nogle yderligere substatusser. I standarden er det ikke muligt at gå tilbage i status. Denne begrænsning forestiller Kunden sig ikke kan overholdes i Løsningen, da en sag fx kan løbe over en lang periode og kan indeholde mange udbetalinger og flere genoplysninger af sagen. Kunden forestiller sig, at de specificerede statusser i standarden skal suppleres med yderligere statusser for fx at tilgodese forretningsbehovene for at kende fremdriften (eller manglen på samme) i en sag. Figur 14 viser et tilstandsdiagram med den forventede sammenhæng mellem status og statusskift. Side 114 af 257
Opstået Oplyst Afgjort Bestilt Udført Afsluttet Under oplysning [Vedligeholdelse af sagen] [Ved manuel godkendelse af udbetaling] Figurforklaring [Ved partshøring/ indhentning af supplerende oplysninger] Afventer borger OIO Sagsstatus (tilstand) KY Substatus (ikke OIO) Figur 14: Forventede sagstatusser Krav# 139: Sagsstatus (sagstilstand) Beskrivelse: Løsningen skal sikre, at der kan registreres og opdateres en status på sagen. a) En sag i Løsningen kan antage statusser beskrevet i OIO specifikationen for Sag eller tilsvarende eller løsningsspecifikke substatusser. b) Status/substatus kan registreres og ændres af Brugeren. c) Status/substatus kan registreres og ændres af automatisk på grundlag af Hændelser med relation til sagen. d) Ved kommunikation med eksterne parter benyttes altid OIO Sagstilstande eller tilsvarende e) Når der er sket et statusskift, har Løsningen registreret en Hændelse om skiftet på sagen. f) Sags- og Dokumentindekset er opdateret korrekt. - Se afsnit 7 vedrørende OIO sagsstandarden. - Se afsnit 6.3.2.3 Sags- og Dokumentindekset. Da forskellige Brugere har adgang til samme sager/opgaver, vil det være sandsynligt, at flere Brugere tilgår disse sager/opgaver samtidig. Derfor vil der være behov for at sikre sagerne og Opgaverne mod, at der opstår uoverensstemmelser i data. Krav# 140: Låsning af sager Beskrivelse: Løsningen skal sikre, at kun en enkelt Bruger kan redigere sagen ad gangen. a) Når en Bruger redigerer en sag, kan sagen og tilknyttede Opgaver læses, men ikke redigeres af andre Brugere, der tilgår sagen. b) Når en Bruger åbner en sag, der allerede redigeres af anden Bruger, viser Løsningen tydeligt, at sagen er i ikke-redigerbar tilstand og angiver, hvem der redigerer sagen. Side 115 af 257
Se informationsmodellen (KY-sag) i underbilag 2.5. Krav# 141: Låsning af Opgaver Beskrivelse: Løsningen skal sikre, at kun en enkelt Bruger kan redigere en Opgave tilknyttet en Person ad gangen. a) Når en Bruger redigerer i en Opgave, der er knyttet til en Person, kan Opgaven ikke redigeres af andre Brugere. b) Når en Bruger åbner en Opgave, der er knyttet til en Person, der allerede redigeres af anden Bruger, viser Løsningen tydeligt, at Opgaven er i ikke-redigerbar tilstand og angiver, hvem der redigerer Opgaven. - Hvis en Opgave er knyttet til en sag, sikrer låsningen af sagen, at en Opgave ikke kan redigeres af flere Brugere samtidigt. Dette krav sikrer, at Opgaver, der er tilknyttet Personen, ikke kan redigeres af flere Brugere samtidigt. - Se Krav# 15 om redigering af oplysninger på en Opgave. Krav# 142: Frigivelse af sager og Opgaver Beskrivelse: Løsningen skal sikre, at en sag eller Opgave frigives til redigering. a) Når Brugeren vælger at gå ud af sagen eller Opgaven, frigives denne, så andre Brugere kan redigere i sagen eller Opgaven. b) Hvis Brugeren en inaktiv i en vis periode, frigives sag eller Opgave til redigering af andre Brugere. - Se Krav# 140 og Krav# 141 om låsning af sag og Opgave. 5.4.5 Saml sag til afsendelse Samling af en sag kan være relevant ved fx en Persons begæring om aktindsigt, jf. lov om offentlighed i forvaltningen. Ved begæringen skal Personen have adgang til al data, herunder dokumentation, som knytter sig til sin sag. Tilsvarende kan der være behov for, fx ved en Persons flytning fra en kommune til en anden, at sende sagen til modtagende kommune. Der er i den forbindelse et behov for, at tilflytningskommunen på en let og smidig måde kan anmode om at modtage en kopi af fraflytningskommunens sag, ligesom fraflytningskommunen på en let og smidig måde kan overføre en kopi af sagen til tilflytningskommunen. Krav# 143: Saml sag og afsend Beskrivelse: En Bruger skal kunne samle sagsdata og afsende dette. a) Brugeren kan samle al sagsdata og afsende denne til en Person eller en anden kommune. Det forudsættes, at Personen har givet samtykke. Side 116 af 257
b) Brugeren skal kunne udvælge særlige dele af data på sagen til afsendelse. c) Hvis modtager er en Person, sker afsendelsen via digital post. - Særlige dele jf. pkt. b kan omfatte journalnotater, sagshistorik m.v - Se Krav# 352 om print. Krav# 144: Anmodning om overførsel af sagsoplysninger hos fraflytningskommune Beskrivelse: Brugeren i tilflytningskommunen skal i Løsningen kunne foretage en anmodning om digital overførelse af sagoplysninger hos Personens fraflytningskommune. a) Anmodningen registreres i Løsningen og oprettes som en Opgave hos fraflytningskommunen. Krav# 145: Overførsel af kopi af sag på baggrund af anmodning fra tilflytningskommune Beskrivelse: Løsningen skal understøtte, at der ved anmodning fra tilflytningskommune kan overføres en kopi af sagen. Det forudsættes, at Personen har givet samtykke. a) Brugeren kan i Løsningen, hvis der er modtaget en anmodning fra tilflytningskommunen, overføre en kopi af hele sagen eller dele af sagen til tilflytningskommunen. b) Samtykke for Personen, hvis sag skal overføres, skal registreres. c) Overførsel oprettes som en Opgave hos tilflytningskommunen indeholdende de overførte sagsdata som et PDF-dokument. - Sagen i fraflytningskommunen påvirkes ikke af kopieringen til tilflytningskommunen - Det forventes, at det er meget få oplysninger, som overføres til tilflytningskommunen, hvor de skal danne grundlag for oplysning af sagen. Oplysningerne kan ikke genbruges direkte, hvorfor en understøttelse af en digital overflytning ikke er en del af Løsningen. 5.4.6 Sammenhæng med økonomisystemer For at sikre revisionsspor og sammenhæng mellem Løsningen og det kommunale økonomisystem, skal Løsningen understøtte en række tværgående Opgaver, som vedrører de økonomiske konsekvenser af de handlinger og registreringer, der foretages i løsningen. Side 117 af 257
Krav# 146: Sporbarhed af økonomiske transaktioner Beskrivelse: Løsningen skal sikre, at alle konteringer foretaget i Løsningen og alle posteringer sendt til det kommunale økonomisystem, kan spores til en bestemt registrering i Løsningen. a) Såfremt en kontering er foretaget i Løsningen, kan den spores til den registrering i Løsningen, som er kilden. b) Såfremt en postering er dannet i Løsningen og sendt til det kommunale økonomisystem, kan posteringen spores til den registrering i Løsningen, som er kilden. c) Såfremt en postering er sendt til det kommunale økonomisystem fra Løsningen, kan posteringen i Løsningen sammenstilles med posteringerne i det kommunale økonomisystem. d) Det skal være muligt for en Bruger at fremfinde relevante oplysninger i Løsningen om posteringer og de tilhørende registreringer. Der skal kunne fremfindes ud fra følgende oplysninger: posterings-id, CPR-nummer, Ydelsesart, periode, beløb, Bruger-id. Se afsnit 6.4.3.7 om ØiR snitflade til udbetalings-, debitor- og økonomisystemer. Krav# 147: Kontototaler Beskrivelse: Løsningen skal for alle konti løbende vedligeholde totaler pr. konto. a) Brugeren skal have adgang til at aflæse totalbeløb på en konto for en valgfri periode angivet af Brugeren - Til brug for bl.a. afstemning er der særligt behov for totaler pr. måned og år for eksempelvis ydelser, indeholdt A-skat, ATP, AMB mv. Visninger Mange af de funktionelle krav indebærer implicit, at der laves en grafisk brugergrænseflade, så Brugeren kan udnytte den beskrevne funktionalitet. Der er i mange af disse tilfælde ikke lavet specifikke krav til, hvordan og hvad den grafiske brugergrænseflade skal indeholde. Der er dog en række områder, hvor Kunden har følt behov for at tydeliggøre specifikke behov til den grafiske brugergrænseflade for at sikre, at brugergrænsefladen i så høj grad som muligt understøtter Brugerens arbejde. Disse områder vil blive uddybet i dette afsnit, og dette afsnit indeholder således beskrivelser samt krav til specifikke informationer og visninger i Løsningen. Kravene Krav# 148 - Krav# 179 skal derfor læses som eksempler på løsninger, hvor Kunden forventer at kravet opfyldes, men hvis Leverandøren kan redegøre for at alternative løsningsmodeller opfylder behovet i lige så høj grad som kravbeskrivelsen, kan de alternative løsningsmodeller benyttes. Side 118 af 257
De specifikke krav til visninger i Løsningen er samlet i dette afsnit, og der vil være henvisninger til og fra de funktionelle krav, hvor visningerne er relevante. Afsnittet er opdelt i underafsnit, hvor hvert underafsnit omhandler et særligt område. Det skal tydeliggøres, at kravene i dette afsnit ikke skal ses som en fyldestgørende samlet liste over visninger i Løsningen, men blot er et udtryk for nogle særlige krav til visninger. Dette afsnit bør læses i sammenhæng med de generelle krav til brugervenlighed (jf.6.5), som på samme vis har til formål at sikre, at Løsningen understøtter Brugernes arbejde. 5.5.1 Visninger generelt Krav# 148: Angivelse af Bruger Beskrivelse: Alle skærmbilleder skal indeholde en angivelse af, hvem der er logget ind. Hvis en Bruger er logget ind med fuldmagt, skal det også fremgå af Løsningen. Krav# 149: Angivelse af Person Beskrivelse: Alle skærmbilleder vedrørende en sag skal indeholde en angivelse af, hvilken Person sagen omhandler. a) Navnet på den Bruger, der er logget ind, vises på hvert skærmbillede. b) Hvis en Bruger er logget ind med fuldmagt, skal dette ligeledes fremgå. - Bemærk, at en Bruger kun kan logge ind med fuldmagt i selvbetjeningsløsningen. Der er ikke adgang med fuldmagt til sagsbehandlingsdelen af Løsningen. a) Navn og CPR-nummer på den Person, sagen omhandler, vises på hvert skærmbillede. - Brugeren må på intet tidspunkt være i tvivl om, hvilken Person der sagsbehandles. Krav# 150: Visning af kommunenavn og logo Beskrivelse: Løsningens brugergrænseflade skal kunne vise kommunelogo og kommunenavn for den kommune, der anvender Løsningen. a) Navn samt kommunelogo (i form af et ikon) er placeret i Løsningens øverste venstre hjørne. Kunden fremskaffer logoer i passende format. b) Løsningen kan håndtere ikoner i 3 grafiske filformater, herunder JPEG, PNG og GIF. Side 119 af 257
Krav# 151: Visning af navn på Løsningen Beskrivelse: Løsningens brugergrænseflade skal kunne vise navnet på Løsningen. Løsningens navn Kommunernes Ydelsessystem er placeret øverst i Løsningens skærmbilleder. Kravet udgør et designprincip, som KOMBIT ønsker at fremme på tværs af monopolsbrudsløsningerne. Der vil i en række situationer være behov for, at sagsbehandleren kan se sagens oplysninger, som de så ud på et givet tidspunkt tilbage i tid, eksempelvis ved forespørgsler eller i forbindelse med behandling af klagesager. Dette muliggøres af de bitemporale egenskaber, som Løsningen understøtter jf. afsnit 6.2.4. Krav# 152: Visning af sagens oplysninger pr. brugervalgt dato og tid Beskrivelse: Løsningen skal kunne vise alle sagens oplysninger, som de var registreret på et givet tidspunkt, som vælges af Brugeren. a) Brugeren kan vælge en dato og tidspunkt, hvorefter Løsningen viser Brugeren, hvordan sagens oplysninger så ud på daværende tidspunkt. b) Brugeren må i denne visning ikke kunne foretage ændringer i historiske data. c) Det er tydeligt for Brugeren, at der vises historiske data. d) Brugeren kan ikke rette i historiske data i denne specifikke visning af sagens oplysninger. - Se underbilag 2.10 Eksempler på skærmbilleder afsnit 2.3 for eksempel på, hvordan Kunden kunne forestille sig en Løsning. Visse sagsbehandlere arbejder med to skærme samtidigt for at kunne håndtere de store mængder af information, der indgår i sagsbehandlingen eller for at kunne håndtere henvendelser, der ikke vedrører den sag, de aktuelt arbejder på. Krav# 153: Visning på flere skærme Beskrivelse: Løsningen skal sikre, at Brugeren kan arbejde med flere sager eller elementer af en enkelt sag på flere skærme samtidigt. a) Brugeren har mulighed for at arbejde i Løsningen med flere sager på flere skærme. b) Flg. elementer fra en sag skal som kunne vises selvstændigt: o Opgaveoversigt o Sagsoversigt Side 120 af 257
o Sagsoplysninger (sagsstatus, sagshistorik, parter) o Dokumenter på sagen o Journalnotater c) Løsningen kan gemme data, der registreres på flere skærme. - Et eksempel på en brugssituation kunne være, at sagsoplysninger vises på den ene skærm, mens sagsbehandleren skriver et journalnotat på den anden skærm. Et andet eksempel kunne være, at sagsbehandleren er i gang med at behandle en sag, men bliver ringet op af en Person. Så slår sagsbehandleren denne Persons sag op i et nyt vindue, så det ikke er nødvendigt at lukke den sag, som sagsbehandleren var i gang med at behandle. - Se underbilag 2.10 Eksempler på skærmbilleder afsnit 2.4 for uddybning af, hvad Kunden forestiller sig. - Se informationsmodellen (KY-Sag) i underbilag 2.5, ift. punktet Sagsoplysninger. Krav# 154: Filtrering og søgning i opgaveoversigt Beskrivelse: Brugeren kan filtrere og søge i opgaveoversigten 5.5.2 Visninger i forhold til opgaveoversigten Dette afsnit indeholder krav til visning af opgaveoversigten i Løsningen. Se afsnit 5.1 for uddybning af funktionaliteten vedrørende Opgaver. Opgaveoversigten skal give overblik over de Opgaver, Brugeren skal løse samt mulighed for at hurtigt at fordele Opgaver til andre sagsbehandlere i Ydelsescentret. a) Brugeren kan filtrere Opgaver fra, så disse ikke vises. b) Brugeren kan filtrere på flere forekomster i samme kolonne og/eller filtrere på flere kolonner samtidig. c) Brugeren kan filtrere ud fra et eller flere af nedenstående intervaller: o Fødselsdatointervaller: på både dag, måned og år o Dato for oprettelse: periode o Deadline for løsning: periode d) Brugeren kan søge i opgavelisten. - Med filtrering på flere forekomster i samme kolonne menes eksempelvis, at der kan filtreres, så der kun vises Ydelsesarter, der enten er Kontanthjælp eller Enkeltydelse. Dette vil give sagsbehandlerne en mere fleksibel måde at filtrere irrelevante Opgaver fra. - Se Krav# 11 for hvilke informationer en Opgave indeholder - Se underbilag 2.10 Eksempler på skærmbilleder afsnit 2.1.2 for eksempel på, hvordan Kunden kunne forestille sig en løsning. Side 121 af 257
Krav# 155: Individuel standardfiltrering/søgning i opgavelisten Beskrivelse: Det er muligt for den enkelte Bruger at opsætte og gemme sin egen standardfiltrering/søgning. a) Brugeren kan gemme og slette egne individuelle filtreringer/søgninger. b) De individuelle filtreringer/søgninger er tilgængelige næste gang Brugeren logger på Løsningen. c) Brugeren kan vælge en af de individuelle filtreringer/søgninger, som opgavelisten åbner som standard, når Brugeren åbner opgavelisten. d) De individuelle filteringer/søgninger kan være en kombination af alle de forskellige filtreringer/søgninger beskrevet i Krav# 154. Krav# 156: Individuel opsætning af oplysninger på opgavelisten Beskrivelse: Brugeren kan individuelt konfigurere hvilke oplysninger, der vises på opgavelisten. a) Brugeren kan vælge hvilke oplysninger, der vises på Brugerens opgaveliste, blandt alle de oplysninger, der kan være på en Opgave. b) Denne opsætning kan gemmes som standardopsætning for den enkelte Bruger. - Fx kan man forestille sig at en Bruger ikke ønsker at se oplysninger om, hvilket team Opgaven er tildelt, hvis kommunen ikke arbejder med teams. Man kunne også forestille sig, at en Bruger ikke ønsker at se Ydelse sat på hold, hvis denne Bruger udelukkende arbejder med enkeltydelser. - Se Krav# 11 hvilke oplysninger en Opgave indeholder. 5.5.3 Visninger i forhold til behandling af sager Krav til behandling af sager ses i afsnit 5.2. Dette afsnit indeholder de specifikke krav til visninger hertil: herunder oplysning af sag, fastsættelse af Ydelsessats og beregning af Ydelse, træf afgørelse, effektuer, vedligeholdelse af sag samt afslut og arkiver sag. Meget af sagsbehandlerens arbejde vil foregå i forbindelse med oplysning af sagen, hvor sagsbehandleren vurderer de eksisterende oplysninger, vurderer eventuelle uoverensstemmelser, indberetter nye oplysninger osv. For at Løsningen kan understøtte sagsbehandlerens arbejde, er det helt centralt, at der skabes nogle gode overbliksgivende skærmbilleder, hvor der både er let adgang til at indberette, men hvor det også er hurtigt at danne sig overblik over eventuelle manglende oplysninger osv. Side 122 af 257
Krav# 157: Vis sagsoversigt Krav# 158: Filtrering og sortering i sagsoversigt Beskrivelse: Brugeren skal kunne filtrere og sortere kolonnerne i sagsoversigten. Beskrivelse: Løsningen skal kunne vise en oversigt over sager i Løsningen. a) Sagsoversigten skal vise flg. oplysninger: Ydelsesart, startdato for Ydelse, ansøgningsårsag, nettobeløb på seneste udbetaling, CPR-nummer og navn på Person, CPR-nummer på Ægtefælle, sagsstatus og sagsbehandler/team på sagen. b) Løsningen skal give mulighed for at Brugeren ved en simpel handling kan få detaljeret en oplysning i sagsoversigten uden at åbne sagen. Løsningen skal kunne vise flg. detaljer om beløbet på den seneste udbetaling: udbetalingsdato, udbetalingsperiode, bruttobeløb, tilbageholdt skat og tilbageholdt ATP, udbetalt til NemKonto eller specifik konto, paragraf, som den seneste udbetaling sket efter, ubehandlet sanktion på sagen. - Se Krav# 8 om fremsøgning af sager. a) Filtrere på en eller flere kolonner i sagsoversigten. b) Sortere indholdet i en kolonne. Krav# 159: Individuel standardvisning af sagsoversigt Beskrivelse: Det er muligt for den enkelte Bruger at opsætte og gemme sin egen standardvisning af sagsoversigten. a) Brugeren kan oprette eller slette en standardvisning af sagsoversigten med eventuelle filtreringer. b) Standardvisningen vises som default for Brugeren, når sagsoversigten vises. c) Brugeren kan fravælge visningen af standardvisningen. Side 123 af 257
Krav# 160: Overblik over sagens oplysninger Beskrivelse: Løsningen skal vise sagens oplysninger (de indberettede, indhentede samt modtagne og beregnede), således at Brugeren får et overblik over de relevante oplysninger. a) Overblikket skal indeholde oplysninger om SagsID, CPR-nummer, parter på sagen, sagsstatus, aktive Opgaver og tilknyttet sagsbehandler. b) Oplysningerne grupperes i samarbejde med Brugerne, så det understøtter Brugernes arbejdsgang. c) Der kan hentes og vises en oversigt over en Persons Ydelser fra Ydelsesindekset. - Se Krav# 26, Krav# 29, Krav# 30 og Krav# 35 samt Krav# 258 Krav# 259, Krav# 260, Krav# 261, Krav# 262, Krav# 269 og Krav# 320 for eksempler på relevante oplysninger. - Se underbilag 2.10 Eksempler på skærmbilleder afsnit 2.2 og 2.4 for inspiration. - Se afsnit 5.4.4 vedrørende sagsstatus Ved nogle Ydelsesarter skal Ægtefællens forhold oplyses i samme detaljegrad som for Personen, der ansøger. Der er derfor behov for, at sagsbehandleren har et let overblik over begge Ægtefællers forhold. I særlige tilfælde på uddannelseshjælp eller kontanthjælp kan den ene Ægtefælle desuden modtage uddannelseshjælp eller kontanthjælp på baggrund af den anden Ægtefælles ansøgning om uddannelseshjælp eller kontanthjælp, og er således ikke selv ansøger. I dette særtilfælde skal det være tydeligt på sagen, hvilken af de to Personer, der har ansøgt og hvilken Person, der ikke har ansøgt om Ydelsen. Krav# 161: Overblik over Ægtefællens oplysninger Beskrivelse: I Løsningens visning af sagens oplysninger, skal der være let adgang til visning af oplysninger om Personens Ægtefælle. a) Oplysninger om Ægtefælle fremgår tydeligt af sagen på sager med gensidig forsørgelse. b) Det fremgår tydeligt af sagen, om Personen har ansøgt om Ydelsen eller om Personen modtager Ydelsen på baggrund af Ægtefællens ansøgning. - Se Krav# 30 vedrørende oplysninger om Ægtefælle. I forbindelse med nogle af de forsørgelsesydelser, som håndteres i Løsningen, kan Personen og eventuelt dennes Ægtefælle sanktioneres økonomisk. I disse sager vil der være behov for, at Brugeren kan få et overblik over de sanktioner, der indgår i sagen. Krav# 162: Overblik over sanktioner i sagen (Sanktionsoverblik) Beskrivelse: Det skal være muligt for en Bruger at se et overblik over alle sanktioner og sanktionsindstillinger i en eller flere sager for Personen, som er primær part i sagen, og dennes Ægtefælle. Side 124 af 257
a) Alle indstillinger om sanktioner er tilgængelige for en Bruger i et samlet overblik. b) Brugeren kan filtrere og sortere, hvilke sanktioner og sanktionsindstillinger, der vises, ud fra Person, sag, typer af sanktion, registreringsperioder, udbetalingsperioder og status på sanktionerne/indstillingerne. c) Brugeren kan navigere direkte fra overblikket til detailoplysningerne om den enkelte sanktion eller sanktionsindstilling. d) Brugeren kan navigere direkte til at træffe afgørelse om sanktionen. - Se Krav# 61 vedrørende afgørelse om sanktion. Krav# 163: Visuel markering af uoverensstemmelser i oplysninger Beskrivelse: Løsningen skal tydeligt vise eventuel uoverensstemmelse mellem de indberettede og de indhentede oplysninger. - Se Krav# 31 vedrørende valg af gældende oplysninger ved uoverensstemmelser. - Se underbilag 2.10 Eksempler på skærmbilleder afsnit 2.5 for eksempel på, hvordan Kunden kunne forestille sig en Løsning. Fastsættelse af Ydelsessats og beregning af Ydelsen (jf. afsnit 5.2.2) foretages af Løsningen. Det skal derfor være muligt for Brugeren at se, hvordan Løsningen er nået frem til resultatet i forhold til fastsættelsen og beregninger. Det skal være så udførligt beskrevet, at Brugeren uden større regneøvelser efterfølgende er i stand til at forklare Personen, hvorfor resultatet ser ud, som det gør. Krav# 164: Visning af specifikation af beregningsgrundlag Beskrivelse: En Bruger skal i løsningen kunne se et skærmbillede med en specifikation af en forventet eller foretaget udbetaling sammen med de beregninger, der ligger til grund for en udbetaling. a) Brugeren kan se en specifikation af en forventet eller foretaget udbetaling sammen med de beregninger, der ligger til grund for en udbetaling. b) Specifikationen skal indeholde de mellemresultater, som følger af Lovgivningens regler for fastsættelse af Ydelsessats, tillæg/fra-drag, sanktioner mv. c) De enkelte fradrag til en administrationsordning skal ligeledes fremgå. - Se Krav# 43 og Krav# 44 vedrørende beregning af Ydelse. - Se Krav# 46 og Krav# 47 vedrørende fastsættelse af Ydelsessats og beregning af beløb. - Se eksempel på anvisningsrapport i underbilag 2.9 vedrørende specifikationsniveauet. - Se underbilag 2.8 vedrørende relevant faglovgivning. Side 125 af 257
Der vil være situationer, hvor den samme Person er part på flere sager i Løsningen. Dette kan være relevant information for sagsbehandleren i forhold til vurderingen af en sag. Fx er det relevant at vide, at der allerede eksisterer en kontanthjælpssag, hvis den samme Person søger om en enkeltydelse. Krav# 165: Visning og adgang til relaterede sager Beskrivelse: Hvis en part i sagen (Personen, Ægtefælle, børn) også er part i andre sager i Løsningen, gøres Brugeren visuelt opmærksom på dette. Brugeren har mulighed for direkte at navigere til de relaterede sager. - Se underbilag 2.10 Eksempler på skærmbilleder afsnit 2.2 for inspiration. Når en Bruger slår op på en sag (fx fordi en Person ringer til Ydelsescentret), skal det via selve sagen være tydeligt for Brugeren, hvis der eksisterer aktive Opgaver på sagen. De skal dermed ikke behøve at gå ind på opgavelisten for at se, om sket noget nyt på sagen eller for at ændre en Opgaves status. Da den samme Opgave kan være relevant for flere sager (fx er behandling af en flyttemeddelelse både relevant for Personens enkeltydelsessag og Personens kontanthjælpssag), skal Opgaverne vises på tværs af sager, så alle Opgaver vedrørende parten i sagen vises. Krav# 166: Visning af aktive Opgaver samt opgavestatus på sagen Beskrivelse: Brugeren har let adgang fra den enkelte sag til at se hvilke aktive Opgaver, der eksisterer på sagen samt Opgavernes status. a) Brugeren kan på den enkelte sag se, hvilke aktive Opgaver, der er knyttet til sagen. Hvis Personen både har en kontanthjælpssag og en enkeltydelsessag, så vises Opgaverne fra begge sager lige meget, hvilken sag sagsbehandleren kigger på. b) Brugeren kan se alle Opgaver på tværs af alle sager i Løsningen c) Gamle Opgaver, der allerede er blevet behandlet, bør ikke vises på sagsoverblikket, men kan ses på sagshistorikken (jf. afsnit 5.5.4). - Se Krav# 25 vedrørende ændring af opgavestatus. - Se underbilag 2.10 Eksempler på skærmbilleder afsnit 2.2 for inspiration. Krav# 167: Visning og registrering af mellemkommunal refusion samt klagesag Beskrivelse: Brugeren kan registrere på sagen, at der findes en mellemkommunal refusionssag og/eller en klagesag med relation til sagen. a) Brugeren kan registrere på sagen, at sagen har en tilhørende mellemkommunal refusionssag relateret til denne sag. Side 126 af 257
b) Brugeren kan registrere på sagen, at sagen har en tilhørende klagesag relateret til denne sag. - Registeringen af en tilknyttet mellemkommunal refusionssag eller klagesag kan fx ske ved angivelse af et sagsnummer på den relaterede sag. - Registreringen af både mellemkommunal refusion og klagesager har ikke direkte indflydelse på sagen i Løsningen, men er blot en registrering af, at der eksisterer en klagesag/mellemkommunal refusionssag. Disse typer af sager vil befinde sig i et andet kommunalt it-system. Typisk i kommunens ESDH. Krav# 168: Visning af særlige adresser samt navne- og adressebeskyttelse Beskrivelse: Det markeres visuelt på sagen, hvis Personen er bosat på en af adresserne fra listen med særlige adresser og/eller ved navne og adressebeskyttelse. a) Det markeres visuelt på sagen, hvis Personen er bosat på en af adresserne fra listen med særlige adresser. b) Er Personen omfattet af navne- og adressebeskyttelse i CPR, skal dette markeres visuelt, så Brugeren tydeligt kan se, at adressen er hemmelig. c) Ved et enkelt tastetryk/klik skal Brugeren kunne få adgang til Personens navn og adresse. d) I oversigter over sager og Opgaver samt øvrige lister med navn og adresse, må navn og adresse ikke være synlige. Brugeren skal dog kunne få vist navn og adresse ved enkel handling i Løsningen. e) Ved udskrivning af lister, skal navne- og adressebeskyttelsen fastholdes. f) Ved udskrivning af breve skal navn og adresse fremgå af brevet. - Se Krav# 214 vedrørende vedligehold af særlige adresser. - Den påloggede sagsbehandler (Ydelscentret) med rettighed til at læse sagen, skal kunne se en Persons navn og adresse. Markeringen af navne- og adressebeskyttelse skal sikre, at Personens navn og adresse ikke vises til andre Personer. Under sagsbehandlingen benytter kommunerne forskellige former for interne vejledninger, tjeklister, links mm. Der bør i Løsningen være en fleksibel måde for den enkelte kommune at give deres sagsbehandlere let adgang til disse informationer. Ofte vil et link til en hjemmeside eller et dokument være tilstrækkeligt. Krav# 169: Links og lokale vejledninger Beskrivelse: Der er let adgang for Brugeren for at tilgå lokale vejledninger eller websites via links opsat af den kommunale administrator. Side 127 af 257
- Se Krav# 213 vedrørende opsætning af links, vejledninger. 5.5.4 Visning af Sagshistorik og Udbetalingshistorik Brugeren kan under sagsbehandlingen have behov for at se forskellige typer af historik på sagen. Følgende krav er specifikke krav i forhold til at understøtte sagsbehandlerens arbejdsopgaver. Sagshistorikken skal give sagsbehandleren et samlet overblik over, hvad der er sket i sagen. Sagshistorikken skal således indeholde alt relevant i forhold til at danne sig et overblik over sagen. Typisk sorteret i kronologisk orden. Krav# 170: Visning af sagshistorik Beskrivelse: Brugeren kan se et samlet overblik over alle Hændelser i sagen via sagshistorik. a) Brugeren kan se et samlet overblik over, hvad der er sket i sagen via sagshistorik. b) Sagshistorikken indeholder følgende oplysninger: a) Hændelsesdato og hændelsesnavn med angivelse af, hvem der er ansvarlig for oprettelse/redigering af journalnotater b) Hændelsesdato og hændelsesnavn samt værdi for tidligere og nuværende status med angivelse af, hvem der er ansvarlig for statusskift på sagen c) Hændelsesdato og hændelsesnavn samt værdi for tidligere og nuværende status med angivelse af, hvem der er ansvarlig for statusskift på Opgaven d) Løsningens automatiske registreringer af Hændelser samt hændelsesbeskedens indhold, dog ikke Hændelser hvor der er fravalgt visning af den kommunale administrator grundet lav grænseværdi. Hændelsen indeholder hændelsesdata, hændelsesnavn samt indhold med angivelse af, hvem der er ansvarlig for Hændelsen. e) Hændelsesdato og hændelsesnavn for modtagne dokumenter f) Hændelsesdato og hændelsesnavn afsendte dokumenter g) Hændelsesdato og hændelsesnavn for alle Beskeder fra jobcentret. - Se afsnit 5.4.2 vedrørende noter/journalnotater og automatiske registreringer af Hændelser. - Se afsnit 5.4.4 vedrørende sags og opgave status. - Se krav Krav# 186 vedrørende Hændelser der ikke skal vises - Se afsnit 5.9.1 vedrørende Beskeder fra Jobcentret. - Se underbilag 2.10 Eksempler på skærmbilleder afsnit 2.6 for inspiration. Side 128 af 257
Krav# 171: Søgning og filtrering i sagshistorikken Beskrivelse: I sagshistorikken er det muligt at sortere, filtrere og søge. a) Brugeren kan sortere og filtrere i sagshistorikken o Der kan sorteres og filtreres på dato for oprettelse, type, sagsbehandler og Hændelse. Der kan filtreres ud fra intervaller i dato for oprettelse b) Brugeren kan søge i sagshistorikken o Der kan søges på dato og anvendes fritekstsøgning. - Se underbilag 2.10 Eksempler på skærmbilleder afsnit 2.6 for inspiration. For at understøtte Brugerens arbejde skal der være et overbliksbillede, der viser udbetalinger til Personen. Dette inkluderer også udbetalinger til Personen på tværs af sager. Brugeren tilgår udbetalingshistorikken via den enkelte sag, men udbetalinger til samme Person i andre sager vises også. Krav# 172: Overblik og historik på udbetalinger i sagen (Udbetalingshistorik) Beskrivelse: Det skal være muligt for en Bruger at se et overblik over alle betalinger for en Person samt dennes Ægtefælle. a) Brugeren kan se et overblik over alle betalinger for en Person samt dennes Ægtefælle. b) Oversigten skal vise betalinger, som er til Personen selv eller til Alternativ Modtager. c) Samtlige udbetalinger, Personen har modtaget og den kommende udbetaling, vises med angivelse af, om udbetalingen er frigivet eller tilbageholdt. Dette gælder også på tværs af sager. d) Fra overblikket er der direkte adgang til den enkelte udbetalings-specifikation. - Med samtlige udbetalinger Personen har modtaget, også på tværs af sager (jf. punkt C) menes, at udbetalinger fra alle sager skal vises på samme overblik. Altså også selvom udbetalingerne er fra forskellige sager (eksempelvis en kontanthjælpssag, en enkeltydelsessag) og Ydelsescentret samtidig administrerer vedkommendes økonomi. - Se Krav# 75 vedrørende udbetalingsspecifikationer. Krav# 173: Filtrering og sortering i Udbetalingshistorik Beskrivelse: Det skal være muligt at filtrere og sortere hvilke betalinger, der vises i udbetalingshistorikken a) Brugeren kan sortere og filtrere i udbetalingshistorikken. Side 129 af 257
b) Der kan sorteres og filtreres ud fra sagsparter, sager, typer af udbetaling, registreringsperioder, udbetalingsperioder og status på udbetalingerne. Krav# 174: Overblik og historik på konteringer i sagen (Konteringshistorik) Beskrivelse: Det skal være muligt for en Bruger at se et overblik over alle konteringer for en sag. - Dette overblik kan anvendes af Brugeren eksempelvis i forbindelse med manuel omkontering. - se Krav# 86 vedrørende manuel omkontering. Krav# 175: Filtrering og sortering i Konteringshistorik Beskrivelse: Det skal være muligt at filtrere og sortere konteringer i konteringshistorikken. a) Der kan sorteres og filtreres ud fra kontonumre, perioder og beløb. 5.5.5 Visninger vedrørende administrationssager Krav til administrationssager ses i afsnit 5.3. Dette afsnit indeholder de specifikke krav til visninger hertil. Krav# 176: Overblik over administrationsordning Beskrivelse: Det skal være muligt for en Bruger at se et overblik over administrationsordningen. a) Brugeren kan se et overblik over administrationsordningen med alle administrationsplaner, betalingsaftaler og rateudbetalingsplaner samt saldo på ordningen. b) Der er direkte adgang fra overblikket til detaljerne om de enkelte administrationsplaner, betalingsaftaler og rateudbetalingsplaner og tilhørende effektueringer. c) Brugeren har mulighed for at filtrere og sortere hvilke administrationsplaner, betalingsaftaler og rateudbetalingsplaner, der er på sagen. d) Der kan filtreres og sorteres ud fra valg af typer, perioder og status. Side 130 af 257
5.5.6 Visninger i forhold til breve og brevskabeloner Krav til breve og brevskabeloner ses i afsnit 5.4.3. Dette afsnit indeholder de specifikke krav til visninger hertil. Krav# 177: Overblik over brevskabeloner Beskrivelse: Brugerne skal have adgang til et samlet overblik over tilgængelige brevskabeloner. a) Brugeren har adgang til et samlet overblik over tilgængelige brevskabeloner. b) Overblikket bør indeholde kategori, art (om den er central eller lokal), dato for oprettelse/redigering og titel. c) Fra overblikket kan Brugeren tilgå og benytte skabelonerne som beskrevet i Krav# 129. - Se underbilag 2.10 Eksempler på skærmbilleder afsnit 2.7 for inspiration. Visse handlinger foretaget i Løsningen vil altid betyde, at der skal sendes et brev. Fx skal der altid sendes et brev, når sagsbehandleren afslår en ansøgning. I disse tilfælde skal det ikke være nødvendigt for Brugeren at gå til skabelon-overblikket (jf. Krav# 177). Her er der direkte link til den relevante skabelon. Så hvis sagsbehandleren under behandling af en kontanthjælpsansøgning afslår ansøgningen, skal der være direkte adgang til et kontanthjælps-afslagsbrev. Krav# 178: Direkte adgang til brevskabeloner Beskrivelse: Når Brugeren træffer en afgørelse, skal der alt efter Ydelsesarten og afgørelsens resultat være direkte adgang for Brugeren til den relevante brevskabelon. a) Når Brugeren træffer en afgørelse, skal der alt efter Ydelsesarten og afgørelsens resultat være direkte adgang for Brugeren til den relevante brevskabelon. b) Hvis der eksisterer en lokal version af brevskabelonen, skal den lokale version benyttes. - Se Krav# 129 om udarbejdelse af breve samt Krav# 130og Krav# 131 vedrørende brug af brevskabeloner. Krav# 179: Overblik over afsendte breve Beskrivelse: Brugeren skal have adgang til et samlet overblik over de afsendte breve på sagen. a) Brugeren har adgang til et samlet overblik over de afsendte breve på den enkelte sag. Side 131 af 257
b) Det fremgår, om brevet er sendt via Digital Post, om brevet er sendt via almindelig papirpost eller om brevet er udleveret til Personen personligt. c) I tilfælde af at brevet er sendt via papirpost, fremgår det, om brevet er sendt med A- eller B-post, samt om det er sendt som anbefalet eller krav om afleveringsattest. d) Der er via overblikket direkte adgang til, at Brugeren kan se de afsendte breve. - Se Krav# 137 vedrørende valg af lokal print. - Se Krav# 135 vedrørende valg af A- og B-post samt anbefalede breve. - Se Krav# 352 vedrørende Print på Serviceplatformen. Systemadministration I dette afsnit beskrives krav til forskellige former for konfigurationsmuligheder. Der vil både indledningsvist og i resten af Løsningens levetid være behov for at kunne foretage konfigurering af stamdata, regler, parametre, defaultværdier mv., som anvendes af Løsningen eksempelvis ved valideringer, beregninger og kontering. Mange af disse oplysninger skal konfigureres på centralt niveau, så det sikres, at de gælder for alle kommuner, og at ændringer slår igennem i alle kommuner. Her er typisk tale om satser og grænseværdier, der er fastsat ved lov, og som forventes at blive ændret regelmæssigt, eksempelvis ved årlige bekendtgørelser. Disse oplysninger forventes at blive vedligeholdt samlet på vegne af alle kommuner af en central administrator-funktion, der er placeret samlet i én organisatorisk enhed. Dertil kommer en række oplysninger, som skal konfigureres på kommunalt niveau, så de gælder for Brugere af Løsningen inden for den pågældende kommune. Det kan eksempelvis være sagsbehandlingsfrister, der afspejler kommunens serviceniveau eller underopdeling af den fælles kontoplan for at understøtte den kommunale økonomistyring. Disse oplysninger forventes at blive vedligeholdt af en kommunal administrator, der udpeges af den enkelte kommune. De to niveauer skal generelt understøtte kommunernes forskellige praksis samtidig med, at den samlede vedligeholdelse af Løsningen lettes. Afsnittet er inddelt i grupperinger af krav, som hænger funktionelt sammen. Nedenstående Figur 15 viser, hvilke grupperinger afsnittet er inddelt i. Tallet i boksen svarer til underafsnittet. Side 132 af 257
5.6 Generelle konfigurationer 5.6.1 Opgaver og vedligeholdelse af sag 5.6.2 Ydelser, regler og beregninger 5.6.3 Brevskabeloner 5.6.4 Journalnotater 5.6.5 Andet Figur 15: Oversigt over afsnit i Systemadministration Det er Kundens forventning, at når der foretages ændringer i konfigurationerne (både lokalt og centralt), så vil disse ændringer træde i kraft på virkningsdatoen uden Leverandørens indblanding (fx skal Leverandøren ikke foretage kodeændringer, der skal ikke deployes ny version af Løsningen, der skal ikke foretages nye installering osv.). Hvis en konfiguration ændres med ikrafttrædelse pr. dags dato eller tidligere, så forventer Kunden ikke at dette afspejles øjeblikkeligt for en Bruger som har en sag åben som er påvirket af ændringen. Her vil det være acceptabelt at Brugeren skal åbne sagen eller Løsningen igen for benytte den ændrede konfiguration. Det skal desuden være muligt altid at se, hvornår en konfigurationsændring er trådt i kraft. Krav# 180, Krav# 181, Krav# 182, Krav# 183 og Krav# 184 er således gældende for samtlige krav i afsnit 5.6. Krav# 180: Konfigurationer træder i kraft uden Leverandørens indblanding Beskrivelse: Når der foretages en konfigurationsændring, skal denne træde i kraft uden Leverandørens indblanding. Dette krav er gældende for samtlige krav i afsnit 5.6. Krav# 181: Konfigurationer skal have virkningsdato Beskrivelse: Alle konfigurationsændringer skal have en virkningsperiode, som kan sættes af administratoren. Konfigurationsændringen skal slå igennem fra den dato hvor virkningsperioden er sat til at starte, og konfigurationsændringen skal stoppe (såfremt der er sat en slutdato) på den dato hvor virkningsperioden er sat til at slutte. Dette krav er gældende for samtlige krav i afsnit 5.6. Side 133 af 257
Når der foretages en konfigurationsændring, skal det ved samtlige konfigurationskrav være muligt at se historikken på konfigurationsændringer. Fx skal det være muligt at se, hvornår en given sats er blevet ændret, hvornår der er blevet redigeret i en brevskabelon osv. Krav# 182: Mulighed for at se historik på konfigurationsændringer Beskrivelse: Det er muligt for den kommunale administrator at se hvilke konfigurationsændringer, der er foretaget i kommunen samt deres virkningsperiode. Den centrale administrator kan se alle konfigurationsændringer og deres virkningsdato. Dette krav er gældende for samtlige krav i afsnit 5.6. Mange af de efterfølgende systemadministrationskrav er kun relevante for enten den lokale eller centrale administrator. Men i nogle krav vil de centrale og lokale konfigureringer omhandle det samme. Et eksempel er brevskabeloner, hvor der både kan eksistere centrale og lokale brevskabeloner for samme brev. Her bør det ikke være muligt for en kommunal administrator at ændre eller overskrive den centrale skabelon (da de andre kommuner derved ville blive påvirket af denne ændring). Men hvis der eksisterer en lokal brevskabelon, så er det den skabelon, Løsningen skal benytte. Samme princip skal benyttes ved fx konfigurering af interne regler samt konfigurering af Ydelser. Krav# 183: Centrale versus lokale konfigurationer Beskrivelse: I de tilfælde, hvor de centrale og lokale konfigurationer omhandler samme data, skal det være klart, hvilke konfigurationer der træder i kraft. a) De centrale konfigurationer kan aldrig ændres af lokale konfigurationer. b) Hvis der i en kommune er opsat lokale konfigurationer, skal disse have forrang frem for de centrale konfigurationer i den pågældende kommune. c) Dette krav er gældende for samtlige krav i afsnit 5.6. - Vær opmærksom på at det er den enkelte kommunes ansvar, at de lokale konfigurationer er lovmedholdelige. Krav# 184: Konfigurationer anvendes i alle funktioner Beskrivelse: Når en parameter er konfigureret, skal den anvendes af Løsningen i al behandling af sager, herunder ved beregning, kontering og effektuering. a) Centrale konfigurationer anvendes generelt i Løsningen. b) Kommunale konfigurationer anvendes inden for den pågældende kommune. c) Dette krav er gældende for samtlige krav i afsnit 5.6. Se afsnit 5.6 om centrale vs. kommunale konfigurationer. Side 134 af 257
5.6.1 Opgaver og vedligeholdelse af sag Kommunerne har forskellig praksis på en række områder. Derfor er der behov for, at den enkelte kommune kan opsætte, hvordan Løsningen skal reagere på givne Hændelser. Det kan være forskelligt fra kommune til kommune, hvilke Hændelser kommunen ønsker, at Løsningen skal danne en Opgave ud fra. Derfor skal det være muligt for kommunen at til- og fravælge, hvilke Opgaver der skal dannes. På samme måde kan det være forskelligt, om kommunen ønsker, at en Hændelse skal kunne stoppe den automatiske udbetaling. Krav# 185: Konfigurering af opgaveoprettelse Beskrivelse: Den kommunale administrator kan konfigurere, hvilke Hændelser Løsningen skal oprette Opgaver ud fra samt, hvorvidt Hændelsen skal stoppe den automatiske udbetaling. a) Den kommunale administrator kan ud fra hver Hændelse konfigurere, hvorvidt der skal dannes en Opgave b) Den kommunale administrator kan ud fra hver Hændelse konfigurere, hvorvidt Hændelsen skal stoppe den automatiske udbetaling. c) Begge ovenstående punkter kan konfigureres for hver enkelt Ydelsesart. - Jf. punkt c: med konfigurering for hver enkelt Ydelsesart menes, at det kan konfigureres for hver Hændelse for hver Ydelsesart. Eksempelvis en Hændelse vedrørende børnefødsel medfører en Opgave, hvis det drejer sig om en kontanthjælpssag, men ikke hvis den samme Hændelse drejer sig om en revalideringssag. - I underbilag 2.13 ses hvilke Hændelser der som udgangspunkt vil udløse en Opgave samt stoppe den automatiske udbetaling. Krav# 186: Opsætning af grænseværdier for visning af Hændelser Beskrivelse: Den kommunale administrator skal for alle Hændelser, der vedrører ændring af et beløb, kunne angive et minimumsbeløb for visning af Hændelsen, således at hvis beløbet i Hændelsen er mindre end minimumsbeløbet, så vises Hændelsen ikke i Løsningen. a) Minimumsbeløbet for visning kan angives for flg. Hændelser: - Start eller ændring af indkomst - Feriepenge udbetalt - Ændring i boligstøtte - Ændring i social pension - Overskydende skat Bemærkning - Se Underbilag 2.13 Hændelsesliste. Side 135 af 257
- Bemærk at der kun skal vises hændelser for ydelser, der ikke er effekturet via Løsningen, fx skal der ikke dannes hændelser for udbetalt kontanthjælp. Løsningen filtrerer på indkomstart og type, og hændelser genereret af indberetninger fra angivne SE numre skal kunne udelades. Krav# 187: Konfigurering af fordelingsnøgler Beskrivelse: Den kommunale administrator kan konfigurere, hvilke fordelingsnøgler kommunen vil fordele Opgaver efter. a) Fordelingsnøglerne kan opsættes for hver enkel Ydelsesart. b) Det er for hver Ydelsesart muligt at benytte flere fordelingsnøgler i kombination. c) Hvis der benyttes flere fordelingsnøgler, skal den kommunale administrator kunne vælge hvilke fordelingsnøgler, der først træder i kraft. d) Det kan opsættes, hvilke sagsbehandlere/teams de forskellige Opgaver fordeles til ud fra fordelingsnøglerne - Med opsættes for hver enkel Ydelsesart menes, at der eksempelvis kan benyttes en fordelingsnøgle for kontanthjælp og en anden for revalideringsydelse. - Med mulighed for at benytte flere fordelingsnøgler i kombination menes, at der fx kan benyttes både områdedelt samt CPR-opdeling. - Se Krav# 19 vedrørende fordelingsnøgler. Krav# 188: Konfigurering af deadline for Opgaver Beskrivelse: Den kommunale administrator kan opsætte hvilke deadlines, der er for de forskellige opgavetyper. Deadlines kan for samme opgavetype differentieres på Ydelsesart. - Med differentieres på Ydelsesart menes, at deadlines kan være forskellige i forhold til Ydelsesarter, så det skal være muligt at opsætte deadlines i kombination af opgavetype og Ydelsesart. Fx kan det tænkes, at der er forskellige deadlines for behandling af en flyttemeddelelse, hvis det drejer sig om en kontanthjælpssag i forhold til en enkeltydelsessag. - Se Krav# 11 vedrørende informationer på en opgave. Krav# 189: Vedligeholdelse af standardopgaver Beskrivelse: Den kommunale administrator kan oprette, slette og redigere standardopgaver som efterfølgende kan benyttes af Brugeren Side 136 af 257
a) En standardopgave kan indeholde samme data som beskrevet i Krav# 11. - Se Krav# 13 vedrørende hvordan Brugeren benytter en standardopgave. Krav# 190: Central konfigurering af interne regler Beskrivelse: Den centrale administrator skal kunne konfigurere en række parametre for de interne regler beskrevet i underbilag 2.13. a) Den centrale administrator kan konfigurere flg. parametre: A. Folkepensionsalder for bestemte grupper af fødselsdatoer B. Fleksydelsesalder for bestemte grupper af fødselsdatoer C. Efterlønsalder for bestemte grupper af fødselsdatoer D. Tidspunkt for ændring af ledighedsydelse pga. fleksydelsesalder E. Tidspunkt for satsændring F. Tidspunkt for overgang til ej-forsørgersats G. Antal måneders ledighedsydelse indenfor seneste antal måneder H. Grænse for modtagelse af revalideringsydelse I. Antal børn i forhold til træk i ydelsen grundet forskudsvist udlagt børnebidrag J. Antal måneder med høj særlig støtte eller antal måneder indenfor antal måneder med kontanthjælp eller særlig støtte K. Antal år i integrationsperioden M. Antal uger med sanktion LAS 42.1 N. Antal uger med sanktion LAS 42.2 O. Antal uger med sanktion LAS 42.3 I Afklaringsfasen defineres yderligere 1-5 parametre. Se Krav# 92 vedrørende interne regler. Krav# 191: Lokal konfigurering af interne regler Beskrivelse: Den kommunale administrator skal kunne konfigurere en række parametre for de interne regler beskrevet i underbilag 2.13. a) Den kommunale administrator kan konfigurere flg. parametre: A. Opfølgningsfrister pr. Ydelsesart B. Tidsfrist for modtagelse af svar ved oplysningspligt C. Tidspunkt for udsendelse af kontoudtog til Person under administration Side 137 af 257
D. Tidsfrist for modtagelse af svar på partshøring I Afklaringsfasen defineres yderligere 1-5 parametre. - De relevante regler og parametre kunne fx dreje sig om: - Opfølgningsfrister (skal sættes op på hver enkelt Ydelsesart). - Tidsfrister i forhold til svar på partshøring og indhentning af supplerende oplysninger. - Se Krav# 92 vedrørende interne regler. 5.6.2 Ydelser, regler og beregninger Der vil både ved ibrugtagning og i den løbende drift af Løsningen være behov for at kunne oprette og ændre på stamdata og regler, særligt beregnings- og konteringsregler, for de Ydelser, som Løsningen kan behandle. Det er afgørende, at disse ændringer kan foretages i god tid inden ikrafttrædelse for at sikre kontinuerlig drift eksempelvis ved årlige satsændringer eller ikrafttrædelse af nye regler (se eventuelt afsnit 6.2.4). En række Ydelser, som fremgår af underbilag 2.15, skal konfigureres på centralt niveau, således at de behandles ens på tværs af alle kommuner. Det gælder særligt for forsørgelsesydelser (kontanthjælp, uddannelseshjælp, ledighedsydelse mv.), hvor Løsningen understøtter beregninger og regler baseret på faglovgivningen (se underbilag 2.8 Lovgivning). Det gælder også for de kendte enkeltydelser, hvor Løsningen i begrænset omfang understøtter beregninger og regler baseret på Lovgivningen. Her må den konfigurering af fx konteringsregler, som er foretaget centralt, ikke kunne ændres på kommunalt niveau, men kan eventuelt suppleres med lokal underopdeling af kontoplanen. Dertil kan den enkelte kommune oprette enkeltydelser og Andre Ydelser, som kun anvendes lokalt, eksempelvis fordi kommunen vælger at udbetale særlige Ydelser på familie- og børneområdet ved hjælp af løsningen. Her understøtter Løsningen som udgangspunkt ikke lovgivningsbestemte beregninger og regler ud over skatteberegning, hvorfor eksempelvis konteringsregler også skal opsættes lokalt. Krav# 192: Central konfigurering af Ydelser Beskrivelse: Det skal være muligt for en central administrator at oprette og konfigurere Ydelser, som Løsningen skal håndtere, med tilhørende stamdata, parametre og regler. a. En central administrator skal i Løsningen kunne oprette Ydelser og indberette de nødvendige oplysninger om stamdata, parametre og regler for alle de Ydelser, som håndteres i Løsningen. b. De oplysninger, som skal kunne konfigureres centralt om en Ydelse, omfatter: A. Navn, beskrivelse og henvisning til lovhjemmel. B. Beløbssatser og grænseværdier, omregningsfaktorer mv. Side 138 af 257
C. Kontonumre, herunder mellemregningskonti, og konteringsregler samt debitorforholdstyper til brug i kommunikation med debitorsystem. D. Kalender for beregning, effektuering og udbetaling. E. Kobling til KLE. F. Beløbssatser på enkeltydelser og Andre Ydelser. G. Defaultværdi for om Ydelsen udbetales forud- eller bagudrettet samt for udbetalingstidspunkt/frekvens. H. Om Ydelsen er skattefri, A-skattepligtig eller B-skattepligtig. I. Om der er træk af AMB på Ydelsen. J. Om der er træk af ATP på Ydelsen. K. Om Hændelser må ændre godkendelse på effektueringsplaner under denne Ydelsesart fra automatisk til manuel. L. Om der må indeholdes forskudsvis udlagt børnebidrag i Ydelsen til afregning med Udbetaling Danmark. M. Om der manuelt må tilknyttes individuelle tillæg/fradrag til udbetalinger af denne Ydelse. N. Om oplysningerne om Ydelsesarten kan ændres på centralt og/eller kommunalt niveau. - Se Krav# 198 vedrørende kalender for beregning, effektuering og udbetaling på forsørgelsesydelser. - Se Krav# 195 og Krav# 197 vedrørende konfigurering af konteringsregler. - Se Krav# 92 vedrørende automatiske reaktioner på Hændelser. - Se Krav# 194 vedrørende konfigurering af individuelle tillæg/fradrag. - Se Krav# 198 vedrørende kalender for beregning, effektuering og udbetaling på enkeltydelser og Andre Ydelser. - Se underbilag 2.22 (Kontering) om konteringsregler og overførsel til økonomisystem. - Se informationsmodellen (Ydelseskatalog) i underbilag 2.5. Krav# 193: Lokal konfigurering af Ydelser Beskrivelse: Det skal være muligt for en kommunal administrator at oprette og konfigurere Ydelser, som Løsningen skal håndtere, med tilhørende stamdata, parametre og regler. a) En kommunal administrator skal i Løsningen kunne oprette Ydelser og indberette de nødvendige oplysninger om stamdata, parametre og regler for Ydelser, som håndteres i Løsningen. b) De oplysninger, som skal kunne konfigureres om en Ydelse, uanset om den er oprettet centralt eller lokalt, omfatter: A. Kontonumre, herunder mellemregningskonti, og konteringsregler samt debitorforholdstyper til brug i kommunikation med debitorsystem. Side 139 af 257
B. Kalender for beregning, effektuering og udbetaling for enkeltydelser og Andre Ydelser. C. Maksimalt beløb, der kan udbetales i én udbetaling. D. Defaultværdi for om udbetalinger skal godkendes manuelt eller ikke. E. Om Hændelser må ændre godkendelse på effektueringsplaner under denne Ydelsesart fra automatisk til manuel. F. Om der manuelt må tilknyttes individuelle tillæg/fradrag til udbetalinger af denne Ydelse. c) De oplysninger, som skal kunne konfigureres om en Ydelse, som er oprettet lokalt, omfatter: A. Navn, beskrivelse og henvisning til lovhjemmel. B. Beløbssatser. C. Kalender for beregning, effektuering og udbetaling. D. Kobling til KLE. E. Defaultværdi for om Ydelsen udbetales forud- eller bagudrettet samt for udbetalingstidspunkt/frekvens. F. Om Ydelsen er skattefri, A-skattepligtig eller B-skattepligtig. G. Om der er træk af AMB på Ydelsen. H. Om der er træk af ATP på Ydelsen. I. Om der må indeholdes forskudsvis udlagt børnebidrag i Ydelsen til afregning med Udbetaling Danmark. - Se Krav# 195 og Krav# 197 vedrørende konfigurering af konteringsregler. - Se Krav# 92 vedrørende automatiske reaktioner på Hændelser. - Se Krav# 194 vedrørende konfigurering af individuelle tillæg/fradrag. - Se Krav# 198 vedrørende kalender for beregning, effektuering og udbetaling på enkeltydelser og Andre Ydelser. - Se underbilag 2.22 (Kontering) om konteringsregler og overførsel til økonomisystem. - Se eventuelt informationsmodellen (Ydelseskatalog) i underbilag 2.5. Krav# 194: Konfigurering af typer af individuelle tillæg/fradrag Beskrivelse: Det skal være muligt for en kommunal administrator at konfigurere de tillæg og fradrag, der manuelt kan indberettes på effektueringsplaner i specifikke sager. a) En kommunal administrator skal i Løsningen kunne indberette de nødvendige oplysninger om stamdata, parametre og regler for manuelle tillæg/fradrag. b) De oplysninger, som skal kunne konfigureres lokalt om en type manuelt tillæg/fradrag, omfatter: a. Navn og beskrivende tekst. Side 140 af 257
b. Maksimalt beløb, der kan bevilges i én bevilling. c. Defaultbeløb. d. Om det individuelle tillæg/fradrag er et brutto-tillæg/fradrag (dvs. det indgår i skatteberegningen ved effektuering) eller et netto-tillæg/fradrag (dvs. det ikke indgår i skatteberegningen ved effektuering). e. Kontonumre, herunder mellemregningskonti og debitorforholdstyper samt konteringsregler for den enkelte type af tillæg/fradrag, som aktiveres når der knyttes et tillæg/fradrag til en bevilget Ydelse i en specifik sag. f. Den eller de Ydelser, hvor tillægget/fradraget kan anvendes. Løsningen skal validere, at der ikke tilknyttes brutto-tillæg/fradrag til skattefri Ydelser. - Se Krav# 54 vedrørende indberetning af individuelle tillæg/fradrag. - Se Krav# 195 og Krav# 197 vedrørende konfigurering af konteringsregler. - Se underbilag 2.22 (Kontering) om konteringsregler og overførsel til økonomisystem. - Se informationsmodellen (KY-kontering, Ydelseskatalog) i underbilag 2.5. Krav# 195: Central konfigurering af konteringsregler Beskrivelse: Det skal være muligt for en central administrator at konfigurere regler for kontering. a) En central administrator skal i Løsningen kunne indberette de nødvendige oplysninger for Ydelser og individuelle tillæg/fradrag, svarende til niveauet for kontonumre og grupperinger i Økonomi- og Indenrigsministeriets kontoplan, herunder eventuelle oplysninger om tilbagebetalingspligt og debitorforholdstype. b) De oplysninger, som skal kunne konfigureres på centralt niveau, omfatter: a. Grundoplysninger for Ydelser og individuelle tillæg/fradrag, som matcher niveauet for kontonumre og grupperinger i Økonomi- og Indenrigsministeriets kontoplan, herunder eventuelle oplysninger om tilbagebetalingspligt, debitorforholdstype mv. b. Det skal være muligt at knytte kontonumre til en eller flere Ydelser og individuelle tillæg/fradrag. Det skal være muligt at knytte flere kontonumre kombineret med specifikke værdisæt for udvalgte typer af sagsrelaterede oplysninger. - Det er forskelligt fra Ydelse til Ydelse hvilke oplysninger, der kan påvirke konteringen. Oplysninger om eksempelvis den bevilgede Ydelse, Personens alder og markering for tilbagebetalingspligt kan påvirke konteringen i en konkret sag. - Se underbilag 2.22 (Kontering) om konteringsregler og overførsel til økonomisystem. Side 141 af 257
- Se afsnit 7 7, ØIM_KONTOPLAN vedr. Økonomi- og Indenrigsministeriets autoriserede kontoplan. - Se informationsmodellen (KY-kontering) i underbilag 2.5. - Se informationsmodellen (Ydelseskatalog) i underbilag 2.5. Krav# 196: Konfigurering af låsning af indkomstår Beskrivelse: Den centrale administrator kan sætte datoen for, hvornår der ikke længere kan indberettes til kontering. a) Datoen slår igennem, således at Brugeren ikke kan indberette til kontering i det låste indkomstår. - Se Krav# 115 vedrørende stop for indberetninger til kontering i et låst indkomstår. Krav# 197: Lokal konfigurering af konteringsregler Beskrivelse: Det skal være muligt for en kommunal administrator at konfigurere regler for kontering, som supplerer de centralt konfigurerede konteringsregler. a) En kommunal administrator skal i Løsningen kunne indberette de nødvendige oplysninger for at konfigurere regler for kontering, som svarer til de centralt konfigurerede konteringsregler samt supplerende kommunale oplysninger. b) Løsningen skal ved kontering i en konkret sag benytte disse oplysninger i kombination med centralt konfigurerede konteringsregler til at finde det korrekte kontonummer ud fra konkrete værdier i sagens oplysninger. c) De oplysninger, som skal kunne konfigureres på kommunalt niveau, omfatter: a. Et eller flere SE/CVR-numre med tilhørende kontoplaner, der understøtter kobling til Økonomi- og Indenrigsministeriets kontoplan, kommunens behov for intern organisatorisk opdeling af kontoplanen og indberetning til SKAT på særskilte SE-numre. b. Det skal være muligt at knytte kontonumre til en eller flere Ydelsesarter og typer af individuelle tillæg/fradrag. Det skal være muligt at knytte flere kontonumre kombineret med specifikke værdisæt for udvalgte typer af sagsrelaterede oplysninger. - Det er forskelligt fra Ydelse til Ydelse hvilke oplysninger, der kan påvirke konteringen på kommunalt niveau. Oplysninger om eksempelvis Personens tilhørsforhold til socialdistrikt kan påvirke konteringen i en konkret sag. Side 142 af 257
- Se underbilag 2.22 (Kontering) om konteringsregler og overførsel til økonomisystem. - Se Krav# 195 vedrørende central konfigurering af konteringsregler. - Se informationsmodellen (KY-kontering, Ydelseskatalog) i underbilag 2.5. Krav# 198: Kalender for beregning, effektuering og udbetaling Beskrivelse: Det skal være muligt på centralt niveau og kommunalt niveau for de enkelte Ydelsesarter at konfigurere, hvornår Løsningen skal foretage beregninger, effektueringer og udbetalinger. a) En central administrator skal i Løsningen kunne indberette de nødvendige oplysninger til at konfigurere kalender for beregning, effektuering og udbetaling på alle Ydelsesarter. b) En kommunal administrator skal i Løsningen kunne indberette de nødvendige oplysninger til at konfigurere kalender for beregning, effektuering og udbetaling for administrationssager, sager om enkeltydelser og Andre Ydelser. c) De oplysninger, som kan indberettes, omfatter: faste intervaller, faste ugedage eller specifikke datoer for hver af de beregninger og udbetalinger, der er for Ydelsesarten. d) Løsningen skal foretage beregninger, effektueringer og udbetalinger på de fastsatte tidspunkter. - Der kan være flere typer af beregninger og udbetalinger for en Ydelsesart, fx kan der være behov for at foretage beregninger af forudbetalt og bagudbetalt kontanthjælp på forskellige tidspunkter. - Se Krav# 43 vedrørende automatisk beregning ved udbetaling. 5.6.2.1 Ydelsesspecifikke konfigurationer Krav# 199: Opsætning af elementer til rådighedsberegning Beskrivelse: Det skal være muligt for en kommunal administrator at konfigurere hvilke indtægter og udgifter, der som standard skal vises på rådighedsberegningen. a) En kommunal administrator skal i Løsningen kunne indberette de nødvendige oplysninger til at konfigurere hvilke typer af indtægter og udgifter, der som standard skal vises på rådighedsberegningen ved behandling af en konkret sag. b) For hvert type af beløb skal der kunne angives betegnelse, indtægt/udgift, placering i opstillingsrækkefølge. c) Det er desuden muligt at opsætte beløbsgrænse for hver enkelt type af udgift (fx max 100 kr. til telefon). Side 143 af 257
- Se Krav# 37 vedrørende rådighedsberegning. Krav# 200: Konfigurering af formueopgørelse Beskrivelse: Det skal være muligt for kommunal administrator at konfigurere de poster, der vises som standard ved opgørelse af formue. a) En kommunal administrator skal i Løsningen kunne indberette de nødvendige oplysninger til at konfigurere de poster, der vises som standard ved opgørelse af formue. b) For hvert beløb skal der kunne angives betegnelse, placering i opstillingsrækkefølge. - Se Krav# 39 vedrørende formueopgørelse. Krav# 201: Opsætning af oplysninger til brug i budget ved administrationssag Beskrivelse: Det skal være muligt for en kommunal administrator at konfigurere de indtægter og udgifter, der kan anvendes i budgettet på en konkret sag. a) En kommunal administrator skal i Løsningen kunne indberette de nødvendige oplysninger til at konfigurere de indtægter og udgifter, der kan anvendes i budgettet på en konkret sag. b) For hver indtægt/udgift skal der kunne angives, om den indgår i standardopstillingen, betegnelse og placering i opstillingsrækkefølge. - Eksempler på sådanne indtægter og udgifter omfatter: Forsørgelsesydelse, Indtægter ved arbejde, Husleje, El, Telefon. - Se Krav# 103 vedrørende budget i en administrationssag. Krav# 202: Opsætning af maksimalt overtræksbeløb for administrationsordninger Beskrivelse: Det skal være muligt for en kommunal administrator at fastsætte et grænsebeløb for hvor stort et overtræk, der maksimalt kan tillades på en administrationsordning. a) En kommunal administrator skal i Løsningen kunne indberette de nødvendige oplysninger til at fastsætte et grænsebeløb for hvor stort et overtræk, der maksimalt kan tillades på en administrationsordning. b) Defaultværdi skal være nul (0) kr. - Se Krav# 104 vedrørende afgørelse eller frivillig aftale om administration. Side 144 af 257
Krav# 203: Konfigurering af adgang til lokale prisaftaler Beskrivelse: Den skal være muligt for en kommunal administrator at konfigurere henvisninger til eksterne dokumenter, der indeholder lokale prisaftaler. a) En kommunal administrator skal i Løsningen kunne indberette de nødvendige oplysninger til at konfigurere henvisninger til eksterne dokumenter, der indeholder lokale prisaftaler. b) Det skal være muligt at konfigurere henvisninger til et antal dokumenter og for hver Ydelsesart at angive hvilket dokument, der skal henvises til. - Se Krav# 40 vedrørende brug af prisaftale. Krav# 204: Konfigurering af maksimalt beløb for Godtgørelse Beskrivelse: Det skal være muligt for en central administrator at konfigurere det maksimale beløb, der kan udbetales i Godtgørelse ved automatisk effektuering ud fra oplysninger modtaget fra Jobcenterløsningen. - Godtgørelse efter LAB 83 er eksempler på relevante Ydelser. - Se Krav# 91 om automatisk effektuering ud fra oplysninger fra Jobcenterløsnng. Krav# 205: Kravet udgår Kategori: Beskrivelse: Type: 5.6.3 Brevskabeloner Krav# 206: Vedligehold af centrale brevskabeloner Beskrivelse: Den centrale administrator skal kunne oprette, slette og redigere centrale brevskabeloner i Løsningen. a) Centrale brevskabeloner kan oprettes, slettes og redigeres i Løsningen af Brugere med adgang som central administrator b) En brevskabelon, der er taget i brug kan ikke slettes. c) Når der sker ændringer eller tilføjelser i de centrale skabeloner skal den kommunale administrator gøres opmærksom på dette. - Leverandøren er ikke ansvarlig for det faglige/juridiske indhold i centrale brevskabeloner. - Se Krav# 130 om centrale brevskabeloner. Side 145 af 257
Krav# 207: Vedligehold af lokale brevskabeloner Beskrivelse: Den kommunale administrator skal kunne oprette, slette og redigere lokale brevskabeloner i Løsningen. a) Lokale brevskabeloner kan oprettes, slettes og redigeres i Løsningen af Brugere med adgang som kommunal administrator. b) En brevskabelon, der er taget i brug kan ikke slettes. c) d) Brugeren kan vælge om den lokale brevskabelon skal baseres på en allerede eksisterende central skabelon eller skal optræde som en helt ny skabelon uden relation til en central skabelon. e) Brugeren skal kunne angive, hvilke data i Løsningen, der skal indgå som flettefelter i brevskabelonen. f) Hvis den lokale skabelon er baseret på en central skabelon, præsenteres Brugerne for den lokale skabelon medmindre den kommunale administrator har markeret, at den centrale skabelon også skal præsenteres og kunne vælges af Brugerne. - Leverandøren er ikke ansvarlig for det faglige/juridiske indhold i lokale brevskabeloner. - Se Krav# 130 om centrale brevskabeloner. - Se Krav# 131 om lokale brevskabeloner. - Se Krav# 178 om direkte adgang til brevskabeloner. Krav# 208: Redigering af kommunespecifikke grundoplysninger i brevskabeloner Beskrivelse: Den kommunale administrator skal kunne redigere kommunespecifikke oplysninger, der benyttes i brevskabeloner. - De kommunespecifikke grundoplysninger vil indgå på både de centrale og lokale brevskabeloner. - Se Krav# 132 om kommunespecifikke grundoplysninger. Krav# 209: Opsætning af A- og B-post Beskrivelse: Den kommunale administrator kan opsætte om breve som default, skal udsendes fra Løsningen som A- eller B-post. a) Når administrator har valgt A- eller B-post som defaultværdien, vil dette slå igennem, når sagsbehandleren skal sende et brev. - Se Krav# 135 om valg af forsendelsestype for breve. Side 146 af 257
5.6.4 Journalnotater Krav# 210: Frist for automatisk låsning af journalnotat Krav# 211: Markering af låst journalnotat Beskrivelse: Den kommunale administrator skal kunne markere, at et givet låst journalnotat ikke skal fremgå af sagen. Beskrivelse: Den kommunale administrator skal kunne konfigurere det antal dage, der skal gå, før Løsningen låser et journalnotat. - Se Krav# 128 om ændring og sletning af journalnotat. a) Den kommunale administrator kan fortsat fremfinde det markerede, låste journalnotat. - Journalnotater, der ikke fremgår af en Persons sag skal kunne genfindes af den kommunale administrator i tilfælde af revision. - Se Krav# 128 om ændring og sletning af journalnotat. Krav# 212: Vedligeholdelse af journalnotatsskabeloner Beskrivelse: Den kommunale administrator kan oprette, slette og vedligeholde lokale journalnotatskabeloner. a) Oprettede journalnotatsskabeloner kan vælges ved oprettelse af nye journalnotater. b) En brevskabelon, der er taget i brug kan ikke slettes. c) d) Journalnotatsskabelonen indeholder samme metadata som et journalnotat. - Se Krav# 125 om oprettelse af journalnotat. - Se Krav# 127 om indhold i journalnotat. 5.6.5 Andet Krav# 213: Konfigurering af links Beskrivelse: Den kommunale administrator skal kunne opsætte links til eksterne dokumenter og websites, som kan tilgås fra centrale skærmbilleder i Løsningen. b) Opsætningen af links indeholder placering af linket i Løsningens skærmbilleder. c) Links kan indsættes på 5 forskellige skærmbilleder i Løsningen. Side 147 af 257
- Eksempler på dokumenter kan for eksempel være lokale vejledninger til Lovgivning og arbejdsgange, beregnings-ark vedr. delpension mv. - Se Krav# 169: Links og lokale vejledninger. Nogle adresser i kommunen bør sagsbehandleren være særlig opmærksom på i forbindelse med sagsbehandlingen (fx i forbindelse med mellemkommunal refusion). Det er et ønske, at kommunen kan vedligeholde en liste over disse adresser. Når Personen bor på en af disse adresser, skal det markeres på sagen, så sagsbehandleren bliver opmærksom på dette (jf. Krav# 168). Krav# 214: Vedligehold af særlige adresser Beskrivelse: Den kommunale administrator skal kunne vedligeholde en liste over særlige adresser i kommunen. a) Den kommunale administrator skal kunne oprette, ændre eller slette en adresse på listen over særlige adresser i kommunen. b) Løsningen skal sikre, at kun adresser, der findes i CPR-registret, kan tilføjes listen. - Se afsnit 6.4.3.1 om snitflade til CPR-registret. - Se Krav# 34 vedrørende benyttelse af alternativ adresse. - Se Krav# 168 vedrørende visning af særlige adresser. Krav# 215: Manuel slettemarkering af sager Beskrivelse: Den kommunale administrator skal kunne slettemarkere en sag, før kassationsfristen er udløbet. a) Ved slettemarkering skal Løsningen opdatere Sags- og Dokumentindeks samt Ydelsesindekset med oplysning om sletningen af sagen. - Se afsnit 6.3.2.3 vedrørende Sags- og Dokumentindeks. - Se hændelseslisten i underbilag 2.13 for udgående Beskeder til Beskedfordeleren. - Se afsnit 5.2.6 om afslutning og sletning af sager. Krav# 216: Flytning af sagsstamme Beskrivelse: Den kommunale administrator kan flytte hele sagsstammen for en given sagsbehandler/team til en anden sagsbehandler/team. - Årsagen til, man kunne ønske at flytte en sagsstamme, er fx, hvis en sagsbehandler er fraværende på grund af langtidssygdom. I dette tilfælde kan der være behov for at flytte alle medarbejderens sager til en ny medarbejder. Dette kaldes at flytte sagsstammen. - Se Krav# 96 vedrørende en Brugers mulighed for at ændre den primære sagsbehandler. Side 148 af 257
Krav# 217: Konfigurering af valuta Beskrivelse: Den centrale administrator skal kunne angive værdien for den valuta, der anvendes i Løsningen. Kravet skal sikre, at den centrale administrator, ved en enkel arbejdsgang, kan ændre betegnelsen kroner til euro i hele Løsningen, hvis Danmark overgår til euro. Krav# 218: Konfiguration af intervaller for autogem Beskrivelse: Det skal i Løsningen være muligt for en central administrator, at konfigurere hvor ofte der autogemmes data. Rapporter og udtræk Løsningen skal understøtte, at sagsbehandlere og ledere kan danne enkle, faste rapporter direkte fra Løsningen til brug for daglig opfølgning og ledelsesinformation. Denne grundfunktionalitet suppleres af muligheden for at eksportere data fra Løsningen til Serviceplatformen (se afsnit 6.4.3.10, hvorfra data kan tilgås af egentlige ledelsesinformationssystemer, der stiller mere omfattende rapporter og statistikmuligheder til rådighed). 5.7.1 Krav til faste rapporter Krav# 219: Krav til faste rapporter Beskrivelse: Brugeren skal kunne udtrække op til 20 fast definerede rapporter på grundlag af det strukturerede data, der er til rådighed i Løsningen. a) Leverandøren sikrer, at Løsningen kan danne op til 20 rapporter. b) Løsningen kan danne de 11 rapporter, der er angivet i eksemplerne på rapporter i underbilag 2.9. Behovet for og indholdet af yderligere op til 9 rapporter afklares af Kunden i afklaringsfasen. Se eksempler på rapporter i underbilag 2.9. For tilgængelige data se informationsmodellen i underbilag 2.5 Krav# 220: Kontekstbestemte rapporter Beskrivelse: Rapporter skal kunne afvikles fra de skærmbilleder, hvor de typisk anvendes. Side 149 af 257
Krav# 221: Præsentation og print af rapporter Beskrivelse: Rapporter skal præsenteres overskueligt, intuitivt og ensartet. Rapporter kan printes på en standardprinter i A4-format. Krav# 222: Eksport af rapporter Beskrivelse: Brugeren skal kunne gemme rapporter lokalt på en form, som egner sig til maskinel viderebehandling. a) Brugeren skal kunne vælge mellem følgende formater: A. De to gængse tekstbehandlingsformater ODF (.odt) og OOXML (.docx). B. Kommasepareret fil (.csv), hvis rapportens struktur ligner et regneark. C. Pdf-fil (PDF/A-2). 5.7.2 Krav til eksport af data Løsningen skal kunne aflevere data til eksterne modtagere til brug for kommunernes, andre myndigheders og Danmarks Statistiks arbejde med ledelsesanalyse, benchmarking og dokumentation. Krav# 223: Eksport af data til brug for ledelsesinformation Beskrivelse: Løsningen skal kunne levere udtræk af data til brug i ledelsesinformationssystemer. Datasættet udstilles til brug for 3. parts leverandører af ledelsesinformationssystemer (LIS). Se Krav# 359 for yderligere information vedr. dataudtræk. Løsningen udstiller snitfladerne (SF1620, SF1630 og SF1820) vha. et filbaseret integrationsmønster. Se nærmere detaljer, samt teknisk specifikation i underbilag 2.6. Krav# 224: Aflever data til Danmarks Statistik Side 150 af 257
Beskrivelse: Løsningen skal kunne levere data til Danmarks Statistik. a) Løsningen afleverer data en gang månedligt til Danmarks Statistik bestående af alle ændringer og tilføjelser af data registreret i den foregående måned. Se Krav# 359 for yderligere information vedr. dataudtræk. Leverandøren kan forvente at skulle deltage i en workshop af 1 dags varighed med KOMBIT og Danmarks Statistik til afklaring af tekniske forhold omkring aflevering af data. Løsningen udstiller snitfladerne (SF1620, SF1630 og SF1820) vha. et filbaseret integrationsmønster. Se nærmere detaljer, samt teknisk specifikation i underbilag 2.6. Krav# 225: Aflever data til Styrelsen for Arbejdsmarked og Rekruttering (STAR) Beskrivelse: Løsningen skal aflevere STAR ydelsesdata til Styrelsen for Arbejdsmarked og Rekrutterings statistiske datavarehus. a) Løsningen afleverer en gang månedligt et datasæt til STAR statistiske datavarehus, jf. bekendtgørelse om det fælles datagrundlag og statistiske datavarehus for beskæftigelsesindsatsen (pt. BEK nr. 1420 af 23/12/2012). Data leveres for Personer omfattet af Lov om aktiv socialpolitik 13-13c, 36-43 og 93 a samt Personer omfattet af Lov om aktiv socialpolitik 69-69 f. Der afleveres ligeledes data for Ægtefælle til en Person, hvis Ægtefællen også rammes af en sanktion på grundlag af kommunens afgørelse. Se Krav# 359 om eksport af sagsdata til Serviceplatformen. Leverandøren kan forvente at skulle deltage i en workshop af 1 dags varighed med KOMBIT og STAR til afklaring af tekniske forhold omkring aflevering af data. Løsningen udstiller snitfladerne (SF1620, SF1630 og SF1820) vha. et filbaseret integrationsmønster. Se nærmere detaljer, samt teknisk specifikation i underbilag 2.6. Selvbetjening Kommunernes Ydelsessystem skal indeholde en selvbetjeningsløsning. Selvbetjeningsløsningen understøtter, at Digitale Ansøgere og Tilknyttede Ansøgere ved at tilgå en online selvbetjeningsløsning kan a) få information om Ydelser og ansøgning om Ydelser b) ansøge om Ydelser og c) følge sin Ydelsessag. Selvbetjeningsløsningen skal understøtte ansøgning om uddannelseshjælp, kontanthjælp, ledighedsydelse under ferie og enkeltydelse. Side 151 af 257
Selvbetjeningsløsningens mål og succeskriterier er: En Digital Ansøger/Tilknyttet Ansøger vil fra starten af ansøgningsprocessen få mere præcis information om, hvad der forventes i forbindelse med ansøgningen. Den Digitale Ansøger/Tilknyttet Ansøger kan nemt, bekvemt og når og hvor de vil, ansøge om Ydelser. Kommunen vil modtage digitale ansøgninger, som i højere grad har den rette dokumentation med den rette kvalitet. Kommunen vil opleve færre henvendelser fra Digitale Ansøgere/Tilknyttede Ansøgere i forbindelse med ansøgninger og løbende sager. Kommunen vil få mindre behov for at anmode Digitale Ansøgere/Tilknyttede Ansøgere om at fremsende supplerende oplysninger. Kommunen vil opleve mere tid til sagsbehandling grundet de færre henvendelser. Digitale Ansøgere/Tilknyttede Ansøgere vil opleve, at det er lettere at opnå adgang til de oplysninger, som allerede findes, og som er nødvendige for at søge om og få tildelt Ydelse samt at holde sig opdateret i forbindelse med en løbende sag. Løsningens mål og succeskriterier skal indfries gennem en bedre, hurtigere, billigere og mere ensartet sagsbehandling via: 1. Høj kvalitet i ansøgninger (for kommunen). 2. Høj kvalitet i ansøgningsprocessen (for Digitale Ansøger/Tilknyttet Ansøger) 3. Digital selvbetjening, der hjælper Digitale Ansøgere/Tilknyttede Ansøgere. 4. Lette og intuitive brugergrænseflader. 5. Genbrug af eksisterende data i ansøgnings- og sagsbehandlingsprocesserne. 6. Forhåndsvejledning, som bevirker, at Digitale Ansøgere/Tilknyttede Ansøgere allerede før ansøgning er påbegyndt, er oplyst om en ansøgningens mulige udfald. 7. Nemmere adgang til at lokalisere selvbetjeningsløsningen via søgemaskiner. Nærværende afsnit er suppleret af underbilag 2.17 Borger personas og underbilag 2.18 Persona brugerrejse. 5.8.1 Krav til selvbetjeningsløsningen I det følgende beskrives kravene til selvbetjeningsløsningen, som er en del af den samlede Løsning. En kommune kan vælge, om den vil anvende selvbetjeningsløsningen eller anvende alternative selvbetjeningsløsninger fra 3. parts leverandører. 3. parts selvbetjeningsløsninger kan anvende den snitflade, der udstilles af Løsningen til sikring af sammenhæng mellem udarbejdelse af ansøgning i selvbetjeningsløsningen og sagsbehandling af ansøgningen i Løsningen. Arkitekturen for selvbetjeningsløsningen er kravsat i afsnit 6.2.3.1 og relevante integrationer i afsnit 6.4 og samt 6.4.4, hvor snitflader, der udelukkende anvendes af selvbetjeningsløsningen er kravsat. Figur 16 nedenfor giver et overblik over, hvilke områder de funktionelle krav for selvbetjeningsløsningen er inddelt i. De følgende krav er kategoriseret efter de i figuren illustrerede processer. Medmindre andet er angivet indgår Tilknyttet Ansøger i rollen som fuldmagtshaver og ikke som inviteret Ægtefælle. Side 152 af 257
Figur 16: Den samlede arbejdsgang er opdelt i 5 delprocesser Processen Dialog og vejledning understøtter, at en Person har behov for dialog og vejledning 4 som grundlag for at vurdere muligheden for at kunne modtage en Ydelse. Herunder at få viden om ansøgningsprocessen og forberede sin ansøgning (jf. afsnit 5.8.1.1). I Ansøgningsprocessen udarbejder den Digitale Ansøger/Tilknyttet Ansøger en ansøgning til kommunen (jf. afsnit 5.8.1.2). Visse Digitale Ansøgere/Tilknyttede Ansøgere vil springe informationsansøgningsprocessen over og gå direkte til ansøgningsprocessen. I Ansøgning og Ansøgning behandles (jf. afsnit 5.8.1.3) behandles sagen og eventuel information eftersendes af den Digitale Ansøger/Tilknyttede Ansøger. I afgørelsesprocessen (jf. afsnit 5.8.1.4) træffer kommunen afgørelse, jf. bl.a. også afsnit 5.2.3 (Træf afgørelse). Efter der er foretaget en afgørelse vil der, med mindre der er tale om et afslag, være en løbende sagsbehandling (jf. afsnit 5.8.1.5). Udover de i figuren listede processer, så anføres der i afsnit 5.8.1.6 en række generelle krav for selvbetjeningsløsningen, som ikke knytter sig til specifikke områder i figuren, men er tværgående. Selvbetjeningsløsningen understøtter to aktører (Digital Ansøger og Tilknyttet Ansøger, jf. afsnit 3.5.2). 5.8.1.1 Dialog og vejledning Når en Person står i den situation, at der opstår et behov for at ansøge om uddannelseshjælp, kontanthjælp, ledighedsydelse under ferie eller enkeltydelse opstår der typisk en række spørgsmål, som Personen søger svar på. Herunder spørgsmål om, hvordan man søger om fx uddannelseshjælp eller kontanthjælp, om man overhovedet er berettiget, og hvilken dokumentation, der er påkrævet, når man søger. Det er derfor vigtigt, at selvbetjeningsløsningen ikke kun håndterer selve den digitale ansøgning (jf. afsnit 5.8.1.2), men også giver mulighed for, at Personen selv kan finde svar på relevante spørgsmål i den indledende proce s forud for selve ansøgningen. 4 Ved vejledninger forstås retskilder, herunder bekendsgørelser, cirkulærer og andre centralt fastsatte regler, der regulerer ydelsessagen. Side 153 af 257
Krav# 226: Info om ansøgningsproces og krav Beskrivelse: Personen skal præsenteres grafisk for den proces, Personen skal igennem for at ansøge om og modtage Ydelser. En Person, der ikke er logget på præsenteres grafisk for ansøgningsprocessen. Personen kan tydeligt se, hvornår Personen bør være i kontakt med Ydelsescenter og Jobcenter. Det fremgår hvilke dokumentationskrav, der typisk gør sig gældende i forhold til den Ydelse, der ansøges om. Det fremgår hvilke muligheder der er for at uploade dokumentation. Bemærkning - Formålet med kravet er, at en Person kan finde information om, hvad der skal til for at ansøge om en given Ydelse. - Se underbilag 2.18 Persona brugerrejser for oplysninger om ansøgningsprocessen. - Eksempler på Ansøgning og Dokumentationskrav fremgår af de eksisterende ansøgningsblanketter (KLE 32.24.04G01 Ansøgning om hjælp til forsørgelse efter Lov om aktiv socialpolitik og KLE 32.21.12G01 Ansøgning om enkeltydelse jf. jf. http://www.kl.dk/vejledninger-og-varktojer/kontanthjalp-id33782/ [indhentet 10-03-2014]). Krav# 227: Vejledning om mulighed for at modtage Ydelse Beskrivelse: Personen skal kunne få vejledning om sine muligheder for at modtage Ydelse, inden ansøgningen påbegyndes. a) Selvbetjeningsløsningen stiller spørgsmål til Personen, og på grundlag af besvarelsen, kan selvbetjeningsløsningen indikere overfor Personen, om denne kan være berettiget til at modtage Ydelse. b) Hvis svaret indikerer, at Personen ikke er berettiget til Ydelse, informerer selvbetjeningsløsningen om Personens muligheder fremover. Bemærkning - Formålet er, allerede før ansøgning er påbegyndt, at informere de Personer, som højst sandsynligt ikke vil være berettigede til at modtage Ydelser, så der ikke unødigt anvendes ressourcer på dels udarbejdelsen af ansøgningen og dels sagsbehandlingen af ansøgningen. - Vejledningen skal give information om, hvilke muligheder Personen har, selvom han ikke er berettiget til Ydelse. Personen skal, så vidt muligt, kunne søge tilstrækkelig vejledning til at han kan komme videre uden Ydelsescentrets bistand. - Korte spørgsmål til indikation af, om det er relevant at søge kan baseres på fx personaer jf. underbilag 2.17 og Lovgivning og beregningsregler jf. underbilag 2.7. Side 154 af 257
5.8.1.2 Ansøgning Når en Person beslutter sig for at ansøge om uddannelseshjælp, kontanthjælp ledighedsydelse under ferie eller enkeltydelser og derved bliver en Digital Ansøger/Tilknyttet Ansøger, skal han som led i ansøgningen besvare en række spørgsmål og på baggrund af spørgsmålene bliver relevante inddateringsfelter og dokumentationskrav synlige. Alt efter hvilken Ydelse, der søges om, er der specifikke krav for, hvilke oplysninger og dokumenter der skal indberettes, for at sagen kan behandles af kommunen. Det kan eksempelvis være vedhæftelse af dokumenter (dokumentationskrav) eller udfyldelse af en række felter. Digitale Ansøgere/Tilknyttede Ansøgere kan også efter indsendelse af ansøgningen - uploade dokumentation. Når ansøgningen er indsendt og klar til sagsbehandling, dannes Opgave til sagsbehandleren. Krav# 228: Opret og afsend ansøgning Beskrivelse: En Digital Ansøger/Tilknyttet Ansøger skal via selvbetjeningsløsningen kunne oprette og afsende en ansøgning. a) Den Digitale Ansøger/Tilknyttede Ansøger skal kunne logge på med NemID og kan oprette og afsende ansøgning b) Al data, der kan forudfyldes, skal være forudfyldt ved påbegyndelsen af ansøgning. c) Selvbetjeningsløsningen validerer løbende ansøgningen i forhold til krævede oplysninger og uoverensstemmelse mellem indtastede oplysninger i ansøgningens felter. d) Selvbetjeningsløsningen validerer løbende, at de rette dokumenter er uploadet. e) Selvbetjeningsløsningen validerer løbende, om der kan gives en indikation af, hvorvidt den Digitale Ansøger er berettiget til en Ydelse. Hvis dette er tilfældet, signaleres dette, og den Digitale Ansøger/Tilknyttede Ansøger kan fortsættes eller afbryde oprettelsen af ansøgningen. f) Det er muligt at uploade relevant dokumentation sammen med ansøgning dog med begrænsningerne nævnt i Krav# 123 g) Der gives vejledning om det videre forløb, herunder forventninger til sagsbehandlingen og ret og pligt for den Digitale Ansøger/Tilknyttede Ansøger. h) Ansøgningens data kan ikke redigeres efter afsendelse. Der kan dog ske upload af dokumentation. Side 155 af 257
Bemærkning - Eksempler på ansøgning og dokumentationskrav fremgår af de eksisterende ansøgningsblanketter (KLE 32.24.04G01 Ansøgning om hjælp til forsørgelse efter Lov om aktiv socialpolitik og KLE 32.21.12G01 Ansøgning om enkeltydelse jf. http://www.kl.dk/vejledninger-og-varktojer/kontanthjalp-id33782/ [indhentet 10-03-2014]). - Se underbilag 2.7 og informationsmodellen KY- Sag og KY-Beslutningsgrundlag i underbilag 2.5. for yderligere information om ansøgningsdata og berettigelse til Ydelse. - I pkt. c indgår validering af manglende Ægtefælle godkendelse af dokumentation. - Formålet med pkt. e er at give en forhåndsvejledning til bestemte målgrupper af Digitale Ansøgere/Tilknyttede Ansøgere, så de inden ansøgningen er afsluttet og afsendt får at vide, at de højst sandsynligt ikke vil være berettiget til uddannelseshjælp eller kontanthjælp, men at de altid har ret til at gennemføre og afsende ansøgningen. Det kan fx. være: o Studerende, der har afsluttet en uddannelse inden sommerferien og skal starte på en ny uddannelse til efteråret og dermed ikke har ret til kontanthjælp. o Unge under 25 år, som har ret til uddannelseshjælp eller kontanthjælp efter satsen som ung hjemmeboende eller ung udeboende, og dermed ikke har ret til særlig støtte til høje boligudgifter. o Digitale Ansøgere der ikke har kontaktforløb oprettet via Besked fra jobcenter eller det fælles datagrundlag. - Vejledningen skal give information om, hvilke muligheder den Digitale Ansøger/Tilknyttede Ansøger har, selvom han ikke er berettiget til Ydelse. Den Digitale Ansøger/Tilknyttede Ansøger skal, så vidt muligt, kunne søge tilstrækkelig vejledning til, at han kan komme videre uden Ydelsescentrets bistand. - Se afsnit 6.2.3 om arkitekturen for selvbetjeningsløsningen. Side 156 af 257
Krav# 229: Visuel og tekstuel navigation i ansøgningen Beskrivelse: Når den Digitale Ansøger/Tilknyttede Ansøger påbegynder ansøgningen, skal han præsenteres for processen med at udfylde ansøgningen. Den Digitale Ansøger/Tilknyttede Ansøger skal ligeledes løbende kunne følge med i, hvor i processen han befinder sig. a) Den Digitale Ansøger/Tilknyttede Ansøger præsenteres grafisk og tekstuelt for processen forbundet med udfyldelse og afsendelse af ansøgning. b) Den Digitale Ansøger/Tilknyttede Ansøger kan visuelt og tekstuelt løbende se, hvor i processen han befinder sig. c) Den Digitale Ansøger/Tilknyttede Ansøger kan bevæge sig frem og tilbage i ansøgningen, via navigation, uden udfyldt data slettes. Bemærkning - Den Digitale Ansøger/Tilknyttede Ansøger kan, forud for ansøgning, bl.a. præsenteres for de emneområder, som han skal igennem og godkende eller udfylde. Krav# 230: Oplysningspligt Beskrivelse: Den Digitale Ansøger/Tilknyttede Ansøger skal i ansøgningen kvittere for, at man er bekendt med sin pligt til at give kommunen oplysninger om ændringer. Bemærkning - Eksempler på ændringer: Indtægter, flytning, ændring i civilstand, mv. Krav# 231: Ægtefælle-erklæring Beskrivelse: Hvis den Digitale Ansøger har en Ægtefælle og har angivet oplysninger samt dokumentation i selvbetjeningsløsningen, skal Løsningen understøtte, at oplysninger og dokumentation skal erklæres som værende korrekte af Ægtefællen. a) Digital Ansøger/Tilknyttet Ansøger kan angive, at den Digitale Ansøgers Ægtefælle skal godkende dokumentation. b) Selvbetjeningsløsningen sender link til selvbetjeningsløsningen til den inviterede Ægtefælle. c) Ægtefælle kan tilgå selvbetjeningsløsningen via NemId og erklære, at informationer og dokumentation er korrekt. Bemærkning - For krav relateret til Nem-Login henvises bl.a. til afsnit 6.4.4.1. - For krav relateret til Print på Serviceplatformen henvises bl.a. til afsnit 6.4.3.3. Side 157 af 257
Krav# 232: Samtykke i forbindelse med ansøgning Beskrivelse: Den Digitale Ansøger/Tilknyttede Ansøger skal i ansøgningsprocessen kunne give samtykke til kommunens indhentelse af yderligere oplysninger om Ansøgeren. Bemærkning - Oplysninger, der kan gives samtykke til indhentelse af, kan eksempelvis være fra arbejdsgiver, egen læge, tidligere bopælskommune, tilbudssted mv. Krav# 233: Kvittering for afsendt ansøgning Beskrivelse: Efter afsendelse af ansøgningen skal der udstedes kvittering, som skal kunne printes. Bemærkning - a) Løsningen kan udstede en kvittering med relevante informationer. Relevante informationer på kvitteringen er eksempelvis navn på den Digitale Ansøger/Tilknyttede Ansøger; dato; sagstype; henvisning til ansøgningen; tidshorisont på svar; link til sagen i selvbetjeningsløsningen, hvor bl.a. status på sagen løbende kan følges samt autosignatur fra den modtagende kommune. b) Den Digitale Ansøger/Tilknyttede Ansøger kan printe kvitteringen i et på en standardprinter læsbart format. Krav# 234: Overblik over dokumentationskrav Beskrivelse: Selvbetjeningsløsningen skal vise, hvilke aktuelle dokumentationskrav der er til en ansøgning. Bemærkning a) Den Digitale Ansøger/Tilknyttede Ansøger præsenteres visuelt og tekstuelt for dokumentationskrav til en ansøgning. Krav# 235: Dynamisk ansøgning Beskrivelse: Selvbetjeningsløsningens ansøgnings skal være dynamisk, således at konkrete inddateringsfelter og dokumentationskrav afhænger af svarene på foregående spørgsmål. a) Den Digitale Ansøger/Tilknyttede Ansøger præsenteres kun for inddateringsfelter og dokumentationskrav, som er relevante for den specifikke ansøgning. Side 158 af 257
Bemærkning - Eksempelvis skal ikke alle Digitale Ansøgere/Tilknyttede Ansøgere spørges om boligoplysninger, men alene Ansøgere, der er omfattet af målgruppen for særlig støtte til høje boligudgifter. - Se informationsmodellen Beslutningsgrundlag i underbilag 2.5 og underbilag 2.7. ift. punkt a Krav# 236: Præsentation af data fra tredjepartsløsninger Beskrivelse: Selvbetjeningsløsningen skal præsentere den Digitale Ansøger/Tilknyttede Ansøger for relevant data, som er tilgængelige i de tredjepartssystemer, Løsningen integrerer med. a) Den Digitale Ansøger/Tilknyttede Ansøger kan altid overskrive data, som er indhentet via integrationer. Bemærkning - Se eventuelt afsnit 6.4 for tredjepartsløsninger, der integreres med. Krav# 237: Min Sag før afgørelse Beskrivelse: Når en Digital Ansøger/Tilknyttet Ansøger gemmer en kladde eller afsender en ansøgning, skal der automatisk oprettes en side, en slags Min Sag, i selvbetjeningsløsningen til visning af oplysninger om sagsforløbet. Under Min Sag, skal det før afgørelsen er modtaget være muligt at tilgå ansøgningen samt øvrige oplysninger. a) Den Digitale Ansøger/Tilknyttede Ansøger kan løbende tilgå en igangværende ansøgning og supplere med manglende dokumentation. b) Den Digitale Ansøger/Tilknyttede Ansøger kan løbende følge status på sag, når ansøgning er afsendt. c) Den Digitale Ansøger/Tilknyttede Ansøger kan ændre i stamdata (fx et tidligere oprettet telefonnummer) d) Den Digitale Ansøger/Tilknyttede Ansøger kan ændre i foretagne valg (fx i forhold til at modtage SMS- og e-mail notifikationer ved nye Hændelser). Bemærkning - For krav til status henvises bl.a. til krav omfattet af afsnit 5.1.3 og for krav vedrørende nye Hændelser (fx ændring i status) henvises bl.a. til Krav# 248. Side 159 af 257
Krav# 238: Fuldmagt Beskrivelse: Den Digitale Ansøger skal i selvbetjeningsløsningen kunne tilknytte Personer til hele eller dele af selvbetjeningsløsningen, således at en anden Person gives fuldmagt til at agere på vegne af Personen. a) En Digital Ansøger kan tilknytte en Tilknyttet Ansøger til hele eller dele af selvbetjeningsløsningen, således de kan agere på vegne af den Digitale Ansøger og udarbejde/opdatere ansøgningen og se oplysninger om Personens sag. b) Funktionaliteten skal baseres på Nem-Login. Bemærkning - Eksempelvis skal en Digital Ansøger kunne give fuldmagt til, at Tilknyttet Ansøger hjælper med ansøgningen uden at fuldmagten nødvendigvis gælder hele selvbetjeningsløsningen. Formålet er eksempelvis at understøtte de unge og socialt udsatte, der på nuværende tidspunkt får hjælp til at udfylde ansøgningen af fx forældre eller medarbejdere på væresteder for hjemløse. - For krav relateret til Nem-Login henvises bl.a. til afsnit 6.4.4.1. Krav# 239: Sidst udfyldte version af påbegyndt ansøgning Beskrivelse: Selvbetjeningsløsningen skal understøtte, at en Digitale Ansøger/Tilknyttet Ansøger kan have en ansøgningskladde. Bemærkning a) Den Digitale Ansøger/Tilknyttede Ansøger kan gemme en ansøgning under udarbejdelse som en kladde. b) Kladden kan redigeres og færdiggøres som ansøgning af den Digitale Ansøger/Tilknyttede Ansøger. c) Den Digitale Ansøger/Tilknyttede Ansøger har alene adgang til én kladde. Dvs., at det ikke skal være muligt at have to eller flere påbegyndte ansøgninger under Min Sag. Krav# 240: Dokumentationskrav løbende upload/upload til sidst Beskrivelse: Det skal være muligt at uploade 1) dokumentation løbende i de forskellige faser af ansøgningsprocessen og 2) vente med at uploade dele af dokumentationen afslutningsvis i ansøgningsprocessen. a) Den Digitale Ansøger/Tilknyttede Ansøger kan både uploade dokumentation løbende og til sidst i ansøgningsprocessen. b) Ved ny dokumentation, der tilføjes efter Ansøgningen er afsendt, oprettes en Opgave jf. bl.a. Krav# 16. c) Ny dokumentation knyttes til den Digital Ansøgers sag. Side 160 af 257
Bemærkning - Det vil for flere Digitale Ansøgere/Tilknyttede Ansøgere være mere hensigtsmæssigt at uploade dokumenter til sidst i processen frem for løbende. Krav# 241: Manglende dokumentation Beskrivelse: Når ansøgningen er udfyldt, skal selvbetjeningsløsningen autogenerere en liste over den umiddelbart relevante dokumentation, den Digitale Ansøger/Tilknyttede Ansøger skal uploade med sin ansøgning a) Den Digitale Ansøger/Tilknyttede Ansøger præsenteres for en liste over dokumentation, som skal uploades til denne type af ansøgning. b) Løsningen informerer tydeligt om, at ansøgning om Ydelse afslås og sagen lukkes, hvis det krævede dokumentation ikke er uploadet inden 10 dage efter indsendelsen af ansøgningen. Hvis der ikke er uploadet dokumentation på fristdatoen, danner Løsningen en opgave til sagsbehandleren om at træffe afgørelse om afslag på ydelse. c) Listen over dokumentation kan udskrives. Bemærkning - Se underbilag 2.13 Oversigt over Hændelser, hvor den interne regel om manglende dokumentation fremgår. 5.8.1.3 Ansøgning behandles Når en ansøgning er afsendt, kan den Digitale Ansøger/Tilknyttede Ansøger følge sagens forløb på Min Sag og behøver derved ikke kontakte kommunen for fx at høre om ansøgningen er modtaget. Når en sagsbehandler har gennemgået ansøgningen, vil sagsbehandler notere, om der mangler relevante oplysninger eller dokumentation. Er der manglende informationer, vil det fremgå på Min Sag, ligesom det også vil fremgå, hvad tidsfristen er. Hvis Den Digitale Ansøger/Tilknyttede Ansøger ikke har reageret inden for den fastsatte tidsfrist, træffes afgørelsen på det foreliggende grundlag. Den Digitale Ansøger/Tilknyttede Ansøger kan altid via Min Sag supplere med manglende informationer bl.a. jf. Krav# 243. Den Digitale Ansøger/Tilknyttede Ansøger kan ligeledes, bl.a. jf. Krav# 248, vælge at modtage SMS- eller e-mailnotifikation, når der sker nyt i sagen. Når en Kommune har modtaget en ansøgning gemmes denne i Løsningen, så sagsbehandleren (Ydelsescentret) til enhver tid kan tilgå ansøgningen med de oplysninger, der er angivet af den Digitale Ansøger/Tilknyttede Ansøger jf. afsnit 5.1.5. Herefter oplyses sagen jf. afsnit 5.2.1. Mangler der oplysninger, så indhentes disse, jf. kravene omfattet af afsnit 5.2.1.1, og oplysninger kan indsendes via selvbetjeningsløsningen. Når der indhentes dokumentation fra andre parter, skal alle relevante oplysninger i udgangspunktet gøres tilgængelige for den Digitale Ansøger/Tilknyttede Ansøger på Min Sag, jf. Krav# 243. 5.8.1.4 Afgørelse Når der foreligger en afgørelse, jf. afsnit 5.2.3, fremgår det på selvbetjeningsløsningen (Min Sag), hvad afgørelsen er. Side 161 af 257
Krav# 242: Se afgørelse Beskrivelse: Den Digitale Ansøger/Tilknyttede Ansøger kan se afgørelsen om Ydelse i selvbetjeningsløsningen. a) Afgørelsen vises i selvbetjeningsløsningen b) Selvbetjeningsløsningen præsenterer, hvilke muligheder, der er for at klage over afgørelsen. Bemærkning a) Se bl.a. afsnit 5.2.3 for krav relateret til afgørelse. 5.8.1.5 Løbende sagsbehandling Formålet med selvbetjeningsløsningen er bl.a. at skabe et samlet overblik over sagen for den Digitale Ansøger/Tilknyttede Ansøger, så han selv løbende kan give og modtage information i forbindelse med sin sag og derved opleve et reduceret behov for at kontakte kommunen. Eksempelvis kan Den Digitale Ansøger/Tilknyttede Ansøger løbende indsende dokumentation (fx Ægtefælles lønseddel, egen lønseddel, ændringer i formue m.v.), løbende se hvilke Ydelser der er modtaget, hvornår næste Ydelse forventes udbetalt og hvilket foreløbigt beløb, det drejer sig om mv. Krav# 243: Min sag efter afgørelse Beskrivelse: Når en Digital Ansøger/Tilknyttet Ansøger har modtaget en afgørelse og har en igangværende ydelsessag, skal Personen kunne tilgå og anvende Min Sag til følgende: a) Se flg. oplysninger: - Ansøgningen som den så ud, da den blev afsendt fra selvbetjeningsløsningen inklusiv data indhentet fra eksterne registre. - Sagsdata: Ydelsesart, sagsstatus, navn på sagsbehandler, startdato på sagen, dato for afsendelse af ansøgning. - Forudgående og kommende udbetalinger af Ydelser med angivelse af, om udbetalingerne er til Personen eller til Alternativ Modtager. - Specifikation af udbetalingsgrundlaget - Egne uploadede dokumenter for den Digitale Ansøger og eventuelle Ægtefælle. - Sagstilknyttede breve og e-mails mellem kommune og Digital Ansøger/Tilknyttet Ansøger. - Journalnotater på sagen - Afgørelsen på sagen b) Den Digitale Ansøger/Tilknyttede Ansøger kan løbende følge status på sagen. c) Den Digitale Ansøger/Tilknyttede Ansøger kan løbende uploade dokumentation. d) Den Digitale Ansøger/Tilknyttede Ansøger kan ændre sin e-mailadresse og telefonnummer. e) Den Digitale Ansøger/Tilknyttede Ansøger kan vælge eller fravælge at modtage SMS- og e-mailnotifikationer ved nye Hændelser i sagen. Side 162 af 257
Bemærkning - Se bl.a. krav omfattet af afsnit 5.1.3 i forhold til pkt. a. - Se bl.a. Krav# 75 og Krav# 78 i forhold til pkt. c. - Se bl.a. Krav# 248 i forhold til pkt. e. Krav# 244: Adgang til historiske data Beskrivelse: En Digital Ansøger/Tilknyttet Ansøger skal have adgang til sagshistorik. Bemærkning Ved flytning til anden kommune har den Digitale Ansøger/Tilknyttede Ansøger adgang til sagshistorik relateret til tidligere bopælskommuner. 5.8.1.6 Generelle krav til selvbetjeningsløsningen Krav# 245: Min Sag for alle Ansøgere Beskrivelse: Digitale Ansøgere/Tilknyttede Ansøgere, der ikke tidligere har anvendt selvbetjeningsløsningen, skal kunne tilgå og anvende selvbetjeningsløsningen med de samme muligheder, som de ansøgere, der har anvendt selvbetjeningsløsningen til eksempelvis ansøgning. Bemærkning - Se bl.a. Krav# 237 og Krav# 243 for eksempler på muligheder, som Personen har. Krav# 246: Log af selvbetjeningsløsningen Beskrivelse: En Digital Ansøger/Tilknyttet Ansøger skal kunne logge af selvbetjeningsløsningen. Bemærkning a) Løsningen lukker den igangværende brugersession og returnerer til den del af Løsningen, der ikke kræver, man er logget på. b) Personen kan herefter ikke tilgå Min Sag uden igen at logge på. Krav# 247: Kommunespecifikke informationer Beskrivelse: En kommunal administrator skal kunne opsætte kommunespecifikke oplysninger og vejledninger, der vises i selvbetjeningsløsningen. a) En kommunal administrator kan opsætte flg. kommunespecifikke oplysninger: kontaktinformation, åbningstider for Ydelsescentret, proces for ansøgning og sagsbehandling af ansøgning, nyheder fra Ydelsescentret og vejledning til forskellige målgrupper af Digitale Ansøgere. b) En kommunal administrator kan opsætte vejledningstekster vedrørende Personers mulighed for at søge om hjælp hos andre myndigheder. Side 163 af 257
Bemærkning - Eksempelvis i forbindelse med at en Persons formue skal angives, hvor en kommune med landdistrikter eksempelvis kan være interesseret i at vejlede om, at heste skal indgå i angivelsen af personlig formue. - Kommunen skal kunne opfylde sin pligt til at yde råd og vejledning om bl.a. regler for ændring af skattekort, ansøgning om boligstøtte og indtægtsbestemt friplads. Krav# 248: Notifikation via e-mail og SMS Beskrivelse: Den Digitale Ansøger/Tilknyttede Ansøger skal kunne få Besked via e-mail eller SMS fra selvbetjeningsløsningen. Bemærkning a) Når der foreligger nyt i sagen på selvbetjeningsløsningen, får den Digitale Ansøger/Tilknyttede Ansøger Besked via e-mail eller SMS. b) Beskeden indeholder link til selvbetjeningsløsningen og information om den Hændelse, der har udløst Notifikationen. Notifikationen sendes via e-mail eller SMS baseret på den Digitale Ansøger/Tilknyttede Ansøger ønske angivet i selvbetjeningsløsningen. c) Links i e-mails til borgere skal overholde anbefalingerne for links i e- mails fra offentlige myndigheder til borgere. - Nyt i sagen kan eksempelvis være ændringer i tidsfrister (fx i forhold til levering af dokumentation), ved møder, udbetaling af Ydelser osv. (jf. bl.a. Krav# 243). - Se bl.a. krav til SMS snitflade jf. afsnit 6.4.3.4. - Se anbefalet sikkerhedspolitik for link i e-mail fra offentlige myndigheder til borgere https://www.nemid.nu/dk-da/privat/sikkerhed/gode_raad_om_sikkerhed/pas_paa_link_i_e-mail/anbefalet_sikkerhedspolitik_for_link_i_e-mail/ [Indhentet 26-03-2014] Krav# 249: Initiativpligt for Ydelsessag Beskrivelse: Selvbetjeningsløsningen skal grafisk vise, hvem der har initiativpligt i sagsforløbet. Bemærkning - Sagens status kan eksempelvis anvendes som udgangspunkt for visning af initiativpligten. - Initiativpligten kan illustreres med svømmebanediagrammer, så den Digitale Ansøger/Tilknyttede Ansøger får overblik over de eventuelle næste trin. Side 164 af 257
Krav# 250: Onlinehjælp Beskrivelse: Leverandøren skal udarbejde onlinehjælp til selvbetjeningsløsningen. a) Onlinehjælpen udarbejdes i overensstemmelse med Krav# 401 og Krav# 403. b) Onlinehjælpen anvender visuelle fremstillinger til forklaring af funktionaliteten i selvbetjeningsløsningen. Bemærkning - visuelle fremstillinger kan eksempelvis være tegneseriestriber og/eller video Krav# 251: Videoer Beskrivelse: Det skal være muligt for KOMBIT at indlejre videosekvenser i selvbetjeningsløsningen af 1 120 sekunders varighed, som kan vises situationsbestemt. Bemærkning - Videosekvenser skal underbygge den Digitale Ansøger/Tilknyttede Ansøger forståelse af brugen af selvbetjeningsløsningen og give eksempler på de mest benyttede sagsforløb. - Det er KOMBIT, der udvikler og leverer videosekvenserne, og som skal have mulighed for at indlejre dem. Krav# 252: Animationer Beskrivelse: Det skal være muligt for KOMBIT at indlejre små animationer i selvbetjeningsløsningen, så de kan vises situationsbestemt. Bemærkning - Animationer kan indgå som en del af vejledningen for selvbetjeningsløsningen, eksempelvis kan det være i forbindelse med vejledning til, hvordan man opfylder et dokumentationskrav, eller en vejledning i udfærdigelse af en ansøgning. - Det er KOMBIT, der udvikler og leverer videosekvenserne, og som skal have mulighed for at indlejre dem. Krav# 253: Mulighed for reference til tidligere uploadet dokumentation Beskrivelse: Det skal være muligt at genbruge den dokumentation, som den Digitale Ansøger/Tilknyttede Ansøger har uploadet ved tidligere ansøgninger om Ydelser. a) Den Digitale Ansøger/Tilknyttede Ansøger kan referere til allerede uploadet dokumentation ved ansøgning, således at denne ikke skal uploade de samme oplysninger på ny. Bemærkning - Kan eksempelvis være relevant ved en engangsansøgning. Side 165 af 257
Krav# 254: Visning af ansøgninger Beskrivelse: Den Digitale Ansøger/Tilknyttede Ansøger kan se de ansøgninger, der er oprettet og afsendt i selvbetjeningsløsningen. Bemærkning a) Den Digitale Ansøger/Tilknyttede Ansøger kan få vist en oversigt over de ansøgninger, der er oprettet og afsendt i selvbetjeningsløsningen med angivelse af dato for afsendelse. b) Den Digitale Ansøger/Tilknyttede Ansøger kan få vist den enkelte ansøgning med de data, der indgik i ansøgningen på afsendelsestidspunktet med angivelse af dato for afsendelse. Krav til dataudveksling Løsningen skal udveksle data med andre myndigheder og organisationer for at kunne understøtte Brugernes behandling af ydelsessager. I dette afsnit beskrives en række krav til dataudveksling, der foregår på forskellige tidspunkter i sagsbehandlingsprocessen; før og under oprettelse af sag, oplysning af sag og vedligeholdelse af sagen. Kravene beskrives samlet for at bevare sammenhængen mellem krav, der vedrører samme myndighed og integrationer. Beskrivelsen af kravene til de specifikke integrationer er angivet i afsnit 6.4. 5.9.1 Jobcenteroplysninger Jobcentret varetager beskæftigelsesindsatsen overfor ledige borgere med henblik på at få borgeren i arbejde eller uddannelse via aktivering o.l. tiltag. Ydelseskontoret træffer afgørelse om de forsørgelsesydelser, der kan bevilges til de ledige på nær enkelte undtagelser, hvor Jobcentret kan bevilge ydelsen fx Godtgørelse og fleksløntilskud. Opgavedelingen mellem de to aktører understøttes af digital udveksling af Beskeder mellem aktørernes it-løsninger; Jobcenterløsningerne på den ene side og Kommuneres Ydelsessystem på den anden side. Jobcentret sender Beskeder om Personer med LAB-målgrupperne 2.2 Kontanthjælp jobparat, 2.3 Kontanthjælp - aktivitetsparat, 2.4 Revalidend, 2.7 Fleksjobberettiget, 2.9 Ung under 18, 2.11 Ressourceforløb, 2.12 Uddannelseshjælp uddannelsesparat, 2.13 Uddannelseshjælp aktivitetsparat (se underbilag 2.16). De følgende afsnit omhandler kravene til integrationen med Jobcenterløsningerne. Kravene er baseret på den eksisterende Jobcentersnitflade. Jobcenterløsningerne afleverer Beskeder om Hændelser i Jobcentret og Ydelsescentret returnerer oplysninger om bevilling af Ydelse til en Person. De modtagne Beskeder gemmes som strukturerede data i Løsningen. 5.9.1.1 Ikke-sagshenførbare Beskeder I flere tilfælde kan Løsningen have behov for at kunne modtage Beskeder om en Person, selvom sagsbehandlingen i Ydelsescentret endnu ikke er begyndt, og der derfor ikke er oprettet en sag i Løsningen, som Beskederne kan tilknyttes. Det skyldes, at Jobcenterløsningen sender Beskeder, uanset om der oprettes en sag i Ydelsescentret eller ej. Registreringen af Beskederne skal give sagsbehandleren i Ydelsescentret et overblik over Jobcenterhændelser, der vedrører en given Person. Side 166 af 257
Når der oprettes en sag, skal Beskederne kobles til sagen og kontaktforløbsid. fra Beskeden, skal gemmes på sagen. Alle Beskeder fra Jobcentret vedrørende kontaktforløbsid en, kobles herefter til sagen. Krav# 255: Håndter ikke-sagshenførbare Beskeder Beskrivelse: Løsningen skal kunne registre og vise Beskeder fra Jobcentret, der vedrører en Person, men som ikke kan knyttes til en sag i Løsningen. a) Løsningen kan gemme Beskeden om kontaktforløb, aktivitet, fravær, sanktioner, visitationsgruppe og tilkendegivelse om tilbud fra Jobcentret med den angivne kontaktforløbsid. b) Brugeren kan få vist ikke-sagshenførbare Beskeder for en Person i Løsningen. - Se informationsmodellen KY-kontaktforløb i underbilag 2.5. - Se underbilag 2.13 hændelsesoversigten for yderligere information om reaktion på meddelelser fra Jobcentret. - Se afsnit 6.4.3.19 om snitflade til Jobcenterløsningerne. Krav# 256: Kobling af ikke-sagshenførbare Beskeder til en sag Beskrivelse: Løsningen skal kunne koble en eller flere ikke-sagshenførbare Beskeder til en nyoprettet sag på Personen. a) Hvis der er oprettet en sag med samme CPR-nummer og en forsørgelsesydelse, der matcher den LAB-målgruppe, der er angivet i en ikkesagshenførbar Besked, skal Beskeden gemmes på sagen. b) Løsningen har gemt kontaktforløbsid fra Beskeden på sagen. c) Hvis koblingen ikke kan foretages automatisk i tilfælde, hvor Sagsbehandleren (Ydelsescentret) selv opretter sagen, skal Løsningen signalere, at der findes ikke-sagshenførbare oplysninger på Personen og give mulighed for knytte dem til sagen i forbindelse med sagsoprettelsen. d) Hvis koblingen ikke kan foretages automatisk i tilfælde, hvor Løsningen opretter sagen, skal Løsningen danne en Opgave til sagsbehandleren (Ydelsescentret) om at foretage sammenkobling af Beskeder til sagen. e) Løsningen har registreret en Hændelse på grundlag af Beskeden og udført handlingen, der initieres af Hændelsen. - Se underbilag 2.16 Mapning mellem Ydelser og Jobcenter målgrupper/målgruppestatus - Se afsnit 6.4.3.19 om snitflade til Jobcenterløsningerne. - Se hændelseslisten i underbilag 2.13. Krav# 257: Oprydning i ikke-sagshenførbare Beskeder Beskrivelse: Løsningen skal kunne foretage oprydning af ikke-sagshenførbare Beskeder. Side 167 af 257
a) Hvis Løsningen modtager Besked om afslutning af kontaktforløb, og der ikke er oprettet en sag i Løsningen, skal registrerede ikke-sagshenførbare Beskeder fjernes. 5.9.1.2 Besked fra Jobcentret om kontaktforløb En Person, der søger om en forsørgelsesydelse i Ydelsescentret, skal have rettet henvendelse til Jobcentret, inden sagsbehandleren (Ydelsescentret) kan træffe en afgørelse om bevilling af en Ydelse. Når Jobcentret registrerer, at Personen har et kontaktforløb med en given LAB-målgruppe, jf. Lov om en aktiv beskæftigelsesindsats, i Jobcenterløsningen, sendes der via Jobcenterløsningen en meddelelse til Løsningen. Meddelelsen anvendes primært til at etablere kommunikation mellem kontaktforløbet i Jobcentret og sagen i Ydelsescentret, så det efterfølgende er muligt at sende meddelelser om aktiviteter, Godtgørelser, fravær og sanktionsindstillinger, men indholdet af meddelelsen vises også på sagen. Jobcentret tilrettelægger aktiviteter for ledige, der skal bringe vedkommende tættere på at komme i arbejde. Aktiviteten kan ligge inden for områderne; vejledning og opkvalificering, virksomhedspraktik eller ansættelse med løntilskud. Den ledige skal tage imod rimeligt tilbud om aktivering for at beholde sin Ydelse. Hvis Jobcentret ændrer kontaktforløbet på Personen, sender Jobcenterløsningen en meddelelse med ændringerne, der gemmes i Løsningen. Ændringer kan danne udgangspunkt for en eventuel genoplysning af sagen. Hvis Jobcentret ændrer LAB-målgruppen på Personen, vil dette ligeledes blive sendt som en meddelelse til Løsningen, og sagsbehandleren (Ydelsescentret) kan vurdere, om målgruppeskiftet medfører behov for ændring af typen på den bevilgede Ydelse. Når Jobcentret afslutter et kontaktforløb, sendes der Besked om ændringen, og Løsningen danner en Opgave til sagsbehandleren (Ydelsescentret) om at ajourføre sagen. Jobcentret kan genoptage et afsluttet kontaktforløb indenfor 28 dage efter stopdatoen. Der sendes Besked til Løsningen om genoptagelse, hvorefter sagsbehandleren (Ydelsescentret) kan tage stilling til genoptagelse af sagen. Krav# 258: Modtag Besked om kontaktforløb fra jobcentret Beskrivelse: Løsningen skal via Jobcentersnitfladen kunne modtage og gemme en Besked fra jobcentret om, at en Person har fået et kontaktforløb, at kontaktforløbet er ændret, genoptaget eller stoppet i Jobcentret. a) Løsningen har modtaget og gemt Beskeden på Personens sag. b) Løsningen har registreret en Hændelse om kontaktforløbet og udført handlingen, der initieres af Hændelsen. - Se afsnit 6.4.3.19 om snitflade til Jobcenterløsningerne. - Se Krav# 92 om automatisk reaktion på Hændelser. - Se Krav# 160 om visning af sagens oplysninger. - Se Krav# 68 om etablering af sag på grundlag af Besked fra Jobcentret. - Se hændelseslisten i underbilag 2.13. Side 168 af 257
- Se informationsmodellen KY-kontaktforløb i underbilag 2.5. 5.9.1.3 Besked fra Jobcentret om aktiviteter Jobcentret tilbyder Personen aktiveringstilbud i form af aktiviteter, der er knyttet til LAB-målgruppen/målgruppestatussen for Personens kontaktforløb i Jobcentret. Jobcentret informerer Ydelsescentret om, hvilke aktiviteter Personen er tilknyttet i en given periode. Aktiviteter er gældende for en bevilling og skal ligge indenfor bevillingsperioden. Aktivitet, LAB-målgruppe/målgruppestatus og bevilling er tæt koblede og har indflydelse på refusionsprocenten for de bevilgede Ydelser. Udover kontering er aktiviteterne vigtige i forhold til modtagelse af Beskeder om fravær og sanktionsindstillinger. Jobcentret registrerer, at en Person har en aktivitet i en given periode. Jobcenterløsningen sender Besked til Ydelsescenterløsningen om aktiviteten og eventuelle ændringer til aktivitetens oplysninger, afbrydelser eller sletninger. Ændringen af aktiviteten gælder for hele den periode, som aktiviteten omfatter og påvirker beregningen og konteringen i Løsningen. Ændringerne af konteringen foregår uden sagsbehandlernes (Ydelsescentret) medvirken. Krav# 259: Modtag Besked om aktivitet fra jobcentret Beskrivelse: Løsningen skal via Jobcentersnitfladen kunne modtage og gemme en Besked fra jobcentret om en Persons deltagelse i en aktivitet, ændring, afbrydelse eller sletning af aktiviteten. a) Løsningen modtager og gemmer Beskeden på Personens sag. b) Løsningen har registreret en Hændelse om aktiviteten og udført handlingen, der initieres af Hændelsen. - Se afsnit 6.4.3.19 om snitflade til Jobcenterløsningerne. - Se Krav# 160 om visning af sagens oplysninger. - Se Krav# 92 om automatisk reaktion på Hændelser. - Se informationsmodellen KY-kontaktforløb i underbilag 2.5. - Se hændelseslisten i underbilag 2.13. 5.9.1.4 Besked fra Jobcentret om Godtgørelser Der kan udbetales Godtgørelse/introduktionsudgift efter LAB 82 og 83 og Integrationslovens 23F til brug for befordringsgodtgørelse og udgifter forbundet ved deltagelse i en given aktivitet. Jobcentret bevilger Godtgørelsen og informerer Ydelsescentret, som udbetaler Godtgørelsen som en dag-til-dag udbetaling eller i forbindelse med udbetaling af forsørgelsesydelsen på grundlag af Beskeden. Modtagelse af Besked om Godtgørelse og håndtering af udbetalingen skal ske uden involvering af sagsbehandleren (Ydelsescentret) via automatisk sagsoprettelse, effektuering og afslutning af sag. Kun i de tilfælde, hvor ydelsescentret angiver beløbet for Godtgørelsen, skal sagsbehandleren (Ydelsescentret) orienteres via en Opgave om bevilling af beløbet. Krav# 260: Modtag Besked om Godtgørelse fra jobcentret Beskrivelse: Løsningen skal via snitfladen til Jobcenter kunne modtage og gemme en Besked fra jobcentret om oprettelse, ændring eller sletning af en Godtgørelse, der er tilknyttet en aktivitet. Side 169 af 257
a) Løsningen modtager og gemmer Beskeden på Personens sag. b) Løsningen har registreret en Hændelse om Godtgørelsen og udført handlingen, der initieres af Hændelsen. - Se afsnit 6.4.3.19 om snitflade til Jobcenterløsningerne. - Se Krav# 160 om visning af sagens oplysninger. - Se Krav# 92 om automatisk reaktion på Hændelser. - Se informationsmodellen KY-kontaktforløb i underbilag 2.5. - Se hændelseslisten i underbilag 2.13. 5.9.1.5 Besked fra Jobcentret om fravær og sanktioner Jobcentret registrerer, når en Person har berettiget fravær fra sit kontaktforløb eller uberettiget fravær fra en specifik aktivitet. Jobcentret informerer Ydelsescentret om fraværet. Fraværsregistreringen skal dels påvirke konteringen af den bevilgede Ydelse, og dels håndteres som en sanktionsindstilling, når fraværet er uberettiget. Jobcentret kan derudover foretage en samlet indstilling til sanktionering på baggrund af en eller flere negative Hændelser, der er sket i forbindelse med Personens kontaktforløb. Et eksempel på en negativ Hændelse kan være Udeblivelse fra jobsamtale. Den samlede indstilling indgives til Ydelsescentret som en sanktionsindstilling. Sanktionsindstillingen er Jobcentrets indstilling til træk i Ydelsen. Den danner grundlag for, at Ydelsescentret vurderer og fastsætter trækket i den bevilgede Ydelse på Personens sag. Krav# 261: Modtag Besked om fravær fra jobcentret Beskrivelse: Løsningen skal via snitfladen til Jobcenter kunne modtage og gemme en Besked fra jobcentret om, at en Person har haft fravær fra sit kontaktforløb eller uberettiget fravær fra en aktivitet. a) Løsningen modtager og gemmer Beskeden på Personens sag. b) Løsningen registrerer en Hændelse om Godtgørelsen og udfører handlingen, der initieres af Hændelsen. c) Løsningen har sikret, at en meddelelse om uberettiget fravær fra en aktivitet har dannet en sanktionsindstilling. - Se afsnit 6.4.3.19 om snitflade til Jobcenterløsningerne. - Se Krav# 160 om visning af sagens oplysninger. - Se Krav# 92 om automatisk reaktion på Hændelser. - Se Krav# 59 og Krav# 60 om registrering af sanktioner. - Se informationsmodellen KY-kontaktforløb i underbilag 2.5. - Se hændelseslisten i underbilag 2.13. Krav# 262: Modtag Besked om sanktionsindstilling fra jobcentret Beskrivelse: Løsningen skal via snitfladen til Jobcenter kunne modtage og gemme en Besked fra jobcentret med en sanktionsindstilling eller en ændring til en sanktionsindstilling. Side 170 af 257
a) Løsningen har modtaget og gemt Beskeden på Personens sag. b) Løsningen har registreret en Hændelse om sanktionsindstillingen og udført handlingen, der initieres af Hændelsen. - Se afsnit 6.4.3.19 om snitflade til Jobcenterløsningerne. - Se Krav# 160 om visning af sagens oplysninger. - Se Krav# 92 om automatisk reaktion på Hændelser. - Se Krav# 59 og Krav# 60 om registrering af sanktioner. - Se informationsmodellen KY-kontaktforløb i underbilag 2.5. - Se hændelseslisten i underbilag 2.13. 5.9.1.6 Besked fra Jobcentret om visitationsgruppe Når Jobcentret visiterer en borger ved en samtale om borgerens kontaktforløb, afgør jobcentersagsbehandleren om borgeren er åbenlyst uddannelsesparat, uddannelsesparat, jobparat eller aktivitetsparat. Borgere, der visiteres som aktivitetsparate, har ret til et aktivitetstillæg, hvis de deltager i en aktivitet. Aktivitetstillægget udbetales af Ydelsescentret og indgår i beregningen af Ydelsen. LAB-målgruppen på et kontaktforløb afgør, hvilke borgere, der er aktivitetsparate, og hvilke der er jobparate. Der er dog enkelte undtagelse, hvor LAB-målgruppen ikke alene kan angive, om borgeren er aktivitetsparat eller jobparat; LAB-målgruppen Kontanthjælpsmodtagere omfattet af integrationsprogrammet kan være enten jobparat eller aktivitetsparat, og LAB 2.12 Uddannelseshjælp kan være enten Åbenlyst uddannelsesparat eller Uddannelsesparat. Jobcenteret sender derfor Besked om, hvordan borgere i disse målgrupper er visiteret, og Løsningen gemmer oplysningen på sagen til brug for udbetaling af aktivitetstillæg. Krav# 263: Modtag Besked om visitationsgruppe fra jobcentret Beskrivelse: Løsningen skal via snitfladen til Jobcenter kunne modtage og gemme en Besked fra jobcentret om, at en Person med målgruppen Kontanthjælpsmodtager omfattet af integrationsprogrammet er visiteret som Jobparat eller Aktivitetsparat eller LAB målgruppen 2.12 Uddannelseshjælp er visiteret som Åbenlyst uddannelsesparat eller Uddannelsesparat, eller at visitationsgruppen er slettet a) Løsningen har modtaget og gemt Beskeden på Personens sag. b) Løsningen har registreret en Hændelse om visitationsgruppen. - Se afsnit 6.4.3.19 om snitflade til Jobcenterløsningerne. - Se Krav# 160 om visning af sagens oplysninger. - Se informationsmodellen KY-kontaktforløb i underbilag 2.5. - Se hændelseslisten i underbilag 2.13. 5.9.1.7 Besked fra Jobcentret om tilkendegivelse om deltagelse i tilbud Når unge under 30 får et kontaktforløb i Jobcentret, skal de tilkendegive, om de ønsker at deltage i tilbud. Datoen hvorpå den unge angiver, at han vil deltage i tilbud har betydning for, hvornår der kan gives aktivitetstillæg til den unge. Krav# 264: Modtag Besked om tilkendegivelse om deltagelse i tilbud fra jobcentret Side 171 af 257
Beskrivelse: Løsningen skal via snitfladen til Jobcenter kunne modtage og gemme en Besked fra jobcentret om, at en Person har tilkendegivet, at han ønsker at deltage i tilbud samt datoen, hvorpå tilkendegivelsen er givet. a) Løsningen har modtaget og gemt Besked om tilkendegivelse eller ændring af tilkendegivelsen på Personens sag. b) Løsningen har registreret en Hændelse om tilkendegivelsen. - Se afsnit 6.4.3.19 om snitflade til Jobcenterløsningerne. - Se Krav# 160 om visning af sagens oplysninger. - Se informationsmodellen KY-kontaktforløb i underbilag 2.5. - Se hændelseslisten i underbilag 2.13. 5.9.1.8 Bevillingsbesked Ydelsessagsbehandleren oplyser sagen i Løsningen og afgør, at Personen skal have bevilget en Ydelse (med undtagelse af fleksløntilskud og Godtgørelser). Sagsbehandleren (Ydelsescentret) angiver typen af Ydelse og en virkningsdato, hvorpå Ydelsen skal træde i kraft. Hvis Personen har et kontaktforløb i Jobcentret, skal Løsningen informere Jobcentret om at den bevilgede Ydelse er registreret i Ydelsescentret og effektueres herfra. Jobcentret informeres ligeledes, hvis bevillingen stoppes. Sagsbehandleren (Ydelsescentret) kan, på baggrund af Hændelser såsom sanktionering af Personen eller flytning, vurdere, at bevillingen skal stoppes. Jobcentret skal informeres om ændringen med angivelse af en stopdato for den bevilgede Ydelse, da Jobcentrets opfølgningsforpligtigelse overfor Personen bortfalder ved stop af Ydelsen. Krav# 265: Afsend Besked om en bevilget Ydelse til jobcentret Beskrivelse: Løsningen kan udstille oplysninger om en bevilget Ydelse til Jobcentret. a) Løsningen overfører bevillingsoplysninger om en af nedenstående Ydelser til Jobcentret ved oprettelse af Ydelsen og ved redigering af start- eller slutdato. Kontanthjælp (LAS 11) Kontanthjælp (60 årige u. pensionsrettigheder, (LAS Kontanthjælp under aktivering (LAS 11) Uddannelseshjælp (LAS 11) Forrevalidering (LAS 47 stk. 4 og 5) Revalidering (LAS 52, jf. 47 stk.3) Ressourceforløbsydelse (LAS 68) Ledighedsydelse ved fleksjob (LAS 74) Fleksløntilskud (LAB 70f) Særligt udsatte unge under 18 år (LAB 75c) b) Løsningen overfører oplysninger om sletning af Ydelse, hvis Ydelsen er lukket med årsagen fejloprettet, eller hvis sagen er slettet. Side 172 af 257
- Se afsnit 6.4.3.19 om snitflade til Jobcenterløsningerne.. - Se Krav# 56 om indberetning af afgørelse. - Se informationsmodellen KY-Bevilling i underbilag 2.5. - Se underbilag 2.16 Mapning mellem Ydelser og jobcenter LAB-målgruppe/målgruppestatus. 5.9.2 Styrelsen for Arbejdsmarked og Rekrutterings (STAR) fælles datagrundlag Ydelsescentret skal levere data til styrelsen om bevilling af kontanthjælp og uddannelseshjælp. Kontanthjælp og uddannelseshjælp er de eneste Ydelser, som skal registreres i STAR fælles datagrundlag. Når der bevilges kontanthjælp eller uddannelseshjælp, ændrer STAR borgerens tilmeldingsstatus fra kontanthjælps/uddannelseshjælpsansøger til modtager. En ledig skal tilmeldes som ledig i jobcentret og registreres dermed i STAR fælles datagrundlag. Tilmeldingen kan ske via Jobnet.dk eller via jobcentret. Den ledige har pligt til at møde op i jobcentret. Hvis den ledige er berettiget til en Ydelse, vil startdatoen for Ydelsen i de fleste tilfælde være lig med tilmeldingsdatoen, men tilmeldingsdatoen kan ligge tidligere end startdatoen for kontaktforløbet. Hvis en borger kommer i arbejde, undlader at tjekke sine jobopslag, eller der ikke bevilges Ydelse, bliver borgeren afmeldt i jobcentret. På grundlag af en afmelding foretager jobcentret en opfølgning eller afslutter borgerens kontaktforløb. Styrelsen for Arbejdsmarked og Rekruttering anvender data til statistik og videreformidler oplysninger til Jobcentret, men holder også styr på til- og afmeldestatus for de borgere, der behandles i hhv. Ydelses- og Jobcentrene, og borgere, der selv tilmelder sig via Jobnet.dk. 5.9.2.1 Ikke-sagshenførbare Beskeder I flere tilfælde kan Løsningen have behov for at kunne modtage Beskeder om en Person, selvom sagsbehandlingen i Ydelsescentret endnu ikke er begyndt, og der derfor ikke er en sag, som Beskederne kan tilknyttes. Det skyldes, at Det Fælles Data Grundlag (DFDG) sender Beskeder, uanset om der er oprettet en sag i Ydelsescentret eller ej. Når der oprettes en sag, skal Beskederne kobles til sagen. Krav# 266: Håndter ikke-sagshenførbare Beskeder Beskrivelse: Løsningen skal kunne modtage og gemme Beskeder fra DFDG, der vedrører en Person, men som ikke kan knyttes til en sag i Løsningen. - Se Krav# 357 om snitfladen til DFDG. - Se underbilag 2.13 for yderligere information om reaktion på meddelelser fra DFDG. Krav# 267: Kobling af ikke-sagshenførbare Beskeder til en sag Beskrivelse: Løsningen skal kunne koble ikke-sagshenførbare Beskeder til en sag, når der oprettes en sag med samme CPR-nummer som Beskeden og kontanthjælp eller uddannelseshjælp som forsørgelsesydelse. a) Løsningen kan koble ikke-sagshenførbare Beskeder til en Persons sag. Side 173 af 257
b) Alle Beskeder fra DFDG vedrørende Personen, der oprettes en sag på, kobles herefter til sagen. - Se Krav# 357 om snitfladen til DFDG. - Se underbilag 2.13 for yderligere information om reaktion på meddelelser fra DFDG. Krav# 268: Oprydning i ikke-sagshenførbare Beskeder Beskrivelse: Løsningen skal sikre, at der sker oprydning af ikke sagshenførbare Beskeder. a) Hvis Løsningen modtager Besked om afmelding af Person, og der ikke er oprettet en sag i Løsningen, skal Beskeden om tilmelding og afmelding slettes. - Se Krav# 357 om snitfladen til DFDG. - Se underbilag 2.13 for yderligere information om reaktion på meddelelser fra DFDG. 5.9.2.2 Beskeder om til- og afmelding samt bevilling Jobcentret registrerer et kontaktforløb for en borger i Jobcenterløsningen og tilmelder borgeren som kontanthjælps- eller uddannelseshjælpsansøger. Tilmeldingen registreres i Styrelsen for Arbejdsmarked og Rekrutterings (STAR) fælles datagrundlag via Jobcenterløsningen. Det fælles datagrundlag sender herefter Besked til Ydelsescentret om, at borgeren er tilmeldt som Ansøger. Løsningen gemmer Beskeden, men afventer en ansøgning om kontanthjælp/uddannelseshjælp fra borgeren, før der oprettes en sag. Når sagen oprettes, kobles Beskeden fra DFDG til sagen, så der efterfølgende kan kommunikeres med DFDG om bevillingen på sagen. Der modtages Beskeder fra det fælles datagrundlag og Jobcenterløsningerne, som har næsten identisk indhold, idet til- og afmelding fra det fælles datagrundlag svarer til kontaktforløb oprettet og kontaktforløb afsluttet fra Jobcenterløsningerne. Løsningen skal gemme Beskederne for at sikre, at der efterfølgende kan udveksles oplysninger mellem Løsningen og hhv. DFDG og Jobcenterløsningerne, men ikke alle Beskeder danner Opgaver til sagsbehandleren (Ydelsescentret). Som udgangspunkt skal Beskederne fra Jobcentret påvirke sagsbehandlingen i Løsningen ved dannelse af Opgaver, mens Beskederne fra STAR blot registreres i sagshistorikken på borgerens sag. Når ydelsessagsbehandleren træffer afgørelse om, hvorvidt borgeren er berettiget til Ydelse, skal Løsningen sende Besked til DFDG. Hvis borgeren ikke er berettiget til Ydelse, afmelder DFDG borgeren. Hvis Ydelsescentret ikke har truffet en afgørelse pt. senest 15 dage efter modtagelsen af tilmeldingen, så registreres borgeren som tilmeldt uden Ydelse og afmeldes som Ansøger af DFDG. På grundlag af afmeldingen i DFDG, skal Jobcentret afslutte borgerens kontaktforløb. For igen at være berettiget til kontant- eller uddannelseshjælp skal borgeren henvende sig i Jobcentret, der skal oprette et nyt kontaktforløb eller genoptage det tidligere. Løsningen gemmer Beskeden om afmeldingen, da afmeldings og gentilmeldingsdato kan danne grundlag for sagsbehandlerens (Ydelsecentret) vurdering af en senere sanktionsindstilling fra Jobcentret. Krav# 269: Modtag Besked fra DFDG om tilmelding eller afmelding af Person Side 174 af 257
Beskrivelse: Løsningen skal via snitfladen til det fælles datagrundlag kunne modtage og gemme Besked om, at en Person er tilmeldt eller afmeldt Jobcentret. a) Løsningen skal modtage og gemme Beskeden. b) Løsningen skal registrere en Hændelse om til- eller afmelding og udføre handlingen, der initieres af Hændelsen. - Se Krav# 357 om snitfladen til DFDG. - Se krav Krav# 92 om automatisk reaktion på Hændelser. - Se informationsmodellen (KY-Person) i underbilag 2.5). - Se underbilag 2.13 for yderligere information om reaktion på meddelelser fra DFDG. Krav# 270: Afsend Besked om afgørelse om bevilling til DFDG Beskrivelse: Løsningen skal via snitfladen til det fælles datagrundlag kunne afsende meddelelse til DFDG om udfaldet af en afgørelse om ansøgning om kontanthjælp eller uddannelseshjælp. - Meddelelsen indeholder start- og slutdato for bevillingen samt, hvorvidt bevilling er godkendt eller afslået. - Se Krav# 357 om snitfladen til DFDG. - Se Krav# 56 om indberetning af afgørelse. - Se informationsmodellen (KY-Person) i underbilag 2.5). 5.9.3 Forskudsvist udlagt børnebidrag Udbetaling Danmark (UDK) lægger ud for forskudsvist udbetalt børnebidrag, når en bidragsbetaler ikke betaler på bidragets forfaldsdag. Det forskudsudlagte beløb tilbageholdes i Personens Ydelse, hvis Personen modtager kontanthjælp, uddannelseshjælp, revalideringsydelse eller ressourceforløbsydelse. Beløbet afregnes til UDK, når Personen er partshørt, og Ydelsescentret har truffet afgørelse om tilbageholdelsen. Når Personer på kontanthjælp, uddannelseshjælp, revalideringsydelse eller ressourceforløbsydelse får et tillæg pga. en bidragspligt, sker der ubetinget fradrag jf. jf. Lov om aktiv Socialpolitik LAS 23 stk. 3, 25 stk. 4, 52 stk. 3, 68, stk. 2 eller 69, stk. 2. Når Personer på kontanthjælp, uddannelseshjælp eller ressourceforløbsydelse får en ydelse på forsørgersats, sker der fradrag efter de objektive kriterier i 96a. Arbejdsgangen med anmodning om og fradrag i ydelsen it-understøttes kun delvist i kommunerne i dag og suppleres af manuelle work arounds. Kommunerne er ansvarlige for at initiere udvekslingen af oplysninger med UDK. Dette sker ved at kommunerne sender oplysninger om borgere, der modtager ydelser efter de angivne lovparagraffer. For Personer med ydelser på forsørgersats sendes oplysninger, hvis Personerne opfylder de objektive kriterier for fradrag i Ydelsen grundet forskudsvist udlagt børnebidrag. Der sendes ligeledes oplysninger, hvis Personen ikke længere modtager tillæg pga. bidragspligt, eller ikke længere opfylder de objektive kriterier. Kort før udbetalingstidspunktet forespørger kommunen UDK om, hvorvidt der er et beløb til modregning i Ydelsen på Side 175 af 257
en Personbetingelserne, og UDK returnerer beløbet. Kommunen foretager herefter fradraget i Ydelsen og sender oplysninger om det fratrukne beløb til UDK. Krav# 271: Send sagsoplysninger til UDK Beskrivelse: Løsningen skal sende oplysninger om borgere, der opfylder betingelserne for fradrag i Ydelsen grundet forskudsvist udlagt børnebidrag, eller som ikke længere opfylder betingelserne til UDK. 1) Løsningen sender sagsoplysninger på Personer, der har en sag i Løsningen med en af Ydelserne kontanthjælp, uddannelseshjælp, revalideringsydelse eller ressourceforløbsydelse, hvis Personen modtager tillæg pga. bidragspligt eller opfylder de objektive kriterier for fradrag i Ydelsen: - For Ydelser efter 96a, må der ikke være registreret en af flg. fritagelsesårsager - Personen forsørger eget barn under 18 år i hjemmet - Personen har forsørgerpligt for flere end to børn under 18, der ikke bor i hjemmet. - Der er indgivet anmodning om tvangsfuldbyrdelse til fogedretten. - Fogedsagen er afsluttet uden udsættelse fradrag kan først ske måneden efter den måned, i hvilken fogedsagen er afsluttet. - Fogedsagen er afsluttet med udsættelse fradrag kan først ske 3 måneder efter den måned, i hvilken udsættelsen har fundet sted. 2) Løsningen sender sagsoplysninger på Personer, der har været fremsendt under pkt. 1, men som ikke længere opfylder betingelserne for fradrag i Ydelsen efter satsændring, ændring i børnetal eller fogedsag. - Se afsnit 6.4.3.15 vedrørende snitflader til KMD OPUS Debitor Betalingsadministration. - Se informationsmodellen KY- UDK-FUB i underbilag 2.5. - Se underbilag 2.7 om Lovgivning og beregningsregler. Krav# 272: Send forespørgsel om beløb til fradrag og modtag svar fra UDK Beskrivelse: Løsningen skal kunne forespørge UDK, om der er beløb til modregning for en given Person. 1. Løsningen har 1 dag før bestilling af udbetaling forespurgt, om der er oprettet en betalingsadministrationsaftale. 2. Løsningen har modtaget svar, og hvis svaret angiver, at der findes en betalingsadministrationsaftale, foretager Løsningen fradrag for børnebidrag i Ydelsen. Side 176 af 257
- Se afsnit 6.4.3.15 vedrørende snitflader til KMD OPUS Debitor Betalingsadministration. - Se informationsmodellen KY- UDK-FUB i underbilag 2.5. - Se underbilag 2.7 om Lovgivning og beregningsregler. Krav# 273: Send oplysning om det fratrukne beløb til UDK Beskrivelse: Løsningen skal kunne sende oplysninger til UDK om de fradrag, der er foretaget i de udbetalte Ydelser 1) Når fradrag for forskudsvist udlagt børnebidrag er foretaget i en Persons Ydelse, har Løsningen sendt oplysninger til UDK om det fratrukne beløb. - Se afsnit 6.4.3.15 vedrørende snitflader til KMD OPUS Debitor Betalingsadministration - Se informationsmodellen KY- UDK-FUB i underbilag 2.5. - Se underbilag 2.7 om Lovgivning og beregningsregler. 6 Ikke-funktionelle krav For at et it-system kan levere den service, Brugeren har behov for, er det nødvendigt at stille en række forskellige tekniske krav. Denne type krav kaldes ikke-funktionelle, idet de ikke direkte relaterer sig til Brugerens forretningsmæssige behov, men derimod beskæftiger sig med systemets servicemæssige kvalitet. De ikke-funktionelle krav er således til stede for at understøtte de funktionelle krav i kapitel 5 og koblingen hertil sker bl.a. gennem målarkitekturen, som beskrevet i kapitel 6.2. Kravene falder i kategorier som sikkerhed, tilgængelighed, brugervenlighed, etc. og de for Løsningen relevante ikke-funktionelle krav findes i dette afsnit. Offentlige strategier og generelle arkitekturprincipper Som central spiller på det kommunale område tager Kunden til enhver tid udgangspunkt i de fællesoffentligt vedtagne initiativer, principper og strategier. Disse vil være retningsgivende og beskriver kontekst og rammebetingelser for den konkrete Løsning, og i denne sammenhæng er Kommunernes Arkitekturråds godkendte fælleskommunale arkitekturprincipper (marts 2013) relevante. Krav# 274 Arkitekturprincipper Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal udvikles efter de fælleskommunale arkitekturprincipper (se http://www.kl.dk/imagevault/images/id_61151/scope_0/imagevaulthandler.aspx) [indhentet 23-10-2013] Side 177 af 257
Løsningen skal i høj grad bygges op omkring Den Fælleskommunale Rammearkitektur. Løsningen anvender i udpræget grad Fælles forretningsservices fra Rammearkitekturen, frem for at udvikle egne services. Herudover har De Fælleskommunale Arkitekturprincipper præget udformningen af krav til Løsningens løsningsarkitektur. Arkitektur Dette afsnit vil først skabe et overblik over Løsningen og dennes sammenspil med andre (eksterne) systemer (afsnit 6.2.1). Herefter gennemgås målarkitekturen for Løsningen (afsnit 6.2.2) og den løskoblede selvbetjeningsløsning (afsnit 6.2.3). Afsluttende beskrives en række tværgående egenskaber for Løsningen (afsnit 6.2.4). 6.2.1 System og integrationskontekst Løsningen skal eksistere i en kontekst, hvor den skal kommunikere med mange andre systemer - eksisterende såvel som kommende. Der er her tale om et bredt spektrum af sammenhænge til generelle tværkommunale løsninger (Rammearkitekturen, fælleskommunale løsninger mfl.), kommunal systemportefølje (økonomi, ESDH mfl.) og så de løsningsspecifikke sammenhænge (selvbetjeningsløsninger mfl.). Figuren nedenfor illustrerer på højt niveau den systemkontekst, løsningen skal indgå i: Figur 17: Løsningens systemkontekst Side 178 af 257
Løsningen, som illustreret på figuren, omfatter en selvbetjening som den enkelte kommune kan anvende. 6.2.2 Målarkitektur Løsningens kontekst, som beskrevet i forrige afsnit 6.2.1, beskriver Løsningens sammenhæng med den kommunale forretnings øvrige systemportefølje og den Fælleskommunale Rammearkitektur. I dette afsnit beskrives Løsningens målarkitektur, der vil sikre, at Løsningen lever op til den beskrevne kontekst. Der er to primære forretningsdrivere der påvirker Løsningens målarkitektur: For det første skal Løsningen efterleve den Fælleskommunale Rammearkitekturs arkitekturprincipper. For det andet er de forretningsområder, som Løsningen understøtter, ofte genstand for ændringer. Kunden ønsker en Løsning hvis tekniske aspekter (løsningsarkitektur) understøtter disse forretningsdrivere. For at imødekomme ændringer i omstændigheder, der påvirker Løsningens forretningskontekst, ønskes en løsning der giver anledning til lave vedligeholdelses- og videreudviklingsomkostninger. Målarkitekturen beskrevet i dette afsnit har derfor fokus på en løsning med en intern komponentopdeling, der følger Løsningens forretningskomponenter. Derudover er der fokus på genbrug af eksisterende forretningsservices i Rammearkitekturen, samt Rammearkitekturens Støttesystemer. Løsningens interne modularisering skal derfor inkludere og bygge på eksisterende funktionalitet, på de forretningsområder hvor dette er relevant. Målarkitekturen er illustreret på nedenstående figur: 3. parts løsninger Borger.dk NemLogin Selvbetjening (Person) Selvbetjeningsmodul Kommunernes Ydelsessystem Sagsbehandler brugergrænseflade Forretningsprocesser Forretnings Komponenter Sag Bevilling Journalnotat Dokument Part Adgangsstyring System Komponenter Regler Opgave Dataudtræk Post Autorisation Fælleskommunal Infrastruktur Beskedfordeler Serviceplatform Rapporter Systemadministration Selvbetjeningsservices Logning... Kommunal systemportefølje Kommunal hjemmeside ØIR Fælleskommunale Støttesystemer Fællesoffentlige registre Fælleskommunale løsninger Jobcenter ESDH Sags- & Dokumentindeks Ydelsesindeks Organisation Klassifikation CPR CVR eindkomst DFDG UIS Digital fuldmagt...... SAPA FLIS... UDK LIS... Figur forklaring: Anvendes af Løsningen Løsningen Side 179 af 257
Figur 18: Logisk arkitektur for Løsningen (målarkitektur) Figur 18 viser en generel opdeling af Løsningen i logiske forretningskomponenter, som de er defineret ud fra den Fælleskommunale Rammearkitekturs forretningsobjekter og -services. Forretningskomponenter er logiske grupperinger af funktionalitet, som matcher de i kap. 5 beskrevne funktionelle områder af Løsningen. Figur 18 viser endvidere en opdeling af Løsningens funktionalitet i systemkomponenter, som er defineret ud fra øvrige funktionelle krav til løsningen. Figur 18 viser ikke en fuldstændig liste over forretningskomponenter og systemkomponenter, men illustrerer et eksempel på mulige funktionelle barrierer, der isolerer og afgrænser funktionalitet i Løsningen, og dermed søger at sikre, at centrale elementer af Løsningen kan vedligeholdelse individuelt. Beskrivelse af relevante forretningskomponenter: Sag: Ansvarlig for Løsningens sager og deres integritet iht. gældende forretningsregler. Dokument: Ansvarlige for Løsningens dokumenter og deres integritet iht. gældende forretningsregler, samt relation til Sag Journalnotat: Ansvarlig for Løsningens journalnotater og deres integritet iht. gældende forretningsregler, samt relation til Sag. Part: Ansvarlig for Løsningens registrering af parter på en sag, samt at holde disse parters oplysninger opdateret fra centrale (autoritative) kilder. Bevilling: Ansvarlig for Løsningens bevillinger på baggrund af en sagsoplysning, samt relation til Sag Beskrivelse af relevante Systemkomponenter Regler: Ansvarlig for at implementerer forretningslogikken for regler for fx afgørelser i ydelsessager, der anvendes i løsningen. Opgaver: Ansvarlig for Løsningens Opgaver, oprettelser og bearbejdelse af disse, herunder deres sammenhæng til Sag og Dokumenter. Post: Afsendelse af Beskeder og breve til Part via Print på Serviceplatformen. Dataudtræk: Ansvarlig for at håndtere udtræk af Løsningens data til relevante modtagere uden for Løsningen Rapporter: Understøtter Løsningens krav til visning af standardrapporter Systemadministration: Understøtter Løsningens muligheder for opsætning og konfiguration Logning: Ansvarlig for at Løsningens krav til Logning overholdes Autorisation: Ansvarlig for at sikre at der alene gives autoriseret adgang til Løsningens data og funktionalitet Selvbetjeningsservices: Udstiller services til kommunikation med selvbetjeningsløsning Forretningskomponenterne Sag, Dokument, Journalnotat, Part og Bevilling er beskrevet i Rammearkitekturen og disse komponenter i Løsningen skal umiddelbart bygge på Rammearkitekturens tilsvarende forretningsservices. Systemkomponenterne Regler, Opgaver, Post, Dataudtræk, Rapporter, Systemadministration, Logning, Autorisation og Selvbetjeningsservices repræsenterer funktionalitet der i høj grad er velafgrænset og selvindeholdt, hvorfor disse umiddelbart tænkes som selvstændige komponenter I Løsningen. Side 180 af 257
Løsningen skal opbygges af løst koblede komponenter, der indgår i en lagdelt og modulær løsningsarkitektur. Løsningen skal have åbne og dokumenterede snitflader til eksterne systemer. Løsningens forretningskomponenter isoleres implementeringsmæssigt gennem indkapsling og abstraktionslag. Krav# 275 Komponentopdeling Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal opdeles i forretningskomponenter. Krav# 276 Forretningsrelaterede komponenter Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningens forretningskomponenter skal relatere sig til Løsningens forretningsprocesser. Krav# 277 Brug af Rammearkitekturens forretningsservices Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal bygge på Rammearkitekturens forretningsservices. Se www.kl.dk/rammearkitektur [Indhentet d. 25-04-2014] Krav# 278 Kategori: Beskrivelse: Kravet udgår - Løsningsarkitektur Type: Løsningen vil løbende skulle tilpasses til lovændringer, regelændring o.l., og det vil derfor være nødvendigt med en gennemgående model i Løsningen, der tilgodeser mulighed for disse ændringer, uden at det bliver for omkostningstungt. Krav# 279 Løsningsarkitekturens modifiability-grad Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningens løsningsarkitektur skal gøre det muligt at håndtere ændringer i love og regler o.l. 6.2.2.1 Generelle egenskaber for Løsningen Løsningen forventes at eksistere i én logisk instans, der benyttes af alle kommuner. Denne topologi betyder, at Løsningen skal holde styr på hvilke data, der hører til hvilke kommuner, så der alene præsenteres de data, Brugeren har adkomstret til. Til gengæld sikrer samme topologi, at antallet af integrationer kan minimeres. Side 181 af 257
Krav# 280 Én logisk instans Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen etableres som én logisk instans. Krav# 281 Data skal afgrænses baseret på kommune Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal sikre isolering mellem de enkelte kommuners data, således at det er muligt for Løsningens administratorer at administrere adgang til data for medarbejder, inden for- og på tværs af kommuner Kunden har en forventning til, at Løsningen kan opbygges ved brug af veletablerede og gennemprøvede teknologiske komponenter enten samlet i form af et standard rammesystem eller via sammensætning af komponenter eller tilsvarende. Krav# 282 Løsningen skal opbygges af velafprøvet teknologi Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal opbygges af veletablerede og gennemprøvede tekniske komponenter. 6.2.2.1.1 Kommunernes IT-miljø Løsningen skal anvendes af sagsbehandlere hos kommunerne, hvilket stiller krav til det miljø som Løsningen skal driftes i. Krav til Løsningen i forbindelse med kommunernes IT-miljø fremgår af underbilag 2.24 (Kommunernes IT-miljø). 6.2.3 Selvbetjeningsløsning Løsningen skal udbyde en selvbetjeningsfunktionalitet til de borgere, der har en sag til behandling i Løsningen, samt til eventuelle andre parter. Det er KOMBITs forventning, at selvbetjeningsløsningen leveres som en separat komponent, der er adskilt fra den resterende del af Løsningen. Baggrunden for dette er at funktionaliteten i selvbetjeningsløsning er væsentlig forskellig fra den resterende del af Løsningen, og at det skal være muligt for kommuner at implementere egen selvbetjeningsløsning ved hjælp af selvbetjeningsløsningens services, se afsnit 6.4.2.4. Side 182 af 257
Serviceplatform NemLogin / Digital fuldmagt Selvbetjeningsløsning Borger.dk Kommunal hjemmeside Selvbetjeningsservices KY Løsningen Figur 19: Selvbetjeningens kontekst 6.2.3.1 Krav til arkitektur for selvbetjening Krav# 283 Selvbetjening som særskilt modul Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningens selvbetjening skal implementeres som et særskilt modul, der trækker på Løsningens publicerede snitflader. Leverandøren skal til besvarelse af dette krav beskrive, hvordan dette bliver realiseret. Side 183 af 257
Krav# 284 Alternative selvbetjeningsløsninger Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Det skal være muligt for en 3. part at implementere en alternativ selvbetjeningsløsning, der kan erstatte den indbyggede til brug på de kommunale hjemmesider. Tilvalget af alternativ selvbetjeningsløsning skal ske kommuneindividuelt. Leverandøren skal til besvarelse af dette krav beskrive, hvordan dette bliver realiseret. Krav# 285 Mindst mulig forretningslogik i selvbetjeningsløsningen Kategori: (K) Type: Ikke-funktionelt Beskrivelse: For at reducere omkostningerne ved implementering af en alternativt selvbetjeningsløsning, skal selvbetjeningsløsningen i videst muligt omfang trække på de af Løsningen udstillede selvbetjeningsrelaterede services. Se afsnit 6.4.2.4 Selvbetjeningsintegration. Leverandøren skal redegøre for forventet træk på Løsningens publicerede snitflader for Løsningens egen selvbetjeningsløsning. Krav# 286 NemLogin Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Selvbetjeningsløsningen skal understøtte, at en Person bliver verificeret ved brug af NemLogin. Dette gælder uanset om Løsningens selvbetjeningsløsning eller en alternativ selvbetjeningsløsning anvendes. Krav# 287 Digital fuldmagt Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Selvbetjeningsløsningen skal understøtte, at der anvendes Digital fuldmagt. Herunder skal det være muligt at håndtere, at Tilknyttet Ansøger ikke er sammenfaldende med den Person, der skal selvbetjenes for, men at der kan angives/vælges CPR-nummer på den pågældende Person. Selvbetjeningsløsningen skal tydeligt vise for Tilknyttet Ansøger, at denne handler på vegne af andre. Side 184 af 257
Krav# 288 Autorisation af borger Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Selvbetjeningsløsningen skal understøtte, at en NemLogin verificeret Person eller Tilknyttet Ansøger kan autoriseres, såfremt der findes en sag på vedkommende eller på den Person, hvis sager der haves fuldmagt til. Krav# 289 Borgeradgang på tværs af kommuner Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal understøtte at, en autoriseret Person kan se sager på tværs af kommuner. Krav# 290 Logning af anvendelse af fuldmagtsprivilegier Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Hvis en Person eller Tilknyttet Ansøger tilgår sagsoplysninger, besvarer henvendelser fra eller kontakter kommunen, hvor dette gøres som repræsentant for en anden Person ved anvendelse af fuldmagtsprivilegier, skal dette logges til Revisionsloggen, se afsnit 6.2.4.2 Logning. Krav# 291 Eksisterende sager Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal understøtte, at en autoriseret Person kan se sine sager, og at en Person kan arbejde videre med sin sag i selvbetjeningen, i det omfang det giver mening i forhold til sagens status og rolle/rettigheder fordelt på en selvbetjeningsbruger og sagsbehandler. Krav# 292: Kravet udgår Kategori: Beskrivelse: Bemærkning Type: I Selvbetjeningen kan den Digitale Ansøgning/Tilknyttede Ansøger søge om kontanthjælp, uddannelseshjælp, ledighedsydelse under ferie og enkeltydelser, men der vil være behov for løbende at kunne tilføje muligheden for at ansøge om andre ydelser. Selvbetjeningens løsningsarkitektur skal derfor sikre et tilpas abstraktion af ansøgningsfunktionalitet og visning af Min sag over konkrete Ydelser, sådan at det er effektivt at udvide Selvbetjeningen med nye Ydelser. Side 185 af 257
Krav# 293: Generisk ansøgningsfunktionalitet Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Selvbetjeningsløsningen skal designes sådan at det vil kræve minimale ændringer i Selvbetjeningsløsningen, herunder relaterede dele af Løsningen, at tilføje mulighed for at ansøge om nye Ydelser. Bemærkning Krav# 294: Selvbetjeningsløsningen anvendelse af Serviceplatformen Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Selvbetjeningsløsningen kan anvende Serviceplatformen til indhentning af data fra eksterne registre, fx fra CPR til automatisk udfyldning af adresseoplysninger mm. Bemærkning Krav# 295: Webservice til udstilling af selvbetjenings URL Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal udstille et JSON objekt via en REST service, der kan returnere en liste over alle kommuner, med hver kommunes fulde URL til selvbetjeningsløsningen, hvis kommunen har aktiveret denne. Bemærkning a) REST servicen skal kaldes uden input parametre b) Det returnerede JSON objekt skal altid være et array med et objekt pr. kommune, hver bestående af et kommunenummer og en URL. c) For de kommuner der har aktiveret Løsningens selvbetjeningsløsning, returneres selvbetjenings-url en til denne. Hvis ikke, returneres en tom streng. d) Løsningen skal udstille REST-servicen og den skal være tilgængelig for eksterne løsninger udenfor kommunen, f.eks. borger.dk eller jobnet.dk e) Servicen skal kunne kaldes via http eller https uden nogle login-oplysninger eller adgangs-tokens f) Servicen kan med fordel være en del af selvbetjeningsløsningen Løsningen udstiller snitfladen (SF2700) vha. et synkron request-response integrationsmønster. Se nærmere detaljer, samt teknisk specifikation i underbilag 2.6. Krav# 296: Selvbetjeningsløsningens URL Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Selvbetjeningsløsningen skal etableres på en webserver som er en del af dem samlede Løsning. For URL en til selvbetjeningsløsningen gælder nedenstående krav. a) URL en for hver kommune skal være statisk, dvs. aldrig ændre sig b) Der skal være en unik URL for hver kommune c) URL en må ikke være længere end 50 tegn i alt inkl. protokol, domæne, sti og eventuelle parametre d) Leverandøren må godt benytte sin egen URL-forkorter hvis dette er nødvendigt Side 186 af 257
Bemærkning e) Selvbetjeningsløsningen skal kun være mulig at tilgå via https f) Leverandøren er ansvarlig for at indkøbe SSL-certifikat fra en anerkendt og udbredt certifikatudsteder Løsningen udstiller snitfladen (SF2700) vha. et synkron request-response integrationsmønster. Se nærmere detaljer, samt teknisk specifikation i underbilag 2.6. 6.2.3.2 Præsentationsmåde Se også kapitel 6.5 Brugervenlighed for yderligere ikke-funktionelle krav til brugergrænsefladen i Selvbetjeningsløsningen. Løsningens selvbetjening skal udstilles på borger.dk jf. krav i afsnit 6.4.4 - Snitflader anvendt af selvbetjening. Løsningens selvbetjening skal derfor udstille webservicekomponenter, der muliggør integration til borger.dk. Samme webservicekomponenter skal muliggøre at Løsningens selvbetjening kan integreres i kommunernes egne hjemmesider. Hertil skal det være muligt for en kommune at style den integrerede selvbetjening så look n feel matcher kommunens side. Det er kommunens ansvar at style selvbetjeningsløsningen til deres egen hjemmeside. Krav# 297 Udstilling af selvbetjeningsløsningen på kommunens egen hjemmeside Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Selvbetjeningsløsningen skal kunne integreres på kommunernes egne hjemmesider. Det skal være muligt for en kommune at style (CSS) den integrerede selvbetjening. a) Det skal være muligt at tilpasse top, bund og sider af selvbetjeningssiden med kommunens egen HTML kode b) Det skal være muligt at uploade billeder til fx kommunens logoer c) Det skal være muligt at uploade CSS stylesheets d) Uploadede filer skal ligge på samme server som selvbetjeningsløsningen og tilgås via samme domænenavn som selvbetjeningsløsningen i kommunens egen HTML kode Se også Krav# 374 omkring udstilling af selvbetjeningsformularen via Borger.dk. Jf. Krav# 284 kan kommunen vælge alternativ selvbetjeningsløsning, hvorved dette krav bortfalder for den pågældende kommune. Krav# 298 Tællerscript til borger.dk Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Selvbetjeningsløsningen skal have påsat tællerscripts fra borger.dk. For yderligere information se http://arkitekturguiden.digitaliser.dk/node/584 [indhentet 14-11-2013] Side 187 af 257
6.2.4 Tværgående egenskaber for Løsningen Ud over de generelle og specifikke egenskaber for Løsningens forretningskomponenter og andre moduler, er der en række tværgående egenskaber, der er samlet i dette afsnit: Bitemporalitet Logning Fejltolerance Skalerbarhed Volumen Løsningens tilgængelighed 3. part programmel 6.2.4.1 Bitemporalitet Mange af de sager, som håndteres ved brug af Løsningen, er aktive over længere perioder. I løbet af sagens levetid vil oplysninger, som ligger til grund for afgørelser, beregninger og udbetalinger, typisk ændres over tid. Der er flere typer af oplysninger: Oplysninger der på et givet tidspunkt har én værdi på en given sag, fx Beløb for arbejdsindtægter, jf. LAS 30 i indeværende udbetalingsperiode. Her vil en ny værdi erstatte den tidligere. Oplysninger der registreres med en given gyldighedsperiode, fx ATP-satsen. Her kan en ny værdi registreres med en gyldighedsperiode, der begynder på et senere tidspunkt. Et sæt af oplysninger, der samlet set vedrører en specifik periode, fx regler, der kan have overlappende perioder og blot være reguleret af sagens starttidspunkt eller tilsvarende Da de oplysninger, der registreres i Løsningen, ikke nødvendigvis gælder fra registreringstidspunktet og frem i tiden, men kan have virkning både bagud i tid og frem i tiden, er det vigtigt for udredning af sagerne, at Løsningen er i stand til at vise sagerne med deres dokumentation, bevillinger og effektueringer således, som de så ud på et givent tidspunkt, hvis der er tvivl om fx grundlaget for en afgørelse eller grundlaget for en beregning. Kundens anbefaling og forventning er, at Løsningen løfter dette behov ved at anvende bitemporalitet. Bitemporalitet dækker over, at Løsningen skal evne at registre både kendskabsperiode og virkningsperiode. Kendskabsperiode starter med registreringstidspunktet og er oftest uden slutperiode, men det bør være understøttet som mulighed. Virkningsperioden er så den periode, i hvilken sagen påvirkes af oplysningen. Som eksempel kan nævnes., at en Ydelse kan fx være givet, selvom der i samme periode har været udbetalt feriepenge. Hvis oplysningen om feriepenge ikke var registreret, da Ydelsen blev beregnet, kunne Løsningen ikke tage højde derfor. Bitemporalitet beskrives i detaljer i Generelle egenskaber for services på sags- og dokumentområdet - OIO-Godkendt.pdf (se http://digitaliser.dk/resource/1567464 [indhentet 14-01-2014]) s 20ff, hvor de værdier, der gemmes ved registrering og virkning, defineres. Krav# 299: Bitemporalitet Kategori: MK Type: Ikke-funktionelt Beskrivelse: Løsningen skal understøtte bitemporalitet for alle klasser i informationsmodellen, samt på alle forretningsbærende data, som Løsningen skal anvende for at opfylde øvrige krav i nærværende kravspecifikation. Side 188 af 257
Alle Rammearkitekturens støttesystemer anvender også OIO modellen eller tilsvarende for bitemporalitet. Så længe en sag findes i Løsningen, fastholdes alle relaterede oplysninger i sagen, hvorved de bitemporale egenskaber ved disse oplysninger gør det muligt at se alle aspekter af en sag, som den var oplyst på et givet tidspunkt (jf. Krav# 152) 6.2.4.2 Logning Løsningen skal foretage logning. Logning skal omfatte begivenheder i Løsningen til en række forskellige formål og i en række forskellige typer af logs. Logs anvendes bl.a. til sporbarhed, kontrol af SLA-krav, fejlfinding og opfyldelse af lovmæssige krav m.v. Logningskravene til Løsningen fremgår af underbilag 2.27 (Logning). 6.2.4.3 Fejltolerance Løsningen er et forretningskritisk system, der skal være tilgængeligt for sagsbehandlere på hverdage i arbejdstiden. Løsningens tilgængelighed er imidlertid afhængig af ikke blot kernesystemet, men også de omkringliggende systemers tilgængelighed. Løsningen benytter fx Serviceplatformen som centralt integrationspunkt og dennes tilgængelighed er således også central. Krav# 300 Fejltolerance Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal designes med fejltolerance for øje. Leverandøren skal således redegøre for, hvordan Løsningen evt. fortsat kan være tilgængelig, selvom omkringliggende systemer ikke er det og i hvilket omfang, samt hvor længe. Løsningen anvender mange integrationer til eksterne systemer både til at indhente information til brug i sagsbehandlingen, men Løsningen skal også aflevere informationer omkring sager m.m. til omkringliggende systemer og myndigheder. For visse sagsgange er det vigtigt, at disse informationer kan udveksles mellem Løsningen og omkringliggende systemer og myndigheder, derfor skal Løsningen kunne håndtere gensendelse af informationer ved transmissionsfejl. Krav# 301 Fejltolerance Retransmission Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal designes med fejltolerance omkring integrationer og transmissionsfejl. Leverandøren skal således redegøre for, hvordan Løsningen kan håndtere transmissionsfejl og gensendelse af information til omkringliggende systemer. Selvbetjeningsløsningen tænkes implementeret som et separat modul, der trækker på veldefinerede snitflader. Selvbetjeningsløsningen tænkes således løst koblet ift. den resterende del af Løsningen, og også her er der behov for at have fokus på fejltolerance. Krav# 302 Fejltolerance Selvbetjeningsløsningen Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Selvbetjeningsløsningen skal designes med fejltolerance for øje. Leverandøren skal således redegøre for, hvordan selvbetjeningsløsningen evt. fortsat kan Side 189 af 257
være tilgængelig, selvom omkringliggende systemer ikke er det og i hvilket omfang, samt hvor længe. 6.2.4.4 Skalerbarhed Løsningens evne til at håndtere belastninger, der ligger ud over det forudsete, er en væsentlig parameter ift. at sikre en stabil og god brugeroplevelse. Det er således væsentligt for Kunden at sikre, at den tilbudte Løsning er bygget så den skaleres vertikalt (større, bedre hardware) og horisontalt (flere instanser, der arbejder sammen). Krav# 303 Skalerbarhed Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal designes, så den kan skalere både horisontalt og vertikalt. Leverandøren bedes redegøre for, hvordan Løsningens design sikrer dette samt for, hvordan Løsningens skalerbarhed dokumenteres. 6.2.4.5 Volumen Der kan ud fra den nuværende Løsning estimeres på antal Brugere og sager, som Løsningen skal være i stand til at håndtere. Tallene i dette afsnit er inkluderet for at give et billede på antal Brugere, sager m.v. 6.2.4.5.1 Brugertal sagsbehandlerdel Det forventede antal samtidige Brugere for Løsningen er angivet i nedenstående tabel: Type Antal Samtidige mulige Brugere 13.000 Samtidige inaktive Brugere logget på 5.000 Løsningen Samtidige aktive Brugere Antal samtidige aktive Brugere under spidsbelastning Minimum: 3.500 Forventet: 4.500 Antal samtidige aktive Brugere i normal drift Minimum: 3.000 Forventet: 4.000 Tabel 7: Samtidige Brugere for Løsningen Krav# 304 Minimum antal Brugere for Løsningen Kategori: (MK) Type: Ikke-funktionelt Beskrivelse: Løsningen skal kunne håndtere minimumstal for antal samtidige aktive Brugere, der er fremsat i Tabel 7. Krav# 305 Brugere af Løsningen Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal kunne håndtere forventet tal for antal samtidige aktive Brugere, der er fremsat i Tabel 7, samt tal for samtidige inaktive Brugere. Side 190 af 257
6.2.4.5.2 Brugertal selvbetjeningsdel Det forventede antal samtidige Brugere for Løsningens selvbetjening er angivet i nedenstående tabel: Type Antal Samtidige mulige Brugere 200.000-400.000 (Digitale Ansøgere) Samtidige inaktive Brugere 1000 logget på Løsningen (Digitale Ansøgere) Samtidige aktive Brugere (Digitale Ansøgere) Tabel 8: Samtidige Brugere for Løsningens selvbetjening Antal samtidige aktive Brugere under spidsbelastning Minimum: 20.000 Forventet: 60.000 Antal samtidige aktive Brugere i normal drift Minimum: 2.000 Forventet: 6.000 Krav# 306 Minimum antal Brugere for Løsningens selvbetjening Kategori: (MK) Type: Ikke-funktionelt Beskrivelse: Løsningen skal kunne håndtere minimumstal for antal samtidige aktive Brugere, der er fremsat i Tabel 8. Krav# 307 Antal Brugere for Løsningens selvbetjening Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal kunne håndtere forventet tal for antal samtidige aktive Brugere, der er fremsat i Tabel 8, samt tal for samtidige inaktive Brugere. Realisering af kravet skal ske i tæt sammenhæng med realisering af krav til skalerbarhed, jf. 6.2.4.4 - Skalerbarhed. 6.2.4.5.3 Sagstal Tabel 9 viser den forventede volumen på sager og relateret relevant information. Antal ved måneds udgang er et udtryk for størrelsen af den løbende bestand af åbne sager. Der forventes således at være ca. 160.000 åbne sager vedrørende uddannelseshjælp og kontanthjælp. Antal nye pr. år udtrykker forventningen til hvor mange ansøgninger/indstillinger, der skal behandles i løbet af et år. Ydelsesart Antal ved måneds udgang Antal nye pr år Uddannelseshjælp og kontanthjælp 160.000 172.000 Revalideringsydelse 9.000 5.100 Ressourceforløbsydelse 20.000 10.000 Ledighedsydelse 18.000 31.000 Fleksløntilskud 39.000 13.000 Administrationssager 25.000 5.000 Enkeltydelser 11.500 84.500 Andre Ydelser 99.000 99.000 Total 381.500 419.600 Tabel 9: Sagstal for Løsningen Side 191 af 257
Krav# 308 Sagstal for Løsningen Kategori: (MK) Type: Ikke-funktionelt Beskrivelse: Løsningen skal kunne håndtere de sagstal, der er fremsat i Tabel 9 Realisering af kravet skal ske i tæt sammenhæng med realisering af krav til skalerbarhed, jf. 6.2.4.4 - Skalerbarhed. 6.2.4.5.1 Tal for brevskabeloner Tabel 10 viser forventet volumen på centrale og lokale brevskabeloner. Tallene er angivet samlet set for alle kommuner. Brevskabeloner Antal Centrale brevskabeloner 150 Lokale varianter af centrale brevskabeloner 1.800 Yderligere lokale brevskabeloner 2.000 Tabel 10: Tal for brevskabeloner Krav# 309 Tal for brevskabeloner Kategori: (MK) Type: Ikke-funktionelt Beskrivelse: Løsningen skal kunne håndtere antallet af brevskabeloner for hhv. centrale brevskabeloner, lokale varianter af centrale brevskabeloner og yderligere lokale brevskabeloner i Tabel 10. - Se afsnit 5.4.3 og 5.6.3 vedrørende krav til breve og brevskabeloner. - Se underbilag 2.12 for eksempler på brevskabeloner. 6.2.4.6 Løsningens tilgængelighed Dette afsnit beskriver hvordan løsningen skal være tilgængelig for de forskellige brugertyper. Krav# 310 Løsningens tilgængelighed Kategori: (MK) Type: Ikke-funktionelt Beskrivelse: Det er muligt for samtlige Brugere af Løsningen, at anvende Løsningen i hele Danmark (fx hjemmearbejdsplads såvel som virksomhedens arbejdsplads). Bemærkning Krav# 311 Selvbetjeningsløsningens tilgængelighed Kategori: (MK) Type: Ikke-funktionelt Beskrivelse: Det er muligt for samtlige Brugere af selvbetjeningsløsningen at anvende denne i hele Danmark såvel som i udlandet (fx private hjem, offentlige steder, udland m.v.). Bemærkning Løsningens Brugere, samt leverandører og disses it-systemer, tilgår Løsningen via et netværk, hvorom det gælder at: Systemets Brugergrænseflader rettet imod selvbetjeningen tilgås via et netværk der har en båndbredde på mindst 1 MBit/sekund, ofte trådløst. Systemets Brugergrænseflader rettet imod sagsbehandleren tilgås via et netværk der har en båndbredde på mindst 10 MBit/sekund, ofte trådløst. Systemets Systemgrænseflader tilgås via et netværk der har en båndbredde på mindst 100 MBit/sekund, som regel kablet. Side 192 af 257
Rammearkitekturens støttesystemer I det følgende forklares først generelt om de fælles forretningsservices, der implementeres som del af Den Fælleskommunale Rammearkitektur, hvorefter det gennemgås specifikt, hvordan Løsningen bør forholde sig til disse. 6.3.1 Den Fælleskommunale Rammearkitektur Den fælleskommunale Rammearkitektur (Rammearkitekturen) er de fælles rammer, KOMBIT på vegne af kommunerne sætter op for alle, der skal arbejde med kommunale processer og kommunal it. Det er populært sagt den spillebane og de spilleregler, der vil gælde for at være med til at levere it til kommunerne fremover. Rammearkitekturen er en måde at analysere og strukturere den forretning, som den kommunale forvaltning udgør. Rammearkitekturen kan deles op i et konceptuelt (logisk) niveau, og et fysisk niveau, som applikationer og systemer relaterer sig til. Rammearkitekturen er derfor en måde: Konceptuelt at o tænke sin forretning o strukturere sin forretning mht. informationsansvar, regler og processer o opsætte spilleregler og principper for dem, der vil levere til det kommunale marked o analysere forretningsbehov metodisk for at sikre alignment i den samlede forretning o kommunikere med omverdenen i et ensartet, forståeligt sprog o kunne fokusere på en mindre del af helheden, uden at miste helheden Fysisk at o strukturere den it, som skal understøtte forretningen o strukturere den byggetegning, som leverandørerne skal bygge systemer efter o sikre at de udviklede it-systemer kan kommunikere på tværs af leverandører o sikre en styret migration fra gammelt til nyt Rammearkitekturen er kort sagt et hjælpemiddel til at opnå bedre, billigere, sammenhængende og forandringsrobuste it-systemer, leveret af et bredt udsnit af leverandører. Løsningens placering i Rammearkitekturen: Side 193 af 257
Figur 20: Løsningens placering i Rammearkitekturen. Rammearkitekturen er under løbende udvikling og konkretisering. Yderligere materiale om Rammearkitekturen generelt kan findes her: http://www.kombit.dk/sts [Indhentet 02-06-2014] 6.3.1.1 Rammearkitekturens støttesystemer Rammearkitekturen består af en række støttesystemer, der enten understøtter de kommunale løsninger eller den kommunale sagsbehandling. Støttesystemerne er kort beskrevet i følgende tabel: Støttesystem Klassifikation Organisation Kort beskrivelse/yderligere materiale Klassifikation har til formål at indeholde og udstille klassifikationssystemer, som er væsentlige for it-understøttelse af den kommunale opgavevaretagelse. Klassifikationssystemer sikrer en ensartet grundstruktur og en fælles referenceramme, som eksempelvis kan lette udveksling af information samt automatisering af processer på tværs af it-løsninger. For mere information om støttesystemet, se http://kombit.dk/indhold/klassifikation [Indhentet pr. 14-11-2013] Organisation udstiller organisatoriske data til de fælleskommunale fagsystemer. Kombineret med informationer fra Klassifikation vil det være muligt at opmærke hvor i kommunen, en Opgave er placeret. Organisation skal sikre, at den autoritative beskrivelse af organisationen og dens aspekter altid findes ét sted, samt at snitfladen til organisationsdata er tilgængelig og veldefineret. For mere information om støttesystemet, se http://www.kombit.dk/indhold/organisation [Indhentet pr. 14-11-2013] Side 194 af 257
Sags- og Dokumentindeks Ydelsesindeks Beskedfordeler Adgangsstyring Dokumentfordeler Sags- og Dokumentindeks vil it-understøtte en effektiv udveksling af informationer om Sager og Dokumenter mellem fagsystemer, således at fagsystemerne kun skal lave opslag i ét system for at få overblik over Sager og Dokumenter. Sags- og Dokumentindeks består alene af et indeks over sager og dokumenter, samt reference til den løsning, der ejer sagen eller dokumentet. For mere information om støttesystemerne, se http://www.kombit.dk/indhold/sags-og-dokumentindeks [Indhentet pr. 05-12-2013] Ydelsesindeks vil it-understøtte en effektiv deling af oplysninger om ydelser i form af bevillinger og effektuerede Ydelser i andre fagsystemer, således at fagsystemerne kun skal lave opslag i ét system for at få overblik over Ydelser. Ydelsesindeks består alene af et indeks over Ydelser, samt reference til den løsning, der ejer Ydelse. For mere information om støttesystemet, se http://www.kombit.dk/indhold/ydelsesindex [Indhentet pr. 14-11-2013] Beskedfordeleren håndterer formidling af Beskeder fra afsender til modtager(e). Systemet fordeler Beskeder mellem de forskellige fagsystemer i og på tværs af kommuner, og gør det muligt at abonnere på relevante Beskeder om ændringer i sager. For mere information om støttesystemet, se http://www.kombit.dk/indhold/beskedfordeler [Indhentet pr. 14-11-2013] Fælleskommunal adgangsstyring, der sikrer en central administration af Brugere, deres rettigheder og adgang til de kommunale fagsystemer, således at det enkelte fagsystem kan nøjes med at styre, hvilke roller, fagsystemet skal tilbyde og understøtte. For mere information, se http://www.kombit.dk/indhold/adgangsstyring [Indhentet pr. 14-11-2013] Dokumentfordeleren fungerer som en fordelingsmekanisme i Rammearkitekturen, der muliggør, at journalnotater og dokumenter der opstår udenfor fagsystemerne kan transporteres til de relevante fagsystemer hvor de associerede til sager, behandles og indgår i sagsbehandlingen. Tabel 11: Oversigt over støttesystemer 6.3.1.2 Aktuel version Rammearkitekturens støttesystemer er pt. under udarbejdelse. Arbejdet kan følges her: http://www.kombit.dk/sts [Indhentet 02-06-2014] Løsningen kravsætter anvendelsen af støttesystemerne gennem en række anvenderkrav (se afsnit 6.3.2 Løsningens brug af Rammearkitekturens støttesystemer). Krav# 312 Aktuel version Kategori: K Type: Ikke-funktionelt Beskrivelse: Løsningen skal være forberedt og robust nok til at kunne håndtere ændringer i Rammearkitekturens støttesystemer, således at Løsningen kan understøtte og anvende den aktuelle version af Rammearkitekturen. 6.3.2 Løsningens brug af Rammearkitekturens støttesystemer Løsningen vil i sin anvendelse af den fælleskommunale Rammearkitektur dele relevante informationer med andre kommunale fagsystemer igennem Rammearkitekturens støttesystemer. Endvidere Side 195 af 257
vil Løsningen gøre brug af informationer fra Rammearkitekturens støttesystemer og andre fagsystemer i sagsbehandlingen. For så vidt angår de i dette afsnit 6.3.2 angivne vilkår for integration, skal det bemærkes, at disse løbende vil blive uddybet og præciseret i takt med at støttesystemerne bliver etableret. Leverandøren skal til enhver tid overholde de gældende integrationsvilkår, som bliver offentliggjort på kombit.dk. 6.3.2.1 Klassifikation Overalt i den offentlige forvaltning findes en række systematikker og standardlister, der anvendes til klassificering af det arbejde, der udføres i den offentlige forvaltning. Klassifikationssystemer sikrer generelt en ensartet grundstruktur, som kommunerne kan hæfte eksempelvis opgaver i den offentlige forvaltning op på. Støttesystemet Klassifikation muliggør at forvaltning af Klassifikationssystemer flyttes fra de enkelte it systemer, herunder Løsningen, til et fælles it system. Dermed sikres det at klassifikationsdata rettes et og kun et sted og efterfølgende kan distribueres til andre it systemer, også kaldet Klassifikation modtager systemer. Formålet med Støttesystemet Klassifikation er at udstille sådanne klassifikationssystemer for fagsystemer hos kommunerne, samt andre Støttesystemer i Rammearkitekturen. Det er alene i Støttesystemet Klassifikation at de fælleskommunale løsninger vil lede efter Klassifikationssystemer. Klassifikation tilbyder flere måder hvorpå klassifikationssystemer oprettes og vedligeholdes. Klassifikation understøtter at: Der opbygges og vedligeholdes klassifikationssystemer via Støttesystemets brugergrænseflade. Her fungerer Klassifikation som master. Klassifikationssystemer som vedligeholdes udenfor Klassifikation importeres via støttesystemets snitflader, Her fungerer Klassifikation som kopi. Der oprettes referencer mellem klassifikationer og elementer og Organisation. Opgaven med at importere, opbygge og vedligeholde klassifikationer i Klassifikation varetages af en redaktør og en Klassifikationsadministrator igennem brugergrænsefladen i klassifikation. Klassifikation tilbyder en snitflade som gør det muligt for Løsningen at: Søge i klassifikationssystemer Trække klassifikationssystemer til en lokal kopi, samt abonnere på Beskeder med opdateringer Vedligeholde kopier af egne klassifikationssystemer i Klassifikation, så de kan deles med andre systemer. Klassifikation tilbyder en række fællesoffentlige klassifikationssystemer, herunder den fælleskommunale opgaveklassifikation KL Emnesystematik [KLE] og den fællesoffentlige forretningsreferencemodel [FORM], samt Økonomi- og Indenrigsministeriets Kontoplan. Løsningen har behov for at kunne påsætte klassifikationer på elementer i Løsningen. Derfor anvender Løsningen Rammearkitekturens støttesystem Klassifikation til opslag og til at skabe en mapning mellem elementer i Løsningen og klassifikation. Løsningen anvender følgende fællesoffentlige klassifikationer: KLE (fra KL) Side 196 af 257
Organisatorisk reference (bruges bl.a. til socialdistrikter, økonomi- og geografiske opdelinger i forbindelse med ØiR) Omkostningssted Standard Opsætning (svarer til IM kontoplanen) Artskontoplan Arts hovedopdeling Debitorforholdsart Derudover er der i Løsningen brug for egne klassifikationer herunder fx: Opgavetype Ydelsesart Støttesystemet Klassifikation anvendes eksempelvis til automatisk opgavefordeling, der pr. kommune kan indstilles til at foregå på forskellig vis, herunder ud fra opgavetype, område, mm. Dette er beskrevet i detaljer i afsnit 5.1.4.2. Den Kommunale Emneplan KLE lister de overordnede kommunale opgaver, som bl.a. Løsningen behandler. For hvert emne i KLE understøtter Løsningen flere Ydelsesarter, og for hver Ydelsesart er det muligt at have flere typer af Opgaver. Sager opmærkes med KLE bl.a. for at kunne fremsøge på tværs i SAPA og der er derfor behov for at koble de 3 klassifikationer som er vist i Figur 21, så der kan filtreres i de Ydelsesarter og opgavetyper, som er mulige på en given sag. Eksempel på relationen mellem klassifikationer i Løsningen er vist nedenfor. Figur 21: Relationen mellem opgavetyper, Ydelsesarter og KLE emner Foruden klassifikationerne er det nødvendigt at oprette mapninger mellem opgavetype og Ydelsesart, samt mellem Ydelsesart og KLE for at gøre det muligt at fremfinde Ydelser, der kan bevilges på givne opgavetyper, samt opmærke Ydelser med KLE numre. Krav# 313 Integration til Klassifikation Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal anvende Rammearkitekturens støttesystem Klassifikation. Det forventes at snitfladebeskrivelser m.v. for Klassifikation bliver tilgængelig omkring start af etape 2. Krav# 314 Vilkår for integration til Klassifikation Kategori: (K) Type: Ikke-funktionelt Beskrivelse: I sin integration til Rammearkitekturens støttesystem Klassifikation, skal Løsningen anvende Vilkår for integration til støttesystemet Klassifikation, version 1.3 af 18. marts 2014, som kan tilgås her: www.kombit.dk/sts/vilkaar Side 197 af 257
6.3.2.2 Organisation Løsningen skal anvende Rammearkitekturens støttesystem Organisation til opslag for mapning mellem eksempelvis KLE-numre og organisatoriske enheder. Sådanne mapninger anvendes til at placere elementer i Løsningen (fx en Opgave) hos en bestemt organisatorisk enhed, givet eksempelvis opgavens KLE-nummer. Et andet behov er at mappe Ydelsesarter i Løsningen med organisatoriske funktioner (med hvert sit SE-nummer) i Organisation. Det skyldes, at kommunen skal indberette oplysninger til SKAT om de Ydelser, der udbetales i Løsningen, på forskellige SE-numre. Eksempelvis skal fleksløntilskud indberettes på et andet SE-nummer end kontanthjælp. Organisation tilbyder opslag på organisatoriske enheder ud fra en lang række søgekriterier, herunder KLE numre, der måtte være knyttet til et organisationssystem. Med et sådant opslag er det muligt at finde den enhed i en kommune, der har med behandlingen af sager med at givet KLE nummer at gøre og dermed fordele sagen korrekt. Krav# 315 Integration til Organisation Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal anvende Rammearkitekturens støttesystem Organisation. Det forventes at snitfladebeskrivelser m.v. for Organisation bliver tilgængelig omkring start af etape 2. Krav# 316 Vilkår for integration til Organisation Kategori: (K) Type: Ikke-funktionelt Beskrivelse: I sin integration til Rammearkitekturens støttesystem Organisation, skal Løsningen anvende Vilkår for integration til støttesystemet Organisation, version 1.3 af 18. marts 2014, som kan tilgås her: www.kombit.dk/sts/vilkaar. 6.3.2.3 Sags- og Dokumentindeks Løsningen anvender Sags- og Dokumentindeks til at informere om egne sager og dokumenter til interesserede fagsystemer i den kommunale systemportefølje. Dette sker ved løbende at opdatere Sags- og Dokumentindekset med ny og/eller ændrede sager eller dokumenter. Endvidere anvendes Sags- og Dokumentindekset til at få overblik over relevante sager og dokumenter, der kan have betydning for Løsningens egne sagsbehandlingsprocesser. Krav# 317 Integration til Sags- og Dokumentindeks Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal anvende Rammearkitekturens støttesystem Sags- og Dokumentindeks. Side 198 af 257
Det forventes at snitfladebeskrivelser m.v. for Sags- og Dokumentindeks bliver tilgængelig omkring start af etape 2. Krav# 318 Vilkår for integration til Sags- og Dokumentindeks Kategori: (K) Type: Ikke-funktionelt Beskrivelse: I sin integration til Rammearkitekturens støttesystem Sags- og Dokumentindeks, skal Løsningen anvende Vilkår for integration til støttesystemet Sags- og Dokumentindeks, version 1.3 af 18. marts 2014, som kan tilgås her: www.kombit.dk/sts/vilkaar. 6.3.2.4 Ydelsesindeks Løsningen anvender Ydelsesindeks til at informere om Ydelser bevilget og effektueret i Løsningen til interesserede fagsystemer i den kommunale systemportefølje. Dette sker ved løbende at opdatere Sags- og Dokumentindekset med ny og/eller ændrede Ydelser (bevilgede eller effektuerede). Endvidere anvendes Ydelsesindekset til at få overblik over relevante Ydelser, der kan have betydning for Løsningens egne sagsbehandlingsprocesser, herunder Ydelsesbevilling og -beregning. Krav# 319 Integration til Ydelsesindeks Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal anvende Rammearkitekturens støttesystem Ydelsesindeks. Det forventes at snitfladebeskrivelser m.v. for Ydelsesindeks bliver tilgængelig omkring start af etape 2. Krav# 320 Vilkår for integration til Ydelsesindeks Kategori: (K) Type: Ikke-funktionelt Beskrivelse: I sin integration til Rammearkitekturens støttesystem Ydelsesindeks, skal Løsningen anvende Vilkår for integration til støttesystemet Ydelsesindeks, version 1.3 af 18. marts 2014, som kan tilgås her: www.kombit.dk/sts/vilkaar. Se bl.a. Krav# 48 Krav# 47 for funktionelle krav, der anvender Ydelsesindekset. 6.3.2.5 Beskedfordeler Løsningen skal reagere på udefra kommende Hændelser fx folkeregisterændringer og ændringer i fx sagstilstande i andre fagsystemer, endvidere skal omkringliggende fagsystemer reagere på Hændelser opstået i Løsningen. Distributionen af Beskeder om Hændelser både sendt til og sendt fra Løsningen er Beskedfordelerens ansvarsområde. Beskedfordeleren understøtter at Løsningen enten selv henter oplysninger om udefra kommende Hændelser ved at spørge Beskedfordeleren Side 199 af 257
efter nye Beskeder, men Løsningen udstiller også en service som Beskedfordeleren sender beskeder til, hvilket vil være det primære integrationsmønster for beskedmodtagelse. På samme vis sender Løsningen Besked til Beskedfordeleren omkring opståede Hændelser. Krav# 321 Integration til Beskedfordeler Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal anvende Rammearkitekturens støttesystem Beskedfordeler (SF1460). Det forventes at snitfladebeskrivelser m.v. for Beskedfordeler bliver tilgængelig omkring start af etape 2. Krav# 322 Vilkår for integration til Beskedfordeler Kategori: (K) Type: Ikke-funktionelt Beskrivelse: I sin integration til Rammearkitekturens støttesystem Beskedfordeler, skal Løsningen anvende Vilkår for integration til støttesystemet Beskedfordeler, version 1.3 af 18. marts 2014, som kan tilgås her: www.kombit.dk/sts/vilkaar 6.3.2.6 Adgangsstyring Løsningen skal understøtte og anvende Rammearkitekturens Adgangsstyringskomponent, da Kunden ønsker, at alle fælleskommunale systemer anvender samme adgangsstyring og følger samme principper for autentifikation og autorisation af Brugerne både for at give genkendelighed, men også for at understøtte Single-Sign-On på løsningerne. Kundens forventninger til Løsningens håndtering af sikkerhed mm. er beskrevet i kapitel 6.7. Krav# 323 Integration til Adgangsstyring Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal anvende Rammearkitekturens støttesystem Adgangsstyring. For yderligere beskrivelse og dokumentation af Rammearkitekturens Adgangsstyring henvises til afsnit 7 om ADGANGSSTYRING og ADMIN_MO- DUL, jf. afsnit 7.1.2 Adgangsstyring, samt snitfladebeskrivelser anført i underbilag 2.6 (1511,1512,1513 og 1514). Det forventes at endelige snitfladebeskrivelser m.v. for Adgangsstyring bliver tilgængelig omkring start af etape 2. Side 200 af 257
Krav# 324 Vilkår for integration til Adgangsstyring Kategori: (K) Type: Ikke-funktionelt Beskrivelse: I sin integration til Rammearkitekturens støttesystem Adgangsstyring, skal Løsningen anvende de i Bilag 2. Sikkerhed beskrevne integrationsvilkår. Bilag 2. Sikkerhed, version 1.3 af 18. marts 2014, som kan tilgås her: www.kombit.dk/sts/vilkaar. 6.3.2.1 Dialogintegration Den fælles kommunale dialogintegration skal sikre at det er muligt for en bruger af de nye monopolbrudssystemer at hoppe til andre systemer, for at gøre det nemmere for brugernes at arbejde på tværs af systemer. Dialogintegration skal implementeres af de enkelte systemer og muliggør herved, at der kan hoppes til og fra systemet. Dialogintegration er beskrevet yderligere i underbilag 2.6. Krav# 325 Integration til Dialogintegration Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal anvende den fælles kommunale dialogintegration (også kaldet hop ). Krav# 326 Vilkår til Dialogintegration Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal anvende den fælles kommunale dialogintegration jf. vilkårene anført i underbilag 2.6. 6.3.2.2 Dokumentfordeler Løsningen skal understøtte Rammearkitekturens Dokumentfordeler, der fungerer som en fordelingsmekanisme for journalnotater og dokumenter, som opstår uden for kommunernes fagsystemer. Bemærk, støttesystemet Dokumentfordeler omtales også som fordelingskomponenten. Krav# 327 Integration til Dokumentfordeler Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal anvende den fælles kommunale Dokumentfordeler og kunne modtage og afsende dokumenter via Dokumentfordelerens services. Se afsnit 5.4.2 Dokumenter og journalnotater Krav# 328 Vilkår til Dokumentfordeler Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal anvende den fælles kommunale Dokumentfordeler jf. vilkårene anført i underbilag 2.6 Side 201 af 257
6.3.3 Serviceplatformen Serviceplatformen fungerer som knudepunkt for integrationer mellem kommunale løsninger. Serviceplatformen er en central del af Rammearkitekturen, men er samtidig en allerede realiseret infrastrukturløsning, der findes beskrevet her: http://www.kombit.dk/serviceplatform [Indhentet pr. 14-11-2013] Serviceplatformen anvendes til alle Løsningens integrationer, der er beskrevet i det følgende kapitel. Såfremt det efterfølgende viser sig, at nogle integrationer ikke findes på Serviceplatformen, vil dette blive håndteret som en ændringsanmodning fremsat af KOMBIT. Integrationer Løsningen har et stort antal integrationer til at udveksle data med andre myndigheder og organisationer for at kunne understøtte Brugernes behandling af ydelsessager. Kravene fremsat i afsnit 5 og 6, samt underbilag 2.6, beskriver de behov, der ligger til grund for integrationskravene i dette kapitel. Integrationskravene i dette kapitel beskriver de konkrete tekniske krav til integrationer til snitflader, som Løsningen skal gøre brug af. Figur 23 og Tabel 12: Snitfladematrix nedenfor viser en oversigt over de snitflader, Løsningen skal anvende. Alle disse snitflader er identificeret ved et snitflade-id (fx SF2600) og kravmaterialet vedrørende snitflader er overordnet set organiseret som vist nedenfor. Det skal bemærkes at der er snitflader som i snitfladetabellen er repræsenteret ved Side 202 af 257
ét snitflade-id, i Underbilag 2.6 er nedbrudt i flere snitflader. I disse tilfælde går snitflade-id igen, men den enkelte snitflade identificeres ved at anvende _A, _B mv. Figur 22 - Sammenhæng i kravmateriale til snitflader Integrationerne fordeler sig på følgende typer af snitflader: 1) Publicerede services. Eksterne snitflader som andre it-systemer kan aftage via Løsningens snitflader. 2) Eksterne services. Snitflade der publiceres af andre fagsystemer eller af støttesystemer udenfor KOMBITs Rammearkitektur. Disse systemer tilgås via Serviceplatformen. 3) Rammearkitekturens støttesystemer (RA-STS). Publiceres af KOMBIT og tilgås via Serviceplatformen 4) Batch. Services, hvor Løsningen leverer eller modtager data som scheduleret batch. Figur 23 nedenfor illustrerer alle integrationer og snitflader Løsningen hhv. anvender eller udstiller. Side 203 af 257
Figur 23: Snitflade og integrationsoversigt Figur 24 viser et andet billede på de integrationer, som Løsningen anvender her er der fokus på hvordan information flyder via integrationer. Der er i Figur 24 vist generelle grupperinger af hvor data flyder til og fra. Eksempelvis er de mange integrationer til eksterne systemer, der er illustreret i Figur 23, alle lagt ind under den generelle gruppe Eksterne Systemer. Hvilke snitflader der indgår i hver gruppe fremgår af Figur 23. Side 204 af 257
Figur 24: Informationsflow for integrationer Detaljerede beskrivelser af de enkelte integrationer er angivet i en række underbilag, der refereres til i kravene nedenfor. Dette kapitel er opbygget således, at generelle og overordnede krav til integrationer først gennemgås. Herefter stilles krav til, hvordan Rammearkitekturens støttesystemer skal anvendes - integrationer til støttesystemerne er illustreret i den nedre del af Figur 23. De to følgende underafsnit beskriver hhv., hvilke snitflader Løsningen skal udstille, og hvilke snitflader Løsningen skal anvende. De snitflader, Løsningen skal udstille, fremgår af Figur 23 i den centrale pakke Kommunernes Ydelsessystem. Snitfladeløsninger, der skal anvendes, er beskrevet i det efterfølgende afsnit og er vist i den øvre del af Figur 23, i pakken Serviceplatformen. Følgende tabel opsummerer de snitflader, Løsningen anvender. Tabellen viser sammenhæng mellem snitfladens titel, som anvendt i nedenstående krav; snitflade-id der unikt identificerer konkrete snitflader (er bl.a. anvendt i underbilag 2.6); samt hvilken type snitfladen er. Tabellen angiver ligeledes, hvordan fejlretning prioriteres ved Incidents for en given snitflade. Side 205 af 257
Titel Snitflade ID Type Incidentprioritet Publicerede services Eksterne services RA-STS 5 Batch A Kritisk integration B Vigtig integration C Mindre vigtig integration Sikkerhed, context handler 1511 X A Sikkerhed, Security Token Service, indgående 1512 X A Sikkerhed, administrationsmodul 1513 X A Sikkerhed, Security Token Service, udgående 1514 X A STAR DFDG 1610 X B Selvbetjening på borger.dk 1670 X B Selvbetjeningsintegrationer 1680 X A Register over samlevende 2570 X C Beskedfordeleren 1460 X X B CPR Hændelser 1320 X B CPR Søgeservice 1520 X A CPR Vejregister 1523 X C CVR 1530 X C Feriekonto batch opslag 0802 X C Feriekonto online opslag 0800 X B Betalingsadministration Send indbetaling til KMD 2520 X B Opus Debitor Betalingsadministration Send forespørgsel til og 2530 X B modtag svar fra KMD Opus Debitor Betalingsadministration Send sagsoplysninger til 2540 X B KMD Opus Debitor Print på Serviceplatformen 1600 X B Klassifikation 1510 X B Social Pension (KMD) formue og helbredstillæg 1411 X B Formue og helbredstillæg Ændringer 1412 X C NemHandel 1691 X C NemLogin, DigitalFuldmagt 1920 X A SMS på Serviceplatformen 2250 X B OIO Dokument 1660 X B OIO Journal 1651 X B OIO Sag 1650 X B Organisation 1500 X B Sags- og Dokumentindeks 1470 X B SKAT eindkomst 0770 X B SKAT Overskydende skat 1180 X C SKAT R75 1570 X B UIS Person Service 1540 X C Ydelsesindeks 1490 X X B Økonomi i Rammearkitekturen (ØiR) 1590 X A Udbetaling Danmark Social Pension 2600 X C Jobcentersnitflade 1690 X B Jobcentersnitflade Bevillingsoplysninger 1780 X B Jobcentersnitflade Målgruppeskift 2590 X B STAR dataload 1620 X C Ledelsesinformation dataload 1630 X C Danmarks statistik dataload 1820 X C Jobnet.dk link og webservice 2700 X C Modtag journalposter og dokumenter fra fordelingskomponent 2800 X A Hent dokument image fra fordelingskomponent 2810 X A Tabel 12: Snitfladematrix Side 206 af 257
Løsningens snitflader til Beskedfordeleren (SF1460) anvendes som teknisk integration til modtagelse og afsendelse af en række forskellige beskeder. Tabel 13 og Tabel 14 nedenfor giver et overblik over hvilke beskeder der indgår. Beskeder, der skal sendes og modtages via Beskedfordeler, er endvidere dokumenteret i underbilag 2.13 (Hændelseslisten) Hændelserne med ID 60,69,76,77,80,81,84,85,88,89,103,105 er interim hændelser som kun skal håndteres i en overgangsperiode, indtil de respektive fagsystemer erstattes af de ny-udbudte løsninger. Hændelserne for de nye fagsystemer, fx UDK Boligstøtte, fremgår også af nedenstående tabel. Ud fra beskrivelse kan man se at hændelsen Sygedagpenge bevilget fremgår flere gange, for hhv KMD Boligstøtte og UDK Boligstøtte. H-ID Beskrivelse Afsendersystem 14 Opholdstilladelse tildelt UIS 15 Opholdstilladelse ændret UIS 16 Opholdstilladelse inddraget UIS 17 Intern flytning i kommunen Serviceplatformen, CPR replika 18 Flytning fra kommunen Serviceplatformen, CPR replika 19 Intern fraflytning, øvrige beboere flytter fra adressen Serviceplatformen, CPR replika 31 Skattekort opdateret KMD Indkomst 34 Start eller ændring af indkomst KMD Indkomst 37-55 Oplysning fra jobcentret vedrørende: kontaktforløb/målgruppeskift/fravær/sanktionsanmodning/ Jobcenterløsning Aktivitet/godtgørelse 60 Ændring i boligstøtte KMD Boligstøtte 69 Skattekort ændret fra hovedkort til bikort KMD Indkomst 70 Borger er tilmeldt som ansøger STAR / DFDG 71 Borger er afmeldt som ansøger STAR / DFDG 72 Overskydende skat KMD Indkomst 74 Boligstøtte bevilliget (Ydelsesindeks opdateret) UDK Boligstøtte 75 Boligstøtte stoppet (Ydelsesindeks opdateret) UDK Boligstøtte 76 Boligstøttesag bevilliget/startdato ændret/genoptaget KMD Boligstøtte (Sags- og Dokumentindeks) 77 Boligstøttesag stoppet (Sags- og Dokumentindeks) KMD Boligstøtte 78 Sygedagpenge bevilget (Ydelsesindeks opdateret) Kommunernes Sygedagpengesystem 79 Sygedagpenge stoppet (Ydelsesindeks opdateret) Kommunernes Sygedagpengesystem 80 Sygedagpenge bevilget (Sags- og Dokumentindeks KMD Dagpenge opdateret) 81 Sygedagpenge stoppet (Sags- og Dokumentindeks KMD Dagpenge opdateret) 82 Barselsdagpenge bevilget (Ydelsesindeks opdateret) UDK Barsel 83 Barselsdagpenge stoppet (Ydelsesindeks opdateret) UDK Barsel 84 Barselsdagpengesag anmodet/bevilget/ genoptaget/startdato KMD Dagpenge ændret/afgjort/bestilt (Sags- og Doku- mentindeks opdateret) 85 Barselsdagpengesag stoppet/startdato (Sags- og KMD Dagpenge Dokumentindeks opdateret) 86 Social pension bevilget (Ydelsesindeks opdateret) UDK Pension 87 Social pension stoppet (Ydelsesindeks opdateret) UDK Pension 88 Social pensionssag oprettet/bevilget/startdato ændret/genoptaget/aktiv (Sags- og Dokumentindeks opdateret) KMD Social Pension 5 Med RA-STS menes Rammearkitekturens støttesystemer. Side 207 af 257
H-ID Beskrivelse Afsendersystem 89 Social pensionssag stoppet/sat i bero (Sags- og Dokumentindeks KMD Social Pension opdateret) 103 Bevilling af underholdsbidrag oprettet/startdato for KMD Underholdsbidrag bevilling af underholdsbidrag ændret (Sags- og Dokumentindeks opdateret) 104 Ægtefællebidrag bevilget (Ydelsesindeks opdateret) UDK Familieydelse 105 Ordinært/ekstra børnetilskud stoppet (Sags- og Dokumentindeks KMD Underholdsbidrag opdateret) 106 Ordinært/ekstra børnetilskud stoppet (Ydelsesindeks opdateret) UDK Familieydelse 107 Klassifikation opdateret Beskedfordeleren 108 Organisation opdateret Beskedfordeleren Tabel 13: Indgående hændelser modtaget fra Beskedfordeleren Hændelse ID udgående beskeder Beskrivelse Afsendersystem 1 Statusskift på sag Løsningen 2 Sag oprettet Løsningen 3 Sag opdateret Løsningen 4 Sag slettet Løsningen 5 Dokument oprettet Løsningen 6 Dokument slettet Løsningen 7 Udbetaling bestilt Løsningen 9 Journalpost oprettet Løsningen 10 Journalpost opdateret Løsningen 11 Journalpost slettet Løsningen 12 Ydelse bevilget Løsningen 13 Klassifikation opdateret Løsningen Tabel 14: Hændelser afsendt til Beskedfordeleren De snitflader som indgår i nedenstående krav i dette afsnit 6.4 skal forstås som værende den gældende version af pågældende snitflade pr. 31. maj 2014, og den snitflade som leverandørens Løsningsbeskrivelse skal tage udgangspunkt i. I afklaringsfasen vil parterne afdække, hvorvidt der er udgivet nye versioner af disse snitflader i Løsningsbeskrivelsen, som skal lægges til grund for Løsningen. Såfremt der er udgivet nye versioner af snitflader indeholdt i krav i afsnit 6.4 vil opdateringen til en ny version af en given snitflade ske som ændringsanmodning fremsat af KOMBIT. Tabel 15 nedenfor viser hvilke snitflader, der anvendes til de specifikke Ydelser. Side 208 af 257
Snitflade / Ydelsesart Sikkerhed, context handler (SF1511) X Sikkerhed, Security Token Service, indgående (SF1512) X Sikkerhed, administrationsmodul (SF1513) X Sikkerhed, Security Token Service, udgående X STAR DFDG (SF1610) X X X X X Selvbetjeningsservice på borger.dk (SF1670) (de Ydelser, vi giver adgang til at søge om via selvbetjeningsløsningen: kontanthjælp, uddannelseshjælp, ledighedsydelser under ferie og enkeltydelser) X X X Selvbetjeningsintegrationer (SF1680) Beskedfordeleren (SF1460) X CPR Hændelser (SF1320) X CPR Søgeservice (SF1520) X CPR Vejregister (SF1523) X CVR Online (SF1530) X X X Feriekonto - batch (SF0802) X Feriekonto - online (SF0800) X Betalingsadministration Send indbetaling til KMD Opus Debitor (SF2520) X X X Betalingsadministration - Send forespørgsel til og modtag svar fra KMD Opus Debitor (SF2530) X X X Betalingsadministration - Send sagsoplysninger til KMD Opus Debitor (SF2540) X Print på serviceplatformen (SF1600) X Klassifikation (SF1510) X Social Pension (KMD) formue og helbredstillæg (SF1411) X Social Pension (KMD) formue og helbredstillæg ændringer (SF1412) X NemHandel (SF1691) X X X Alle Ydelser Kontant- og uddannelseshjælp Revalideringsydelse Ressourceforløbsydelse Ledighedsydelse Fleksløntilskud Enkeltydelser Andre Ydelser Administrationssager Side 209 af 257
Snitflade / Ydelsesart NemLogin, DigitalFuldmagt (SF1920) (de Ydelser, vi giver adgang til at søge om via selvbetjeningsløsningen: kontanthjælp, uddannelseshjælp, ledighedsydelser under ferie og enkeltydelser). X X X SMS på Serviceplatformen (SF2250) (de Ydelser, vi giver adgang til at søge om via selvbetjeningsløsningen: kontanthjælp, uddannelseshjælp, ledighedsydelser under ferie og enkeltydelser). X X X OIO Dokument (SF1660) X OIO Journal (SF1651) X OIO Sag (SF1650) X Organisation (SF1500) X Sags- og Dokumentindeks (SF1470) X SKAT eindkomst (SF0770) X SKAT Overskydende skat (SF1180) X SKAT R75 (SF1570) X UIS Person Service (SF1540) X Ydelsesindeks (SF1490) X ØiR (SF1590) X Udbetaling Danmark Social Pension (SF2600) X Jobcentersnitflade (SF1690) X X X X X X Jobcentersnitflade Bevillingsoplysninger (SF1780) X X X X X X Jobcentersnitflade Målgruppeskift (SF2590) X X X X X STAR dataload (SF1620) X Ledelsesinformation dataload (SF1630) X Danmarks Statistik dataload (SF1820) X Jobnet.dk link og webservice (SF2700) Modtag journalposter og dokumenter fra fordelingskomponent (SF2800) X Hent dokument image fra fordelingskomponent (SF2810) Alle Ydelser Kontant- og uddannelseshjælp Revalideringsydelse Ressourceforløbsydelse X Tabel 15: Snitflader anvendt af specifikke Ydelser Ledighedsydelse Fleksløntilskud Enkeltydelser Andre Ydelser Administrationssager Side 210 af 257
Som udgangspunkt indgår KOMBIT aftaler med 3. parts leverandører om brug af de angivne snitflader i Løsningen. I enkelte tilfælde skal Leverandøren selv forestå aftaleindgåelse. I disse tilfælde fremgår det af kravet til snitfladen. 6.4.1 Overordnede integrationskrav Integrationer skal kobles så løst som muligt mellem de it-løsninger, der integreres. Krav# 329 Anvendelse af Kundens Serviceplatform Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal anvende de for Løsningen relevante snitflader, der er implementeret på Serviceplatformen, herunder snitfladernes sikkerhedsmodel. Se afsnit 6.3.3 Serviceplatformen og afsnit Tabel 12: Snitfladematrix Se beskrivelse af Serviceplatformen: http://www.kombit.dk/serviceplatform [Indhentet pr. 27-05-2014] Se beskrivelse af teknisk adgang på Serviceplatformen, certifikatbaseret sikkerhedsmodel: https://www.serviceplatformen.dk/administration/help/provider-tech-guide [indhentet 27-05-2014] Se afsnit 6.3.2.6 Adgangsstyring Overordnede krav til batch udtræk Krav# 330 Brug af informationsmodel i dataudtræk Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Dataudtræk fra Løsningen til brug i fx ledelsesinformationssystemer, Danmarks Statistik med videre, modelleres efter og benytter sig af Løsningens informationsmodel, og er uafhængig af Løsningens interne datamodel. Krav# 331 Udtræks ID på batch udtræk Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Alle batchudtræk skal have et unikt ID associeret med udtrækket. Krav# 332 Start dato på batch udtræk Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Alle batchudtræk skal kunne parameteriseres med en start dato, sådan at der kan udtrækkes data fra den angivne start dato og frem. Side 211 af 257
Krav# 333 Timestamp på batch udtræk Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Alle batchudtræk skal kunne parameteriseres med en Point-in-time/timestamp dato, sådan at data, der udtrækkes fra systemet, reflekterer datas tilstand (herunder sager, dokumenter m.v.) som det var på den angivne dato. Krav# 334 Dataformat Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal kunne levere dataudtræk i OIOXML format. Leverandøren skal specificere hvilke øvrige formater, data kan leveres i, samt for alle dataudtræk beskrive semantikken bag alle dataelementer. Krav# 335 Dataafgrænsning Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal understøtte, at 1) Det alene er data, der har ændret sig siden en given dato, der udlæses. 2) Data for en given virkningsperiode udtrækkes. Det giver mulighed for at hente data bagud i tid. 3) Alle data for alle kommuner udtrækkes med identifikation af hvilke data, der hører til hvilken kommune 4) At data for en specifik kommune udtrækkes. Leverandøren skal beskrive hvilke muligheder for udtræk, Løsningen leverer. Krav# 336 Frekvens af dataleverance Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal kunne konfigureres til, at data leveres med forskellige frekvenser. Leverandøren skal beskrive hvilke frekvenser, der er mulige, samt hvordan dette realiseres. Krav# 337 Understøtte brug af forretningskvitteringer Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal understøtte brug af forretningskvitteringer i integrationer. a) Løsningen skal kunne modtage og håndtere forretningskvittering som svar på afsendelse af Besked b) Løsningen skal kunne afsende forretningskvittering som svar på modtaget Besked Krav# 338 Fejlhåndtering i forbindelse med forretningskvitteringer Kategori: (K) Type: Ikke-funktionelt Side 212 af 257
Beskrivelse: Løsningen skal indeholde funktionalitet til fejlhåndtering i forbindelse med brug af forretningskvitteringer i integrationer. a) Fejlmelding af manglende modtagelse af forretningskvitteringer b) Fejlmelding i forbindelse med fejl modtaget i forretningskvitteringer. Krav# 339 Web Services versioner Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Webservice snitfladerne skal kunne sameksistere i flere aktive versioner. Krav# 340 Unikt UUID Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Hver sag skal tildeles et unikt sags-id (UUID), der følger Sags- og Dokumentstandarden fra OIO eller tilsvarende, som angivet i http://digitaliser.dk/resource/324032/artefact/uid-standard_endelig.pdf [Indhentet pr. 15-11-2013] Krav# 341 Læsbart ID Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Hver sag skal tildeles et unikt sags-id, der kan læses og formidles af mennesker. Id et skal bruges i forbindelse med udsendelse af breve. Krav# 342 Tilladte dokumenttyper ved upload Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Det skal være muligt for Central Administrator at angive en liste af tilladte filtyper i Løsningen. Eksempelvis kan det angives at.pdf,.jpeg,.png er tilladte. 6.4.2 Snitflader som ejes af Løsningen Løsningen skal udstille et antal snitflader til brug for andre fagsystemer og andre eksterne systemer (fx Jobcenterløsninger). De udstillede snitflader giver andre fagsystemer og eksterne systemer mulighed for at hente information fra, samt aflevere information til Løsningen. For visse af de snitflader Løsningen skal udstille findes der til en vis grad dokumentation af snitfladen. Snitflader baseret på OIO-standarder eller tilsvarende er et eksempel på dette. Dog vil der for de fleste af snitfladerne, der udstilles af løsningen, være en opgave for Leverandøren i at lave et løsningsdesign, der kan opfylde de behov som snitfladerne repræsenterer. Eksempelvist vil det for snitfladen Selvbetjeningsintegrationer være op til Leverandøren at udarbejde et løsningsdesign. Udviklingen af de enkelte snitflader udstillet af Løsningen planlægges jf. Bilag 1 Tidsplan til at finde sted i forbindelse med en delleverance i etape 2. Leverandørens løsningsforslag skal i Designfasen for den planlagte delleverance udarbejdes og godkendes i samarbejde med KOMBIT. Side 213 af 257
Krav# 343 Udstilling af snitflader til brug for andre fagsystemer Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal udstille nedenstående seks snitflader til brug for andre fagsystemer og eksterne systemer: - Sagsservice - Dokumentservice - NemHandel - Selvbetjeningsintegrationer - Journalservice - Beskedmodtagelse 6.4.2.1 Sagsservice Løsningen skal udstille en snitflade, der kan anvendes af andre it-systemer til at tilgå Løsningens sager. Krav# 344: Sagsservice (OIO-Sag) Kategori: K Type: Ikke-funktionelt Beskrivelse: Løsningen skal udstille en snitflade, hvor igennem det er muligt for andre it-systemer at søge og vise sager i Løsningen Snitfladen skal overholde OIO standarderne eller tilsvarende, som angivet i underbilag 2.6. Løsningen udstiller snitfladen OIO-Sag (SF1650) vha. et synkron requestresponse integrationsmønster. 6.4.2.2 Dokumentservice Løsningen skal udstille en snitflade, der kan anvendes af andre it-systemer til at tilgå Løsningens dokumenter. Krav# 345: Dokumentservice (OIO-Dokument) Kategori: K Type: Ikke-funktionelt Beskrivelse: Løsningen skal udstille en snitflade, hvor igennem det er muligt for andre it-systemer at søge og vise dokumenter fra sager i Løsningen. Løsningen udstiller snitfladen OIO-Dokument (SF1660) vha. et synkron request-response integrationsmønster. Se nærmere detaljer, samt teknisk specifikation i underbilag 2.6. 6.4.2.3 NemHandel Det skal være muligt for andre systemer at uploade e-faktura til løsningen som dokumentation på en sag. Side 214 af 257
Krav# 346: Integration til NemHandel Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal have integration til NemHandel. Via snitfladen skal der være mulighed for at modtage en e-faktura. En delmængde af NemHandel arkitekturen kan anvendes til at modtage faktura. Derved kan Løsningen modtage og håndtere elektroniske faktura. Selve OIO UBL snitfladen dækker flere og mange brugsmønstre. Løsningen skal kunne håndtere fakturadelen af OIO UBL eller tilsvarende. Som et led i understøttelse af NemHandel skal Løsningen også registreres i NemHandel registeret, således at andre systemer kan slå Løsningen op. Løsningen udstiller snitfladen OIO-UBL/NemHandel (SF1691) vha. et synkron request-response integrationsmønster. Snitfladen understøtter følgende funktionelle krav: Krav# 81. Se nærmere detaljer, samt teknisk specifikation i underbilag 2.6 6.4.2.4 Selvbetjeningsintegration Krav# 347: Integration med Selvbetjeningsløsninger Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal udstille snitflader der tilbyder den fornødne funktionalitet krævet af Løsningens selvbetjeningsløsning, der måtte ligge ud over funktionalitet ikke allerede er dækket af eksisterende snitflader på Serviceplatformen, eller andre snitflader udstillet af Løsningen (fx OIO Sag eller tilsvarende). Leverandøren skal redegøre for, hvordan den tekniske specifikation af snitfladen ser ud. Det er en forudsætning, at snitfladen kan anvendes af 3. parts selvbetjeningsløsninger, jf. afsnit 6.2. Se underbilag 2.6 (SF1670 og SF1680) Eksempelvis er der behov for at udstille en snitflade, som Løsningens selvbetjeningsløsning kan anvende til at afleverer ansøgninger til Løsningen, jf. afsnit 6.2.3.1. 6.4.2.5 Journalservice Krav# 348: Journalservice (OIO-Journal) Kategori: K Type: Ikke-funktionelt Beskrivelse: Løsningen skal udstille en snitflade, hvor igennem det er muligt for andre it-systemer at søge og vise journalnotater fra sager i Løsningen. Løsningen udstiller snitfladen OIO-Journal (SF1651) vha. et synkron request-response integrationsmønster. Se nærmere detaljer, samt teknisk specifikation i underbilag 2.6 6.4.2.6 Beskedmodtagelse Krav# 349: Beskedmodtagelse Side 215 af 257
Kategori: K Type: Ikke-funktionelt Beskrivelse: Løsningen skal udstille en snitflade, der understøtter, at Rammearkitekturens Beskedfordeler kan aflevere Beskeder til Løsningen, som Løsningen efterfølgende behandler. Se afsnit 6.3.2.5 om Beskedfordeleren. 6.4.3 Snitflader, der ejes af et andet system 6.4.3.1 CPR-Søgeservice Krav# 350: Integration til CPR-registret Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal have integration til CPR-registeret. Persondata skal kunne hentes fra CPR. Derudover skal persondata automatisk hentes igen på baggrund af Beskeder, der modtages via Beskedfordeler. Denne snitflade vil primært levere data til Klassen Person, der anvendes i mange sammenhænge. Løsningen udstiller snitfladen CPR Søgeservice (SF1520), igennem Serviceplatformen, vha. et synkron request-response integrationsmønster. Snitfladen understøtter følgende funktionelle krav: Krav# 26, Krav# 27, Krav# 34 Se nærmere detaljer, samt teknisk specifikation i underbilag 2.6 6.4.3.2 CPR-Hændelser Krav# 351: Integration til Hændelser fra CPR-registret Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal have integration til hændelsesopdateringer fra CPR-registeret (CPR Abonnement). Opdateringer omkring persondata skal modtages fra CPR. Denne snitflade vil primært levere data til Klassen Person, der anvendes i mange sammenhænge. Løsningen anvender snitfladen CPR Hændelser (SF1320), igennem Serviceplatformen, vha. hhv. et synkron request-response integrationsmønster til webservicedelen af snitflade, og et filbaseret integrationsmønster til FTP delen af snitfladen. Snitfladen understøtter følgende funktionelle krav: Krav# 26, Krav# 27, Krav# 34 Se nærmere detaljer, samt teknisk specifikation i underbilag 2.6 6.4.3.3 Print på Serviceplatformen Krav# 352: Integration til Print på Serviceplatformen Kategori: (K) Type: Ikke-funktionelt Side 216 af 257
Beskrivelse: Løsningen skal have integration til den fælles printkomponent på Serviceplatformen. Snitfladen anvendes til at sende digitale eller trykte breve og til at modtage status om, hvorvidt brevet er nået frem, hvordan det er afleveret til borgeren (fx digitalt eller brevpost), eller om der sket en fejl og i så fald, hvad der er sket. Snitfladen (SF1600) håndterer enkelt- eller masseforsendelser. Printkomponenten er en ny service der etableres på Serviceplatformen. Snitfladen understøtter følgende funktionelle krav: Krav# 57, Krav# 75, Krav# 78, Krav# 92, Krav# 97, Krav# 179 Se nærmere detaljer, samt teknisk specifikation i underbilag 2.6 6.4.3.4 SMS på Serviceplatformen Krav# 353: Integration til SMS på Serviceplatformen Kategori: (K) Type: Ikke-funktionelt Beskrivelse: I forbindelse med selvbetjening, se afsnit 5.8, skal Løsningen have integration til den fælles SMS component på Serviceplatformen, som er en ny service, der etableres på Serviceplatformen. Løsningen skal kunne sende Besked til SMS og give Besked om, at der skal udsendes en sms. Denne handling skal kunne automatiseres, således at systemet udsender en sms som følge af en Hændelse, hvilket kan være et særligt tidspunkt, bekræftelse af tilmelding eller lign. Integrationen skal kunne sende en meddelelse om, at en sms er sendt og om den er modtaget eller der er sket en fejl. Snitfladen understøtter følgende funktionelle krav: Krav# 248. Se nærmere detaljer, samt teknisk specifikation i underbilag 2.6 6.4.3.5 SKAT eindkomst Krav# 354: Integration til SKAT - eindkomst Kategori: (K) Type: Ikke-funktionelt Side 217 af 257
Beskrivelse: Løsningen skal have integration til SKAT eindkomst for at kunne opfylde flg. formål: Via snitfladen skal der kunne hentes oplysninger om en Persons indkomst. Indkomstoplysninger indgår i oplysning af sagen og i beregningsgrundlaget for Ydelsen. Via integrationen skal Løsningen hente oplysninger om, hvorvidt en kontanthjælps-/uddannelseshjælpsansøgers Ægtefælle eller Samlever modtager SU. Oplysningerne indgår i oplysning af sagen og har betydning for udmåling af Ydelsen. Via snitfladen skal der kunne modtages Hændelser om ændring af indkomstoplysninger. På grundlag af Hændelsen dannes Opgave til sagsbehandleren om vurdering af sagen. Via snitfladen skal Løsningen kunne indberette skattepligtige Ydelser til SKAT. Via snitfladen skal der kunne hentes oplysninger om en Persons skattekort, fribeløb, trækprocent mv. (e-skattekortoplysninger). Løsningen udstiller snitfladen SKAT- eindkomst, modtag data (SF0770) og SKAT eindkomst, Indberet data (SF0770), vha. et synkron request-response integrationsmønster. Snitfladen understøtter følgende funktionelle krav: Krav# 26, Krav# 27, Krav# 30, Krav# 76, Krav# 192, Krav# 193. Se nærmere detaljer, samt teknisk specifikation i underbilag 2.6 6.4.3.6 SKAT R75 Krav# 355: Integration til SKAT R75 Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal have integration til SKAT R75. Denne snitflade anvendes til at indhente oplysninger om formue. Disse er essentielle data, der anvendes i forbindelse med Beregningsgrundlaget, der optræder i flere informationsmodeller. Løsningen anvender snitfladen SKAT-R75 (SF1570) vha. et synkron request-response integrationsmønster. Løsningen anvender endvidere KMD Indkomst snitflade (SF1180) til generering af hændelser vdr. overskydende skat. Snitfladen understøtter følgende funktionelle krav: Krav# 26, Krav# 27, Krav# 30. Se nærmere detaljer, samt teknisk specifikation i underbilag 2.6 Side 218 af 257
6.4.3.7 Økonomi i Rammearkitekturen Krav# 356: Integration til økonomisystem Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal have integration til ØiR snitfladen til økonomisystem, debitorsystem og udbetalingssystem, der er udstillet på Serviceplatformen. For yderligere oplysninger på denne snitflade bedes der refereret til nedenstående SF1590. Snitfladen understøtter følgende funktionelle krav: Krav# 65, Krav# 66, Krav# 71, Krav# 72, Krav# 83, Krav# 106, Krav# 109, Krav# 112, Krav# 192, Krav# 193, Krav# 194, Krav# 195, Krav# 197, Krav# 198. Se nærmere detaljer, samt teknisk specifikation i underbilag 2.6 6.4.3.8 STAR Det fælles datagrundlag Krav# 357: Integration til STAR Det fælles datagrundlag (DFDG) Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal have integration til STAR - DFDG. Løsningen skal kunne modtage oplysninger om til- og afmeldinger af en borger i STAR - DFDG. Løsningen skal kunne opdatere STAR - DFDG med oplysning om bevilling af eller afslag på en Ydelse. Løsningen anvender snitfladen STAR - DFDG (SF1610) vha. et synkron request-response integrationsmønster. Snitfladen understøtter følgende funktionelle krav: Krav# 266, Krav# 267, Krav# 268, Krav# 269 og Krav# 270. Se nærmere detaljer, samt teknisk specifikation i underbilag 2.6 6.4.3.9 FerieKonto - online opslag Krav# 358: Integration til FerieKonto online opslag Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal have integration til Feriekonto online opslag. Via snitfladen skal der være mulighed for at hente oplysninger om feriepenge for en given Person. Flg. oplysninger fra snitfladen skal bl.a. kunne hentes: a) Beløb til udbetaling b) Udbetalingsdato c) Antal dage, der er udbetalt feriepenge for d) Dato for første feriedag e) Saldo feriepenge f) Saldo feriedage Løsningen udstiller snitfladen Feriekonto (SF0800) vha. et synkron request-response integrationsmønster. Side 219 af 257
Snitfladen understøtter følgende funktionelle krav: Krav# 26, Krav# 27 Se nærmere detaljer, samt teknisk specifikation i underbilag 2.6 6.4.3.10 Dataudtræk til Serviceplatformen Krav# 359: Dataudtræk Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal kunne levere data til et af Serviceplatformen udpeget datalager eller en service på Serviceplatformen (sftp). Herfra vil Serviceplatformen gøre data tilgængelige for aftagere af data. Data skal kunne leveres enten som data fra samtlige kommuner eller som data fra én enkelt kommune. Data skal kunne leveres som fuld load og som delta load til Serviceplatformen med en parameterstyret start og slut dato, samt tidsinterval for levering. Data skal kunne afgrænses med datoer uden årstalsangivelse, sådan at det fx er mulig at levere et dump af data en gang om måneden hvor indholdet er data fra 1. januar og frem til dags dato. Data skal kunne afgrænses med et antal måneder bagud fra dags dato, sådan at det fx er muligt at levere et dump hver måned bestående af data fra de seneste 36 måneder. Data skal kunne afgrænses således at det er muligt at levere hele foregående års data i det efterfølgende år, fx at levere data fra 1. januar <årstal minus 1> til 31. december <årstal minus 1> på datoen den 5. januar <årstal>. Dette skal kunne sættes op som et årligt udtræk. Løsningen skal understøtte at der kan være flere aktive konfigurationer af dataleverancer. Det skal være muligt at afgrænse hvilke aftagere af data, der kan tilgå bestemte dataleverancer. Løsningen skal endvidere kunne udsende en Besked via Beskedfordeleren efter data er leveret, som aftagersystemer kan abonnere på. Snitfladen understøtter følgende funktionelle krav: Krav# 223, Krav# 224,Krav# 225. Krav# 360: Dataudtræk: Dataafgrænsning i eksport konfigurationer Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal gøre det muligt at definere hvilke dele af informationsmodellen, der skal indgår i en dataleverance, som en del af konfiguration af data leverancen jf. Krav# 359. Snitfladen understøtter følgende funktionelle krav: Krav# 223, Krav# 224,Krav# 225. Side 220 af 257
6.4.3.11 CPR Vejregister Krav# 361: Integration til CPR Vejregister Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal have integration til CPR Vejregister. Via snitfladen skal der hentes data om sociale distrikter, der anvendes i forbindelse med delegering af sager og Opgaver til sagsbehandlere. Løsningen udstiller snitfladen CPR Vejregister (SF1523) vha. et synkron request-response integrationsmønster. Snitfladen understøtter følgende funktionelle krav: Krav# 19 Se nærmere detaljer, samt teknisk specifikation i underbilag 2.6 6.4.3.12 CVR Krav# 362: Integration til CVR-registret Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal have integration til CVR-registret. Igennem integrationen skal der være mulighed at søge efter: juridisk enhed, produktionsenhed og fuldt ansvarlig deltager. Oplysningerne anvendes til at afgøre, om en given Person ejer eller er involveret i en virksomhed eller til at finde virksomhedsoplysninger i forbindelse med udbetaling af Ydelser. Denne snitflade vil levere data til bl.a. informationsmodellen KY-Person, der anvendes i mange sammenhænge. Løsningen udstiller snitfladen CVR Online (SF1530) vha. et synkron request-response integrationsmønster. Snitfladen understøtter følgende funktionelle krav: Krav# 26, Krav# 27, Krav# 65 Se nærmere detaljer, samt teknisk specifikation i underbilag 2.6 6.4.3.13 FerieKonto - batch Krav# 363: Integration til Feriekonto batch Kategori: (K) Type: Ikke-funktionelt Side 221 af 257
Beskrivelse: Løsningen skal have integration til Feriekonto - batch. Via snitfladen skal der være mulighed for at danne og videresende en Besked om udbetaling af feriepenge til en Person med en sag i Løsningen. Flg. oplysninger fra snitfladen skal bl.a. anvendes: g) Beløb til udbetaling h) Udbetalingsdato i) Antal dage, der er udbetalt feriepenge for j) Dato for første feriedag k) Saldo feriepenge l) Saldo feriedage Filbaseret integrationsmønster anvendes til snitfladen: ATP Batch snitflade (SF0802). Snitfladen understøtter følgende funktionelle krav: Krav# 10, Krav# 92 Se nærmere detaljer, samt teknisk specifikation i underbilag 2.6 6.4.3.14 KMD Social Pension Krav# 364: Integration til KMD Social Pension. Hent formue og helbredstillægsprocent Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal have integration til KMD Social Pension. Via snitfladen skal det være muligt at hente oplysninger om formue og helbredstillægsprocent fra KMD Social Pension for en Person samt dennes Ægtefælle, så de kan indgå i oplysning og beregning af sager om Andre Ydelser og personlige tillæg. Følgende oplysninger skal anvendes fra snitfladen: Likvid formue Helbredsprocent Personlig tillægsprocent Via snitfladen skal der kunne modtages Beskeder om ændringer i likvid formue, helbredsprocent og personlig tillægsprocent fra KMD Social Pension (SF1412). Løsningen udstiller snitfladen Formue og tillægsprocent (Sociale Pensioner) (SF1411) vha. et synkron request-response integrationsmønster. Snitfladen understøtter følgende funktionelle krav: Krav# 55 Se nærmere detaljer, samt teknisk specifikation i underbilag 2.6 6.4.3.15 Forskudsvist udlagt børnebidrag hos Udbetaling Danmark (UDK) Krav# 365: Integration til OPUS Debitor Betalingsadministration Kategori: (K) Type: Ikke-funktionelt Side 222 af 257
Beskrivelse: Løsningen skal have integration til OPUS Debitor Betalingsadministration. Snitfladen skal anvendes til udveksling af oplysninger om kontanthjælpsmodtagere, der er berettiget til forskudsvist udlagt børnebidrag. SF2520, SF2530, SF2540 Snitfladen understøtter følgende funktionelle krav: Krav# 271, Krav# 272, Krav# 273. Se nærmere detaljer, samt teknisk specifikation i underbilag 2.6 6.4.3.16 UdlændingeInformationsSystemet (UIS) Krav# 366: Integration til UdlændingeInformationsSystemet Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal have integration til UIS. Løsningen anvender UIS PersonSag Service snitfladen til at hente autoritative oplysninger om en udlændings status omkring ophold i Danmark. Status oplysning hentes i form af sager og afgørelser. Løsningen udstiller snitfladen UIS PersonSagService (SF1540) og UIS PersonService (SF1540) vha. et synkron request-response integrationsmønster. Snitfladen understøtter følgende funktionelle krav: Krav# 26, Krav# 27 Se nærmere detaljer, samt teknisk specifikation i underbilag 2.6 6.4.3.17 Register over samlevende Krav# 367: Hent oplysning om samlevende Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal på Brugerens foranledning kunne indhente oplysninger om, hvorvidt en Person, der ansøger om kontant- eller uddannelseshjælp, er eller har været registreret som samlevende i et offentligt register til brug for oplysning og beregning af sagen. Oplysninger hentes via snitfladen: Register over samlevende (SF2570). Snitfladen returnerer oplysninger om i hvilken periode, Personen har været noteret i registret samt CPR-nummer på den samlevende. Snitfladen udstilles som en webservice vha. et synkron request-response integrationsmønster. - Snitfladen er under udarbejdelse. - Snitfladen understøtter følgende funktionelle krav: Krav# 26 og Krav# 27 - Se Lov nr. 894 af 04/07/2013: Lov om ændring af lov om aktiv socialpolitik, SU-loven, Lov om børnetilskud og forskudsvis udbetaling af børnebidrag mv. Side 223 af 257
6.4.3.18 Udbetaling Danmark Social Pension Krav# 368: UDK Social Pension Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Formålet med snitfladen er at overføre oplysninger om de pensionsudbetalinger, som UDK overfører til kommunen, fordi kommunen administrerer pensionen for pensionisten. De oplysninger, som overføres via snitfladen, specificerer på personniveau, hvilket beløb, der er overført fra UDK til kommunen i en given udbetalingsperiode. Selve pengeoverførslen sker som en sumoverførsel til kommunens pengeinstitut. Kommunen har behov for, at disse oplysninger på personniveau bliver registreret i Løsningen på den enkelte administrationssag og tilknyttede ydelsessag, så kommunen kan varetage opgaven med at administrere pensionistens økonomi. Oplysninger hentes via snitfladen: UDK Social Pension (SF2600). Snitfladen understøtter følgende funktionelle krav: Krav# 108. Se nærmere detaljer, samt teknisk specifikation i Underbilag 2.6 6.4.3.19 Jobcenterintegration Integration til jobcentreløsningerne er kritisk for forretningsgangene i Løsningen. Løsningen vil initialt gøre brug af de eksisterende jobcentersnitflader, som udstilles på Serviceplatformen. Denne integration vil fungere som en transitionsarkitektur, der vil muliggøre en løbende overgang fra de eksisterende jobcentersnitflader, til en asynkron integration via Rammearkitekturens Beskedfordeler. Der er behov for at Løsningens arkitektur adskiller den forretningsmæssige håndtering af forretningsbeskeder til og fra Jobcenterløsningerne og de fysiske integrationer, som vil være hhv. Serviceplatform- og Beskedfordeler baseret. Løsningsarkitekturen skal sikre at det er effektivt at skrifte fra den Serviceplatformbaserede integration, til udveksling af Beskeder via Beskedfordeleren. Krav# 369: Integration til Jobcenterløsningerne standardsnitflade Kategori: (K) Type: Ikke-funktionelt Side 224 af 257
Beskrivelse: Løsningen skal udstille Jobcentersnitfladen via Serviceplatformen. Formålet med snitfladen er at understøtte centrale arbejdsgange mellem kommunens Jobcentre og Ydelseskontoret. Herunder overførsel af oplysninger om kontaktforløb, aktiviteter, Godtgørelser, fravær og sanktionsindstillinger fra Jobcenterløsninger til Løsningen. Snitfladen skal anvende et integrationsmønster, der er webservicebaseret synkron request-response service. Snitfladen er opdelt i flere konkrete webservices: KontaktforloebService AktivitetService GodtgoerelseService FravaerService SanktionsindstillingsService Oplysninger hentes via snitfladen: Jobcenter (SF1690). Snitfladen understøtter følgende funktionelle krav: Krav# 255, Krav# 256, Krav# 257, Krav# 258, Krav# 259, Krav# 260, Krav# 261, Krav# 262, Krav# 263 og Krav# 264. Se nærmere detaljer samt teknisk specifikation i underbilag 2.6 Krav# 370: Jobcentersnitflade Bevillingsoplysninger Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal anvende snitfladen til håndtering af bevillingsoplysninger via Serviceplatformen. Formålet med snitfladen er at formidle oplysning om bevilgede Ydelser fra Ydelsescentret til Jobcentret. Vis snitfladen skal der være mulighed for at oprette, opdatere samt slette bevillinger. Snitfladen skal anvende et integrationsmønster, der er webservicebaseret synkron request-response service via snitfladen. Oplysninger hentes via snitfladen: Jobcenter Bevillingsoplysninger (SF1780). Snitfladen understøtter følgende funktionelle krav: Krav# 265 Se nærmere detaljer samt teknisk specifikation i underbilag 2.6 Krav# 371: Jobcentersnitflade Målgruppeskift Kategori: (K) Type: Ikke-funktionelt Side 225 af 257
Beskrivelse: Løsningen skal udstille Jobcenter-målgruppeskiftsnitfladen via Serviceplatformen. Formålet med snitfladen er at understøtte centrale arbejdsgange mellem kommunens Jobcentre og Ydelseskontoret; herunder målgruppeskift på kontaktforløb, der sendes fra Jobcentret til Ydelseskontoret. Målgruppeskiftet er et alternativ til at afslutte et kontaktforløb for derefter at oprette et nyt med en ny målgruppe og tilhørende aktiviteter. Via snitfladen skal der være mulighed for at læse, skrive og opdatere. Snitfladen skal anvende et integrationsmønster, der er webservicebaseret synkron request-response service via snitfladen. Snitfladen består af webservicen: MaalgruppeSkift Oplysninger modtages via snitfladen: Jobcenter Målgruppeskift (SF2590). Snitfladen understøtter følgende funktionelle krav: Krav# 258. Se nærmere detaljer samt teknisk specifikation i underbilag 2.6 Krav# 372: Jobcenterintegration via Beskedfordeler Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal have integration til Jobcenterløsningerne som foregår igennem den fælleskommunale Beskedfordeler se afsnit 6.3.2.5 for detaljer. Beskeder, der skal sendes og modtages via Beskedfordeler, er dokumenteret i underbilag 2.13 (Hændelseslisten) Integrationen via Beskedfordeler vil kunne erstatte eksisterende integrationer over Serviceplatformen, specifikt: Jobcentersnitflade (SF1690) Jobcentersnitflade Bevillingsoplysninger (SF1780) Jobcentersnitflade Målgruppeskift (SF2590) 6.4.4 Snitflader anvendt af selvbetjeningsløsningen 6.4.4.1 NemLog-in (Digital Fuldmagt) Krav# 373: Integration til NemLog-in (Digital Fuldmagt) Side 226 af 257
Kategori: (MK) Type: Ikke-funktionelt Beskrivelse: I forbindelse med Selvbetjening, se afsnit 5.8, skal løsningen skal have integration til NemLog-in snitfladen, der udstilles af Digitaliseringsstyrelsen. Se afsnit 5.8 Selvbetjening for beskrivelsen af anvendelsen af denne snitflade til Bruger login. Snitfladen skal ligeledes understøtte anvendelsen af digital fuldmagt. Løsningen udstiller snitfladen Digital fuldmagt (SF1920) vha. et synkron request-response integrationsmønster. Snitfladen understøtter krav beskrevet i afsnit 5.8 Selvbetjening. Se nærmere detaljer, samt teknisk specifikation i underbilag 2.6 Leverandøren skal indgå aftale om brug og test af NemLog-in og fuldmagtsløsningen med snitfladeleverandøren. 6.4.4.2 Borger.dk Krav# 374: Integration til Borger.dk Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal udstille webkomponenter af selvbetjeningsdelen, som anvendes til at etablere integration med Borger.dk. Integrationen skal ske jf. borger.dk s HTMLGuide. http://htmlguide.borger.dk/integration-types.html [Indhentet pr. 23-04-2014] Via denne integration (SF1670) skal en borger, der er logget på Borger.dk vha. NemID, kunne tilgå og arbejde med sine sager eller foretage nye ansøgninger. Snitfladen understøtter krav beskrevet i afsnit 5.8 Selvbetjening. Se nærmere detaljer, samt teknisk specifikation i underbilag 2.6 Leverandøren skal indgå aftale om brug og test af borger.dk med snitfladeleverandøren. Brugervenlighed og Look n Feel Krav til Løsningens brugervenlighed skal sikre, at Løsningen er fleksibel, effektiv i daglig brug og er behaglig og tryg at benytte for Brugerne. Det er vigtigt for projektets succes, at brugervenligheden bidrager til at skabe effektivitet i sagsbehandlingen, og at Leverandøren lader sig inspirere af nye fremskridt inden for den teknologiske udvikling, som bl.a. har til formål at minimere antallet af klik og sideopdateringer. Ligeledes bør der tages højde for eksisterende arbejdsprocesser, således at det sikres, at Systemet i nødvendigt omfang understøtter praksis i Brugerens arbejde. Brugerne af Løsningen er både novicer og erfarne it-brugere. Derfor er en informativ og støttende online-hjælp, som er tilpasset it-kompetencerne hos brugergruppen, et vigtigt hjælperedskab i bru- Side 227 af 257
gen af Løsningen. Løsningen skal endvidere optimeres, så erfarne Brugere, der anvender Løsningen dagligt, kan udføre deres arbejdsopgaver hurtigt og effektivt og ikke hæmmes af fastlåste flows i Løsningen. Hvis andet ikke er nævnt, omfatter kravene til brugervenlighed og Look n Feel både sagsbehandler- og selvbetjeningsdelen af Løsningen. 6.5.1 Brugervenlighed Dette afsnit indeholder krav til den samlede Løsnings brugervenlighed. Kravene skal ses i sammenhæng med kravene til gennemførsel af brugervenlighedstest både i forbindelse med de løbende delleverancer og den endelige leverance af Løsningen. Se Bilag 6 for yderligere information om prøver. Krav# 375: Løsningen skal være effektiv sagsbehandlerdel Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningens sagsbehandlerdel skal være effektiv og intuitiv at anvende, så den gør Brugeren i stand til hurtigt og korrekt at gennemføre ofte forekommende opgaver. a) En erfaren sagsbehandler skal kunne gennemføre oprettelse og oplysning af en ukompliceret sag, hvor al dokumentation er tilgængelig i Løsningen på max 10 minutter. Se personas for erfarne sagsbehandlere Anette, Birgitte, Peter eller Katrine i underbilag 2.11. Se eksempler på testopgaver i bilag 6 (Prøver og tests) Krav# 376: Løsningen skal være intuitiv selvbetjeningsdel Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningens selvbetjeningsdel skal være intuitiv at anvende, så den gør Brugeren i stand til at gennemføre simple opgaver korrekt. a) En borger skal kunne udfylde og afsende en ukompliceret ansøgning om kontanthjælp på max 30 minutter. Bemærkning Se persona for en borger, Peter i underbilag 2.17. Se eksempler på testopgaver i bilag 6 (Prøver og tests) Krav# 377: Løsningen skal være tilfredsstillende at anvende Kategori: (K) Ikke-funktionelt Beskrivelse: Løsningen skal være tilfredsstillende at anvende for Brugeren, så Løsningen opfattes af Brugeren som værende nem og tryg at bruge. Se beskrivelse af brugeraktørerne i afsnit 3.5.2 Brugeraktører. Se eksempler på testopgaver i bilag 6 (Prøver og tests) Side 228 af 257
Krav# 378: Principper for selvbetjeningsløsninger - Selvbetjeningsdel Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Selvbetjeningsløsningen skal følge principperne i den nyeste udgave af Digitaliseringsstyrelsens Udviklingsvejledning for selvbetjeningsløsninger. a) Selvbetjeningsløsningen overholder principperne, der er angivet under overskriften Kravbanken i Udviklingsvejledningen. Udviklingsvejledning for Selvbetjeningsløsninger: http://arkitekturguiden.digitaliser.dk/godselvbetjening [indhentet pr. 27-03- 2014] Krav# 379: Kravet udgår Kategori: Beskrivelse: Type: Krav# 380: Kravet udgår Kategori: Beskrivelse: Type: 6.5.2 Tekniske krav Dette afsnit indeholder tekniske krav til brugergrænsefladen. Kravene udtrykker, at kommunerne har mange forskellige tekniske setups, som Løsningen skal kunne håndtere fx i forhold til skærmopløsning, browserbrug og Citrixmiljø. 6.5.2.1 Tekniske krav til sagsbehandlerbrugergrænsefladen Krav# 381: Dynamisk tilpasning til skærmstørrelser sagsbehandlerdelen Kategori: (K) Ikke-funktionelt Beskrivelse: Brugergrænsefladen skal kunne tilpasse sig forskellige skærmopløsninger dynamisk. Side 229 af 257
6.5.2.2 Tekniske krav til selvbetjeningsbrugergrænsefladen Krav# 382: Selvbetjeningsløsningen som webbaseret løsning Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Det komplette præsentationslag til Løsningens selvbetjeningsdel skal realiseres som en webbaseret løsning. a) Selvbetjeningsløsningen skal kunne afvikles i alle nyere browsere jf. underbilag 2.24 Kommunernes IT-Miljø. b) Selvbetjeningsløsningen skal baseres på Responsive Webdesign. Krav# 383: Selvbetjeningsløsningen via mobile enheder Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Selvbetjeningsløsningen skal kunne tilgås via mobile enheder. a) Selvbetjeningsløsningen har samme funktionalitet, som selvbetjeningsløsningen har, når den tilgås via PC. b) Selvbetjeningsløsningen skal kunne understøtte NemID til mobile enheder. Bemærkning - Se underbilag 2.24 Kommunernes IT-Miljø for beskrivelse af de mobile enheder, der skal understøttes. 6.5.2.3 Generelle tekniske krav Krav# 384: Validering af webbaserede brugergrænseflader Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Webbaserede brugergrænseflader skal baseres på tidssvarende webteknologier. Løsningen skal, i det omfang der eksisterer W3C valideringer af anvendte teknologier, kunne opnå W3C validering for de anvendte teknologier. a) De anvendte webteknologier har gennemgået W3C validering, jf. Leverandørens beskrivelse i tilbudsbesvarelsen. Krav# 385: Webtilgængelighed Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Webbaserede brugergrænseflader skal opfylde Web Content Accessibility Guidelines (WCAG) 2.0 Level AA eller nyere. Side 230 af 257
6.5.3 Navigation og interaktion Dette afsnit indeholder krav til navigation og interaktion med Løsningen. Krav# 386: Konsistent navigation Kategori: (K) Ikke-funktionelt Beskrivelse: Løsningen skal sikre, at navigationen er konsistent på tværs af skærmbilleder og flows i Løsningen. a) Løsningen anvender samme betegnelse for samme funktion, og funktionen udføres ens. b) Ensartede navigationselementer og kommandoer er placeret samme sted i brugergrænsefladen på tværs af skærmbilleder. Krav# 387: Konsistent brug af ledetekster og inddatafelter Kategori: (K) Ikke-funktionelt Beskrivelse: Løsningen skal understøtte en ensartet brug af ledetekster og inddatafelter på tværs af skærmbilleder i Løsningen. a) Ledetekster ("labels") skal normalt placeres til venstre for det inddatafelt, som de beskriver. De skal afsluttes med et kolon. Ledeteksen bør kun hvor særlige forhold gør sig gældendeplaceres over inddatafeltet. b) Hvis der anvendes en instruktionsledetekst ("instruction label") skal den placeres til højre for inddatafeltet. c) Hvis et inddatafelt er beregnet til indtastning af datoer, skal løsningen vise et kalenderikon til højre for inddatafeltet. Et klik på dette ikon viser en kalender, hvor Brugeren kan vælge datoen i stedet for at indtaste den. Løsningen skal også give Brugeren mulighed for at taste dato ind med tastatur uden brug af kalenderen. Kravet udgør et designprincip, som KOMBIT ønsker at fremme på tværs af monopolsbrudsløsningerne. Side 231 af 257
Krav# 388: Tastaturgenveje Kategori: (K) Ikke-funktionelt Beskrivelse: Løsningens sagsbehandlingsdel skal i videst muligt omfang kunne betjenes med og uden mus og med færrest mulige tastetryk. a) Det er muligt at navigere mellem indtastningsfelter og navigationselementer ved brug af tab-tasten. b) Tabuleringen følger placeringen af indtastningsfelter og navigationselementer fra venstre mod højre, oppe fra og nedefter. c) Brugeren kan anvende genvejstaster til 2 af de mest anvendte funktioner i et skærmbillede. d) Når Brugeren trykker på en hurtigtast, skal Løsningen flytte markøren til det felt på skærmbilledet, som er angivet af cifret. e) På hvert skærmbillede bør der højst være 10 hurtigtaster til rådighed. Ved navigationselementer forstås kommandoer såsom knapper og links. Tabuleringsrækkefølgen er normalt venstre mod højre, oppefra og nedefter. Genvejstaster kan fx være F-taster og hurtigtaster (access keys). ). En hurtigtast kan være tastkombinationen Alt+ciffer. Krav# 389: Handling ved Enter Kategori: (K) Ikke-funktionelt Beskrivelse: Løsningen skal, ved brug af Enter-tasten, udføre den oftest foretagne handling i et skærmbillede. a) Løsningen udfører altid den samme handling ved brug af Enter på et givent skærmbillede. b) Løsningen signalerer til Brugeren, hvilken handling, der udføres ved brug af Enter-tasten. Eksempelvis kan den knap eller link i Løsningen, der aktiveres ved brug af Enter-tasten, være fremhævet. Krav# 390: Placering af fokus Kategori: (K) Ikke-funktionelt Beskrivelse: Når Løsningen viser et skærmbillede, skal fokus placeres i det indtastningsfelt, der naturligt behandles først i den mest typiske brugssituation. Side 232 af 257
Krav# 391: Dataformater Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal understøtte registrering af inddata og visning af uddata som angivet i Figur 25. a) Inddata registreres i Løsningen som angivet i Figur 25. b) Løsningen skal for datoer tillade skilletegnene skråstreg (/) og punktum (.) på lige fod med bindestreg (-) i inddata. c) For datoer angiver d.d. dags dato. +5 angiver datoen 5 dage efter dags dato. d) -7 angiver datoen 7 dage før dags dato. e) I datoer er det ikke tilladt at udelade de to første cifre i årstallet på grund af den tvetydighed som derved opstår (er 110512 = 11-05-2012 eller 2011-05-12?). f) Løsningen skal acceptere alle ikke-tvetydige danske datoformater g) Uddata vises i Løsningen som angivet i Figur 25. h) Løsningen skal altid vise udenlandske telefonnumre som +landekode efterfulgt af mellemrum efterfulgt af resten af telefonnummeret i grupper med 3 cifre adskilt af mellemrum. Side 233 af 257
Figur 25: Dataformater for forskellige datatyper. Side 234 af 257
Krav# 392: Valg af værdier i brugergrænsefladen Kategori: (K) Ikke-funktionelt Beskrivelse: Løsningen skal sikre, at der kan vælges værdier fra input-kontroller på en ensartet måde. Derudover skal det være muligt at hoppe til valgmuligheder vha. type-ahead, hvor dette er relevant (drop-down menuer, lister etc.). a) Ved en mindre mængde af faste valgmuligheder, skal det tilstræbes at værdierne vælges i en drop-down menu eller med alternativknapper. b) I drop-down menuer og lister skal det være muligt at foretage et ønsket valg ved at indtaste første og andet bogstav i valgmuligheden (typeahead). c) Løsningen skal også give Brugeren mulighed for at taste dato ind med tastatur, uden at kalenderen dukker op. Krav# 393: Kommandofelt Kategori: (K) Ikke-funktionelt Beskrivelse: Løsningen skal understøtte brugen af et kommandofelt, der gør Brugeren i stand til at gå fra et skærmbillede til et andet uden om den logiske struktur i brugergrænsefladen. a) Brugeren kan gå direkte til et vilkårligt andet skærmbillede på en sag ved at indtaste en kode for skærmbilledet. b) Brugeren kan skifte mellem sager for forskellige borgere ved at indtaste borgerens CPR-nummer i kommandofeltet. Kravet udgør et designprincip, som KOMBIT ønsker at fremme på tværs af monopolsbrudsløsningerne. Et kommandofelt hjælper erfarne Brugere med at anvende løsningen effektivt uden mus. Eksempel på brug af kommandofeltet: Som svar på kommandoen fo + Enter viser løsningen billedet "Fordeling af Opgaver". Dette billede kan også nås på traditionel vis fra skærmbilledet opgaveliste. Forkortelsen fo er valgt, så den er nem at huske i forhold til skærmbilledets betegnelse. Side 235 af 257
6.5.4 Layout Krav# 394: Strukturering af skærmindhold Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Felter, ledetekster og styringselementer på skærmen skal opstilles overskueligt og logisk, således at sammenhørende felter, ledetekster og styringselementer grupperes i forhold til Brugerens arbejdsgange og ved anvendelse af gestaltlovene for nærhed og lighed. a) Ledetekster som står i samme kolonne, skal alle have samme venstremargin. b) Styringselementer som står i samme kolonne, skal alle have samme venstremargin. Punkterne a) og b) udgør designprincipper, som KOMBIT ønsker at fremme på tværs af monopolsbrudsløsningerne. Skærmbilleder kan struktureres ved at gruppere sammenhørende styringselementer også kendt som controls: 1. Eksplicit ved hjælp af bokse, gerne med overskrifter, eller skillelinjer 2. Implicit ved hjælp af gestaltloven om nærhed For beskrivelse af gestaltlovene og nærhed og lighed se fx http://www.scholarpedia.org/article/gestalt_principles [indhentet pr. 25-11-2013] Se eksempler på layout af skærmbilleder i Figur 26 til Figur 28 herunder. Se beskrivelse af brugeraktørerne i 3.5.2 Brugeraktører. Se eksempler på testopgaver i bilag 6 (Prøver og tests) Side 236 af 257
Figur 26: Eksempel på layout af skærmbillede Side 237 af 257
Figur 27: Eksempel på layout af skærmbillede Side 238 af 257
Figur 28: Eksempel på layout af skærmbillede Side 239 af 257
Krav# 395: Brug af tabeller Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal sikre, at tabeller anvendes konsistent i forhold til opførsel og udseende på tværs af skærmbilleder i Løsningen. a) Hver tabel har en overskrift, som kort beskriver tabellens indhold. b) Tabellens første række indeholder en overskrift for hver kolonne. c) Hvis en overskrift er for lang til at kunne vises i sin helhed, så vises så mange tegn i overskriften som muligt og hele overskriften vises i tooltip. d) Data i tabellen kan sorteres efter en kolonne ved tryk på kolonneoverskriften. e) Hvis Brugeren kan regulere bredden af en kolonne, skal det ske ved at trække kanten af knappen i overskriften med musen. f) Alle dataelementerne i en kolonne skal være af samme type. Beløbsog talangivelser skal være højrestillede i en kolonne. Alle andre datatyper skal være venstrestillede. Hver overskrift skal justeres på samme måde som dataelementerne i kolonnen. Kravet udgør et designprincip, som KOMBIT ønsker at fremme på tværs af monopolsbrudsløsningerne. En tabeloverskrift kan være en ledetekst eller den omgivende gruppeboks' overskrift. Krav# 396: Brug af faneblade Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Hvis Løsningens interaktionsdesign er baseret på brug af faneblade, skal faneblade anvendes konsistent i forhold til opførsel og udseende på tværs af skærmbilleder i Løsningen. a) Sammenhørende data er placeret på samme faneblad. b) De hyppigst anvendte data er placeret på de faneblade, hvis faner ligger længst mod venstre. c) I et fanebladssæt er fanerne placeret vandret over fanebladsområdet (horizontal tabs) eller lodret til venstre for fanebladsområdet (vertical tabs). Faner må ikke placeres under fanebladsområdet. d) Hvis fanerne er placeret vandret over fanebladsområdet (horizontal tabs), må der kun være en række faner, og alle faner skal altid være synlige. Kravet udgør et designprincip, som KOMBIT ønsker at fremme på tværs af monopolsbrudsløsningerne. Side 240 af 257
Krav# 397: Indikator for data, der skal behandles af Brugeren Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal gøre Brugeren opmærksom på data i brugergrænsefladen, som kræver Brugerens stillingtagen, eller som er obligatoriske at udfylde. a) Ved visning af oplysninger i Løsningen fremgår det med visuel markering, om en oplysning skal håndteres af Brugeren. b) Ved indtastning af oplysninger i Løsningen fremgår det med visuel markering i form af en rød stjerne efter ledeteksten, hvilke oplysninger, der er krævede, for at registreringen kan gennemføres. - Punkt b) udgør et designprincip, som KOMBIT ønsker at fremme på tværs af monopolsbrudsløsningerne. - Data, der skal håndteres af Brugeren, kan være fejl i indtastede data, der fremkommer ved Løsningens validering af data. Krav# 398: Kontekstafhængig visning af oplysninger Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningens skærmbilleder skal være tilpasset den Ydelsesart og Person, som en given sag omhandler, så Brugeren hurtigt kan danne sig et overblik over sagen og lokalisere væsentlige oplysninger. a) Løsningen viser skærmbilleder på en sag afhængig af Ydelsesarten. b) Løsningen viser skærmbilleder på en sag på grundlag af de oplysninger, der er angivet ved oplysning af sagen. - Et eksempel kunne være, at børneoplysninger ikke vises på en sag, hvis Personen ikke har børn. Et andet eksempel kunne være, at Ægtefællens indtægtsoplysninger ikke vises i de Ydelsesarter, hvor disse ikke er relevante. - Se informationsmodeller pr. Ydelsesart i underbilag 2.5 I Krav# 398 beskrives behovet for kontekstafhængige skærmbilleder, så Brugerens overblik ikke forstyrres af irrelevante oplysninger. Men der kan være situationer, hvor de kontekstafhængige skærmbilleder kan være begrænsende. Fx hvis Løsningen fejlagtigt tror, at Personen ikke har børn (og derfor ikke viser børneoplysninger), men det viser sig, at Personen faktisk har børn. I disse tilfælde skal det være muligt for Brugeren at få adgang til det fulde sæt af oplysninger og dermed manuelt kunne opdatere oplysningerne. Krav# 399: Adgang til det fulde sæt af oplysninger på en sag Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Brugeren har mulighed for at få adgang til det fulde sæt af oplysninger på en sag, selvom disse ikke vises som udgangspunkt. Side 241 af 257
Krav# 400: Font i Løsningen Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal anvende fonten Arial. a) Tekst i brugergrænsefladen er i fonten Arial. Kravet udgør et designprincip, som KOMBIT ønsker at fremme på tværs af monopolsbrudsløsningerne. 6.5.5 Meddelelser og fejlhåndtering Dette afsnit indeholder krav til udarbejdelse og håndtering af brugervenlige informations- og fejlmeddelelser samt onlinehjælp i Løsningen. Krav# 401: Udarbejdelse af tekst Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Leverandøren skal udarbejde samtlige tekster i Løsningen (med undtagelse af breve), herunder fejl- og informationsmeddelelser, ledetekster, onlinehjælp, tooltips på korrekt dansk og med korrekt tegnsætning. Der må kun anvendes ord, vendinger og begreber, som er forståelige for målgruppen. a) Al tekst skal forfattes på korrekt dansk og med korrekt dansk tegnsætning, jf. seneste udgave af Retskrivningsordbogen. b) Fejlmeddelelser indeholder retur- og/eller årsagskode til fejlen. c) Tekster skal forelægges Kunden til godkendelse i Designfasen. Se eksempler på testopgaver i bilag 6 (Prøver og tests). Krav# 402: Redigering af tekster Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Tekster skal kunne redigeres på en enkel måde af Leverandørens vedligeholdelses- og supportpersonale. a) Rettelser til teksterne kan foretages uden deployment af ny version af Løsningen eller ny installering af Løsningen. Side 242 af 257
Krav# 403: Onlinehjælp Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Leverandøren skal udarbejde onlinehjælp, som dækker alle brugerrettede funktioner, og som beskriver navigation, brugerflader og anvendelse af Løsningen. a) Der skal være hjælp til felter og klikbare skærmobjekter, dvs. felthjælp og tooltips. b) Der skal være hjælp til at udføre funktionaliteten i et givent skærmbillede (sidehjælp). c) Onlinehjælpen skal være målrettet Løsningens forskellige brugeraktører d) Onlinehjælpens sidehjælp skal kunne udskrives i læsevenligt A4 format. e) Kravet udgår Se beskrivelse af brugeraktørerne i afsnit 3.5.2. Krav# 404: Tilbagemelding ved lang svartid Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal give Brugeren en letforståelig og standardiseret tilbagemelding på handlinger, der medfører en lang svartid. Bemærkninger: a) Hvis Løsningens forventede svartid på en handling foretaget af en Bruger er over 1 sekund, skal Løsningen signalere dette til Brugeren. b) Hvis Løsningens forventede svartid er over 5 sekunder, skal Løsningen give Brugeren en grov idé om, hvordan Løsningen skrider frem gennem en statusindikator. Der kan fx anvendes et timeglasikon til signalering af svartider på under 1 sekund. Krav# 405: Feedback på udførte handlinger Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal vise en meddelelse, når systemet har foretaget en handling, hvor Brugeren forventer en tilbagemelding. a) Løsningen viser meddelelser ved oprettelse af nye objekter, der ikke er rutinemæssige funktioner som fx Gem. b) Løsningen viser meddelelser ved ændring af koder eller parametre. c) Løsningen stiller ikke krav om kvittering for, at meddelelser er set af Brugeren. Eksempler på handlinger, der kræver feedback er oprettelse af nye objekter eller ændring af sikkerhedsparametre som fx adgangskode. Side 243 af 257
Krav# 406: Forebyg fejl Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal forebygge typiske brugerfejl. Forebyggende foranstaltninger må ikke uden grund i væsentlig grad påvirke effektiviteten ved udførelsen af arbejdsopgaven. a) Løsningen tilbyder at lade Brugeren vælge værdier, frem for at indtaste dem, hvor muligt. b) Løsningen foreslår en defaultværdi i indtastningsfelter. Krav# 407: Skærmobjekter, som midlertidigt ikke er tilgængelige Kategori: (K) Ikke-funktionelt Beskrivelse: Løsningen skal sløre skærmobjekter, fx knapper og indtastningsfelter, som midlertidigt ikke er tilgængelige for Brugeren. a) Brugeren kan ikke tilgå knapper og indtastningsfelter, som ikke må anvendes i en given kontekst. Løsningen skal understøtte autogem af data, som en Bruger har indtastet, således at Brugerens arbejde ikke går tabt, hvis Brugeren er inaktiv i Løsningen over en længere periode eller et vindue i Løsningen utilsigtet lukkes. Løsningen skal ved login, såfremt der findes autogemt data, spørge Brugeren om autogemt data skal kunne genindlæses. Hvis Brugeren ønsker genindlæsning, skal Løsningen kunne udfylde inputfelter når vinduer/dialoger (gen)åbnes, såfremt der er autogemt data for inputfelter i det pågældende vindue. Autogemte data bortfalder når de er genindlæst i vinduer/dialoger eller hvis Brugeren svarer nej til at autogemte data skal kunne genindlæses. Autogem funktionaliteten er udelukkende beregnet til at øge Brugervenligheden i Løsningen, og autogemt data skal således ikke registreres på informationsmodels-objekter, og er dermed ikke underlagt krav for persisteret data, herunder bitemporalitet. Hvis en Bruger vender tilbage til fx en sag, hvor der er autogemt data, men hvor der, siden data er autogemt, er sket en opdateringen af sagen, skal det autogemte data kasseres, hvorefter Brugeren notificeres om dette. Der skal således ikke ske nogen form for merging af data. Når en Bruger udfører en gem operation, kan den autogemte data ligeledes kasseres. Autogemt data kan kasseres efter en vis periode, såfremt ikke er anvendt, jf. nedenstående krav. Autogem funktionaliteten skal ses i sammenhæng med kravet vedrørende frigivelse af sager og Opgaver (jf. Krav# 142), hvor Brugeren logges af Løsningen ved inaktivitet over en periode. Krav# 408: Autogem data Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal autogemme dataindhold i inputfelter, der kan redigeres af Brugeren, regelmæssigt uden brugerinteraktion med Løsningen. Løsningen skal slette autogemt data efter 24 timer. Side 244 af 257
Eksempler på inputfelter, hvor dataindholdet skal gemmes er journalnotater og breve. Krav# 409: Autogem data på tværs af sessioner Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Autogemt data skal være tilgængeligt på tværs af sessioner. Det vil sige at autogemt data bevares hvis Brugerens session udløber, og er tilgængelig ved næste login, hvor en ny session oprettes. 6.6 Lovkrav 6.6.1 Folketingsbeslutning B103 Anvendelse af obligatoriske, åbne standarder Den 1. januar 2008 blev det obligatorisk for alle offentlige myndigheder at anvende en række åbne standarder i alle nye offentlige it-løsninger. Offentlige myndigheder skal således sikre, at fremtidige it-løsninger baseres på, eller understøtter, disse obligatoriske, åbne standarder. Løsningen skal således baseres på eller understøtte følgende obligatoriske, åbne standarder: Standarder for dataudveksling mellem offentlige myndigheder. Standarder til elektronisk sags- og dokumenthåndtering. Standarder til digital signatur. Standarder for offentlige netsteder/hjemmesider og tilgængelighed. Standarder for it-sikkerhed. Standarder for dokumentudveksling. Nærmere information findes i Digitaliseringsstyrelsens vejledninger om obligatoriske, åbne standarder. Hvis det vurderes, at det ikke er hensigtsmæssigt at basere Løsningen på de relevante obligatoriske, åbne standarder, skal der i forbindelse med afklaringsfasen udarbejdes en rapport af Leverandøren, der forklarer, hvorfor kravet ikke følges. Forklaringen skal begrunde, at mindst et af nedenstående forhold er gældende: Løsningen vil være væsentlig dyrere i forhold til anvendelse af andre standarder. Løsningen vil svække sikkerhedsniveauet væsentligt i forhold til anvendelse af andre standarder. Løsningen vil medføre væsentlig funktionel forringelse, der er direkte forårsaget af, at den er baseret på de obligatoriske, åbne standarder. Løsningen vil øge implementeringstiden markant. Side 245 af 257
Løsningen vil medføre konflikt med standarder, der på grund af internationale forpligtelser er gældende inden for enkelte områder i forhold til anvendelse af andre standarder. Begrundelsen for at fravige kravet om anvendelse af obligatoriske, åbne standarder indberettes af KOMBIT til Digitaliseringsstyrelsen med henblik på offentliggørelse. Krav# 410 Kravet udgår Kategori: Beskrivelse: Type: 6.6.2 ISO 27.001:2013 Det offentlige Danmark anvender ISO 27.001:2013 som standard for informationssikkerhed. ISO 27.001:2013 er en del af ISO/IEC 2700 serien og består af en række standarder med indbyrdes relationer. Krav# 411 Overholdelse af ISO 27.001:2013 Kategori: (MK) Type: Lov og politik Beskrivelse: Leverandøren og Systemet skal overholde ISO 27.001:2013, eller tilsvarende. 6.6.3 Persondataloven mv. Løsningen skal understøtte overholdelse af persondataloven og sikkerhedsbekendtgørelsen. Som udgangspunkt skal enhver behandling af personoplysninger, der foretages for en offentlig myndighed anmeldes til Datatilsynet. KOMBIT og/eller kommunerne forestår denne anmeldelse, idet Leverandøren skal medvirke i relevant og nødvendigt omfang. Krav# 412 Overholdelse af persondataloven mv. Kategori: (MK) Type: Lov og politik Beskrivelse: Løsningen skal understøtte overholdelse af: Lov om behandling af personoplysninger (Persondataloven) Lov nr. 429 af 31.5.2000 med ændringer, herunder ved lov nr. 280 af 25.4.2001 (Justitsministeriet/Datatilsynet), og Lov nr. 639 af 12.6.2013 (Justitsministeriet). Bekendtgørelse nr. 528 af 15. juni 2000 som ændret ved Bekendtgørelse nr. 201 af 22. marts 2001 om sikkerhedsforanstaltninger til beskyttelse af personoplysninger, som behandles for den offentlige forvaltning (Sikkerhedsbekendtgørelsen). Løsningen skal understøtte overholdelse af: Bekendtgørelse om krav til information og samtykke ved lagring af eller adgang til oplysninger i slutbrugeres terminaludstyr - Nr. 1148 af 9. december 2011. Side 246 af 257
6.6.4 Regnskabsbekendtgørelsen - bekendtgørelse nr. 34 af 14/01/2014 om kommunernes budget- og regnskabsvæsen, revision m.v. Kommunernes budget- og regnskabsvæsen er reguleret via henholdsvis kommunestyrelsesloven og regnskabsbekendtgørelsen. Løsningen skal understøtte overholdelse af kravene i regnskabsbekendtgørelsen, herunder krav om korrekt kontering mv. Krav# 413 Overholdelse af regnskabsbekendtgørelsen Kategori: (MK) Type: Lov og politik Beskrivelse: Løsningen skal understøtte overholdelse af kravene i regnskabsbekendtgørelsen. 6.6.5 Bekendtgørelse nr. 789 af 25. juni 2014 om statsrefusion mv. Bekendtgørelsens fulde navn er: Bekendtgørelse om statsrefusion og tilskud samt regnskabsaflæggelse og revision på Social-, Børne- og Integrationsministeriets, Beskæftigelsesministeriets, Ministeriet for By, Bolig og Landdistrikters og Undervisningsministeriets ressortområder - BEK 789 af 25. juni 2014.. Bekendtgørelse om statsrefusion mv. indeholder bl.a. regler om regnskabsaflæggelse i kommuner samt revision af kommunernes regnskaber for udgifter omfattet af ordninger om refusion eller tilskud fra staten, samt krav til dokumentation og registrering af nærmere angivne oplysninger. Krav# 414: Overholdelse af bekendtgørelse nr. 789 af 25. juni 2014.om statsrefusion mv. Kategori: (MK) Type: Lov og politik Beskrivelse: Løsningen skal understøtte, at der kan foretages en fuldstændig og løbende bogføring af samtlige udgifter og indtægter, der i årets løb afholdes eller modtages i henhold til de love og lovbestemmelser, som bekendtgørelsen omfatter, og at konteringen følger de regler, som Økonomi- og Indenrigsministeriet fastsætter i Budget- og regnskabssystem for kommuner, jf. bekendtgørelsens 2. Løsningen skal endvidere understøtte, at kravene i bekendtgørelsens kapitel 8 om dokumentation og registrering overholdes. 6.6.6 Bekendtgørelse nr. 810 af 27. juni 2014 om kommunernes ret til refusion af udgifterne til Ydelser Bekendtgørelse om kommunernes ret til refusion af udgifterne til uddannelseshjælp, kontanthjælp, revalideringsydelse, sygedagpenge, ledighedsydelse og ressourceforløbsydelse til Personer, der deltager i tilbud efter en aktiv beskæftigelsesindsats, eller til sygedagpengemodtagere, der gradvist vender tilbage til arbejdet, BEK 810 af 27. juni 2014. Side 247 af 257
Krav# 415: Overholdelse af bekendtgørelse 810 af 27. juni 2014 om kommunernes ret til refusion af udgifter til Ydelser. Kategori: (MK) Type: Lov og politik Beskrivelse: Løsningen skal understøtte, at der kan ske opdeling af Ydelserne til korrekt kontering ud fra modtagne oplysninger. Sikkerhed Dette afsnit beskriver den overordnede model for sikkerhed og brugerstyring. Sikkerhedsmodellen beskrevet i dette afsnit er valgt med udgangspunkt i Løsningens konkrete forretningsbehov og med udgangspunkt i den sikkerhedsmodel, der er specificeret i Den Fælleskommunale Rammearkitektur. Løsningen karakteriseres ved: Primært at skulle betjene sagsbehandlere og andre interne i kommunen, samt borgere via en dedikeret selvbetjeningsløsning. At integrere til et større antal andre it-systemer. Derfor skal mekanismer til beskyttelse af Løsningen og data prioriteres meget højt, således at Løsningen til enhver tid indeholder de korrekte data, og at disse er tilgængelige for de autoriserede Brugere og kun disse. 6.7.1 Forretningsbehov og antagelser Sikkerhedsmodellen tager udgangspunkt i flg. forretningsbehov og antagelser: 1. Løsningen behandler og indeholder personfølsomme oplysninger i forbindelse med sine primære forretningsprocesser. 2. Løsningen vil blive afviklet på et driftsmiljø, der er separat fra kommunernes infrastruktur, og derfor vil adgang til Løsningen foregå på tværs af sikkerhedsdomæner. 3. Brugergrænseflader kan være web-baserede og tilgås af kommunale sagsbehandlere via internettet. Derudover udstiller og konsumerer Løsningen også web services, der ligeledes tilgås via internettet. 4. Rammearkitekturens sikkerhedsmodel (se Vilkår for Integration til støttesystemet Adgangsstyring (se [ADGANGSSTYING-VILK]) samt [ADGANGSSTYRING], 7.1.2 Adgangsstyring muliggør, at kommuner kan vedligeholde deres medarbejdere lokalt i kommunen, herunder oprettelse og nedlæggelse. Dette skal kunne ske via de forskelligartede brugeradministrationssystemer, som kommunerne i forvejen anvender (herunder Active Directory, IdM løsninger etc.) 5. Løsningen kan understøtte, at kommunerne opbygger deres organisationer forskelligt. Forskellige kommuner skal således kunne vælge forskellige opsætninger til forskellige profiler afhængig af den konkrete kommunes organisation. 6. Løsningen skal kunne understøtte, at en Borger kan involveres i sagsbehandlingen af sin egen sag. 7. Sagsbehandlere i kommunerne bør opnå single sign-on til Løsningen, således at de ikke behøver at logge på igen for at tilgå Løsningens brugergrænseflade. 8. Adgangsstyring i selvbetjeningsløsningen foregår via NemLogin, se afsnit 6.2.3 Selvbetjeningsløsning for yderligere information. Side 248 af 257
6.7.2 Overblik Løsningens sikkerhedsmodel bygger på Adgangsstyring i Rammearkitekturen. Adgangsstyring anvendes til autentifikation og autorisation af Brugere i den brugervendte del af Løsningen. Derudover anvendes Adgangsstyring til autentifikation og autorisation, både når Løsningen optræder som anvendersystem af Rammearkitekturens Støttesystemer og andre fælleskommunale fagsystemer, såvel som til håndtering af sikkerhed omkring anvendelse af Løsningens udstillede snitflader. Adgangsstyring beskriver en overordnet model for sikkerhed og tilbyder en række konkrete services til realisering af denne sikkerhedsmodel. Nedenstående figur illustrerer den kontekst, som Løsningen sikkerhedsmæssigt skal indgå i i forhold til autentifikation og autorisation af Brugere: Figur 29: Sikkerhedsmæssig kontekst for Løsningen Som vist på Figur 29 håndteres brugeradministration i kommunen via deres lokale brugerkatalog.kommunen har ansvar for administration af Brugere, herunder via Støttesystemernes Administrationsmodul at mappe lokale jobfunktionsroller til Løsningens Brugersystemroller.. Derudover har kommunen ansvar for at opstille og drifte en Identity Provider, som kan anvendes af Rammearkitekturens Adgangsstyring i forbindelse med autentifikation og autorisation af Brugeren, når denne tilgår et brugervendt system. Figuren nedenfor illustrerer sikkerhedsmæssig kontekst for systemintegration i Løsningen ved anvendelse af Adgangsstyring. Serviceplatformen anvender både den token baserede sikkerhedsmodel beskrevet for Adgangsstyring, og en certifikatbaseret adgang, se afsnit 6.3.3 Serviceplatformen og 6.4.1 Overordnede integrationskrav for information om Serviceplatformen. Side 249 af 257
Figur 30: Sikkerhedsmæssig kontekst for systemintegration i Løsningen Figur 29 og Figur 30 illustrerer de komponenter, der udgør den fælleskommunale infrastruktur for sikkerhed (Adgangsstyring). Adgangsstyring består overordnet af flg. komponenter: En Context Handler som veksler SAML tokens med jobfunktionsroller fra en kommunal Identity Provider til et nyt (centralt udstedt) SAML token, som indeholder systemroller. Context Handleren holder endvidere styr på Brugerens kontekst altså hvilken kommune, han agerer på vegne af. En Security Token Service som kan anvendes til at få udstedt SAML tokens, der anvendes i web service kald mod støttesystemer samt Serviceplatformen. Administrationsmodulet anvendes til opsætning, konfiguration og administration af roller for Løsningen. Den fælleskommunale adgangsstyring og de krav, der beskriver, hvordan Løsningen lever op til denne, er beskrevet i Vilkår for integration til støttesystemet Adgangsstyring (se [ADGANGS- STYING-VILK] og derudover [ADGANGSSTYRING], 7.1.2 Adgangsstyring for yderligere dokumentation og beskrivelse).. 6.7.3 Generelle krav til sikkerhed Krav# 416 Kategori: Beskrivelse: Kravet udgår - Beskrivelse af sikkerhedsmodel Type: Side 250 af 257
Krav# 417 Sessionsstyring i Løsningen automatisk logout Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal håndtere sessionsstyring ved Bruger login, og herunder implementere automatisk timeout af brugersessioner i Løsningen ved inaktivitet i en vis periode. Perioden skal være konfigurerebar af en administrator. Krav# 418 Sessionsstyring i Løsningen deaktivering af automatisk logout Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal muliggøre konfigurationen af timeout perioder, sådan at det er muligt at deaktivere timeout af en session i Løsningen. Deaktiveringen af timeout skal være mulig for hver kommune individuelt. Krav# 419 Kategori: Beskrivelse: Kravet udgår Type: 6.7.4 Roller og Rettigheder Brugeradgang håndteres efter en føderationsmodel. For Løsningen betyder det, at den ikke behøver at administrere de enkelte Brugere. Løsningen skal i forbindelse med bruger-login henvise Brugeren til Rammearkitekturens Context Handler, der sørger for, at bruger-login håndteres af Brugerens egen organisation. Løsningen skal efterfølgende håndhæve adgang på baggrund af security tokens, der udstedes af Rammearkitekturens Context Handler. Håndhævelsen af brugerrettigheder sker ud fra en række systemroller, som defineres af Løsningen. Disse systemroller oprettes og vedligeholdes af Leverandøren i Rammearkitekturens administrationsmodul og defineres i dette afsnit. En systemrolle defineres af et antal rettigheder, som Løsningen selv står for at håndhæve. Krav# 420 Autorisation af Brugeren Kategori: (K) Type: Ikke-funktionelt Beskrivelse: I forbindelse med enhver tilgang til informationer i Løsningen, er Løsningen ansvarlig for at autorisere Brugeren i forhold til de data og den funktionalitet, der tilgås. Håndhævelsen skal ske ud fra de roller og dataafgrænsninger der modtages i brugerens token udstedt af Rammearkikturens Context Handler Side 251 af 257
6.7.4.1 Brugersystemroller og Servicesystemroller Løsningen opererer med Brugersystemrollerne Central Administrator og Kommunal Administrator, som adskiller ansvaret for henholdsvis centrale og kommunale administrationsopgaver. Herudover indeholder Løsningen en række præoprettede Brugersystemroller, som giver aktører adgang til at anvende Løsningens funktioner og snitflader. En Central Administrator kan desuden oprette nye systemroller baseret på de rettigheder, der findes i Løsningen. Servicesystemroller anvendes til adgangsstyring for systemer, der anvender Løsningens udstillede snitflader. Det forventes at Løsningen, som en del af Løsningens sikkerhedsmodel, har en række rettigheder koblet til dennes interne funktionalitet, hvor rettighederne kan grupperes i et sæt af roller. Krav# 421: Oprettelse af systemroller Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Det skal være muligt at oprette nye Bruger- og Servicesystemroller baseret på Løsningens interne systemrettigheder. Krav# 422: Redigering af systemroller Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Det skal være muligt at redigere koblingen mellem Bruger- og Servicesystemroller og Løsningens interne systemrettigheder. Krav# 423: Kravet udgår Kategori: Beskrivelse: Type: Krav# 424 Præoprettede roller Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal initialt have opsat følgende generelle systemroller: Central Administrator Kommunal Administrator (Grænse: Kommune) Sagskassations Administrator (Grænse: Kommune) Sagsbehandler (Grænse: Ydelse, Kommune) Sagslæser (Grænse: Ydelse, Kommune) Rapportredaktør (Grænse: Kommune) Rapportlæser (Grænse: Kommune) Anvendersystem Sag og Dokument (Grænse: Kommune) Anvendersystem Jobcenter Anvendersystem NemHandel Anvendersystem Journal Side 252 af 257
Anvendersystem selvbetjeningsintegrationer Borger (Grænse: Egne data) Økonomi (Grænse: Kommune) Selvbetjening Support (Grænse: selvbetjeningsdata) Hvor Grænse refererer til en specifik afgrænsning på data, som nærmere specificeret under den enkelte systemrolle. Løsningens systemroller er angivet med dataafgrænsninger på Ydelsesarter i skemaerne nedenfor. Konkret giver dataafgrænsningen mulighed for fx at definere en rettighed til alene at læse enkeltydelsessager. Krav# 425 Sikkerhedsafgrænsning af Ydelser Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal gøre det muligt at anvende rolle/rettighedsbegrænsninger på Ydelsesarterne, der er omfattet af Løsningen jf. underbilag 2.15. Krav# 426 Sikkerhedsafgrænsning af administrationssager Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal gøre det muligt at anvende rolle/rettighed begrænsninger i administrationssager. Krav# 427 Håndhævelse af rettigheder Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal håndhæve rettighedsstyring jf. Løsningens interne sikkerhedsmodel. I Etape 2, Analyse og design defineres, hvilke dele af Løsningens funktionalitet, der skal kunne anvendes af hvilke roller. Når Løsningen idriftsættes eksisterer brugersystemrollen Sagsbehandler som har et sæt af rettigheder på alle Ydelsesarter. En central administrator kan vælge at lave en ny brugersystemrolle, der ligeledes kan se og redigere sager, men blot for en eller flere Ydelsesarter. Sådanne brugersystemroller oprettes i givet fald af Central Administrator. Tabellen herunder viser et eksempel på tildeling af rettigheder og dataafgrænsning til rollen Sagsbehandler. Bemærk at rettighederne er eksempler og det forventes at rollen sammensættes af Løsningens faktiske rettigheder, når disse er kendte. Sagsbehandler Dataafgrænsning Side 253 af 257
Rettighed Forsørgelsesydelse Enkeltydelse Andre Ydelser Administra-tionssager Behandling af X X X X sanktioner Læs sager X X X X Redigér sager X X X X Læs selvbetjening X X X Samlet kontering X X X X Tabel 16: Rettigheder og dataafgrænsning for systemrollen sagsbehandler Nogle Brugere skal ikke have adgang til at sagsbehandle, men alene se sager i brugergrænsefladen. Disse modelleres i brugersystemrollen Sagslæser. Sagslæser Dataafgrænsning Rettighed Forsørgelsesydelse Enkeltydelse Andre Ydelser Administra-tionssager Læs sager X X X X Læs selvbetjening X X X Tabel 17: Rettigheder og dataafgrænsning for Brugersystemrollen Sagslæser Rapportredaktør Dataafgrænsning Rettighed Forsørgelsesydelse Enkeltydelse Andre Ydelser Administra-tionssager Læs rapporter X X X X Redigér rapporter X X X X Tabel 18: Rettigheder for og dataafgrænsning Brugersystemrollen Rapportredaktør Rapportlæser Dataafgrænsning Rettighed Forsørgelsesydelse Enkeltydelse Andre Ydelser Administra-tionssager Læs rapporter X X X X Tabel 19: Rettigheder og dataafgrænsning for Brugersystemrollen Rapportlæser Borger Rettighed Dataafgrænsning Forsørgelsesydelsonssager Enkeltydelse Andre Ydelser Administra-ti- X X Tabel 20: Rettigheder og dataafgrænsning for Brugersystemrollen Borger Redigér selvbetjening Økonomi Dataafgrænsning Rettighed Forsørgelsesydelse Enkeltydelse Andre Ydelser Administra-tionssager Samlet kontering X X X X Tabel 21: Rettigheder og dataafgrænsning for Brugersystemrollen Økonomi 6.7.5 Data afgrænsning I informationsmodellen beskrevet i [ADGANGSSTYRING, se afsnit 7.1.1]. kan man afgrænse rettigheder på funktion, data og følsomhed. Løsningen anvender funktions- og dataafgrænsning. Følsomhed anvendes som udgangspunkt ikke. Side 254 af 257
Krav# 428 Sikkerhedsafgrænsning af funktioner og data Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal gøre det muligt at anvende rolle/rettighed begrænsninger på følgende konceptuelle dele af Løsningen: Krav# 429 Adgang til data en Bruger med en given rolle skal kun kunne se de data, vedkommende har adgang til Adgang til forretningsservices / intern funktionalitet en Bruger skal kun kunne anvende de (forretnings)services, som denne har adgang til Adgang til snitflader et anvendersystem skal kun kunne anvende de af Løsningen udstillede snitflader, som denne har adgang til Sikring af Løsningen Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Leverandøren skal sikre at alle integration og brugergrænseflader som udstilles af Løsningen, over offentlige netværk eller private netværk, skal være sikrede mod indtrængen og angreb, som almindelig god IT-skik tilsiger. 6.7.6 Selvbetjening Borgeren autentificerer sig overfor selvbetjeningen vha. NemID/NemLog-In infrastrukturen (se kap. 6.4.4.1). Selvbetjeningen er en separat komponent ift. Løsningen, og selvbetjeningens autentifikation (og autorisation) af borgeren har ikke umiddelbart noget overlap med Rammearkitekturens Adgangsstyring. Borgeren kan igennem selvbetjeningen indirekte tilgå services udstillet af Løsningen eller af Serviceplatformen. I dette scenarie optræder selvbetjening som et Anvendersystem af hhv. Løsningen eller Serviceplatformen, og de sikkerhedsmæssige aspekter af integrationen er således dækket af [ADGANGSSTYRING, se afsnit 7.1.1]. 6.7.7 Mobile enheder Borgeres adgang til selvbetjeningsløsningen fra en mobil enhed er dækket af den generelle adgangsstyring beskrevet i afsnit 6.7.6. 6.7.8 Protokoller og datatransport Løsningen udstiller snitflader, hvorigennem der bliver overført personfølsomme data. Det er derfor vigtigt, at Løsningens snitflader anvender tilstrækkelig sikkerhed til transport af data. Det skal sikres, at alle informationer, der udveksles, herunder i særdeleshed personfølsomme oplysninger, udveksles under hensyntagen til: Side 255 af 257
Fortrolighed Autenticitet Uafviselighed Udveksling af følsomme personoplysninger skal beskyttes med stærk kryptering baseret på en anerkendt algoritme jf. Datatilsynets praksis 6. Krav# 430 Kryptering af data i transit Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Data i transit skal være krypteret. Krav# 431 Kryptering af persisteret data Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Persisteret data der er personhenførbart eller personfølsomt skal opbevares krypteret. Krav# 432 Stærk kryptering Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Konfidentialitet skal sikres med stærk kryptering i henhold til Datatilsynets definition af stærk kryptering 7 dvs. med en krypteringsnøgle på 128-bit og ved anvendelse af AES- eller Tripple-DES algoritmerne. 7 Referencer 7.1.1 OIO Sag [OIO_SAG] OIO standarderne for sag og dokument, http://digitaliser.dk/resource/444163 [indhentet 10-03-2014] 7.1.2 Adgangsstyring [ADGANGSSTYING] Kravspecifikation for fælleskommunal adgangsstyring tilgængelig på kombit.dk (http://www.kombit.dk/indhold/adgangsstyring) [ADGANGSSTYING-VILK] Vilkår for integration til Adgangsstyring http://www.kombit.dk/sts/vilkaar [Indhentet pr. 26-03-2014] 6 http://www.datatilsynet.dk/offentlig/sikkerhed/transmission-over-internettet/ [Indhentet pr. 14-01-2014] 7 http://www.datatilsynet.dk/offentlig/sikkerhed/staerk-kryptering/ [indhentet 04-12-2013] Side 256 af 257
[ADMIN_MODUL] Rammearkitektures administrationsmodul tilgængelig på kombit.dk (http://www.kombit.dk/indhold/adgangsstyring) 7.1.3 Rammearkitektur [RA] Den Fælleskommunale Rammearkitektur http://www.kl.dk/imagevaultfiles/id_64664/cf_202/introduktion_til_rammearkitektur_-_version_1_0.pdf [indhentet d. 06-12- 2013] [RA-PRINCIP] Fælleskommunale Arkitekturprincipper http://www.kl.dk/imagevault/images/id_61151/scope_0/imagevaulthandler.aspx [indhentet d. 06-12-2013] [DIGI-STRAT] Fælleskommunale Digitaliseringsstrategi http://www.kl.dk/fagomrader/administration-og-digitalisering/digitaliseringsstrategier1/den-falleskommunale-digitaliseringsstrategi/sammenhangende-it-og-konkurrence/ [indhentet d. 06-12-2013] 7.1.4 Andet [ØIM_KONTOPLAN] Økonomi- og Indenrigsministeriets autoriserede kontoplan: http://budregn.oim.dk/budget-og-regnskabssystem-for-kommuner/3-den-autoriserede-kontoplan.aspx [indhentet 12-03-2014]. 8 Revisionshistorik Revisionsdato Version Ændringer Ændringer markeret? Forfatter 06-05-2015 1.1 Ændringer efter review Ja Lilian Munk Larsen 13-05-2015 1.2 Efter aftale med Camilla Buhr opdateret Tabel 6: Oversigt over sanktionsårsager og lovhenvisninger. 08-06-2015 6.0 Krav 21: Bemærkning opdateret med fjernelse af reference til SKAT snitfladen efter aftale med Lilian Munk Larsen. 19-09-2015 6.1 Opdateret Tabel 15 Snitflader anvendt af specifikke Ydelser s. 204-205 jf. KY Lev Funk Emne ID 56 19-09-2015 6.2 I relation til kravmapningsproces er Krav# 278, 292, 379, 380, 403e og 423 opdateret med "Kravet udgår". 22-09-2015 7.1 I relation til kravmapningsproces er Krav# 416 opdateret med "Kravet udgår". Ja Nej Ja Ja Ja Lilian Munk Larsen Camilla Buhr Lilian Munk Larsen Lilian Munk Larsen Lilian Munk Larsen Side 257 af 257