Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning

Versionshistorik af betydning for eksterne (v0.1, v0.3, v0.5 og v1.0)

Ingen ændringer på eksterne snitflader.

Interne links (indhold i links ikke relevant for eksterne)

VIR-3905 - Getting issue details... STATUS

Indholdsfortegnelse

Afgrænsning af epic

Ikke behov for tilsagn.

Oversigt over berørte webservices 

Ingen ændringer i webservices.

Beskrivelse af epic

Baggrund

Denne epic har til formål at give bedre konsistens mellem ordningerne på VITAS. VITAS bærer i såvel kode, funktionalitet og brugergrænseflade præg af, at hver ordning i stort omfang er udviklet uafhængigt af hinanden. Indholdet i hver ordning er præget af analyser og prioriteringer foretaget af PO, forretning, FA mht. ambitionsniveau, budget mv. VITAS fremstår derfor i dag med nogle konsistensproblemer, hvor brugere med rimelighed forventer, at ordningerne opfører sig ens og konsistent, men hvor ordningerne i VITAS har mere eller mindre tilfældige forskelle. 

Indholdet i epic'en tager udgangspunkt i specifikke FB-sager jf. epicens acceptkriterier.

VITAS' ordninger er implementerede på hhv. gammel og ny applikation. Der forventes fortsat visuelle forskelle mellem gammel og ny applikation, mens der forventes større ensartethed mellem ordninger på samme applikation. Den gamle applikation forventes udfaset på et tidspunkt, hvorefter ordninger på den gamle applikation migreres til den nye applikation. Det afhænger af moderniseringsprojektet.

Regler

Jf. nedenstående epic acceptkriterier.

Forventet påvirkning af jobcenter-, a-kasse- eller ydelsessystemer

Alle brugere af VITAS oplever større ensartethed mellem ordningerne i VITAS. Der vil fortsat være mindre forskelle mellem ordninger på hhv. gammel og ny applikation i VITAS.

971.54.1 Hver aktør (borgere, virksomheder, jobcentre, AA) oplever konsistent præsentation af borgerinformation (navn, adresse og CPR_nummer) på alle ordninger (FB 165067) 

Status: Godkendt af PO. Prioritet: 1

Alle ordninger skal implementere følgende principper:

/wiki/spaces/CITY/pages/3391619122: /wiki/spaces/CITY/pages/3391619122

med følgende modifikationer:

• Skjulte bogstaver ved passwords mv. vises med "***" (som genkendes ved indtastning af skjulte tegn i passwords).
• konsistente meddelelser ved manglende adgang til borgerdata:
  • Anden aktør:  “Er ikke udlagt til anden aktør”
  • Jobcenter (ikke egen borger): “Tilhører en anden kommune”

Dokumentation

Dokumentation af forretningsregler for præsentation af borgerinformation skal opdateres med ovenstående forretningsregler som del af dette epic acceptkriterie:

• /wiki/spaces/CITY/pages/3391619122

FB'er:

• https://manuscript.star.dk/f/cases/165067/Flexjob-Mentor-PA-Hj-lpemidler-signing-person-virksomhed-borger-f-r-vist-CPR-nummer-og-historik-p-bevillingen

971.54.2 Alle ordninger opfører sig ens, når de oprettes og indsendes af Anden Aktør (FB 178721, FB 164970) 

Status: Godkendt af PO

Ansøgninger fra alle ordninger følger standardflow for ansøgninger, der er indsendt af Anden Aktør jf. /wiki/spaces/CITY/pages/3528949768.

FB'er:

• https://manuscript.star.dk/f/cases/178721/AA-behandling-af-ans-gninger-f-lger-ikke-vejledningen
• https://manuscript.star.dk/f/cases/164970/Flexjob-Anden-akt-r-ans-gning-bliver-ikke-automatiskt-flyttet-over-til-JC-efter-JC-godkender-ans-gningen

Øvrige observationer:

971.54.3 Alle ordninger med "send kladde" understøtter gensend kladde (FB 142979) 

Status: Godkendt af PO

Det er muligt at gensende e-mails, som tidligere er blevet sendt via ”Gensend”- knap. ”Gensend”-knappen vises på ansøgnings-, forlængelses- og ophørskladder samt på bevillingen, når den har status ”Sendt til arbejdsgiver”. Derudover vises ”Gensend”-knappen på ansøgninger, som er sent til høring – som dermed har status: ”Sendt til medarbejder-rep”. ”Gensend”-knappen vises øverst til højre på sagen, og vises som et papir-flyver ikon, uanset om der er tale om virksomhedens indgang til systemet eller jobcenterets sagsbehandlingsmodul.
Ved tryk på ”Gensend”-knappen fremkommer en dialogboks hvor den oprindelige e-mail adresse er for-udfyldt. Det er muligt at ændre på e-mail-adressen, og herefter sende mailen igen.
E-mails kan gensendes mere end en gang. Hver gang e-mailen gensendes vil dette blive stemplet i historikken og brugeren vil dermed kunne se hvornår der er blevet gensendt e-mails. Bemærk at det ikke er ansøgningen der gensendes, men kun mailen vedrørende ansøgningen.

Knappen aktiverer en dialog, hvor brugeren kan indtaste en ny e-mail adresse.

Findes allerede på virksomhedpraktik (og formentlig øvrige gamle ordninger).

Mangler på Fleksjob (og formentlig på Jobrotation).

FB'er: 

• https://manuscript.star.dk/f/cases/142979/Der-findes-ikke-en-gensend-kladde-knap-p-fleksjob-kladder-n-r-de-tilg-s-fra-JC-AA-sendte-kladde-liste-som-p-de-vrige-forl-b

Reference

Fra versionsnote 2: VITAS – Versionsnote pr. 15. April 2016

"Det er nu muligt at gensende e-mails, som tidligere er blevet sendt via en ”Gensend”- knap. ”Gensend”-knappen vises på ansøgnings-, forlængelses- og ophørskladder samt på bevillingen, når den har status ”Sendt til arbejdsgiver”. Derudover vises ”Gensend”-knappen på ansøgninger, som er sent til høring – som dermed har status: ”Sendt til medarbejder-rep”. ”Gensend”-knappen vises øverst til højre på sagen, og vises som et papir-flyver ikon, uanset om der er tale om virksomhedens indgang til systemet eller jobcenterets sagsbehandlingsmodul.
Ved tryk på ”Gensend”-knappen fremkommer en dialogboks hvor den oprindelige e-mail adresse er for-udfyldt. Det er muligt at ændre på e-mail-adressen, og herefter sende mailen igen.
E-mails kan gensendes mere end en gang. Hver gang e-mailen gensendes vil dette blive stemplet i historikken og brugeren vil dermed kunne se hvornår der er blevet gensendt e-mails. Bemærk at det ikke er ansøgningen der gensendes, men kun mailen vedrørende ansøgningen."

971.54.4 Ensartede regler for valg og flytning af sager mellem jobcentre

Status: Klar til PO review

STAR ønsker ensartede regler og funktionalitet vedr. valg og flytning mellem jobcentre, hvor der i dag er forskelle jf.:

• /wiki/spaces/CITY/pages/3517939736.
  • Kendte afvigelser, som skal tilrettes: Voksenlærling, Fleksjob, Mentor, Personlig assistance, Hjælpemiddel
• /wiki/spaces/CITY/pages/3356065847 
  • Kendte afvigelser, som skal tilrettes: Voksenlærling. 

Camilla Hagedorn Trolle: Er det kun voksenlærling, som skal understøtte udrejste borgere?

Dokumentation opdateres når ensartning er implementeret.: /wiki/spaces/CITY/pages/3517939736.

FB'er:

• https://manuscript.star.dk/f/cases/217070/Tidligere-Bop-lskommune-giver-fejl-i-forbindelse-med-voksenl-rlige-der-skal-oprettes-i-arbejdgiver-kommune

Noter:

• Dette epic acceptkriterie overtager indhold fra epic 971.35, som er slettet.

971.54.5 "Sæt ansvarlig" for jobcenter og Anden Aktør virker ens på alle ordninger (FB 171606) 

Status: Godkendt af PO

Alle ordinger virker ens vedr. "Sæt ansvarlig". Specifikt skal Fleksjob, Jobrotation og kompenserende ordninger virke på samme måde som Virksomhedspraktik.

FB'er:

• https://manuscript.star.dk/f/cases/171606/Flex-som-AA-fungerer-s-t-ansvarlig-p-ans-gning-ikke

971.54.6 Indtast og fjern CPR-nummer på ansøgninger og bevillinger fungerer ens på tværs af ordninger (FB 179932, FB 213132, FB 225005) 

Status: Godkendt af PO

Ansøgninger:

1. Det er kun muligt at aktivere "Hent oplysninger" på dt indtastede / indsatte CPR-nummer når bruger har afkrydset "Jeg erklærer, at borgeren ..."
2. Når brugeren har indtastet / indsat CPR-nummer og trykket "Hent oplysninger", skal de fire sidste cifre maskes af med "****" og kun fornavn vises.
3. Når brugeren trykker "Fjern oplysninger" skal alle borgeroplysninger slettes og ansøgningen skal føres tilbage til tilstand før CPR-nummer blev tilføjet. Herunder skal jobcenter ved "Spørgsmål angående ansøgningen" evt. føres tilbage.

Ovenstående gælder både når virksomhed udfylder ansøgning og når jobcenter / anden aktør udfylder ansøgning i virksomhedssupport.

• Dog kan jobcenter i virksomhedssupport ikke lave opslag på borgere fra anden kommune.
• Dog kan anden aktør i virksomhedssupport ikke lave opslag på borgere, der ikke er udlagt til anden aktør.

Der må være mindre forskelle i brugeroplevelsen mellem ordninger på VITAS gamle applikation og på VITAS nye applikation, men den egentlige funktionalitet skal være den samme.

Epic acceptkriteriet implementeres ved først at identificere afvigelser, idet den beskrevne funktionalitet forventes at være implementeret. Herunder gentestens nedenstående FB'er. Afvigelser rettes.

FB'er:

• https://manuscript.star.dk/f/cases/179932/Integrationsgrunduddannelse-opret-ans-gning-cpr-nummer-feltet-fungerer-ikke-som-p-andre-ordninger
• https://manuscript.star.dk/f/cases/213132/Voksenl-rling-Ans-gning-Fjern-oplysninger-p-borgerfanen-fejler-hvis-fanen-er-udfyldt
• https://manuscript.star.dk/f/cases/225005/Virksomhedspraktik-Fjern-oplysninger-p-borger-fjerner-ikke-borgeren-jobcenter-i-venstre-boks

971.54.7 Frigiv / overtag fungerer ens på tværs af ordninger (FB 180749, FB 212804) 

Status: Godkendt af PO

Overtag / frigiv findes på alle ordninger og på alle blankettyper (ansøgning, tilbud, bevilling, vurdering, tillægsbevilling) for jobcenter og anden aktør.

Overtag / Frigiv findes ikke i virksomhedssupport (Jobcenter og Anden Aktør).

FB'er:

• https://manuscript.star.dk/f/cases/180749/AA-Personlig-assistance-Frigiv-overtag-boks-mangler
• https://manuscript.star.dk/f/cases/212804/Fleksjob-Viser-frigiv-knap-og-oph-r-knap-under-supportvisning

971.54.8 Beskyttet navn- og adresse håndteres ensartet

Status: Klar til PO review

VITAS håndterer i dag beskyttet adresse, men "IsProtectedAddress" i DFDG's PersonStatusService betyder at BÅDE navn OG adresse er beskyttet. Dvs. der er kun én egenskab, som styrer begge forhold. 

Den nuværende håndtering er beskrevet her: /wiki/spaces/CITY/pages/3391619122

Disse forretningsregler skal implementeres på alle ordninger.

Desuden skal følgende ændringer implementeres:

• Jobcenter må se adresse med adressebeskyttelse i såvel edit som i read-only view
  • Med meddelelse om "Personen har beskyttet adresse" i såvel edit som i read-only view
  • Hidtil har jobcenter kunnet se  beskyttet adresse i edit, men ikke i read-only (måske kun for nogle ordninger). 
  • Prioritet: Kan fravælges, hvis det er for dyrt (> 2 SP)
• Tjek for adressebeskyttelse er dynamisk. Tjek mod aktuelle data og ikke mod data på indberetningstidspunkt.

Analyse:

Camilla Hagedorn Trolle: Et det de ønskede forretningsregler? Se også nedenstående:

FA observationer til forretningsafklaring vedr. navne- og adressebeskyttelse:

1. Er det korrekt, at virksomheden ikke må kende adresse på en potentielt ansat med beskyttet adresse?
   1. Bevillingen handler om at der skal indgås et ansættelses (lignende) forhold
2. Hvorfor er der ikke oplysning om beskyttet navn til alle aktører?
   1. Hvad er ønsket forretningsregel?
      Det forekommer at være korrekt, at virksomhed, borgers jobcenter og udlagt anden aktør kan se navn på indsendt ansøgning, samt på bevilling, da også virksomheden har behov for at vide hvem virksomheden ansætter.

Dokumentation opdateres med evt. ændringer: /wiki/spaces/CITY/pages/3391619122

FB'er:

• https://manuscript.star.dk/f/cases/165008/Visning-af-adresse-for-sagsbehandler-n-r-den-er-beskyttet-viker-ikke-p-Personlig-assistance 

971.54.9 Øremærkede ansøgninger fordeles automatisk til Anden Aktør, hvis borger er udlagt til Anden Aktør  (FB 121411)

Status: Klar til PO review

Et jobcenter skal kunne vælge at øremærkede ansøgninger vedr. en borger, der er udlagt til Anden Aktør, automatisk sendes til Anden Aktør. Det gælder kun for Anden Aktør, som er tilknyttet jobcenteret som rolle 3 (myndighed). Hvis borger er udlagt til flere Anden Aktør med myndighedsrolle på jobcenteret, vælger VITAS tilfældigt en af disse Anden Aktør.

Ny tjekboks (default fravalgt svarende til nuværende forretningsregler):

"[ ] Anden Aktør modtager automatisk øremærkede ansøgninger vedrørende borgere, der er udlagt til Anden Aktør"

Tjekboks indsættes på siden "Anden Aktør administration":

Denne fordelingsregel har højere prioritet end øvrige forretningsregler for fordeling af ansøgninger, herunder:

• Opsatte fordelingsregler for teams jf. "Administration af fordelingsregler"
• Regler for at AA modtager ansøgning, når virksomhed underskriver ansøgning i AA's session eller virksomhed indsender kladde, som AA har fremsendt til virksomhed. 

Dokumentation opdateres:

• /wiki/spaces/CITY/pages/3528949768

FB'er:

• https://manuscript.star.dk/f/cases/121411/VITAS-Ans-gning-hvor-borger-er-henvist-til-AA-rolle-3-sendes-automatisk-til-behandling-ved-AA

971.54.10 Ensartede forretningsregler for borgerrelationer (FB 240522)

Status: Skal afklares med PO

STAR skal fastlægge ensartede forretningsregler for relationer mellem borger og jobcenter. Problemstillingen er beskrevet i FB 240522:

Vi har ifm. Vallensbæk / Ishøj opsplitning fundet ud af at nye og gamle ordninger opfører sig forskelligt mht. fortolkning af relation mellem blanket, borger og jobcenter. VITAS har (af ikke helt forståede årsager) både en relation fra blanket til jobcenter og en relation fra blankettens borger til jobcenter.

"Nye ordninger:
Borgerens jobcentercode er afgørende for om borgeren bliver vist
Efter flytning kan Ishøj ikke se borgeren på øremærkede ansøgninger/bevillinger (Men Vallensbæk kan godt)

Gamle ordninger:
Blankettens jobcentercode er afgørende for om borgeren bliver vist
Efter flytning kan Ishøj se borgeren på øremærkede ansøgninger/bevillinger (Og Vallensbæk kan ikke)"

Ved manuel flytning af sager i VITAS, flyttes kun blankettens jobcenterkode og ikke blankettens borgers jobcenterkode. Det giver problemer på de nye ordninger.

Vi ønsker ensartede regler.
1) Vi skal afklare hvorfor vi har 2 relationer og afklare sammenhæng mellem relationer og forretningsregler i VITAS. Det vil være optimalt, hvis kun den ene relation styrer forretningsregler.
2) Vi skal have en ensartet implementering af jobcenterrelation og forretningsregler på nye og gamle ordninger.
3) VITAS anvender på statiske relationer mellem blanket/borger og jobcenter. Borgerens aktuelle status fra DFDG anvendes ikke. Vi skal sikre, at STAR er enige i den fortolking.
Dokumentation af disse forretningsregler skal opdateres efter afklaring:
/wiki/spaces/CITY/pages/3391619122

971.54.11 Upload af bilag med godkendelse er generelt alternativ til underskrift med pen eller NemID / MitID

Status: Prioriteret af PO, men endelig løsning skal godkendes af PO

VITAS tilbyder i dag mulighed for at en bruger kan underskrive med pen eller eller NemID / MitID, hvis brugeren skal godkende / underskrive i en anden brugers session. Det gælder bl.a. ved:

• Virksomhed indsender ansøgning i virksomhedssupport (Jobcenter eller Anden Aktør har sessionen)
• Medarbejderrepræsentant godkender ansøgning (Virksomhed, Jobcenter eller Anden Aktør har sessionen)
• Virksomhed godkender bevilling i virksomhedssupport (Jobcenter eller Anden Aktør har sessionen)
• Borger godkender ansøgning / bevilling (Virksomhed, Jobcenter eller Anden Aktør har sessionen)

Medarbejderrepræsentant har desuden mulighed for at godkende ved upload af bilag med underskrift jf. /wiki/spaces/CITY/pages/3523641382

Brugerne ønsker at gøre det muligt at godkende ved upload af bilag med godkendelse som et generelt alternativ til at en bruger kan underskrive med pen eller eller NemID / MitID, når en anden bruger har den aktive session. Det vil bl.a. løse et stort ønske fra jobcentrene for at virksomheder kan godkende via e-mail eller telefonnotat:

1. Den nuværende mulighed for at godkende ved upload af bilag med underskrift for medarbejderrepræsentant ændres til et generelt alternativ for alle godkendelser i andre brugeres sessioner.
   1. Ny knap "Godkend med bilag" indsættes efter (til højre for) eksisterende godkendelsesknapper
2. Brugeren (Jobkonsulent m.fl.) kan upload et bilag med godkendelse. Bilaget kan fx være scannet dokument, e-mail eller telefonnotat - VITAS kan ikke"se" forskel på typer af bilag med godkendelse og validerer ikke indholdet, dvs. det er brugerens ansvar at bilaget indeholder en godkendelse. VITAS registrerer hvilken bruger, der har uploaded bilaget som godkendelse, tidspunkt, samt selve bilaget.
3. Det nuværende flow erstattet af et mere brugervenligt flow, da det nuværende flow er for tungt. Se evt. /wiki/spaces/CITY/pages/3523641382. Det nuværende upload flow for bilag på de nye ordninger, fx. for Mentor,kan danne udgangspunkt for et mere brugervenligt flow. 
   1. TO DO
   2. Der skal være to steps: 1) upload af bilag, 2) bekræft at bilaget er en godkendelse (lidt som ved pen)
4. Der indsættes vejledning om hvad der skal indgå i et bilag med godkendelse.
5. Bilag med godkendelse skal lagres på sagen som dokumenttype "Bilag med godkendelse" (formentlig ny type).
   1. TO DO: Tjek at dokumenttype allerede findes med default værdi "Dokument". Alle eksisterende bilag får typen "Dokument". 
6. "Bilag med godkendelse" kan ikke slettes
   1. Heller ikke fra papirclips (bør have generel backend validering)
7. Bilag med godkendelse findes på sagens bilagsliste (papirclips) og kan downloades som øvrige bilag
   1. Nice-to-have: Signering og historik linker til bilaget (direkte download af bilaget)

Wireframes (eksisterende design - se "Godkend med pen" og"papirclips):

1: Knapper

2: Popup dialog med upload + godkendelse (interaktion baseret på eksisterende "Med pen" og "papirclips" på nye ordninger for at tilstræbe ensartethed):

• Tjekboks "Jeg bekræfter at ovenstående bilag ..." er default ikke-afkrydset og deaktiveret
• Tjekboks "Jeg bekræfter at ovenstående bilag ..." aktiveres, når der er valg og uploaded et bilag med knap "Vælg"
  • Vælg har samme brugeroplevelse som ved "papirclips" på nye ordninger - dokumenttype = "Bilag med godkendelse"
• Knap "OK" er deaktiveret indtil tjekboks "Jeg bekræfter at ovenstående bilag ..." er afkrydset
• Bilaget tilknyttes først sagen , når der er klikket "OK"
  • Herefter kan bilaget ikke slettes fra sagen (fx fra sagens papirclips)

Når der er valgt og uploaded et bilag, ændrer dialogen tilstand som skitseret herunder:

Upload dialog på Mentor som inspiration:

Særlige krav til test

* Batchjobs

• bør testes både med delta og fuldt load,
• bør hvis der er afhængigheder køres med normalt load fra BI i ét testmiljø i hele testperioden
• bør testes i samarbejde med teams som har afhængigheder
• kørselstid, særligt hvis det er en del af NightlyBatch

Konsekvenser for drift/idriftsættelse

I forbindelse med idriftsættelse:

• Skal der køres et fuldt dataload ved første kørsel af et batchjob - aftal med SF hvornår load skal køres:  
• Skal der køres konvertering:  
• Skal der køres databasescripts for opdatering af tabeller i databasen:  

Efter idriftsættelse:

Arkitektur- og implementeringsnoter 

Her beskriver PO/FA om arkitekturen og teknikken bag løsningen, om der f.eks. anvendes:

• Nye dataområder:  
• Nye snitflader:  
• Nye komponenter:  
• Nye miljøer:  
• Nye teknologier:  
• Nye aftagertyper:  
• Eller afvigelser fra principperne:  
• Eventuelle behov for reduktion af teknisk gæld skal afdækkes:  

Der gives en beskrivelse af hvorledes disse tænkes håndteret/implementeret i løsningen og om dette har været vendt med STAR arkitekten.

Husk GDPR stillingtagen

Ingen personfølsomme data i epics

Illustrationer, skærmdumps m.v. må ikke indeholde cpr.nr., CV. nr., rigtige personnavne på borgere eller deres kontaktoplysninger i form af e-mail, telefonnr., adresse m.v.

•  Ja, det er tjekket, at epic ikke indeholder dette.

• Angiv hvem der har foretaget dette tjek: 

• Angiv dato for tjek: 

Opbevaring af oplysninger i STARs it-systemer

Ved oprettelse af nye dataområder skal der tages stilling til, hvornår formålet med data ophører og dermed fastlægges en slettepolitik.

Ved indførelse af nye data på eksisterende dataområder skal GDPR slettejobs opdateres.

Hvem må tilgå oplysningerne?

Afsnittet må ikke blot slettes, hvis det vurderes ikke relevant. Det skal dokumenteres at man har forhold sig til nedenstående.

Husk det er hensynet til borgeren der tæller højst. Der skal være hjemmel til at sagsbehandler må tilgå oplysninger. Formålet skal være som led i administrationen af beskæftigelsesreglerne eller ydelsesadministration.  

Korrekte sikkerhedsattributter på services

PO skal for hver enkelt servicemetode angive hvilke myndighedstyper, der må kalde de forskellige servicemetoder.

Tilladte organisationer (eksempel - se den fulde liste over myndighedstyper på siden DFDGs sikkerhedsmodel )

A-kasse filtrering

Hvis a-kassen må anvende metoden, må a-kassen så se / hente alle data? Eller skal der foretages filtrering ift. at a-kassen fx kun må se nogle udfaldsrum / kodelisteværdier? Husk at filtreringen skal ramme eventuel visning på Jobnet aht. sagsbehandlerlogin

Sagsbehandlerlogin på Jobnet - tag stilling til adgang!

En sagsbehandler i et jobcenter kan tilgå en borger tilknyttet det konkrete jobcenter.

En sagsbehandler i en a-kasse kan tilgå en borger, som er medlem af a-kassen og KG 1 (tilmeldt og ikke-tilmeldt) eller KG 8 og tilmeldekategori 5 - dimittend.

Begrænsninger kan foretages via (a-kasse-) filtrering, eller ved at afgrænse på action niveau på konkrete sider på Jobnet.

Stillingtagen: Beskriv kort, at der er taget stilling til sagsbehandlerlogin