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)

BVL-605 - 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

Fortsætter Epic 971.57

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.58.1 Hver aktør (borgere, virksomheder, jobcentre, AA) oplever konsistent præsentation af borgerinformation (navn, adresse og CPR_nummer) på alle ordninger 

Status: Godkendt af PO. Prioritet: 1 (tilrettet tah)

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). /rettelse af afvigelser er ikke prioriteret til 2023-1
• Teamet skal lave analyse af visning af person oplysninger: navn/cpr/adresse/inkl. liste visning og excel.
  • Dokumentation af analysen skal danne udgangspunkt for rettelser i forhold til afvigelser jf dokumentation og ønsker om **** markering af cpr og konsistente advarsler.
  • Afvigelser og ønsker om **** markering af cpr og konsistente advarsler er implementeret. rettelser til afvigelser er ikke prioriteret til 2023-1

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:
Nedenstående rettelser til visning af persondata blev ikke prioriteret til 2023-1

• 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
• https://manuscript.star.dk/f/cases/308479/Kundetest-Hvorfor-vises-f-dselsdatoXXXX-ikke-i-bevilling
• https://manuscript.star.dk/f/cases/308231/

971.58.2 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? CHT: ja
   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.58.3 Alle ordninger opfører sig ens, når de oprettes og indsendes af Anden Aktør (FB 164970) 

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.58.4 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.58.6 Ensartede forretningsregler for borgerrelationer (FB 240522)

Se krav 10

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

Note: jf. FB sag https://manuscript.star.dk/f/cases/316987/ opdateres personoplysninger på ansøgning/bevilling ikke efter borgeren flytter kommune.

971.58.8 Batchjob DisableInactiveUsers skal omlægges til stonebranch 

Som en SystemForvalter vil jeg have VITAS batchjobs lagt om til STAR City Standard - Stonebranch for at få standardiseret, stabil drift i overensstemmelse med STAR City standarder.

Acceptkriterier:

• Alle VITAS batchjobs er lagt om til STAR City standard - Stonebranch. Gælder både STAR City jobs og Hangfire jobs 
• Alle VITAS batchjobs kan overvåges med DFDG's AdminTools modul
• Alle VITAS batchjobs er dokumenterede jf. STAR City standard
• Alle VITAS batchjobs afvikles konsistent, så de enten er gennemført fuldstændigt med status succes eller er fejlet med status fejlet.
• Batchjobs kan ikke længere overvåges eller idriftsættes fra VITAS (konsekvens af omlægning) 
• VITAS batchjobs er ikke længere følsomme overfor driftsafviklingstidspunkt
• VITAS batchjobs er ikke længere følsomme overfor fejl under driftsafvikling

971.58.9 Sagsbehandler skal aktivt vælge om der skal sendes orienterings brev til borgeren v afvisning af øremærket ansøgning for flg. ordninger:
Løntilskud, Virksomhedspraktik samt Fleksjob 

Acceptkriterie:

• 
  Som STAR ønsker jeg at sagsbehandler aktiv skal tage stilling til om orienteringsbrev skal sendes til borgeren hvis der gives afslag på øremærket ansøgning om:
  Løntilskud, virksomhedspraktik samt fleksjob.
• /wiki/spaces/CITY/pages/1428652167 Dokumentation opdateres med henvisning til at flueben ikke er sat default/ jf FB sag, samt accepteret ønske fra 6 by mødet.

Noter:

• Se relateret FB 154201
• Med den valgte løsning vil borgere der er fritaget digital post heller ikke modtage orienteringsbrev "sendt fra VITAS" omkring afslag på ansøgning.
• Et forbedringsønske på sigt kan være at der fremgår under hændelser/status /eller under brevstatus at der er taget stilling til/ sagsbehandler ikke har tilvalgt at orienteringsbrev ikke skal sendes til borgeren.

971.58.10 Som STAR ønsker jeg ensartet regler for visning af persondata i forbindelse med flytning af sager mellem jobcentre:

Accptkrit:

• Når en øremærket sag – ordning fleksjob. (ansøgning/tilbud/vurdering) overføres fra et jobcenter til et andet skal det modtagende jobcenter kunne se persondata på borgeren, også selvom borgeren ikke er tilknyttet det jobcenter der modtager sagen (se note*).
• Jobcenter der ”har sagen” skal altid kunne se persondata på borgeren – også selvom borgeren ikke er tilknyttet jobcenter der modtager sagen, dette virker for gamle ordninger, og skal også virke på samme måde for de nye ordninger (fleksjob)
• Dokumentation skal tilrettes. https://starwiki.atlassian.net/wiki/spaces/CITY/pages/3391619122/Forretningsregler+for+afgr+nsning+af+adgang+til+borgers+persondata+i+VITAS#Forretningsreglerforafgr%C3%A6nsningafadgangtilborgerspersondataiVITAS-Pr%C3%A6sentation-af-borgers-CPR-nummer,-navn-og-adresse (tal med Tanvir i forhold til dokumentation)

Noter:

• Bemærk: Nye ordninger – det er kun ordningen fleksjob der kan flyttes mellem jobcentre.
  (Jobrotation+komp ordninger kan ikke flyttes)
• Borger er tilmeldt jobcenter A, Jobcenter A sender øremærket sag til Jobcenter B,
  Jobcenter A – tilgår sagen via Deeplink /gemt URL til sagen = får vist flg.:
  Under Ansøgning ”forklæde”= Tilhører anden kommune,
  Under Ansøgning ”fane borgeren” = IKKE vist Cpr nr eller navn (blanke felter)
  Under vurdering ”forklæde” = Tilhører anden kommune
  Under vurdering ” fanen personen der ansættes i fleksjobbet” = IKKE vist cpr nr, navn mfl. (Alle felter er blanke).
  Jobcenter B tilgår sagen, og kan se persondata, i alle ovenstående felter, samt lister.

Note* I DFDG styres borgerens tilknytningforhold til et jobcenter. Da VITAS blev udviklet udenfor Star City i tidernes morgen, har man således ikke benyttet sig af denne viden. Det betyder, at en borger, som er til samtale med jobcenter 30/5 meddeler, at borgeren flytter pr. 1/6, men først får registreret adresseændring den 2/6.  at jobcentret skal have mulighed or at flytte sagen til den nye kommune, og at den nye kommune, selvom borgeren ikke formelt er flyttet, skal kunne tilgå sagen. Vi bør overveje ny løsning med tilknytning til DFDG-data ifm. modernisering.

• FB :316987
  https://manuscript.star.dk/f/cases/edit/316987/Fleksjobvurdering-er-overf-rt-til-andet-jobcenter-men-nuv-rende-jobcenter-kan-ikke-se-personoplysninger

971.58.11 Teknisk: alle unit tests i EURES projektet skal køres i pipeline

Som STAR ønsker jeg at alle unitest bliver eksekveret sammen med et build, så udviklingsteamet får kvalitetssikret koden og derved kan fortælle om kvaliteten. udfra fejlede eller passed tests.

Som EURES pipeline er sat op i dag, er det kun tests fra test-projektet “Eures.Business.Test”, der bliver kørt under et build.

Det skulle gerne være således at pipeline dynamisk samler alle unit tests op fra alle ”.Test”-projekter og kører dem for hvert build.

Acceptkriterie:

Script er tilrettet og Unitest i alle projekter kan eksekveres under build.

* 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: Tanvir Ahmed

• Angiv dato for tjek: 12.01.2023

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