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

Indholdsfortegnelse

Afgrænsning af epic

Oversigt over berørte webservices 

Automatisk dannet oversigt 

(kun synlig for STAR)

Manuel kopieret oversigt

(også synlig for eksterne)

Beskrivelse af epic

Oversigt over sager der indgår i epic

Sager der oprindeligt er kodet i 2019-2 LAB-kodespor - og som pga. ikrafttrædelsestidspunkt for ny LAB (1.1.2020) idriftsættes med release 2019-4

Manuscript 121331 Opdatering af hovedjobcentres (xxx00) adresse m.v. via JobcenterService

JobcenterService

Som udgangspunkt findes der forretningsmæssigt kun ét hovedjobcenter og det er pr. definition jobcenter xxx01 og jobcenteret skal derfor også kun opdatere på xxx01 og eventuelle subjobcentre (xxx02-xxx99).

STAR udvider funktionaliteten bag update af det forretnngsmæssige hovedjobcenter xxx01 således, at der samtidigt også bliver opdateret på xxx00 og der udsendes WSRM på begge rettelser. Rettelsen slår igennem med det samme på xxx00-jobcenteret.

Dvs. ved en opdatering af xxx01 vil samme værdier blive skrevet til xxx00.

Input

Manuscript 134215 Jobcenterskift er ikke repræsenteret i PHS, men kun i PSS

PHS returnerer nu altid også aktuelt jobcenter.

Der er ikke foretaget datafenopretning bagudrettet (da analyse ifm GDPR-sletteprojekt tidligere har vist at DFDG ikke har egnede historiske data om jobcenter-tilknytning).

Manuscript 136994 Kontaktgr 25 kan slette jobnetprofil - og 142626 Sygemeldte danner under sygdom nyt CV

SDP-modtagere fra ledighed (KG25) skal med ny LAB have et CV.

• CV’et skal være synligt/søgbart for sagsbehandlere
• Der er ikke lovkrav om at CV skal være synligt/søgbart for arbejdsgivere, men borger skal kunne vælge at gøre det søgbart for arbejdsgiver
• Borger i KG25  og KG1 med 'Sygdom - sygemelding' skal derfor ikke kunne komme i uføre ved at slette sit CV – og må derfor ikke kunne slette sit CV

Manuscrip 143499 Ukendt ID på ActivityStatusCauseTypeIdentifier

Der indføres validering således, at der kun kan anvendes værdier i kodelisten, når der registreres en status-årsags-kode.

Ved oprettelse eller opdatering af aktivitet med ugyldig ActivityStatusCauseTypeIdentifier, kastes nu fejl 9131 (Invalid CodeListItemIdentifier). 

Herudover er værdien 0 anvendt (heller ikke en gyldig værdi).

Manuscript 142881 - Ændring af batchjobbet DFDG-TASS-HandleFromKGSDPMToKG7, som skifter kontaktgruppe fra 24 til 7, når fleksjobaktivitet ophører

DFDG-TASS-HandleFromKGSDPMToKG7 og DFDG-TASS-HandleFromKG10ToKG7-batchjobbene er ændret, så borgeren betragtes som ansat i fleksjobaktivitet til og med døgnets udløb. Hvis borgeren har en ny fleksjobansættelse med start den efterfølgende dag, ser batchjobbet nu bort fra borgeren og undlader altså at skifte kontaktgruppe fra 24 til 7.

Manuscript 143007 - The reported duration is negative, start date is greater than end date

Systemet fejler, når det prøver at håndtere et ulovligt fravær (fx id 61) for den nye KG8, når fraværet har starttidspunkt før tidligere end kontaktgruppen på datoen for start på fraværet.

Løsning: DFDG ser bort fra fraværet, da det på samme dag har en lovlig kontaktgruppe. 

Manuscript 154237 og 154822 - Redaktionelle ændringer til kodelisten AvailabilityAssessmentRegistrationTypeIdentifier

På baggrund af spørgsmål fra a-kasser om kodernes anvendelse foretages redaktionelle ændringer i id 72, 73, 75 og 76:

Manuscript 143878 - Fremtidig raskmelding - kan vi få batchjobbet til at smage på raskmeldingsårsager?

Batchjobbet DFDG_TASS_HandleEndedIllnessForSDPM gentilmelder ikke længere, når raskmeldingsårsag er:

• 12 - Tilkendt pension
• 27 - Revalideringsydelse
• 31 - Overgår til fleksjob

Ændringen er foranlediget af ønske fra KSS (case 139570), idet DFDG hidtil har gentilmeldt i disse situationer.

Manuscript 142758 - Håndtering af CPR-flytning (ændring af bopælskommune)

Problem ved CPR-flytning: I WSRM-besked er fraflytnings-jc's jc-kode sendt til fraflytnings-jc - og tillytnings-jc's jc-kode sendt til tilflytnings-jc. 

Løsning: Tilflytterjobcenterets id sendes fremover både til fraflytnings- og tilflytningsjobcenter i PersonJobcenterRegistration wsrm'erne (GetPersonJobcenterVersion4).

DFDG sender først en PersonJobcenterRegistration til det afgivende og det modtagende jobcenter ifm. opdatering af jobcenter tilhørsforhold, og derefter senere på morgnen sendes en PersonNotification til det afgivende jobcenter, hvis der er brug for at der indberettes en status for den flyttende borger (OBS - Se under beskrivelsen af TransferDataService for hvilke KG, der sendes PersonNotification beskeder).

Manuscript 153861 - Nye målgrupper med pligt til selvbook bliver vist som fritaget for selvbook

PersonExemptTypeIdentifier id 2. Fritagelsen skal omdøbes til

• Navn: "Selvbook med risiko for automatisk afmelding" 
• Beskrivelse: "Borger kan ikke automatisk afmeldes pba. manglende selvbook". 

På den måde afspejler det den markante fritagelseseffekt, der p.t. eksisterer vedrørende selvbooking (for a-dagpengemodtagere).

Manuscript 153623 - Skift fra KG 24 ved raskmelding

Problem: Ved raskmelding fra KG24 (af personer, der var fleksjobansat), blev borger ikke returneret til at være KG10 (fleksjobansat), men i stedet KG7 (leidig fleksjobvisiteret).

Løsning: Den logik i DFDG, som håndterer raskmelding og kontaktgruppeskift fra 24 til 10, blev ikke eksekveret ved kald af JobnetIllnessService fra Jobnet. Vi har indført logikken i JobnetIllnessService.

Manuscript 142245 - Ændringsønske: fravær med 6 uger til arbejde, barsel, pension m.v - så bør man kunne afmelde 6 uger før

På baggrund af ønske fra jobcentre ønskes der mulighed for at registrere fremtidig afmelding samtidig med, at der registreres mindre intensiv indsats således, at registreringen kan ske i én arbejdsgang. I dag kan fremtidig afmelding max ske 30 dage frem i tid.

Der er derfor tilføjet mulighed for registrering af fremtidig afmelding op til 60 dage før for visse fraværstyper (mindre intensiv indsats - AbsenceIdentifier 43, 44, 45, 46, 71, 72, 73), der overlapper med afmeldedato).Dermed vil flere fremtidige afmeldinger kunne registreres  af sagsbehandlere samtidig med, at der registreres fravær vedrørende mindre intensiv indsats.

Borgeren vil endvidere fra Jobnet kun foretage fremtidig afmelding op til 60 dage, hvis  sagsbehandler forinden er registreret en af ovennævnte fraværstyper vedrørende mindre intensiv indsats, der overlapper med afmeldedato.

925.4.2 Som STAR ønsker jeg at orientere brugerne (sagsbehandler-bruger) om hvilke oplysningstyper, der behandles om den enkelte bruger

Det ønskes tilføjet under Vis brugerprofil i AMP, hvilke oplysningstyper STAR behandler om de enkelte brugere. Teksten ønskes vist uanset hvilken organisationstype (fx STAR, jobcenter, kommune, a-kasse) som brugeren tilhører.

Teksten kan tilføjes den eksisterende grå højre-spalte:

Følgende tekst tilføjes:

Således ser det ud efter tilføjelse (fra T2 - 20194):

Overvej for hvert acceptkriterie hvilke systemer der berøres af ændringen:

• DFDG
  • Services
  • WSRMer
  • Kodelister
  • PersonStatusService (PSS)
  • PersonHistoryService (PHS)
  • LSS (Landssupportsystem) og herunder Registerudtræk (hvis STAR har dataejerskab og der er lavet PHS på domænet)
• Jobnet
• VITAS
• JobKon
• JobAG
• BI integrationsplatform
• Alle områder
  • Nye batchjobs
    • Dokumentation af jobbet til SF (jf. skabelon: xxx link til skabelon) 
  • Dataløft
    • Hvis der i Databaser tilføjes eller fjernes kolonner med personfølsomme data (f.eks. person navne, adresser, email, telefonumre etc.), så skal SF informeres så disse data fremadrettet tilføjes eller fjernes fra scrambling.
• Kommunalt sagsbehandlingssystem
• A-kasse sagsbehandlingssystem
• Kommunalt bookingsystem
  • JobcenterPlanner (JCP)
  • WorkForcePlanner (WFP)
• Kommunalt ydelsessystem

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.